Комментарии 16
За многие годы я пришёл к очень простому пониманию: этот код способен прочесть средний middle разработчик и понять что он делает(при условии что это вообще применимо)? Если да, то этого достаточно. Не никакого смысла тратить кучу времени и создавать напряжённости в команде полируя одноразовый код. Нет никакой проблемы вообще. Если код окажется плохим, вы это увидите потом, отрефакторите. Более того, практику поголовынх ревью и рефакторинг просто потому что кому-то не нравится, можно выразить перефразированной очень популярной цитатой:
Преждевременный рефакторинг - корень всех зол
Могу разве что добавить, что код ревью несут в том числе воспитательную цель. От "тыканья носом" в код с не сильно плохим запахом разработчик чему-то научится? Нет? Ну и фиг с ним тогда.
Полностью согласен, на ревью я прежде всего смотрю, а не поломается ли что-то, если замержат этот код, нет ли каких-то дефектов.
SOLID обычно проверяется на design review, когда раскидывают объекты.
Ох уж это "потом отрефакторите". Обычно это означает "и так сойдет".
Да. Ровно также как и с оптимизациями. Можно оптимизировать миллион мест и это принесёт но 0 прибыли. Всегда должен быть допустимый уровень погрешности. Нет смысла точить колёся поезда с допусками поршня. Нет смысла пилить одноразовый код с требованиями ядра хай перфоманс системы.
Если можно написать хорошо, то зачем писать плохо?
Правки на ревью это не про написать. Это про переписать работающий код. Это про вложить ещё денег, сил, сроков в чьи то хотелки по оформлению кода вместо того чтобы вложить их в продукт. И принятие этого решения должно быть очень взвешенным и ориентированным на текущие бизнес потребности проекта.
Одна из потребностей бизнеса это создание понятного и поддерживаемого кода. Ибо как ни крути, но будут приходить новые разработчики которым придется поддерживать кодовую базу.
Даже старым разработчикам будет гораздо проще поддерживать код, который написан правильно.
Вы очень верно употребили термин "одна из потребностей". Есть и другие. И их нужно взвешивать. Я ни в коем случае не говорю что ревью и рефакторинги это плохо. Это инструмент. И иногда он уместен, а иногда нет. Часто можно услышать позицию возведения "качества кода" в абсолют в угоду другим параметрам продукта. И именно гиперконцентрация на этом часто вылазит боком. Очень часто скорость проверки гипотезы важнее последующей сопровождаемости, потому что 9 попыток из 10 уйдут в урну. Еще раз. Качеством кода можно и нужно управлять. Это хорошо. Сказать что соблюдение неких кодстайлов или паттернов есть критерий качества - хуже. Возвести это в абсолют - ужасно. Как пример могу предложить рассмотреть стандариты кодирования НАСА. Очень надёжный код получается. Но никому на рынке не выжить с таким подходом.
Я стал смотреть больше не на сами компоненты, а на то, как они встраиваются и понятна ли общая канва.
Раз за разом ситуация, что классики еще нормально полируют (проще искать ключи под фонарем), модули и системы - похуже, а на уровне проекта треш, угар и непонятные механизмы, управляющие центральными состояниями системы.
Хотя должно быть наоборот - напиши аккуратное встраивание, и что будет в конкретной реализации - почти пофиг, при переписывании ее выкинут и воткнут новую.
За многие годы я пришёл к очень простому пониманию: этот автомобиль способен производить среднее middle предприятие и понять как он устроен(при условии что это вообще применимо)? Если да, то этого достаточно. Не никакого смысла тратить кучу времени и создавать напряжённости в команде полируя одноразовый автомобиль. Нет никакой проблемы вообще. Если автомобиль окажется плохим, вы это увидите потом, сделаете новый. Более того, практику поголовынх ревью и повышение качества просто потому что кому-то не нравится, можно выразить перефразированной очень популярной цитатой:
Делать людям хорошо — себе дороже
.
# Good
d = {i: char for i, char in enumerate(chars)}# Very Good
d = dict(enumerate(chars))Соблюдение принципов SOLID
На всякий случай напомню, SOLID — это аббревиатура для 5 основных принципов ООП:
Во-первых, принципы SOLID не ограничены ООП. Они практически все применимы и к другим парадигмам. Но это ерунда. Не ерунда, то, ради чего все это затевается. Требовать соблюдения принципов — зачем?
А вот зачем (вики):
Для чего нужны принципы SOLID
При создании программных систем использование принципов SOLID способствует созданию такой системы, которую будет легко поддерживать и расширять в течение долгого времени[3].
Ну т.е. принципы эти призваны создать такой код, который будет потом просто расширять и поддерживать. Прежде чем требовать этого на ревью (ну или проверять соблюдение), хорошо бы понимать, что для проекта это реально важно. И не только вообще, а вот в этом конкретном месте.
А если это не нужно, то требовать применения принципов — все равно что требовать использования паттернов проектирования (которые являются способами решения типовых задач, и в отсутствии самих задач не имеют смысла). И многие очевидно видели, к чему приводит такое бездумное применение.
Еще раз о Code Review