Резюме
Как пишет JacquesB, не все согласны с «Чистым кодом» Роберта Мартина.
Проекты с открытым исходным кодом, которые, как вы обнаружили, «нарушают» принципы, которые вы ожидали, скорее всего, просто будут иметь другие принципы.
Моя перспектива
Мне довелось наблюдать за несколькими основами кода, которые в значительной степени придерживаются принципов Роберта Мартина. Тем не менее, я на самом деле не утверждаю, что они правы , я могу только сказать, что они хорошо работают для нас - и что «мы» на самом деле является комбинацией по крайней мере
- объем и архитектура наших продуктов,
- целевой рынок / ожидания клиентов,
- как долго сохраняются продукты,
- методология разработки, которую мы используем,
- организационная структура нашей компании и
- привычки, мнения и прошлый опыт наших разработчиков.
По сути, это сводится к следующему: каждая команда (будь то компания, отдел или проект с открытым исходным кодом) уникальна. У них будут разные приоритеты и разные точки зрения, и, конечно, они будут делать разные компромиссы. Эти компромиссы и стиль кода, к которому они приводят, во многом являются вкусом и не могут быть доказаны как «неправильные» или «правильные». Команды могут только сказать «мы делаем это, потому что это работает для нас» или «мы должны изменить это, потому что это не работает для нас».
Тем не менее, я считаю, что, чтобы иметь возможность успешно поддерживать большие кодовые базы в течение многих лет, каждая команда должна согласовать набор соглашений по кодам, которые, по их мнению, подходят для указанных выше аспектов. Это может означать принятие практики Робертом К. Мартином другим автором или изобретение собственной; это может означать запись их формально или документирование их «примером». Но они должны существовать.
пример
Рассмотрим практику «разделения кода длинного метода на несколько частных методов».
Роберт C. Мартин говорит , что этот стиль позволяет для ограничения содержимого каждого метода на один уровень абстракции - как упрощенный пример, открытый метод, вероятно , состоит только из звонков частных методов , таких как verifyInput(...)
, loadDataFromHardDisk(...)
, transformDataToJson(...)
и , наконец sendJsonToClient(...)
, и эти методы будут иметь детали реализации.
- Кому-то это нравится, потому что читатели могут получить краткий обзор шагов высокого уровня и выбрать, какие детали они хотят прочитать.
- Некоторым людям это не нравится, потому что, когда вы хотите знать все детали, вы должны прыгать в классе, чтобы проследить за ходом выполнения (это то, на что, вероятно, ссылается JacquesB, когда он пишет о добавлении сложности).
Урок: все они правы, потому что имеют право иметь мнение.