Гибкие методологии вернули программированию центральную роль в разработке программного обеспечения. Важная часть этой философии — признание исходного кода главным источником документации о работающей системе.

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

Однако только исходный код обладает достаточной точностью и полнотой, чтобы достоверно описать реальное поведение системы. Эту мысль убедительно сформулировал Джек Ривз в эссе «Что есть проектирование программного обеспечения»: проект программного обеспечения — это и есть его исходный код.

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

Почему код бывает сложно читать

Главная причина запутанного кода — отсутствие фокуса на читателе. Если разработчик не ставит перед собой цель написать понятный текст, ясность не появится сама собой. В университетах и на курсах студентов часто учат заставлять программу работать, но редко объясняют, как сделать ее понятной для других людей.

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

Как развивать навык читаемого кода

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

• Регулярное код-ревью. Обсуждайте не только баги и производительность, но и прозрачность замысла.
• Парное программирование. Дает мгновенную реакцию второго разработчика на структуру и имена в процессе написания.
• Изучение классической литературы. Принципы чистоты кода подробно разобраны в книгах «Совершенный код» Стива Макконнелла и «Рефакторинг».

Кодовая база принадлежит команде

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

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