97 этюдов для программистов. Опыт ведущих экспертов

• Снижается роль «фактора грузовика». Вот слегка пугающий мысленный эксперимент: сколько членов вашей команды должно попасть под грузовик, чтобы стал невозможным выпуск конечного продукта? Иными словами, насколько выпуск вашего конечного продукта зависит от определенных участников команды? Являются ли знания привилегией или находятся в общем доступе? Если вы осуществляете ротацию задач между парами, всегда найдется кто-то еще, обладающий знаниями, необходимыми для завершения работы. На состояние потока вашей команды «фактор грузовика» не повлияет.

• Эффективно решаются проблемы. Если вы программируете в паре и сталкиваетесь со сложной проблемой, вам всегда есть с кем ее обсудить. В таком диалоге варианты решения найдутся скорее, чем если вы будете биться над проблемой в одиночестве. В результате ротации задач внутри команды ваше решение будет повторно рассмотрено и критически оценено следующей парой, поэтому не столь важно, если ваше первоначальное решение окажется неоптимальным.

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

• Можно безболезненно прерываться. Если кто-то подошел к вам с вопросом, или звонит телефон, или нужно срочно ответить на письмо, или нужно принять участие в совещании, ваш партнер по парному программированию может продолжить работу над кодом. Когда вы вернетесь, ваш напарник все еще будет в состоянии потока, и вы сможете быстро наверстать упущенное и присоединиться к нему.

• Новые участники команды быстро вливаются в проект. Если в команде применяется парное программирование и правильно организована ротация пар и задач, новички быстро знакомятся как с кодом, так и с другими членами команды.

Поток дает невероятную продуктивность. Но это состояние легко утратить. Старайтесь всеми силами войти в рабочий поток, а затем, когда это получилось, удерживайтесь в нем!

Предпочитайте примитивам предметно-ориентированные типы данных

Эйнар Ландре

23 сентября 1999 года

космический аппарат Mars Climate Orbiter стоимостью 327,6 миллионов долларов потерялся при выходе на орбиту Марса из-за программной ошибки на Земле. Ошибку впоследствии окрестили смешением единиц измерений (metric mix-up). Программное обеспечение наземной станции производило расчеты в фунтах силы, а космический аппарат ожидал указаний в ньютонах,[22] в результате чего наземная станция недооценила мощность ускорителей аппарата в 4,45 раза.

Это один из многих примеров отказов программного обеспечения, которых можно было избежать благодаря более строгой и предметно-ориентированной типизации. Это также наглядная демонстрация назначения многих возможностей языка Ada, спроектированного преимущественно для создания встраиваемого отказоустойчивого программного обеспечения. В Ada применяется строгая типизация со статической проверкой как примитивных, так и определенных пользователем типов:

type Velocity_In_Knots is new Float range 0.0.. 500.00;

type Distance_In_Nautical_Miles is new Float range 0.0.. 3000.00;

Velocity: Velocity_In_Knots;

Distance: Distance_In_Nautical_Miles;

Some_Number: Float;

Some_Number:= Distance + Velocity; — Компилятор отловит здесь ошибочное использование типов.

Разработчики приложений, сбои в которых менее критичны, также могут выиграть от более широкого применения предметно-ориентированной типизации. Предметно-ориентированные типы можно использовать вместо имеющихся в языках программирования и библиотеках базовых типов данных, таких как строки и числа с плавающей запятой. В Java, C++, Python и других современных языках абстрактный тип данных известен как class. Применение таких классов, как Velocity_In_Knots (скорость в узлах) и Distance_In_Nautical_Miles (расстояние в морских милях) значительно повышает качество кода:

• Такой код легче читать, поскольку он выражает понятия предметной области, а не просто описывает строки (String) или действительные числа (Float).

• Такой код легче тестировать, потому что он инкапсулирует поведение, которое легко проверить.