Насколько велик следующий метод Java?
1
2
3
4
5
|
public Collection getDescription() { SystemLibrary systemLib = registry.get(SystemLibrary. class ); Analysis analysis = systemLib.getCurrentAnalysis(registry); return getDescription(analysis); } |
Этот простой метод находит какую-то системную библиотеку, извлекает анализ и возвращает описание этого анализа .
Но насколько большой вы бы это сказали? Вы бы сказали, что это 3 строки кода? Если да, то вы бы сказали, что следующий поведенчески эквивалентный метод имеет длину 2 строки кода? И это лучше, потому что это короче?
1
2
3
4
|
public Collection getDescription() { Analysis analysis = registry.get(SystemLibrary. class ).getCurrentAnalysis(registry); return getDescription(analysis); } |
Или вы бы сказали, что два вышеупомянутых варианта имеют одинаковый размер, потому что оба по сути вызывают одни и те же методы? Или что они имеют одинаковый размер, потому что оба имеют три обязанности, независимо от форматирования. Или потому, что они несут только одну ответственность: возвращение описания анализа?
Возникают путаницы с размерами методов и имеют значение. Они возникают потому, что проекты с самого начала не могут согласовать объективную единицу измерения. Они имеют значение, потому что сохранение малых методов является наиболее фундаментальным из структурных принципов SIPT, для которого существуют объективные доказательства снижения затрат.
Одна неинтуитивная мера размера, на которую стоит обратить внимание, — это количество байт-кода, до которого компилируется метод. Подождите! Прежде чем убить этот браузер и удалить его навсегда, подумайте…
Конечно, немногие Java-программисты знают или заботятся о том, чтобы вышеуказанный метод компилировался в 35 байтов (это так). Но использование байт-кода имеет огромное двойное преимущество: он абсолютно объективен (программистам больше никогда не придется мучиться с тем, является ли метод длиной в 2 или 3 строки), а сценарии и анализаторы могут собирать информацию автоматически и непрерывно.
Кроме того, программистам никогда не приходится учиться делать что-то столь же нелепое, как компиляция Java в своих головах.
Допустим, ваш проект согласен ограничить размер метода до 50 байтов. Дебора быстро — в течение нескольких минут — обнаруживает, что 50 байтов — это примерно 5 строк кода по ее традиционному стандарту измерения строки. Таким образом, она держит свои методы длиной в 4 строки кода, и новичкам проекта никогда не придется стучаться в ее дверь. (Посмотрите, сможете ли вы развить этот навык менее чем за минуту, здесь .)
Дэнни, с другой стороны, считает, что 50 байтов — это 6 строк кода, в соответствии с его стилем программирования, поэтому его методы сохраняются в 5 строках. До тех пор, пока оба удовлетворяют сценарию (и соответствующему автоматизированному вооружению), который анализирует скомпилированный код при каждой регистрации, тогда менеджеры проектов могут бездействовать, зная, что качество — по крайней мере для этого конкретного свойства кода — является безопасным.
Конечно, иногда методы отражают их хозяев и начинают выпячиваться в талии. Когда размер метода начинает увеличиваться, политика, по которой ваш проект интерпретирует статистику, становится решающей.
Практические проекты понимают важность как небольших методов, так и доверия программистов к некоторой гибкости. Практические проекты не требуют, чтобы все методы были маленькими, только чтобы они были небольшими в среднем и что — что еще более важно — эта средняя величина не имела тенденцию к росту без ограничений.
Допустим, проект решает, что средний метод должен иметь длину менее 50 байтов. Затем, если средний размер метода колеблется в 47 байтов в длину, проект может позволить команде внести чуть большие изменения, в результате чего среднее значение достигнет 48 байтов. (Хотя некоторые программисты гордятся никогда, никогда не увеличивая средний размер метода, независимо от того, насколько он низок.)
Но проект не позволит — не должен — позволить какой-либо команде перетаскивать эту цифру до 50 байт или более.
50 байтов ?! Ты сумасшедший!
Как вы думаете, 50 байтов (скажем, 5 строк кода) слишком мало? Считаете ли вы невозможным, чтобы любой крупный программный проект на Java мог иметь такой маленький средний размер метода?
Ваш проект использует Дженкинс ? Среднее значение 15,089 методов Дженкинса составляет всего 29 байт. Это примерно 3 строки кода.
На самом деле современные проекты имеют мало проблем с поддержанием низких порогов. Таблица 1 показывает список популярных программ на Java и их средние размеры в байт-коде.
программа | Средний размер метода (в байтах) | программа | Средний размер метода (в байтах) |
Нетти | 20 | ActiveMQ Broker | 32 |
JUnit | 23 | весна | 40 |
верблюд | 27 | Log4J | 40 |
Дженкинс | 29 | Кот (койот) | 44 |
Спойклин Соис | 29 | Cassandra | 53 |
Распорки | 30 | Lucene | 55 |
FitNesse | 31 | Работник зоопарка | 55 |
специалист | 35 | Catalina | 57 |
Таблица 1: Средние размеры метода в байт-коде.
Во всяком случае, 50 байтов могут быть слишком щедрыми. Возможно, 40 байтов будет лучше. Или 30
Резюме
Размер имеет значение, потому что большие методы стоят дороже, чем меньшие. Это не единственное, что имеет значение — множество других основополагающих структурных принципов ждут своего часа — но оно щедро возмещает усилия, приложенные для того, чтобы держать его под контролем. Выбор объективного и автоматизированного процесса измерения, а также общее согласие с пороговым значением, выше которого никто не должен подниматься, гарантируют, что такие инвестиции принесут свои плоды.
Ссылка: | Мой метод выглядит большим в этом? от нашего партнера JCG Эдмунда Кирвана в блоге о программном обеспечении. блог. |