Одним из основных аспектов программирования также является модульность. Чтобы убедиться, что код не сложный, простой для понимания, код можно тестировать, все это зависит от того, насколько ваш код модульный.
Просто для обсуждения, если мы подумаем, зачем нам нужно делать модульный код, писать так много разных методов и организовывать их, в качестве аналогии, просто подумайте о своих гардеробах. Если вы сложите всю свою одежду в одну большую коробку, что произойдет?
Пара проблем, с которыми вы столкнетесь, будет
1. Нелегко найти, когда вам это нужно
2. Трудно понять на вид
3. Не выглядит чистым.
4. Крайне невозможно, чтобы другой человек расшифровал его J
Это будет похоже на паутину. Те же проблемы применимы даже для неорганизованного кода. Недостаточно просто достичь функциональности. Я видел, как многие разработчики говорили или торопились реализовать функциональность пользовательской истории и отказывались от всех этих лучших практик. Думаю почистить позже. Я не думаю, что когда-нибудь придет время вернуться и почистить ваш код, если только технический долг не вырастет настолько, что начнет вас беспокоить.
Во-первых, даже рефакторинг кода снова и снова сделал бы код хрупким. Это все равно, что наклеить на рубашку несколько заплаток вместо одного куска ткани. Долговечность и надежность будут потеряны при слишком большом рефакторинге. Некоторые из других недостатков будут
1. Усилия по рефакторингу, вещи могут не рухнуть для рефакторинга и в итоге будет слишком много компромиссов.
2. Попытка QA снова и снова регрессировать после рефакторинга.
3. Зависимый код может потребовать рефакторинга, такого как скрипты автоматизации тестирования, зависимые методы и т. д.,
Таким образом, принципы, которым следует следовать, будут
1. Сначала дизайн
2. Сначала делайте это правильно
Когда возникает проблема, важно продумать дизайн, а затем организовать код в соответствующие более мелкие методы. Один из главных принципов дизайна, которым он должен следовать, — «Единая ответственность». Каждый метод должен быть написан для достижения единой ответственности.
По мере того, как вы добавляете больше ответственности, сложность метода будет увеличиваться. Все возможные пути кода усложнили бы метод. Их можно легко измерить с помощью любого статического анализатора кода.
Просто вернемся к оригинальной аналогии с беспорядочными шкафами. В случае организованных гардеробов все ваши рубашки, брюки, галстуки, ремни, бумажник, часы организованы в соответствующие отсеки. Каждый из этих ящиков служит одной ответственности. Таким образом, все вышеперечисленные проблемы будут решены. Точно так же наш код должен быть модульным в соответствующих отсеках (методах), чтобы они несли единую ответственность за каждый метод.
Таким образом, ваш код также
1. не сложный
2. Простота тестирования
3. Простота отладки
4. Простота повторного использования кода, поскольку он является модульным, такая же функциональность может потребоваться и в других случаях использования.
5. Также легко понять, улучшить, повторно использовать другой человек.
Другой подход, которому я буду следовать, касается декорирования методов алгоритмами. Напишите алгоритмы для достижения требуемой функциональности. Возможно, поместите их в комментарии к коду и начните добавлять методы для каждого из этих алгоритмов.
Метод будет содержать несколько шагов для достижения желаемого результата.
Шаг 1: принять входные данные
Шаг 2: проверьте входные данные
Шаг 3. Выберите оператор для вычисления
Эти шаги также могут быть организованы таким образом, чтобы их было легко идентифицировать, просто просматривая журналы. Журналы приложений должны быть похожи на вашу ЭКГ, чтобы найти аномалии в работе вашего сердца. Любые аномалии в вашем методе можно определить, просто просмотрев журналы.
Подводя итог, убедитесь, что ваше мышление для решения проблемы начинается с проектирования, ваш подход к решению проблемы будет основан на алгоритме, а каждый модульный метод следует принципу единой ответственности.
