Кофе-брейк #13: Что должен знать каждый новичок в программировании; 4 способа включить дизайнерское мышление в процесс разработки

О чем должен знать каждый новичок в программировании

Источник: Stackoverflow Как разработчик, вы услышите много разных теорий о том, как должен выглядеть код. Некоторые считают, что чем меньше строчек кода в приложении, тем легче его читать. Но это лишь частично верно. Я предпочитаю оценивать качество кода по следующим критериям:

1. Код должен быть последовательным, информативным, хорошо документированным.
2. Код должен использовать стабильные современные функции.
3. Код не должен быть излишне сложным или неработоспособным.

Если вы решили сократить количество строк кода в ущерб одному из вышеперечисленных критериев, это станет проблемой. Не делайте этого.

Читать чужой код сложно

Действительно, соотношение времени, потраченного на чтение и написание кода, составляет более 10 к 1. Но без чтения чужого кода не обойтись. Вам придется читать чужой код. И чем раньше вы улучшите свои навыки, тем лучше. Попробуйте изучать чужой код по открытым репозиториям GitHub. Можно практиковаться в любое время: просто найдите подходящий вам проект и вникайте в каждую строчку. Еще один способ, который поможет улучшить чтение чужого кода, состоит в том, чтобы вы начали копировать стиль. Когда вы пишете код в чужом стиле, это не только улучшает навыки чтения, но и делаете код более привычным для вас. Попробуйте.

Вы никогда не будете писать «идеальный» код

Я четыре года был разработчиком-одиночкой, прежде чем начал работать в команде. Большую часть этого времени я считал, что любой опытный программист пишет идеальный код. По моему мнению, научиться писать идеальный код — это только вопрос времени и усилий. Но когда я присоединился к команде, стало ясно, что никто не пишет «идеальный» код. Правда, код, который в конечном итоге включался в систему, почти всегда был «идеальным». Почему так получалось? Все дело в анализе кода. Я работаю с командой действительно блестящих инженеров. Это одни из самых компетентных, уверенных в себе программистов, которых можно нанять за деньги. Но у каждого из них (включая меня) началась бы настоящая паническая атака, если бы кто-то когда-либо предложил включить в приложение непроверенный код. Даже если вы думаете, что вы следующий Билл Гейтс, вы будете делать ошибки. Я даже не говорю про логические ошибки, я говорю про опечатки, пропущенные символы. Вещи, которые ваш мозг иногда просто не улавливает. Вещи, которые можно заметить только свежим взглядом. Стремитесь работать с теми, кто внимателен к деталям и готов критиковать вашу работу. Поначалу будет тяжело воспринимать критику, но это единственный надежный способ улучшить качество кода. Делайте все возможное, чтобы не защищаться во время проверки кода, и никогда не воспринимайте критику лично. Вы — это не ваш код.

Вы не должны писать код 8 часов в день

Никто вам точно не скажет, сколько времени в день он тратит на написание кода. Но на самом деле мало кто пишет код более 4 часов в день. Люди, которые не согласны с этим, являются либо исключением из правил, либо работают в компаниях, которые плохо относятся к своему персоналу. Программирование — напряженная, психически истощающая работа. Совершенно неправильно думать, что кто-то будет писать код по 8 часов в день, 5 дней в неделю. Будут редкие случаи, когда вам нужно уложиться в дедлайн, но когда я говорю «редко», я имею в виду почти никогда. Не допускайте, чтобы работа тяготила вас и заставляла работать сверхурочно. Я не предлагаю вам работать только четыре часа в день. Остальные четыре часа обычно лучше всего тратить на такие вещи, как:

• изучение новых инструментов, функций, приложений;
• обсуждение рабочих процессов с коллегами;
• помощь коллегам, у которых возникли трудности в работе;
• планирование задач;
• анализ кода;
• деловые собрания/встречи.

