Меньше, чем сейчас.
Вступление
В прошлой жизни, прежде чем стать разработчиком программного обеспечения, я был пехотинцем в армии США. Я обычно проходил 12 миль за один раз с примерно 45 фунтами снаряжения. Однажды мы прошли 20 миль. Я не спал 3 дня подряд, патрулируя.
Это были долгие-долгие мили и долгие-долгие дни.
Но даже этот опыт не мог подготовить меня к тому, что я недавно столкнулся с чудовищной функцией, состоящей из 2000 строк, с одинарным интервалом, которая обрабатывает критически важную логику в приложении нашей команды.
Было 12 аргументов, включая kwargs, десятки переменных локальной области видимости, которыми манипулируют по-разному, и ужасающие комментарии вроде «Надеюсь, это не вернется и не укусит меня…»
Раньше я проходил эти 12-мильные марши менее чем за 3 часа, но я знал, что потребуется гораздо больше времени, чтобы понять эту функцию, уменьшить ее ущерб и рефакторинг. Может, целую неделю. Может, всю мою жизнь.
Я здесь отчасти шучу. Только частично.
Долгие функции свидетельствуют о потере контроля
Длинные сложные функции, подобные описанной выше, свидетельствуют о том, что разработчик потерял контроль над этим кодом.
Мы кузнецы логики, работающей на кремнии, и для создания сложных систем мы должны сохранять жесткий контроль над нашими инструментами и материалами.
Первоначальный разработчик этой гигантской функции явно потерял контроль.
Они отказались от поводья и позволили лошади вести себя сам.
Вместо того, чтобы сгибать материалы по своему вкусу, они сгибали проявитель.
Последствия долгих функций
Чем крупнее функция и сфера ответственности, тем сложнее ее отлаживать, обновлять и рефакторинг.
По мере роста функции в какой-то момент разработчики будут слишком напуганы, чтобы менять ее, опасаясь что-то сломать. В отсутствие тестов внести такие изменения еще сложнее.
В такой ситуации, когда функция-переросток является неотъемлемой частью работающего приложения, изменение кода в соответствии с вашими более крупными целями становится практически невозможным.
Рекомендации по длине функции
Сделайте их маленькими. Сделайте их простыми.
Если вы боитесь, что ваши функции будут слишком маленькими, вам не о чем беспокоиться. На сегодняшний день более серьезная угроза заключается в том, что ваши функции становятся слишком большими.
Если ваши функции состоят всего из нескольких строк, имеют описательные имена и организованы таким образом, чтобы не требовать пояснений, тогда это прекрасно.
Может ли функция быть слишком маленькой?
Есть важное предостережение в отношении стремления к меньшим и более простым функциям. По мере того, как функции становятся меньше, в определенный момент код становится настолько простым, что разделение его на собственную функцию фактически затрудняет работу.
См. Функцию ниже:
Приведенный выше код не может быть собственной функцией. Он усложняет то, что на самом деле очень просто. Звонить items_list.append(item)
намного лучше.
Практическое правило
Как правило, функции должны быть настолько малы, насколько вы можете их создавать, без названия просто повторяйте, что функция делает.
Видите ли вы в приведенном выше примере, как имя функции просто повторяет ее реализацию? Эта избыточность делает менее понятным, что делает код.
Сосредоточьтесь на написании кода, который ясно сообщает о своей цели, и вы не ошибетесь.
Длина функции и выбор языка
Языки более низкого уровня, такие как C и C ++, обычно требуют больше строк кода, чем языки более высокого уровня, такие как Python, для той же задачи. Некоторые языки, такие как Java, многословны по дизайну и соглашению.
Независимо от языка, если ваши функции состоят из 30–50 или более строк, они почти наверняка выиграют от разделения.
Контрольный список из 3 частей для написания функций
Если вы пишете новый код или разбиваете старые функции на более мелкие блоки, есть несколько полезных проверок, которые вы можете использовать.
Каждая функция должна иметь:
- Одна ответственность - Принцип единой ответственности гласит, что функция или класс должны иметь одну ответственность. Если функция имеет составные
if
операторы и многочисленные переменные разных типов, то она, вероятно, обременена более чем одной обязанностью. Разделите это на части. - Один уровень абстракции. Функции более высокого уровня и общедоступные функции не должны также выполнять действия более низкого уровня, такие как непосредственное управление структурами данных. Отделите публичное поведение высокого уровня от внутренних реализаций более низкого уровня.
- Минимальное количество аргументов. Функция с множеством аргументов сигнализирует о росте сложности и, вероятно, нарушает одно из приведенных выше правил. Чем больше аргументов, тем труднее использовать и поддерживать функции. Постарайтесь, чтобы ваши аргументы не превышали 2. Если функция имеет 3 или более аргумента, ищите возможности разделить ее части.
Удачного кодирования!
Больше контента на plainenglish.io