Как Вы сохраняете себя и Ваших коллег от создания огромных классов [закрытыми]
7 ответов
Думаю, это зависит от ваших внутренних процессов в большей степени.
В моей компании мы практикуем экспертную оценку, и весь код, который будет скомпилирован, должен сопровождаться другим разработчиком, которому вы должны объяснить свой код.
Временные ограничения - это одно, но если я просматриваю код с ужасно длинными классами, я не соглашусь на регистрацию.
Поначалу к этому трудно привыкнуть, но, в конце концов, так лучше для всех.
Кроме того, очень помогает наличие старшего разработчика, который является сторонником хорошего дизайна класса, готов и может приводить примеры.
Наконец, мы часто проводим сеанс программирования «покажи и расскажи», где мы можем продемонстрировать нашу работу коллегам, нам следует не делать этого с помощью уродливого кода!
Другое предложение - делать только то, о чем просят. Не играйте в игру «Что, если» и не пытайтесь придумать решение. За этим стоит идея «Держите это просто, глупо».
Единственным наиболее важным шагом для меня, чтобы избежать больших классов, которые часто нарушают SRP, было использование простой структуры внедрения зависимостей. Это освободило меня от слишком много размышлений о том, как связать все вместе. Я использую внедрение конструктора только для того, чтобы не допустить циклов в дизайне. Такие инструменты, как Resharper, помогают инициализировать поля из аргументов конструктора. Эта комбинация приводит к почти нулевым накладным расходам на создание и подключение новых классов и неявно побуждает меня более подробно структурировать поведение.
Все это работает лучше всего, если данные хранятся отдельно от поведения, и ваш язык поддерживает такие конструкции, как события, которые можно использовать для разделения обмена данными, идущими в нисходящем направлении графа зависимостей.
Длинные классы - один из многих возможных неприятных запахов кода.
Исправление слишком больших классов путем создания множества маленьких может создать свои собственные проблемы. Новым инженерам в вашем проекте может быть трудно следить за потоком кода, чтобы понять, что и где происходит. Одним из артефактов этой проблемы могут быть очень высокие стеки вызовов, выполнение которых может быть разделено на множество небольших классов.
Мы - магазин java и maven, и один из ... Думаю, можно сказать, что судебно-медицинские методы, которые мы используем, - это отличные FindBugs. , Плагины PMD и javancss. Все будут предупреждать о чрезмерной длине метода, а вычисления цикломатической сложности могут открыть глаза.
использовать некоторый статический анализ кода инструменты в ваших автоматических сборках и писать / настраивать / использовать некоторые правила, чтобы, например, кто-то должен был написать обоснование, когда он / она его нарушает ..
Используйте такой инструмент, как Resharper, и команду «Извлечь метод».