Нормально ли с точки зрения хорошей архитектуры иметь метод на 50-60+ строк? [закрыт]

#java #json #jackson

        
             
                
                    
                        
                            Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы на него можно было дать ответ, основанный на фактах и цитатах, отредактировав его.
                        
                        Закрыт 2 года назад.
                                                                                
           
                
        
Есть метод, на вход которого приходит список Json - строк. Из них нужно распарсить
 данные, преобразовать их к рабочему виду и склеить в один текст, который уже уйдёт
на фронт. Использую Jackson, привожу Json к дереву, из дерева достаю нужное. 
Нормально ли с точки зрения хорошей архитектуры всё это делать в одном методе, который
будет содержать минимум 50-60+ строк, либо нужно как-то красиво разделить задачу на
несколько методов и при этом лишний раз не передавая кучу данных между методами?

P.S Прислушался к ответчикам и разделил функционал на два метода: один отвечает за
парсинг, а другой - за форматирование. 
P.S.S Не вижу смысла редактировать вопрос, так как изначально и не предполагалось
найти железную истину, но хотелось услышать мнение опытных разработчиков. Всем спасибо! 
    

Ответы

Ответ 1

Р. Мартин в своей книге "Чистый код" пишет: 


  Желательно, чтобы длина функции не превышала 20 строк


М. Фаулер в книге "Рефакторинг" называет длинные методы в числе основных признаков
"кода с душком" и советует делать их как можно короче. Он пишет 


  Мы придерживаемся эвристического правила, гласящего, что если ощущается необходимость
что-то прокомментировать, надо написать метод. В таком методе содержится код, который
требовал комментариев, но его название отражает назначение кода, а не то, как он решает
свою задачу. Такая процедура может применяться к группе строк или всего лишь к одной
строке кода.


Лично я с ними совершенно согласен, стараюсь не писать методов длинее 10-20 строк,
часто методы содержат лишь одну строку кода: 

  exp2 = findBinaryExponent(mant10, exp10);


понять намного проще, чем 

  exp2 = (long) Math.floor( exp10 * LOG2_10 + log2(mant10) );  // find binary exponent


Метод findBinaryExponent() из первого примера кода содержит лишь вычисление выражения,
приведенного во втором примере. 

Фаулер описывает конкретные приемы изменения кода, позволяющие улучшать качество
(методы рефакторинга), напр. 


  Преобразуйте фрагмент кода в метод, название которого объясняет назначение этого кода


и подробно описывает технику их исполнения, позволяющую избегать ошибок. 

В обеих упомянутых книжках много полезных соображений о том, как писать код и как
его улучшать, чтобы он был понятным, модифицируемым и легко сопровождаемым. Сильно
рекомендую их почитать. 

Современные IDE позволяют автоматизировать многие приемы рефакторинга, в т. ч. выделение
фрагмента кода в отдельный метод. Советую с этими возможностями разобраться и использовать их. 

За исключением очень редких, экзотических, случаев, удобочитаемость программы намного
важнее, чем скорость ее выполнения. Давно сказано, что код пишется один раз, а читается
многократно. Где-то мелькали результаты исследований, показавших, что программист тратит
на написание нового кода во много раз меньше времени и сил, чем на чтение чужого и
своего же, ранее написанного, кода. Это значит, что улучшение кода в смысле его понятности
означает повышение производительности. Мой личный опыт и наблюдения вполне подтверждают
это. 

Однако, как верно замечено в комментариях к вопросу, никакие правила не должны отменять
или заменять здравый смысл. Бывают ситуации, когда дробить длинные методы на мелкие
части не только не полезно, а прямо вредно. В комментарии приведен пример программирования
контроллеров, подобные ситуации также часто бывают при инициализации сложных окон в GUI.


Ответ 2

Метод должен выполнять одну задачу. Так его читать и тестировать удобно. Если в нем
десятки строк, значит в нем смешение функционала. 

А, вообще, лучшим ответом является практика, когда через некоторое время (месяц,
два, три... когда уже контекст подзабылся) поднимаешь свой старый код, и если его нужно
разбирать больше (условно) 5 секунд, значит с кодом, точно не все в порядке. 

Это же верно и для классов. Очень не айс потом разбирать огромные супер-классы, в
которых методы "хитро" взаимосвязаны друг с другом.

Опять же, большие методы (и, как следствие, классы) - могут быть следствием попытки
думать линейным алгоритмом, а не взаимодействием объектов.