О чистоте кода
Сегодня я прочитал статью Дэна Абрамова о чистом коде, и, поскольку я очень сильно отношусь к чистому/читабельному/понятному коду, я хотел изложить свои мысли на эту тему на (цифровой) бумаге.
Пункты в статье объективно верны и, вероятно, полезны для многих людей, но в то же время я думаю, что в ней упущен важный момент.
Принцип DRY сформулирован как Каждая часть знаний должна иметь единственное, недвусмысленное, авторитетное представление в системе. (Википедия)
Для меня DRY — это не сохранение слов или символов и сокращение кода. В любом случае Gzip сделает это лучше вас.
Я думаю, что важной частью является понимание того, что означает «Каждая часть знания». Для меня это означает, что в первую очередь создание СУХОГО кода должно передавать информацию, а именно то, что эти две вещи на самом деле являются одной вещью, даже если они используются или на них ссылаются из разных мест. Таким образом, DRY — очень важный инструмент для передачи важной информации другим.
Важно понимать, что эта концепция того, что является «частью знаний», не обязательно однозначно сопоставляется с текстом. Иногда один и тот же код может представлять разные концепции, или две части кода, текстуально отличающиеся друг от друга, представляют одну и ту же концепцию.
Этот принцип также не находится на скользящей шкале между дублированием и отсутствием абстракции до СУХОГО с избытком абстракции. Выбор подходящей абстракции для того, что делает код, важен, но вы можете сделать свой код СУХИМ с очень небольшой абстракцией или иметь много дублирования, используя запутанную и сложную абстракцию.
Во-вторых, ничего не бывает бесплатно. Мой код обменял возможность изменения требований на сокращение дублирования, и это не было хорошей сделкой. Например, позже нам понадобилось много особых случаев и поведений для разных ручек на разных фигурах. Моя абстракция должна была бы стать в несколько раз более запутанной, чтобы позволить себе это, тогда как с исходной грязной версией такие изменения оставались легкими как пирог. (Статья Дэна)
Для некоторых это может означать, что существует корреляция между дублированием и изменчивостью кода. Я думаю, что это создает соломенный аргумент, утверждающий, что единственный путь вперед после рефакторинга — это сохранить абстракцию, даже если основные концепции изменяются таким образом, что абстракция больше не подходит.
Я думаю, что это то, что многие люди ошибаются. На мой взгляд, код, который легче всего изменить, это не тот код, который был написан с учетом изменений и требует наименьшего количества текстовых различий для включения новых требований. Код, который легче всего изменить, является наиболее читаемым и наиболее точно представляет систему, которую он моделирует в текущий момент времени, что позволяет легко понять, что нужно изменить и как.
Легче всего изменить систему, которую легче всего понять.
Таким образом, не говоря уже о том, был ли рефакторинг полезен или нет, главное соображение заключается не в том, лучше ли он предсказал будущие требования или сколько нового кода потребуется для его изменения. Для меня более важным вопросом было бы то, насколько разумно смоделировано текущее состояние системы, стал ли код после рефакторинга легче понять, чем раньше, и, следовательно, легче ли его изменить с уверенностью.
Ответ по-прежнему может быть «Нет». Возможно, абстракция была слишком сложной для этого случая, и ее было труднее понять, чем раньше. Может быть, код, который был почти таким же, не представлял ту же самую «Часть знания», или он представлял ее, и на самом деле было бы полезно сделать ее СУХОЙ. Даже если его нужно было отменить позже, когда он перестал правильно представлять систему, изменение могло быть проще даже при изменении абстракции.
Итак, подведем итог: не просто бросайте шаблоны, принципы или абстракции волей-неволей. Понимание обычно важнее всего. Вы повышаете понимание путем правильного общения, в этом контексте, с вашим кодом. Поэтому при изменении кода спросите себя, облегчит ли ваше изменение понимание системы другими людьми или нет.
