В современном мире разработки программного обеспечения существует широко известное утверждение — код читается гораздо чаще, чем пишется. Однако эта точка зрения не передает всей картины. Более точно будет сказать, что код зачастую просматривают, а не читают подробно. Эта особенность существенно влияет на подход к написанию программного обеспечения и задаёт новые требования к его качеству и структуре. При разработке и сопровождении программного обеспечения программный код служит основным источником информации для разработчиков, которые в нем работаюют.
Несмотря на то, что создание новой функциональности требует написания новых строк кода, основное время тратится именно на чтение, понимание и изменение уже существующего кода. Это связано с необходимостью исправления ошибок, добавления новых возможностей и улучшения архитектуры проекта. И при этом с каждым новым обращением разработчику приходится в кратчайшие сроки ориентироваться в ранее написанном, чтобы внести корректные и безопасные изменения. Очень важно понимать, что не только автор кода сталкивается с его повторным чтением. В командной работе над проектом различные программисты, возможно, с разным опытом и приоритетами, также вынуждены обращаться к одному и тому же коду.
Они работают в иных условиях и подчас с другими целями, поэтому им необходимо уметь быстро ориентироваться в чужом коде и максимально облегчить процесс его быстрого восприятия. В реальности детальное прочтение и разбор каждой строки кода происходит лишь в очень немногих случаях. Чаще всего программист быстро просматривает код, пытаясь схватить общий смысл и определить, что именно в нем происходит. Это помогает четко и быстро понять основные задачи и структуры, а затем при необходимости погрузиться в детали. Фраза "код просматривается чаще, чем читается" лучше отражает реальный процесс взаимодействия с программной базой.
Как же сделать код таким, чтобы его можно было читать "с первого взгляда"? Ответ кроется в том, чтобы уделять особое внимание форме и структуре кода, чтобы она давала мгновенное представление о том, что он делает. Нужно стремиться к тому, чтобы связанный по логике код выглядел связанным визуально, а не относящийся к теме — отчетливо отделялся. Визуальная организация не является разменной монетой качества, но она существенно облегчает работу с кодом. Одним из главных препятствий для быстрого восприятия кода является чрезмерная детализация и многословность. Слишком длинные и запутанные имена переменных, методов или классов, особенно если они неуместны, затрудняют отслеживание основных идей.
Хотя важна достоверность и ясность, чрезмерная «бравада» с использованием громоздких названий может излишне загромождать код и разрушать его естественный ритм. Для примера рассмотрим выражение, реализованное с применением Java BigDecimal. Использование методов, таких как multiply(), pow(), plus(), в комбинации создает сложное для восприятия пространство, требующее вдумчивого сканирования для понимания математической формулы. Когда же применить перегрузку операторов, которую Java по умолчанию не поддерживает, выражение становится гораздо ближе к привычному математическому виду и считывается с гораздо меньшей задержкой. Это иллюстрирует, насколько важна форма записи важнейших частей кода для восприятия "с первого взгляда".
Понятие «обвязки» или «plumbing» кода играет здесь важную роль. Это «технические детали», поддерживающий каркас, в котором реализована основная логика. Контроль потока, обработка исключений, преобразования типов — вроде каркаса вокруг основного действия. Чтобы ускорить понимание, важно визуально выделить основное содержание — саму логику, а второстепенные операции пусть уходят на задний план. Ярко выраженная структура позволяет так же, как в языке естественном, быстро отличать «главное» от «второстепенного».
Очень важен и контекст, в котором находится код. Люди умеют улавливать значение слов или выражений исходя из конкретной ситуации, даже если они теоретически многозначны. Аналогично в программировании, если модуль посвящен работе с HTTP запросами к определенной системе, название метода get может подразумевать отправку аутентифицированного двух разных контекстах — оно будет означать разное. Такая зависимость от контекста помогает убрать избыточные уточнения и сделать код более компактным без потери понимания. Понятие минимального количества информации, необходимого для понимания выражения, тоже важный аспект.
Если выражение описывает полином, то для его понимания нужны лишь коэффициенты и степень переменной. Остальной код — будь то вспомогательные вызовы или настройки — является технической частью, которая часто только загромождает восприятие при первом приближении. Стремление выделять в архитектуре только важные элементы ведет к созданию более компактных и читаемых API, где основное — проще и понятнее. Методы визуализации и нотации, используемые в математике, могут служить хорошими примерами для программирования. Математический язык обладает высокой степенью информационной плотности, и его элементы оформлены так, чтобы быть сразу узнаваемыми и легко различаемыми.
Символы как интеграл, знаки операций, границы интегрирования — все это формирует отчетливый «контур» формулы и делает возможным ее мгновенное узнавание даже при беглом взгляде. Подобные принципы можно использовать при создании кода с продуманной визуальной формой. Главным в работе над проектированием и поддержкой программных продуктов является понимание того, как люди взаимодействуют с кодом. Чтобы сделать процесс более легким и интуитивным, важно выстраивать архитектуру и стиль программирования с учетом способов чтения, просмотров, редактирования и повторного использования. Создание кода, который можно понять и оценить с первого взгляда, — это не только вопрос красоты или стиля, но и важнейший инструмент улучшения продуктивности.
