Вы пишете слишком много кода?

Задайте себе эти шесть вопросов и узнайте

Для многих новичков код - это процесс написания if else операторов и попытки понять, как заставить все работать. В ходе этого процесса созданный код превращается в запутанного мамонта с неожиданными поворотами сюжета, которые могут соперничать с Красной свадьбой из «Игры престолов».

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

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

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

Насколько это функционально?

Как бы нам ни нравилась идея объектно-ориентированных шаблонов, функциональные идеологии также могут существовать внутри классов и методов. Функциональное программирование имеет дело с тем, как данные обрабатываются в зависимости от конкретной ситуации, и имеет сильное отвращение к зависимостям.

Зависимости - это неплохо, но слишком большое их количество может привести к нежелательной паутине.

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

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

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

Должен ли он быть публичным?

Не все должно быть глобальным состоянием или существовать как общественная функция. Иногда конфиденциальность кода - это хорошо; это может предотвратить смещение области видимости и обеспечить безопасность для ваших переменных.

Сделать все общедоступным легко, но вопрос доступности не в этом.

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

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

Вы слишком или недостаточно абстрагируетесь?

Иногда мы увлекаемся кодификацией бизнес-требований. Мы становимся одержимы идеей модульности или просто слишком увлекаемся попытками уловить сложную идею.

Излишняя абстрагирование происходит, когда мы пытаемся сделать наш код слишком модульным, потому что нам сказали, что это способ делать что-то. Недостаточное абстрагирование - это когда мы сталкиваемся со сложным набором правил, которые мы еще не совсем поняли, как упростить. К концу упражнения абстракция просто слишком утомительна для ума, чтобы ее можно было реорганизовать, иначе у нас просто закончилось время.

Итак, что такое правильная степень абстракции?

Цель абстракции - выявить четкие границы повторяемого кода. Необходимая степень абстракции возникает, когда мы не планируем чрезмерно возможное использование и не пишем ту же логику снова, но в другом пространстве области видимости.

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

Действительно ли ваши имена полезны?

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

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

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

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

Вы писали это раньше?

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

Или, возможно, кто-то написал это в другом месте. Вот где абстракция и рефакторинг становятся необходимыми для поддержания целостности вашего кода и предотвращения повторения.

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

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

Что именно вы пытаетесь запечатлеть?

У кода всегда есть цель. Он существует, чтобы что-то представлять. Возникает вопрос: что именно представляет собой ваш код?

Каков ожидаемый результат? Как нам достичь этого ожидаемого результата? Расплывчатость в названиях и функциональных процессах приведет к нестабильному коду, у которого нет четких границ или цели для существования.

Когда бизнес требует добавления новых элементов, это изменение вызвано ростом. Разрушит ли этот рост исходный компонент? Или он достаточно изолирован, с четкими границами, чтобы получить минимальное воздействие?

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

Последние мысли

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

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

На самом деле в коде не бывает «лучшего». Скорее, это то, что является наиболее эффективным и действенным для требований вашего проекта с учетом временных ограничений и имеющихся ресурсов.

Спасибо за чтение.