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

Об этой статье

Это часть моей серии статей, в которых я по главам просматриваю «Чистую архитектуру» Роберта Мартина и делюсь своими мыслями, анализом и накопленными мною знаниями.

Дизайн и архитектура

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

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

Сведем к минимуму усилия

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

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

Медленно, но уверенно

Далее возникает вопрос. Как получается, что во многих случаях, когда проект становится все больше и больше, и все больше программистов присоединяется к команде разработчиков, вывод LOC (строки кода) остается в некоторой степени постоянным? Разве не должно увеличиваться количество разработчиков?

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

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

Единственный способ ехать быстро - хорошо ехать.

Избегайте самоуверенности

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

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

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

Резюме

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