… иначе как мне улучшить свой код?

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

Допустим, хороший код — это то, что работает так, как задумано, приемлемым образом. Но само по себе это не делает дизайн хорошим. Существует достаточно паттернов кодирования, антипаттернов, парадигм и анархистских теорий, которые мы все любим или ненавидим. Множество статических контролеров могут просмотреть ваш код и сказать вам, когда ваш код кажется выплюнутым кучей обезьян, пытающихся написать Шекспира после прочтения Ницше, или он просто неразборчив. Большинство этих идеологий выходят за рамки языков программирования и могут быть отнесены к разделу «Дзен и искусство проектирования программного обеспечения». Но со всем этим изобилием доступных парадигм, как выбрать правильную? Как запомнить все это, когда на самом деле собираешься кодировать? Размышление о заменяемости кода — это один из способов, который можно использовать в качестве руководства при разработке программного обеспечения.

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

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

Эффективно организованный, хорошо изолированный

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

Заменяемый значит улучшаемый

Мы постоянно развиваемся, становимся лучше. Почему наш код не должен от этого выигрывать? Любой, кто работал над проектом, длящимся дольше, чем продолжительность жизни мыши, слышал об устаревшем коде и техническом долге. Большая часть того, что мы делаем как инженеры, — это улучшение и исправление. Мы боимся менять большие части системы, потому что они сильно запутаны, и даже небольшие фрагменты кода могут поставить большие проекты на колени. Заменяемая конструкция означает, что мы можем перестраивать вещи изолированно и медленно улучшать нашу систему. Кроме того, это позволяет нам использовать другие/более новые технологии и инструменты и улучшать систему, не перестраивая всю чертову штуку.

Зачем перепроектировать то, что вы собираетесь заменить?

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

Тесты, тесты и еще раз тесты

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

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