Пиши свой код так, будто его будет читать маньяк убийца, который знает где ты живешь.
Даже если ты только начал программировать, тебе пришлось столкнуться с тем, что твой код читают другие люди.
Жизнь программиста подобна писателю.
Он все время пишет для того, чтобы его читали:
- редактор;
- цензор;
- корректор и т.д.
Но в результате все делается для того, чтобы текст увидел читатель.
В программировании это разделяется на два типа, с которыми взаимодействует код: читатели и пользователи.
Твой код читают:
- коллеги;
- наставники;
- руководитель группы;
- тестировщики и т.д.
Читают все те, кто участвуют вместе с тобой в разработке программы.
А вот пользователь твой код не увидит, ему важно удобство работы с программой.
Возникает здравый вопрос: зачем уделять время красоте кода, если мы разрабатываем программу для пользователя, а он никогда не увидит твой код?
Аргументов очень много, но я бы выделил один:
Для того, чтобы пользователь в итоге смог увидеть вашу программу в работоспособном состоянии, а не в ожидании завершения процесса её перманентной разработки.
Как красивый код влияет на конечный продукт?
Перед обсуждением всегда необходимо договориться о применяемых терминах:
- главное работает - применение любых практик, костылей, нагромождений и т.д. лишь бы код запустился и решал поставленную задачу;
- размытый код - код написанный по принципу главное работает, который очень сложно читать и переполнен ненужным подробностями;
- четкий код - вычищенный код без наличия примесей, в котором ярко выражен посыл каждого элемента;
- стыд - код написанный по принципу главное работает, с высокой концентрацией размытости, но с отсутствием желания дать возможность увидеть его кому-либо из твоих коллег или знакомых;
- красивый код - это четкий код, который читается без объясняющих комментариев и после прочтения вызывает чувство эстетического наслаждения.
Давайте проведем небольшой эксперимент:
напишите прям сейчас в комментариях, в каких терминах вы увидели себя, а после прочтения статьи напишите ответ на свой комментарий и с учетом полученной информации.
Так вы увидите, сошлись ли результаты и насколько вы склонны к стремлению делать свой код более красивым.
А теперь вернемся к ответу на вопрос, который кроется в названии раздела и разберем его на рядовом случае.
Пример
Команда разработчиков получает некую задачу и начинает писать код.
Кто-то штудирует документацию, другой занят поиском решения, третий считает, что успеет сделать это завтра и смотрит обучающие видео.
В целом работа как-то идет, но кодовая база проекта не увеличивается.
Это безобразие замечает продуктовый менеджер и начинает срочно всех подгонять.
Программисты начинают спотыкаясь писать код в формате главное работает. Кодовая база начинает разрастаться.
Если вчера программисты садились писать новую функцию с нуля, то сегодня им приходится в первую очередь понять, а что у них уже есть в коде, чтобы начать писать что-то новое.
Учитывая, что этот код является размытым, то в процессе его чтения программист начинает тратить больше времени на изучение своего же кода и минимальное оставшееся время рабочего дня тратит на написание нового кода.
Таким образом, скорость разработки начинает замедляться по геометрической прогрессии. Чем больше кода написали, тем больше нужно разбираться на следующий день.
Также стоит отметить, что команда должна работать совместно над проектом, хоть задачи и поделены между её участниками.
Но руководитель группы начинает замечать, что программисты стараются решить все задачи связанные с его модулями, главное не подпустить к своему коду других участников.
Так формируется стыд, который предполагает, что программиста будут ругать, насмехаться, придумывать шуточки по его некрасивому коду.
В результате скорость разработки к середине проекта замедляется настолько, что какая-то часть программистов просто выгорает.
Руководитель группы понимает это и принимает меры. Единственным быстрым решением он считает добавление объясняющих комментариев.
Команда приступает к комментированию кода и создаёт концентрацию размытости еще больше. Теперь в процессе чтения программисту вначале нужно прочитать комментарий, а затем анализировать этот участок кода.
Ситуация хуже не придумаешь, а сроки сдачи первой версии уже поджимают. Естественно с такими темпами разработки команда не укладывается и руководитель принимает решение расширить состав, чтобы работа шла быстрее.
HR нанимает новых сотрудников, на это кстати уходит не мало времени.
Затем их интегрируют в команду и сажают за изучением кодовой базы, а там вы уже помните, что творится нечто ужасное.
Если сами авторы уже с большой сложностью читают такой код, то каков успех на быстрое понимание теми, кто только подключился к проекту?
В результате выгорание первых участников проекта приводит их к тому, что они уходят из него, а на их место приходят новые.
Новички еще сильнее усугубляют кодовую базу добавляя все больше размытия в код, т.к. сроки уже горят и менеджер требует от них писать быстрее и быстрее.
Поэтому формат главное работает - выходит на финишную прямую и занимает 100% кодовой базы.
В итоге в сроки не укладываются, а что еще хуже, проект может быть заморожен, если он имел сезонный характер и его выпуск был запланирован под какую-то акцию или сезон.
Вот так, на первый взгляд не привязанная к пользователю красота кода ни позволила появиться проекту на свет и пользователь его так и не смог увидеть. 😐
Как писать красивый код?
Термин красивый код мы уже определили и понимаем, что в первую очередь это четкий код без примесей.
Что больше всего добавляет примесей в код, которые делают его размытым?
Это смешанное применение абстракций в коде.
Про абстракции вы можете прочитать в другой статье.
А как же сделать так, чтобы четкость кода оставалась неизменной и его прочтение оставляло чувство эстетического наслаждения, как заявлено в определении термина красивый код?
Для этого необходимо следовать правилу газетной статьи.
Чтобы читатель обратил внимание на статью необходимо сделать громкий заголовок. Это означает, что абсолютная абстрагированность от какой-то конкретики, главное чтобы читатель уловил посыл, которые кроется в статье.
Следующий шаг - это первая часть статьи, она должна делать громкие заявления и не доставлять скуки читателю своими точными данными, расчетами, датами и т.д.
К середине статьи, читателя нужно полностью погрузить в проблематику, которую охватывает эта тема и подготовить его к желанию получить точные данные.
Ближе к концу статьи автор начинает сыпать аргументами, статистическими выкладками, датами, числами и т.д.
Почему именно так? Потому, что читатель еще не знаком с проблемой и вначале статьи ему необходимо дать только общую информацию, чтобы увлечь его и двигать далее по тексту. Задача погрузить его настолько, чтобы он был готов получать точные данные.
Если это правило попытаться визуализировать, то получится воронка движения читателя по статье от высокой абстракции к точным данным.
Ровно по такому же правилу необходимо писать программный код. Я не вдаюсь в подробности того, что каждый класс выделяется в отдельный файл. Мы говорим сразу о том, как должна выглядеть подача кода в любом файле. Запомните эту воронку и именно по такому принципу применяйте абстракции в коде.
Ниже приведу два примера кода, один будет написан по правилу газетной статьи, а второй не придерживается этого правила. Попробуй угадать написав в комментарии, какой код написан по правилу газетной статьи и скажи, какой код было легче читать.
Программный код №1.
Программный код №2.
Жду ваших ответов в комментариях.
Подписывайся, чтобы быть в курсе актуальной информации мира IT и иметь возможность участвовать в обсуждении.
Переходите к следующей статье по чистому коду:
