Какой размер вашего класса? - Насколько большой слишком большой?
У всех, кто пишет код, была проблема - каким должен быть идеальный размер моего кода в классе / методе / функции.
Это отличается от каждого разработчика. Стив МакКоннелл в своей книге Code Complete пишет, что, как правило, 30 лет:
Если элемент состоит из более чем 30 подэлементов, весьма вероятно, что существует серьезная проблема:
- a) Методы не должны иметь в среднем более 30 строк кода (не считая пробелов и комментариев).
- б) Класс должен содержать в среднем менее 30 методов, в результате чего получается до 900 строк кода.
- в) Пакет не должен содержать более 30 классов, то есть до 27 000 строк кода.
Исследования показывают, что количество строк кода является основой качества и сложности программного обеспечения, которое вы создаете. Настоящая ценность таких рекомендаций, как Правило 30, заключается в том, что вы просматриваете код и выявляете риски и затраты.
Слишком много строк кода будет сложно скомпилировать и протестировать. Однако не существует идеальных показателей, измеряющих жирность класса. Он основан не только на «мнении», он основан на результате десятилетий практики. Проверки кода помогают выявлять и исправлять проблемы в базе кода.
Неофициальные обзоры могут выявить 20–30% дефектов кода. Исследования, проведенные в IBM, HP, Microsoft и других местах, показывают, что обнаруживать ошибки в проверках кода в несколько раз дешевле, чем путем тестирования. И продолжают поступать доказательства, подтверждающие, что проверки кода работают.
Horus, платформа инженерного управления, помогает проанализировать строки кода, которые пишутся, и то, что они значат для разработчиков, пишущих его, риски и затраты, связанные с этим, для руководства среднего и высшего уровня, независимо от предметной области, уровня зрелости организация или этап жизненного цикла, на котором они применялись.