Или как сделать свой код хорошим

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

  • Маленькие функции
  • Осмысленные имена методов/переменных/классов/и т.д.
  • Последовательный единый стиль кода

И другие лаконичные правила. ТВЕРДЫЙ, ЯГНИ, ПОЦЕЛУЙ. Все это поможет вам сохранить ваш код чистым и читаемым для других людей и для вас самих.

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

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

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

Мой код похож на открытую книгу.

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

Для некоторых проектов это драма в трех действиях. Для других проектов это научная фантастика с невообразимым количеством UFcb (неопределенные летающие кодовые блоки, дающие неизвестные результаты). Для некоторых проектов это фантазия, полная магического кода и блоков заклинаний, которые нужно повторять, чтобы что-то запустить. А для остальных проектов это хоррор или комедия.

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

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

Другое происходит, когда вы читаете код. Я полагаю, что в большинстве случаев не хочется знать всю историю, а нужно найти что-то и понять. Вот почему я сравнил его со справочниками или книгами по программированию. Возьмем, к примеру, Эффективную Java Джошуа Блоха. Если вы перейдете к началу книги, вы увидите Содержание: список глав с элементами и ссылками на страницы. Это своеобразный набор функций (глав), которые вызывают другие функции (элементы). Это сделано потому, что, скорее всего, вы не прочитаете всю книгу за один раз (по крайней мере, скорее всего, один раз), а будете перечитывать ее снова и снова, возвращаясь к нужным главам/пунктам, когда столкнетесь с вопросы, проблемы или вам нужна информация от них.

Мой код отличается

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

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