если я работаю с кодом существующего проекта и не знаю, где могут использоваться различные его части, я гораздо осторожнее подхожу к совместному использованию кода.

Осторожнее с общим кодом. Изучите контекст. И лишь затем действуйте.

Правило бойскаута

Роберт Мартин, известный также как «Дядюшка Боб»

У бойскаутов есть правило: «Оставь после себя лагерь чище, чем он был, когда ты пришел». Если на земле валяется мусор, ты убираешь его, даже если намусорили другие. Ты намеренно улучшаешь условия существования для следующей группы, которая придет в лагерь. (А исходно это правило, установленное основателем скаутского движения Робертом Стивенсоном Смитом Бейден-Пауэллом, звучало так: «Постарайся, чтобы этот мир стал лучше, чем до того, как ты в него пришел».)

Представьте, что мы следуем похожему правилу для нашего кода: «Всегда сохраняй модуль в репозиторий в лучшем состоянии, чем он был, когда ты его оттуда загрузил». Кто бы ни написал этот модуль изначально, что если потратить хоть немного сил, чтобы улучшить его? К чему это может привести?

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

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

Честно говоря, мне кажется, что это обычные правила приличия — как мыть руки после туалета или выбрасывать мусор в мусорное ведро, а не на пол. Скажем прямо, оставлять беспорядок в коде должно быть столь же социально неприемлемо, как сорить на улице. Такого попросту не следует делать.

Здесь скрыто больше, чем кажется. Одно дело — следить за порядком в собственном коде, и совсем другое — следить за порядком в коде всей команды. Команды помогают одна другой и подчищают код одна за другой. Каждая следует правилу бойскаута, потому что оно приносит пользу всем, а не только одной конкретной команде.

Прежде чем пенять на других, проверь собственный код

Аллан Келли

Разработчику — любому из нас! — часто бывает трудно признать, что его код не работает. Это кажется настолько неправдоподобным, что мы скорее готовы допустить наличие ошибки в компиляторе.

В действительности, очень и очень редко код оказывается неработоспособным из-за ошибки в компиляторе, интерпретаторе, операционной системе, сервере приложений, базе данных, менеджере памяти или любом другом элементе системного программного обеспечения. Да, там встречаются ошибки, но гораздо реже, чем нам хотелось бы думать.

Однажды я действительно столкнулся с ошибкой в компиляторе (удаление переменной цикла при оптимизации), но во всех остальных случаях мои претензии к компилятору или операционной системе оказывались беспочвенными. Я тратил массу своего времени, времени службы поддержки и времени начальства, а в результате оказывался в неловком положении, когда обнаруживалось, что ошибка — моя собственная.

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

Учитывая, насколько редки ошибки в компиляторах, гораздо выгоднее тратить время и силы на поиск ошибок в собственном коде, а не пытаться доказать, что компилятор ошибается. Тут действуют все обычные соображения по отладке: изолировать проблему, поставить заглушки вместо вызовов, окружить проблемный участок проверками; проверить выполнение соглашений по вызовам, общие библиотеки и номера версий; описать проблему коллеге; выяснить, не поврежден ли стек, и установить соответствие типов переменных; попробовать выполнить код на разных компьютерах и в разных конфигурациях сборки, например отладочной и окончательной (release).

Подвергайте сомнению собственные допущения и допущения других людей. Допущения в основе работы инструментов разных производителей могут не совпадать; то же верно и для разных инструментов одного и того же производителя.

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

Моя личная система такова: если я не могу обнаружить ошибку и начинаю грешить на компилятор, пришло время проверить целостность стека. Это особенно полезно, когда при добавлении кода трассировки локализация проблемы меняется.

Многопоточность — еще один источник ошибок, из-за которых программисты начинают орать на компьютер и раньше срока седеют. Все советы писать простой код многократно увеличиваются в цене для многопоточных систем. При поиске таких ошибок трудно системно полагаться на отладку и модульное тестирование, поэтому простота конструкции приобретает первостепенное значение.

Итак, прежде чем забрасывать обвинениями компилятор, вспомните совет Шерлока Холмса — «Если исключить все невозможное, то, что останется, и будет истиной, какой бы неправдоподобной она ни казалась» — и следуйте ему, а не совету Дирка Джентли:[5] «Если исключить все неправдоподобное, то, что останется, и будет истиной, какой бы невозможной она ни казалась».

Тщательно выбирайте инструменты

Джованни Аспрони

Современные приложения крайне редко создают «с чистого листа». Их собирают из уже существующих кубиков — компонентов, библиотек и фреймворков, и тому есть ряд веских причин:

• Объемы, сложность и изощренность приложений растут, а времени на их создание отводится все меньше. Выгоднее тратить время и интеллект разработчиков на код бизнес-логики, чем на код инфраструктуры приложения.

• В широко используемых компонентах и фреймворках меньше шансов столкнуться с ошибками, чем в разработанных самостоятельно.

• Высококачественный инструментарий доступен бесплатно в сети Интернет, благодаря чему снижаются затраты на разработку и упрощается поиск заинтересованных разработчиков с нужным опытом.

• Создание и сопровождение программного обеспечения