Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Авторы очередного убийцы redux\jira\microsoft обычно обижаются в ответ на разумные замечания по качеству кода и пишут что то вроде ‘При чём тут качество кода? Посмотрите какую штуку я запилил’. Что, блин? Неужели сложно понять, что код сложно понять?
Написание такого кода говорит о том, что код либо не планируется поддерживать, либо у автора недостаточно опыта, чтобы понимать, почему это важно. В любом случае, в успехе такого продукта есть определённые сомнения.
Но вообще, в чём проблема читабельности? По моему мнению, это как элементарная гигиена: пришёл с улицы - помыл руки, написал код - привёл его в порядок. Почему же читабельность часто становится неким камнем преткновения?
Небольшое отступление, что понимать под ‘читабельностью’.
Читабельность - это понятность кода. Мы не будем углубляться в архитектурные детали, как раскидать код по уровням\слоям\модулям, чтоб стало понятнее, мы рассмотрим относительно простые варианты, в духе имён переменных, разделения методов, вложенность циклов\условий, консистентность в форматировании и т. д.
Чего тут не будет
Я не буду предлагать примеры кода, так как идея статьи не в рассмотрении 'как сделать лучше', а в 'зачем уделять внимание читабельности и почему часто ей его не удаляют'
Для ситхов
Если я говорю "никогда" - это значит, "никогда кроме исключительных ситуаций". Ещё раз, "никогда кроме, действительно, исключительных ситуаций".
Вообще, я вижу три проблемы, связанные с читабельностью и с тем, почему ей часто пренебрегают.
Читабельность - не самоцель
От вопросов в духе ‘зачем вообще переименовывать метод’, ‘зачем разбивать код на части, он всё равно используется только тут’ и т.д. у меня складывается впечатление, что не всегда очевидно, что читабельность - это не самоцель. Читабельность - это инструмент.
Давайте для начала попробуем определить, зачем, собственно, нам нужно писать код, который можно легко читать и понимать. Для этого рассмотрим требования, предъявляемые к коду на протяжении его жизненного цикла.
На первом этапе реализации функционала к коду предъявляется только одно требование - делать то, что он должен делать (я думаю, многие слышали про принцип make it work, make it right, make it fast и большинство неосознанно или осознанно его соблюдают. По крайней мере первую его часть :)). Соответственно, на этом этапе, поддержка читабельности только расходует ресурсы и не даёт ничего здесь и сейчас (к ресурсам мы ещё вернёмся позже). Но читабельность - это плацдарм.
Давайте попробуем выстроить некую пирамиду свойств, которыми должен\может обладать код. Начнём снизу.
Что у нас в основании пирамиды? Думаю, что тут никто не будет спорить, что самое главное свойство кода - выполнять поставленную задачу, реализовывать конкретный функционал. Без этого код не нужен. При этом, в разных ситуациях, это может быть единственное свойство, которым обладает код. Вы можете написать скрипт, который нельзя ни понять, ни изменить, ни прочитать, но если он делает своё дело - Вы можете им пользоваться. Итак, определились, что в основании. Что ставим следующим уровнем? После некоторых размышлений, я пришёл к выводу, что следующим этапом идёт как раз читабельность. В общем случае мы не можем сделать код безопасным, если мы не можем его понять. Мы не можем сделать код расширяемым, если его трудно читать. Мы не можем протестировать код, если он непонятный. Т.е. читабельность является фундаментом, на котором мы можем возвести код, обладающий необходимыми качествами. И это очень важный момент, т.е. читабельность - это не только про понятность кода. Это не в последнюю очередь про изменяемость и поддержку кода. Но если нам это не нужно, то и читабельность нам не нужна.
Читабельность не так проста
Читабельность - она не бинарная, она иногда может быть субъективна, она может быть хуже или лучше, она состоит из множества мелких деталей. Назвали переменную не так - ну что ж, вроде от одного отсутствующего кирпича дом не развалится. Не разбили метод на части или сделали тройной вложенный цикл - ну что ж, это не выглядит глобальной проблемой. Трудно увидеть, когда проблема встаёт в полный рост. Да и поздно уже.
Одна переменная с плохим названием - это проблема? Ну, очевидно, пока нет. А две? А три? А когда станет проблемой? Не стоит забывать и про теорию разбитых окон - вкупе с пренебрежительным отношением к единичным мелким проблема она может объяснить причину низкого качества итогового кода.
В результате читабельность требует достаточно скрупулёзного соблюдения правил.
Стоимость читабельности возрастает очень быстро
Стоимость поддержки читабельности, достаточно низкая на этапе разработки, значительно возрастает сразу после завершения этого этапа. Когда код уже перешёл в стадию ревью, есть две потенциальные проблемы. Первая - это мелкие ошибки, правка которых потребует больше накладных расходов (переключение веток, сборка проекта, повторное ревью), чем непосредственно правка обнаруженных проблем. Чаще всего никто не будет тратить время на такое переименование переменной. Вторая проблема - это когда обнаружены крупные проблемы. И тут два варианта - оставляем как есть и заказчик счастлив, т.к. функционал работает, или потенциально оставляем клиента без функционала. Ну ‘оставляем клиента без функционала’ - это как второй вариант видится извне. Полный вариант звучит как ‘вероятно, оставляем клиента без функционала и правим проблему’. К сожалению, в любом случае, профит может быть не так очевиден, а оставить клиента без функционала - это не наш путь. Данную проблема можно рассмотреть на конкретном примере: сколько стоит переименовать переменную? А если нужно переключиться на ветку, собрать проект, запустить, проверить, повторить ревью этой части?
Поэтому читабельностью нужно заниматься сразу - здесь и сейчас (по моему опыту), сделать код чище и читабельнее занимает конечное время. Это не дни, не x5 к общему времени разработки, даже не x1.5 - не какие то заоблачные цифры. Пока что. В будущем приведение кода в порядок потребует намного больше времени - возможно, те самые x5 или x1.5.
В заключение
Мне тут пришла одна аналогия, что читабельность - это как техдолг, только наоборот, мы сейчас тратим чуть больше времени, но экономим его в будущем. Поддержка читабельности - это технический вклад.
Если эта статья не блещет читабельностью, то это только потому, что я не планирую в будущем её поддерживать.
