97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф
Если в сценариях сборки используются неверные идиомы, такие сценарии тяжело сопровождать и, что хуже, тяжело улучшать. Стоит потратить некоторое время, чтобы разобраться, как правильно вносить изменения. Если приложение собирается с неверными версиями зависимых библиотек или во время сборки заданы неверные параметры конфигурации, это может вызвать ошибки в самом приложении.
Традиционно тестирование всегда возлагалось на группу контроля качества. Сейчас мы понимаем, что тестирование в процессе написания кода — необходимое условие для получения предсказуемого результата. Аналогично и владельцем процесса сборки должна быть команда разработчиков.
Понимание процесса сборки может упростить весь жизненный цикл разработки и сократить издержки. Если процесс сборки легко осмыслить и применить, это дает возможность новому разработчику быстро и легко включиться в работу. Если конфигурацию приложения автоматизировать в рамках процесса сборки, это поможет гарантировать получение одинаковых результатов, когда над проектом работает несколько человек, и избежать реплик в духе «А у меня все работает». Многие инструменты сборки генерируют отчеты о качестве кода, заблаговременно вскрывающие потенциальные проблемы. Потратив время и научившись самостоятельно управлять процессом сборки, вы облегчите жизнь себе и всем остальным участникам вашей команды. Вы сможете сосредоточиться на разработке новой функциональности, что принесет пользу клиентам и сделает вашу работу более приятной.
Изучите процесс сборки достаточно хорошо, чтобы знать, когда и как изменять его. Сценарии сборки — это тоже код. Они слишком важны, чтобы доверить их кому-то другому, хотя бы по той причине, что приложение не закончено, пока оно не собрано. Задача программирования не завершена, пока мы не поставили работающее приложение пользователю.
Программируйте парами и входите в поток
Гудни Хаукнес, Кари Россланд и Анн Кэтрин Гэгнат
Представьте себе, что вы совершенно поглощены своей работой: сосредоточены, увлечены и заняты. Вы потеряли счет времени. Вы счастливы. Вы в состоянии потока. В масштабах всей команды разработчиков трудно достичь и поддерживать состояние потока из-за многочисленных помех, отвлечений и прочих препятствий, которые легко могут его нарушить.
Если вы уже участвовали в парном программировании, то, вероятно, знаете, как оно способствует достижению состояния потока. Если нет, то мы хотим поделиться своим опытом, чтобы побудить вас заняться парным программированием немедленно! Чтобы парное программирование было успешным, требуются некоторые усилия со стороны отдельных участников команды и всей команды в целом.
Будучи частью команды, проявляйте терпение по отношению к менее опытным разработчикам. Преодолейте свой страх перед более опытными разработчиками. Осознайте, что все люди разные, и научитесь это ценить. Помните о сильных и слабых качествах — как своих, так и других членов команды. Вас может удивить, сколь многому способны научить коллеги.
Применяйте парное программирование для распространения навыков и знаний среди всех участников проекта. Задачи нужно решать парами и часто производить ротацию участников пар и выполняемых каждой парой задач. Сообща установите правило для такой ротации. Если нужно, откажитесь от этого правила или подправьте его. Наш опыт показывает, что не обязательно доводить задачу до конца, прежде чем передать ее следующей паре. Может показаться, будто это неразумно, однако на практике мы обнаружили, что это эффективно.
Существует множество ситуаций, когда состояние потока может быть нарушено, но парное программирование позволяет его сохранить:
• Снижается роль «фактора грузовика». Вот слегка пугающий мысленный эксперимент: сколько членов вашей команды должно попасть под грузовик, чтобы стал невозможным выпуск конечного продукта? Иными словами, насколько выпуск вашего конечного продукта зависит от определенных участников команды? Являются ли знания привилегией или находятся в общем доступе? Если вы осуществляете ротацию задач между парами, всегда найдется кто-то еще, обладающий знаниями, необходимыми для завершения работы. На состояние потока вашей команды «фактор грузовика» не повлияет.
• Эффективно решаются проблемы. Если вы программируете в паре и сталкиваетесь со сложной проблемой, вам всегда есть с кем ее обсудить. В таком диалоге варианты решения найдутся скорее, чем если вы будете биться над проблемой в одиночестве. В результате ротации задач внутри команды ваше решение будет повторно рассмотрено и критически оценено следующей парой, поэтому не столь важно, если ваше первоначальное решение окажется неоптимальным.
• Плавно проходит интеграция. Если ваша текущая задача требует обращения к другому фрагменту кода, можно надеяться, что названия методов, документы и тесты достаточно содержательны, чтобы получить представление о том, что этот код делает. Если это не так, то, работая в паре с автором этого фрагмента кода, вы сможете лучше понять и быстрее интегрировать его в свой код. Кроме того, в процессе обсуждения вы получите возможность улучшить именование, документацию и способы тестирования.
• Можно безболезненно прерываться. Если кто-то подошел к вам с вопросом, или звонит телефон, или нужно срочно ответить на письмо, или нужно принять участие в совещании, ваш партнер по парному программированию может продолжить работу над кодом. Когда вы вернетесь, ваш напарник все еще будет в состоянии потока, и вы сможете быстро наверстать упущенное и присоединиться к нему.
• Новые участники команды быстро вливаются в проект. Если в команде применяется парное программирование и правильно организована ротация пар и задач, новички быстро знакомятся как с кодом, так и с другими членами команды.
Поток дает невероятную продуктивность. Но это состояние легко утратить. Старайтесь всеми силами войти в рабочий поток, а затем, когда это получилось, удерживайтесь в нем!
Предпочитайте примитивам предметно-ориентированные типы данных
Эйнар Ландре
23 сентября 1999 года космический аппарат Mars Climate Orbiter стоимостью 327,6 миллионов долларов потерялся при выходе на орбиту Марса из-за программной ошибки на Земле. Ошибку впоследствии окрестили смешением единиц измерений (metric mix-up). Программное обеспечение наземной станции производило расчеты в фунтах силы, а космический аппарат ожидал указаний в ньютонах,[22] в результате чего наземная станция недооценила мощность ускорителей аппарата в 4,45 раза.
Это один из многих примеров отказов программного обеспечения, которых можно было избежать благодаря более строгой и предметно-ориентированной типизации. Это также наглядная демонстрация назначения
