[Совершенный код] Почему сложно понять, что код не должно быть сложно понять?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Авторы очередного убийцы redux\jira\microsoft обычно обижаются в ответ на разумные замечания по качеству кода и пишут что то вроде ‘При чём тут качество кода? Посмотрите какую штуку я запилил’. Что, блин? Неужели сложно понять, что код сложно понять?Написание такого кода говорит о том, что код либо не планируется поддерживать, либо у автора недостаточно опыта, чтобы понимать, почему это важно. В любом случае, в успехе такого продукта есть определённые сомнения.Но вообще, в чём проблема читабельности? По моему мнению, это как элементарная гигиена: пришёл с улицы - помыл руки, написал код - привёл его в порядок. Почему же читабельность часто становится неким камнем преткновения?Небольшое отступление, что понимать под ‘читабельностью’. Читабельность - это понятность кода. Мы не будем углубляться в архитектурные детали, как раскидать код по уровням\слоям\модулям, чтоб стало понятнее, мы рассмотрим относительно простые варианты, в духе имён переменных, разделения методов, вложенность циклов\условий, консистентность в форматировании и т. д. Чего тут не будетЯ не буду предлагать примеры кода, так как идея статьи не в рассмотрении 'как сделать лучше', а в 'зачем уделять внимание читабельности и почему часто ей его не удаляют'Для ситховЕсли я говорю "никогда" - это значит, "никогда кроме исключительных ситуаций". Ещё раз, "никогда кроме, действительно, исключительных ситуаций".Вообще, я вижу три проблемы, связанные с читабельностью и с тем, почему ей часто пренебрегают.Читабельность - не самоцельОт вопросов в духе ‘зачем вообще переименовывать метод’, ‘зачем разбивать код на части, он всё равно используется только тут’ и т.д. у меня складывается впечатление, что не всегда очевидно, что читабельность - это не самоцель. Читабельность - это инструмент.Давайте для начала попробуем определить, зачем, собственно, нам нужно писать код, который можно легко читать и понимать. Для этого рассмотрим требования, предъявляемые к коду на протяжении его жизненного цикла.На первом этапе реализации функционала к коду предъявляется только одно требование - делать то, что он должен делать (я думаю, многие слышали про принцип make it work, make it right, make it fast и большинство неосознанно или осознанно его соблюдают. По крайней мере первую его часть :)). Соответственно, на этом этапе, поддержка читабельности только расходует ресурсы и не даёт ничего здесь и сейчас (к ресурсам мы ещё вернёмся позже). Но читабельность - это плацдарм.Давайте попробуем выстроить некую пирамиду свойств, которыми должен\может обладать код. Начнём снизу.Что у нас в основании пирамиды? Думаю, что тут никто не будет спорить, что самое главное свойство кода - выполнять поставленную задачу, реализовывать конкретный функционал. Без этого код не нужен. При этом, в разных ситуациях, это может быть единственное свойство, которым обладает код. Вы можете написать скрипт, который нельзя ни понять, ни изменить, ни прочитать, но если он делает своё дело - Вы можете им пользоваться. Итак, определились, что в основании. Что ставим следующим уровнем? После некоторых размышлений, я пришёл к выводу, что следующим этапом идёт как раз читабельность. В общем случае мы не можем сделать код безопасным, если мы не можем его понять. Мы не можем сделать код расширяемым, если его трудно читать. Мы не можем протестировать код, если он непонятный. Т.е. читабельность является фундаментом, на котором мы можем возвести код, обладающий необходимыми качествами. И это очень важный момент, т.е. читабельность - это не только про понятность кода. Это не в последнюю очередь про изменяемость и поддержку кода. Но если нам это не нужно, то и читабельность нам не нужна.Читабельность не так простаЧитабельность - она не бинарная, она иногда может быть субъективна, она может быть хуже или лучше, она состоит из множества мелких деталей. Назвали переменную не так - ну что ж, вроде от одного отсутствующего кирпича дом не развалится. Не разбили метод на части или сделали тройной вложенный цикл - ну что ж, это не выглядит глобальной проблемой. Трудно увидеть, когда проблема встаёт в полный рост. Да и поздно уже.Одна переменная с плохим названием - это проблема? Ну, очевидно, пока нет. А две? А три? А когда станет проблемой? Не стоит забывать и про теорию разбитых окон - вкупе с пренебрежительным отношением к единичным мелким проблема она может объяснить причину низкого качества итогового кода.В результате читабельность требует достаточно скрупулёзного соблюдения правил.Стоимость читабельности возрастает очень быстроСтоимость поддержки читабельности, достаточно низкая на этапе разработки, значительно возрастает сразу после завершения этого этапа. Когда код уже перешёл в стадию ревью, есть две потенциальные проблемы. Первая - это мелкие ошибки, правка которых потребует больше накладных расходов (переключение веток, сборка проекта, повторное ревью), чем непосредственно правка обнаруженных проблем. Чаще всего никто не будет тратить время на такое переименование переменной. Вторая проблема - это когда обнаружены крупные проблемы. И тут два варианта - оставляем как есть и заказчик счастлив, т.к. функционал работает, или потенциально оставляем клиента без функционала. Ну ‘оставляем клиента без функционала’ - это как второй вариант видится извне. Полный вариант звучит как ‘вероятно, оставляем клиента без функционала и правим проблему’. К сожалению, в любом случае, профит может быть не так очевиден, а оставить клиента без функционала - это не наш путь. Данную проблема можно рассмотреть на конкретном примере: сколько стоит переименовать переменную? А если нужно переключиться на ветку, собрать проект, запустить, проверить, повторить ревью этой части? Поэтому читабельностью нужно заниматься сразу - здесь и сейчас (по моему опыту), сделать код чище и читабельнее занимает конечное время. Это не дни, не x5 к общему времени разработки, даже не x1.5 - не какие то заоблачные цифры. Пока что. В будущем приведение кода в порядок потребует намного больше времени - возможно, те самые x5 или x1.5.В заключениеМне тут пришла одна аналогия, что читабельность - это как техдолг, только наоборот, мы сейчас тратим чуть больше времени, но экономим его в будущем. Поддержка читабельности - это технический вклад.Если эта статья не блещет читабельностью, то это только потому, что я не планирую в будущем её поддерживать.
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Java] Создание самодостаточных исполняемых JAR (перевод)
- [Совершенный код, Клиентская оптимизация, Компиляторы] «Компилятор всё оптимизирует»? Ну уж нет (перевод)
- [Программирование, Совершенный код, Проектирование и рефакторинг, Управление разработкой, Исследования и прогнозы в IT] Про комментарии к коду (перевод)
- [Совершенный код, Разработка под e-commerce, Тестирование веб-сервисов, Управление e-commerce, IT-компании] Плюсуем к скидке. Покупатели Яндекс.Маркет заметили, что товары для подписчиков Плюса стоят дороже, чем без подписки
- [Программирование, Совершенный код, Проектирование и рефакторинг] Актуальность принципов SOLID (перевод)
- [Разработка веб-сайтов, JavaScript, Программирование, Совершенный код] Погружение во внедрение зависимостей (DI), или как взломать Матрицу
- [PHP, Программирование, Совершенный код, Проектирование и рефакторинг, ООП] Принцип подстановки Барбары Лисков (предусловия и постусловия)
- [Python, Совершенный код, ООП] В поисках упорядоченного множества в Python: разбираемся с теорией и выбираем лучшую реализацию
- [Программирование, Совершенный код] Практическое руководство по именованию классов, функций и переменных (перевод)
- [Python, Программирование, Совершенный код, Научно-популярное] Разукрашиваем вывод в консоли: теория и практика
Теги для поиска: #_sovershennyj_kod (Совершенный код), #_chitabelnost (читабельность), #_horoshij_kod (хороший код), #_horoshie_praktiki (хорошие практики), #_sovershennyj_kod (
Совершенный код
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:54
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Авторы очередного убийцы redux\jira\microsoft обычно обижаются в ответ на разумные замечания по качеству кода и пишут что то вроде ‘При чём тут качество кода? Посмотрите какую штуку я запилил’. Что, блин? Неужели сложно понять, что код сложно понять?Написание такого кода говорит о том, что код либо не планируется поддерживать, либо у автора недостаточно опыта, чтобы понимать, почему это важно. В любом случае, в успехе такого продукта есть определённые сомнения.Но вообще, в чём проблема читабельности? По моему мнению, это как элементарная гигиена: пришёл с улицы - помыл руки, написал код - привёл его в порядок. Почему же читабельность часто становится неким камнем преткновения?Небольшое отступление, что понимать под ‘читабельностью’. Читабельность - это понятность кода. Мы не будем углубляться в архитектурные детали, как раскидать код по уровням\слоям\модулям, чтоб стало понятнее, мы рассмотрим относительно простые варианты, в духе имён переменных, разделения методов, вложенность циклов\условий, консистентность в форматировании и т. д. Чего тут не будетЯ не буду предлагать примеры кода, так как идея статьи не в рассмотрении 'как сделать лучше', а в 'зачем уделять внимание читабельности и почему часто ей его не удаляют'Для ситховЕсли я говорю "никогда" - это значит, "никогда кроме исключительных ситуаций". Ещё раз, "никогда кроме, действительно, исключительных ситуаций".Вообще, я вижу три проблемы, связанные с читабельностью и с тем, почему ей часто пренебрегают.Читабельность - не самоцельОт вопросов в духе ‘зачем вообще переименовывать метод’, ‘зачем разбивать код на части, он всё равно используется только тут’ и т.д. у меня складывается впечатление, что не всегда очевидно, что читабельность - это не самоцель. Читабельность - это инструмент.Давайте для начала попробуем определить, зачем, собственно, нам нужно писать код, который можно легко читать и понимать. Для этого рассмотрим требования, предъявляемые к коду на протяжении его жизненного цикла.На первом этапе реализации функционала к коду предъявляется только одно требование - делать то, что он должен делать (я думаю, многие слышали про принцип make it work, make it right, make it fast и большинство неосознанно или осознанно его соблюдают. По крайней мере первую его часть :)). Соответственно, на этом этапе, поддержка читабельности только расходует ресурсы и не даёт ничего здесь и сейчас (к ресурсам мы ещё вернёмся позже). Но читабельность - это плацдарм.Давайте попробуем выстроить некую пирамиду свойств, которыми должен\может обладать код. Начнём снизу.Что у нас в основании пирамиды? Думаю, что тут никто не будет спорить, что самое главное свойство кода - выполнять поставленную задачу, реализовывать конкретный функционал. Без этого код не нужен. При этом, в разных ситуациях, это может быть единственное свойство, которым обладает код. Вы можете написать скрипт, который нельзя ни понять, ни изменить, ни прочитать, но если он делает своё дело - Вы можете им пользоваться. Итак, определились, что в основании. Что ставим следующим уровнем? После некоторых размышлений, я пришёл к выводу, что следующим этапом идёт как раз читабельность. В общем случае мы не можем сделать код безопасным, если мы не можем его понять. Мы не можем сделать код расширяемым, если его трудно читать. Мы не можем протестировать код, если он непонятный. Т.е. читабельность является фундаментом, на котором мы можем возвести код, обладающий необходимыми качествами. И это очень важный момент, т.е. читабельность - это не только про понятность кода. Это не в последнюю очередь про изменяемость и поддержку кода. Но если нам это не нужно, то и читабельность нам не нужна.Читабельность не так простаЧитабельность - она не бинарная, она иногда может быть субъективна, она может быть хуже или лучше, она состоит из множества мелких деталей. Назвали переменную не так - ну что ж, вроде от одного отсутствующего кирпича дом не развалится. Не разбили метод на части или сделали тройной вложенный цикл - ну что ж, это не выглядит глобальной проблемой. Трудно увидеть, когда проблема встаёт в полный рост. Да и поздно уже.Одна переменная с плохим названием - это проблема? Ну, очевидно, пока нет. А две? А три? А когда станет проблемой? Не стоит забывать и про теорию разбитых окон - вкупе с пренебрежительным отношением к единичным мелким проблема она может объяснить причину низкого качества итогового кода.В результате читабельность требует достаточно скрупулёзного соблюдения правил.Стоимость читабельности возрастает очень быстроСтоимость поддержки читабельности, достаточно низкая на этапе разработки, значительно возрастает сразу после завершения этого этапа. Когда код уже перешёл в стадию ревью, есть две потенциальные проблемы. Первая - это мелкие ошибки, правка которых потребует больше накладных расходов (переключение веток, сборка проекта, повторное ревью), чем непосредственно правка обнаруженных проблем. Чаще всего никто не будет тратить время на такое переименование переменной. Вторая проблема - это когда обнаружены крупные проблемы. И тут два варианта - оставляем как есть и заказчик счастлив, т.к. функционал работает, или потенциально оставляем клиента без функционала. Ну ‘оставляем клиента без функционала’ - это как второй вариант видится извне. Полный вариант звучит как ‘вероятно, оставляем клиента без функционала и правим проблему’. К сожалению, в любом случае, профит может быть не так очевиден, а оставить клиента без функционала - это не наш путь. Данную проблема можно рассмотреть на конкретном примере: сколько стоит переименовать переменную? А если нужно переключиться на ветку, собрать проект, запустить, проверить, повторить ревью этой части? Поэтому читабельностью нужно заниматься сразу - здесь и сейчас (по моему опыту), сделать код чище и читабельнее занимает конечное время. Это не дни, не x5 к общему времени разработки, даже не x1.5 - не какие то заоблачные цифры. Пока что. В будущем приведение кода в порядок потребует намного больше времени - возможно, те самые x5 или x1.5.В заключениеМне тут пришла одна аналогия, что читабельность - это как техдолг, только наоборот, мы сейчас тратим чуть больше времени, но экономим его в будущем. Поддержка читабельности - это технический вклад.Если эта статья не блещет читабельностью, то это только потому, что я не планирую в будущем её поддерживать. =========== Источник: habr.com =========== Похожие новости:
Совершенный код ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:54
Часовой пояс: UTC + 5