Я также настоятельно рекомендую делать регулярные перерывы в течение дня и делать физические упражнения (хотя бы немного). Положительное влияние упражнений давно доказано.

4 способа включить дизайнерское мышление в процесс разработки

Источник Tech Beacon Чтобы создать продукт, отвечающий потребностям ваших клиентов, вам придется учитывать их желания. Если вы написали приложение с запутанной навигацией или с излишне долгой загрузкой интерфейса, готовьтесь к будущей неудаче. Будучи программистом, возможно, вам придется глубже вникнуть в дизайн продукта, над которым работает ваша команда. Такое сотрудничество очень полезно, поскольку каждый подмечает то, на что другой может не обратить внимание. Я предлагаю вам 4 совета, как разработчик и дизайнер могут работать вместе.

1. Включайтесь в процесс с самого начала

Не стоит полагать, что дизайн всегда стоит на первом месте, а разработка — на втором. Может это и правда, но это не значит, что разработчики не должны участвовать в процессе проектирования. Программист способен предоставить важную техническую информацию о том, как проект может быть реализован, в то время как дизайнеры лучше понимают желания пользователей. Лучше как можно раньше выяснить, какая функция технически невозможна или не удовлетворяет пользовательским требованиям. Если дизайнеры и разработчики работают вместе, проблемы можно обнаружить и решить сразу же, а не после утверждения проекта. Многие компании применяют совместный подход к разработке софта. Это означает, что участники команды отвечают не только за свой этап или часть кода, а берут на себя коллективную ответственность за все: от проектирования до тестирования.

2. Изучите процесс UX

Тот, кто не знаком с UX (пользовательский опыт), может не понять, почему команды меняют дизайн снова и снова ради, как может показаться, незначительных деталей. Каждый шаг в процессе UX происходит по одной причине: чтобы предоставить пользователю наилучшие возможности. Поэтому важно с самого начала уделить внимание созданию UX-процесса. Он может включать в себя:

• исследование цели проекта;
• создание каркаса — простого дизайна, позволяющего определить основные характеристики продукта;
• внесение в дизайн проекта более тонких деталей, таких как пользовательский интерфейс;
• тестирование дизайна пользователями. Пожалуй, это самый важный этап UX-разработки. Это дает ценную информацию о продукте, прежде чем вы потратите время на разработку;
• итерация: используя анализ результатов тестирования, итерируйте проект, чтобы улучшить взаимодействие с пользователем.

Команды повторяют этапы проектирования и тестирования несколько раз, пока не останется никаких изменений, или пока это позволяет время. Обычно это означает, что у вас будет несколько версий дизайна.

3. Следите за разработкой дизайна

Очень плохо, когда дизайнеры создают проект, не советуясь с разработчиками. Это контрпродуктивно. Для DevOps важно установить правила, чтобы у разработчиков был доступ к эскизам проекта в легкодоступных форматах, таких как PNG или PDF. Эффективное сотрудничество между разработчиками и дизайнерами имеет решающее значение для успешной реализации приложения. Любой ценой избегайте слепой передачи готового дизайна. Ошибку лучше исправить на начальном этапе, а не в конце.

4. Согласуйте, на каком этапе вам покажут проект

Когда разработчиков просят создать минимально жизнеспособную версию продукта (MVP), они с самого начала должны знать требования к окончательной версии. Это необходимо чтобы избежать проблем с неоправданными ожиданиями. Дизайнеры должны показать разработчику обе версии дизайна: как для MVP, так и для окончательного варианта. Это поможет реализовать MVP с учетом того, что заказчик ожидает увидеть в финальной версии. Работая вместе, дизайнеры и разработчики получают множество преимуществ. Каждый из них обладает знаниями, которые можно применить к опыту другого. Разработчики могут предоставить ценную информацию о том, какие функции невозможно реализовать в дизайне. С другой стороны, сотрудничество с программистом избавит дизайнера от необходимости переделки проекта, что, соответственно, сэкономит время всей команде.