Don’t Be That Guy, Write Better Functions
Не будь таким, пиши функции лучше
Однажды утром, когда я готовил себе завтрак на кухне в офисе, вошел мой коллега, и мы начали небольшую беседу. Я буду называть его Фредди. Фредди работал в компании несколько недель, поэтому я, естественно, спросил его, как дела. То, что он сказал, до сих пор не выходит у меня из головы. Он начал со вздоха и рассказал о том, как у него были проблемы с пониманием кодовой базы, которую он унаследовал в конкретном проекте, над которым он работал.
Фредди провел много времени, рассказывая мне о том, как он стал раздраженным и уставшим от того, что смотрел на чудище функций, которое не имело смысла. Я спросил его, пытался ли он проверить с одним из своих товарищей по команде, которые работали над программным обеспечением до него, на что он ответил с легким смешком и сказал следующее: “(имя товарища по команде) также не имел понятия. Он уставился на него так же пристально, как и я, и просто сказал, что не писал.”
После разговора с Фредди я сказал себе две вещи. Первое: “Не будь таким парнем!”. То есть не уподобляйтесь человеку, который заставил страдать Фредди. Во-вторых, “написать функции лучше”. Это единственный способ не быть похожим на того парня. Я уверен, что есть бесчисленное множество Фредди, которые должны унаследовать, понять и рефакторить плохо написанные функции в программных проектах. Хорошо разработанное программное обеспечение заботится о небольших единицах (или методах), таких как функции на микроуровне, а не об общей функциональности на макроуровне.
Я написал много плохих функций за мое короткое время кодирования, и поэтому я стал обдумывать улучшение в этой конкретной области. Ниже приведены некоторые рекомендации и подходы, которые я научился (и до сих пор учусь) применять от опытных профессионалов, коллег и других авторитетных источников.
Understanding Functions
Понимание Функций: Определение для себя чего-либо всегда является хорошим местом для начала работы.
Функции-это запрограммированные процедуры. Если вы ищете что-то более многословное, вам придется перейти в Google. Программные системы будут состоять из функций в различной степени. Возможно, вы разрабатываете программное обеспечение с объектно-ориентированным дизайном, в котором функции будут жить внутри классов, составляющих систему, и эти функции действуют на состояние классов, в которых они живут. Или, может быть, ваша система является функционально ориентированной конструкцией, в которой система декомпозируется на набор взаимодействующих функций, действующих на централизованное состояние. Независимо от подхода, функции существуют, потому что нам нужно разложить нашу концепцию решения, и на очень низком уровне этой декомпозиции мы находим эти небольшие единицы, которые служат определенной цели.
Functions Should Be Small
Функции Должны Быть Небольшими: Сохранение малого размера упрощает не только чтение, но и понимание, тестирование, отладку функций. Нет конкретного количества строк. Некоторые эксперты сказали бы не более 15, другие сказали бы не более 25. Вероятно, это то, что вам придется решать в своей команде. Важно помнить о причинах принципа сохранения функций малыми.
Читаемость: функция обычно имеет подпись и блок-код, который выполняется при вызове функции. Наличие меньшего количества строк кода в блоке функции помогает легко прочитать и получить суть того, что функция должна делать.
Понятность: меньшие функции помогают уменьшить вероятность отклонения от основного назначения функции. Чем линейнее понятие или назначение функции, тем понятнее оно будет.
Тестируемость: короткие методы имеют меньше вариаций, что означает, что их легче тестировать
Вот пример функции, предназначенной для проверки валидности маркера носителя:
Functions Should Be Clean
Функции Должны Быть Чистыми: Более двусмысленно, вероятно, не получится. Однако речь идет не столько о стилях кода, отступах или длине имен переменных. Речь идет о понятности. Сможет ли Фредди взглянуть на вашу функцию, понять ее намерение и внести изменения, потеряв несколько дней работы?
Все сводится к измерению того, насколько обслуживаем ваш код, а обслуживаемый код формирует большую часть костяка обслуживаемого программного обеспечения. Я понимаю, что это другие атрибуты, которые будут использоваться для определения чистого кода, которые являются субъективными, и это то, что вы и ваша команда можете решить.
Functions Should Be Simple
Функции Должны Быть Простыми: Мой технический лидер часто говорил мне: “если это (функция) требует много усилий, вы останавливаетесь и переосмысливаете свое решение”. В нашей области усилия не всегда следует приветствовать, потому что чаще всего усилия порождают нечто сложное.
“При разработке программного обеспечения усилия не растут линейно по мере усложнения — они растут экспоненциально. Таким образом, проще управлять двумя наборами из четырех сценариев каждый, чем один с шестью. — — Абрахам Марин-Перес
Если мы сможем написать функции на основе модульного решения и сократить пути выполнения, которые имеет функция, будет намного легче понять, что они должны делать. Когда код сложно написан, его гораздо труднее понять, и такого рода недоразумения часто приводят к ошибкам.
Вот пример функции, которая проверяет, является ли полученный аргумент массивом строк:
Functions Should Have One Job (No Side Effects)
Функции должны иметь одну задачу(не должно быть побочных эффектов): Роберт Мартин лучше всего выразил это в чистом коде “ “ ваша функция обещает сделать одну вещь…”, и поэтому она должна. Наличие побочных эффектов только делает наш код менее читаемым из-за изменений в блоке кода, которые не служат одной конкретной цели. Наши функции должны быть основаны на детерминированном алгоритме, заданном определенным входом, он всегда возвращает один и тот же выход.
Возьмем следующий пример, функция предназначена для получения определенной даты и возврата недели, когда дата происходит в виде массива с объектами date.
Можно утверждать, что функция, как правило, имеет одну цель. Однако вы, возможно, заметили, что существует точка, в которой мы генерируем неделю на основе двух аргументов, объекта ( в данном случае объекта Moment) и дней недели (т. е. воскресенье, понедельник, вторник и т. д.). Таким образом, мы можем фактически создать новую функцию и сделать наши методы более линейными в их назначении.
Когда мы разделяем нашу функцию на две, мы имеем следующее:
В результате теперь программисту проще понять назначение наших функций, сделать для них тестовые наборы и при необходимости модифицировать.
That being said…
Это было сказано: Эти рекомендации не единственные, которым следует следовать, но они, безусловно, закладывают достаточно хорошую основу, помогая нам создавать высококачественный код при написании наших функций. Кроме того, написание хороших функций потребует практики, преднамеренного рефакторинга и еще одного набора глаз (экспертных оценок). Может показаться, что требуется много дополнительной работы для создания такого кода, но результаты себя оправдают. Edsger Dijkstra, Крестный отец программирования, сказал следующее,
“В программировании элегантность-это не ненужная роскошь, а качество, которое выбирает между успехом и неудачей.”
Не будь таким парнем, пиши лучше функции.
Translated: medium
Help us with your claps ;)
