Если состояние некорректно, значит, в коде ошибка, и вы рискуете потерять данные, если не прервете выполнение. Если вам кажется, что проверки состояний замусоривают код, научитесь скрывать их с помощью специальных инструментов, генерации кода, вплетений (weaving) или аспектов. Независимо от того, какой метод вы выберете, подход на основе состояний сделает ваш код более простым и надежным.
Одна голова хорошо, но две — часто лучшеЭдриан Уайбл
Программирование требует вдумчивости, а вдумчивость может существовать только в уединении. Такой стереотип присущ многим программистам.
Но стиль «одинокого волка» в программировании уже давно отступает перед командным подходом, который, смею утверждать, улучшает качество работы, повышает производительность и позволяет разработчикам получать большее удовольствие от работы. Новый подход заставляет разработчиков работать друг с другом теснее, а также работать с теми, кто не участвует в разработке, — системными и бизнес-аналитиками, специалистами в области контроля качества и пользователями.
Что это означает для разработчиков? Уже недостаточно быть экспертом в области технологии программирования. Вы должны научиться эффективно работать с другими людьми.
Сотрудничество на работе — это не игра в вопросы и ответы и не долгие совещания. Сотрудничество — это засучить рукава вдвоем с коллегой и приступить к трудной задаче.
Я большой поклонник парного программирования. Можно назвать это «экстремальным сотрудничеством». Когда я работаю в паре, мое мастерство программиста растет. Если я слабее своего партнера в предметной области или в какой-либо технологии, то просто учусь на его опыте. Когда я сильнее в каком-то аспекте, то начинаю лучше понимать, что я знаю и чего не знаю, поскольку мне приходится давать объяснения. В любом случае мы оба вносим свой вклад и учимся друг у друга.
Работая в паре, мы привносим свой коллективный опыт — как опыт в предметной области, так и технический — для решения стоящей перед нами задачи. Вместе мы способны предложить свое уникальное видение и опыт, что позволяет нам решать задачи эффективно и рационально. Даже при наличии значительной разницы в уровне знаний предметной области или в технологических вопросах, более опытный партнер все равно чему-то учится у второго — ну, скажем, узнаёт о новых «горячих клавишах» либо встречается с новым инструментом или библиотекой. Для менее опытного партнера такая работа — замечательный способ «набрать скорость».
Парное программирование популярно у сторонников гибкой разработки, хотя и не только у них. Иногда противники парной работы интересуются: «А почему я должен платить двум программистам за выполнение работы одного?» Конечно, не должны. Но дело в том, что работа в паре повышает качество, улучшает понимание предметной области, технологий и приемов работы (скажем, неочевидных приемов работы с интегрированной средой разработки, IDE), а также уменьшает отрицательное влияние лотерейного риска (когда один из ваших специалистов-разработчиков выигрывает в лотерею и увольняется на следующий же день).
Какова долгосрочная выгода от того, что вы узнаете о новой «горячей клавише»? Какой мерой мы измерим улучшение качества продукта, достигнутое работой в паре? Какой мерой измерить пользу от того, что ваш партнер не дал вам зайти в тупик в решении сложной проблемы? Одно исследование свидетельствует о приросте эффективности и скорости на 40 %.[29] А как оценить уменьшение «лотерейного риска»? Большинство плюсов работы в паре трудно измерить.
Кто должен работать в паре и с кем? Если вы новичок в команде, то важно, чтобы вашим напарником оказался опытный специалист. Столь же важно, чтобы он обладал хорошими навыками общения и наставничества. Если у вас недостаточно знаний в предметной области, работайте в паре с тем, кто ее хорошо знает.
Если нет уверенности, экспериментируйте: сотрудничайте с коллегами. Создавайте пары для решения интересных сложных проблем. Посмотрите, что у вас получится. Попробуйте несколько раз.
Две ошибки могут гасить одна другую (и тогда их трудно исправлять)Аллан Келли
Код никогда не лжет, но может быть внутренне противоречивым. Иногда противоречия вызывают недоумение: как это вообще может работать?
В своем интервью[30] Аллан Клампп (Allan Klumpp), ведущий разработчик программного обеспечения для лунного модуля Apollo, раскрыл тот факт, что ПО управления двигателями содержало дефект, из-за которого спускаемый модуль должен был вести себя неустойчиво. Однако в программе была еще одна ошибка, компенсировавшая первую, и при посадке Apollo 11 и 12 на Луну это ПО успешно использовалось, прежде чем ошибки были обнаружены и исправлены.
Рассмотрим функцию, которая возвращает код завершения. Допустим, она возвращает false, когда должна была бы вернуть true. Теперь представим, что в вызывающей функции не реализована проверка возвращаемого значения. Все работает прекрасно, пока однажды кто-то не обнаружит отсутствие проверки и не вставит ее.
Или рассмотрим приложение, которое хранит состояние в виде документа XML. Допустим, что один из узлов некорректно записывается как TimeToLive (время жизни) вместо TimeToDie (время смерти), как следовало бы, если верить документации. Все будет хорошо, пока код записи и код чтения содержат одну и ту же ошибку. Но исправьте ее в одном месте или добавьте новое приложение, читающее тот же документ, и симметрия рухнет, как и весь код.
Когда в коде два дефекта, а отказ на вид только один, может стать бесполезным сам методический подход к исправлению ошибок. Получив сообщение об ошибке, разработчик обнаруживает дефект, исправляет его и проводит тестирование. Возникает тот же самый отказ, но уже в силу действия второго дефекта. Тогда отменяется первое исправление, код снова исследуется, и обнаруживается второй дефект, который и исправляется. Но первый дефект снова на месте, снова возникает тот же отказ, и тогда откатывается второе исправление. Процесс повторяется, но теперь разработчик отказался от двух исправлений и пытается найти третье, чего ему никогда не удастся.
Взаимодействие двух дефектов в коде, проявляющих себя одинаковым сбоем, не только затрудняет решение проблемы, но и заводит разработчиков в тупик, где они обнаруживают, что их ранние решения проблемы были правильными.
Такое случается не только с кодом: проблемы встречаются в документах, содержащих технические требования. И они способны распространяться, подобно вирусу, из одного места в другое. Ошибка в коде компенсирует ошибку в письменной спецификации.
Вирус может поразить и человека: пользователи обнаруживают, что когда программа говорит «левая», она имеет в виду «правая», и подстраивают под нее свои действия. Они даже сообщают о проблеме новым пользователям: «Запомни, когда приложение говорит, что нужно щелкнуть левой кнопкой, это значит, что нужно щелкнуть правой». Стоит исправить ошибку, и пользователям придется переучиваться.
Одиночные ошибки, как правило, легко обнаруживаются и исправляются. Проблемы возникают в случае множества ошибок, требующих множества исправлений. Частично это вызвано тем, что простые проблемы легко исправлять, и потому их обычно не откладывают, а более сложные проблемы копятся до лучших времен.
Нет простого ответа на вопрос, как решать проблемы, возникающие в связи с родственными дефектами. Нужно помнить об их существовании, иметь ясную голову и готовность при необходимости рассмотреть все возможности.
Написание кода в духе Убунту для друзейАслам Хан
Очень часто мы программируем в изоляции, и наши программы отражают как нашу личную интерпретацию проблемы, так и очень личное ее решение. Мы можем работать в команде, но и тогда мы изолированы как команда. Мы легко забываем, что код, созданный в такой изоляции, будут выполнять, использовать и расширять другие люди. Легко упустить из вида социальную сторону программирования. Создание программ — одновременно и техническое, и социальное занятие. Нам следует чаще оглядываться вокруг, чтобы понять, что мы работаем не изолированно и что мы несем общую ответственность за возможный успех не только группы разработчиков, но и каждого человека вокруг нас.
Можно написать код высокого качества в отрыве от реальности, полностью уйдя в себя. С одной стороны, это эгоцентричный подход (эго не в смысле высокомерия, а в смысле личности). Это философия Дзен, и в момент создания программы в этом случае действительно существуете только вы. Я всегда стараюсь жить в текущем моменте, поскольку это помогает приблизиться к лучшему качеству, но при этом я живу в своем текущем моменте. А как же быть с текущим моментом моей команды? Мой момент и момент моей команды — совпадают ли они?
На языке зулу философия Убунту определяется как «Умунту нгумунту нгабанту», что в первом приближении можно перевести так: «Личность — это личность через (другие) личности». Я становлюсь лучше, поскольку ты делаешь меня лучше своими добрыми поступками. Но, с другой стороны, вы хуже делаете свое дело, если я плохо делаю свое. Для разработчиков это сводится к тому, что «разработчик — это разработчик через (других) разработчиков». Если опуститься до «железа», то «код — это код через (другой) код».
Качество кода, который пишу я, влияет на качество кода, который пишете вы. А что если мой код низкого качества? Даже если вы напишете очень чистый код, там, где вы будете пользоваться моим кодом, качество вашего кода упадет примерно до уровня моего кода. Можно применять множество шаблонов и приемов, чтобы ограничить ущерб, но полностью от него уже не избавиться. Я заставил вас делать больше, чем требовалось, просто потому, что не думал о вас, когда жил в своем моменте.