Функции — это основа любой программы. Однако всегда ведутся споры о том, какой длины должна быть функция. Некоторые говорят, что не более 30 строк кода, некоторые говорят, что он не должен иметь отступов, другие говорят, что он должен делать одну и только одну вещь, а общая длина не имеет значения. Лично я согласен с боковым. Все эти предложения имеют одну общую черту: они представляют собой методы управления функциями. Однако как определить, выполняет ли метод одно и только одно действие? Как легко определить, правы ли вы? После многих лет написания функций я придумал способ определить, когда создавать функцию, а когда абстрагировать код.
Короче говоря, моя методика построена на SRP (Single Responsibility Principal). SRP — это принцип SOLID, который гласит, что блок кода делает одну и только одну вещь. Короче говоря, вы не хотите, чтобы функция выполняла более одной функции. Рассмотрим этот пример, давайте представим, что у нас есть метод, который меняет цвет и текст фона при нажатии. Рассмотрим псевдокод,
Эта притворная функция изменит цвет фона и фонового текста. По большей части это сработает; однако давайте представим, что наш босс вернулся после трехдневного запоя и решил, что нужно добавить новую кнопку, но проблема в том, что эта кнопка только меняет текст. Это оставляет нас в чем-то вроде рассола. Мы могли бы добавить новую функцию, подобную следующей:
Это сработает, но мы как бы нарушили правило «Не повторяйся». У нас есть background.text = green в двух местах. Что происходит, когда мы хотим изменить фоновый текст на синий? Теперь нам нужно изменить несколько функций, чтобы добиться этого. Это нехорошо, потому что общее эмпирическое правило при написании кода заключается в том, что после того, как код написан, вы больше никогда не захотите к нему прикасаться. Скорее всего, вы никогда не достигнете этой цели, но это хорошая цель, к которой стоит стремиться. Каждый раз, когда вы изменяете часть существующего кода, он должен считаться нестабильным, а это означает, что вы должны тестировать его снова. Для некоторого кода это может не иметь большого значения, но для более сложного кода это может легко стать кошмаром, особенно когда есть странные пограничные случаи. Мы также могли бы сделать что-то вроде управляющих операторов, но это загромождает код. Итак, что нам делать? Более удобным решением было бы разделение обязанностей функции. Давайте посмотрим на это решение, которое будет делать то же самое.
Первое, что нужно сделать, это посмотреть на слово «и». Слово «и» является союзом, означающим, что оно соединяет вещи вместе. Как мы установили в последних двух примерах, разделение функций на части — это плохо. Это либо приведет к тому, что код станет загроможденным, потенциально нестабильным или повторяющимся. Итак, как мы можем использовать это в своих интересах? Ответ прост: когда мы проектируем наше программное обеспечение, мы должны проектировать наши функции таким образом, чтобы они представляли собой законченное предложение без слова «и». Давайте посмотрим на примере, как мы можем это сделать.
В данном случае мы добавили две новые функции. Одна функция отвечает только за изменение цвета фона, а другая отвечает только за изменение текста. Это делает программу более гибкой для будущих изменений. Мы могли бы легко добавить третью кнопку, которая меняет только цвет фона. Мы могли бы легко изменить цвет текста, просто изменив одну функцию вместо двух.
Таким образом, наша кодовая база в долгосрочной перспективе будет менее подвержена ошибкам, поскольку вы не будете изменять старый код. Итак, при написании функции я нашел хороший способ определить, много ли делают ваши функции, — использовать фразу.
Эта функция выполняет ‹функциональность›
Если вам нужно использовать слово «и» в функциональном блоке, все после «и» нужно разбить на отдельные функции. Вы получите больше функций; однако ваш код будет более модульным по своей природе. Таким образом, вы сможете легче менять модули и использовать менее модифицированный и нестабильный код.
Этот метод является скорее эмпирическим правилом, а не жестким правилом. Как и все остальное, им можно злоупотреблять. Тем не менее, я использую эту технику уже довольно давно, и должен сказать, что мои кодовые базы значительно улучшились. Я начал обучать этому методу своих студентов и могу сказать, что у студентов, которые используют этот метод, программы чище и легче для понимания. Я также принял это в своей профессиональной жизни, а также с аналогичными результатами. В целом, модульная кодовая база — это долговечная кодовая база. Я настоятельно рекомендую вам попробовать эту технику и посмотреть, как улучшатся ваши кодовые базы.
