У меня есть чувство dejavu при чтении [Что делать с исходным файлом на С++ в 11000 строк?], но я не думаю, что могу начать принимать меры самостоятельно, так как у меня нет полномочий принимать меры. Поэтому я считаю, что первым шагом является убедить людей в организации, что большой кусок кода плохой.
У меня похожая ситуация, когда есть один класс с 11975 строками кода, и каждый раз, когда появляются новые функции, существует высокая вероятность того, что этот класс станет больше и больше.
У вас есть мои симпатии. Любой класс, который является таким огромным, неизбежно нарушает принцип единой ответственности, что затрудняет его поддержание.
Мой лучший совет - привести пример:
Ваш код будет сиять как маяк по сравнению с устаревшим кодом, и ваша команда поймет, какой код проще поддерживать.
11975 (или это уже 12000 уже:)) строк реализации класса. Это плохо? Черепно выглядит так. Но...
Это зависит. Обычно классы, которые реализуют шаблон посредника или шаблон "Фасад", имеют тенденцию быть очень большими. У них очень сложный протокол маршрутизации/связи. "Бог" как классы также имеют тенденцию быть очень огромными и монолитными. Короче говоря, класс A может быть большим, но это может быть не проблемой.
Поэтому вместо фокусировки на LOC в качестве параметра, сосредоточьтесь на функциональности/дизайне класса. Является ли класс нарушением принципа единой ответственности? Только LOC не может быть единственным решающим фактором для заключения, если класс действительно огромен. Посмотрите на другие показатели, например. Cyclomatic Complexity.
Однако, если вы сделаете вывод, что это действительно плохо в контексте вашего проекта, у вас должна быть веская причина убедить соответствующих заинтересованных сторон. Например,
а. У этого класса много ошибок?
б. Устанавливаются ли исправления этого класса всегда с ошибками регрессии? (Высокая связь, низкая когезия?)
с. Как долго устраняются дефекты в этом классе? Как это соотносится с другими модулями?
д. Создайте несколько UML-диаграмм для этого модуля, чтобы проиллюстрировать важные проблемы (например, связь).
е. Прочитайте как можно больше о показателях/обратитесь к своей команде Quality/Metrics/QA и создайте достаточные точки данных. Пример показателей OOAD: здесь, но я уверен, что их много.
ИЗМЕНИТЬ 2 (некоторые незначительные изменения)
ф. Получите первоначальную поддержку от некоторых ключевых заинтересованных сторон в вашей сфере контроля. Затем, получите, тот, кто может хорошо представить эти факты!. Я видел, как многие вещи терпят неудачу на этом этапе!
Удачи!
Скажите, чтобы они суммировали то, что класс делает\представляет через минуту.
Если этот класс состоит из множества более мелких методов, и эти методы фактически принадлежат классу i.e, они являются целыми друг к другу и классу, то это не обязательно плохо.
Сам факт того, что класс большой, не делает его автоматически плохим.
Что более важно, так это избегать так называемого "божественного класса", который содержит много методов, которые не имеют концептуального отношения друг к другу или к самому классу.
Сохранение размера отдельных методов также стоит сосредоточить внимание, потому что большинству разработчиков потребуется "загрузить" целый метод в свои мозги за один раз, а не весь класс. Таким образом, более краткий метод, который проще для разработчиков поддерживать.
Вы должны собрать показатели о количестве проблем с поддержкой, которые можно проследить до кода в этом классе. Кроме того, как долго разработчики проводят изменения в этом классе по сравнению с другими меньшими классами? Когда у вас есть эти показатели, вы можете лучше объяснить, почему такой большой класс плохой.
В ситуации большого класса с небольшим количеством больших методов я бы использовал методы рефакторинга, описанные в книге Мартина Фаулерса, а также чтобы не вводить новые ошибки.
После того, как вы переработали огромный метод до нескольких простых понятных методов и получили успешные модульные тесты, просто продемонстрируйте это своим коллегам.
На данный момент, если ваши коллеги не согласны или не видят общего улучшения понимания и ремонтопригодности реорганизованного кода, вы имеете дело с политической проблемой/личностью. В этом случае это зависит от вас, если вы хотите продолжить работу в такой среде.
Наличие огромного класса неплохое. Если программист может это понять и понять, то это идеальный класс. Если программист полностью потерян, когда он пытается изменить или добавить что-то в класс, то это плохо.
С программированием все зависит от предпочтений. Если они предпочитают иметь один класс из 11975 строк кода, и они могут управлять им, тогда это их выбор.
Но да, это вообще плохо.
Здесь моя первоначальная реакция:
Здесь нет предложений, кроме рефакторинга, что вы можете. Найдите любую функцию, нарушающую D-R-Y, а затем очистите ее.
Убедить кого-либо изменить существующую реализацию (особенно если "она работает" ) непросто.
Я бы начал с того, чтобы просить противников выполнить тривиальную задачу (по моему опыту с такими экстремальными классами, я считаю, что существует несколько достаточно больших методов), например, добавление чего-то к одному из огромных методов. Он должен научить их одному уроку: найти правильное место будет очень больно. Затем вы можете спросить: "Представьте, что вы поддерживаете этот класс, это будет простая задача?".
Вы можете попробовать другой подход, но он, вероятно, не сработает: попросите их написать unit test для этого кода. Или просто попросите их подумать о любом...
В основном эти люди не владеют знаниями по oops? Выполнение OOAD перед запуском проекта - это лучшая идея избежать этого, из моего опыта я могу сказать, что каждый программист не знает об этом, поэтому, очевидно, они не могут написать лучший код.
Вот где разница с программистом и аналитиком -