Хороший дизайн и архитектура программного обеспечения исходят от доски, а не от клавиатуры.
У меня есть странная привычка - я редко бываю за своим рабочим столом, когда у меня есть задача по программированию. Когда я не за своим столом, я в основном хожу или смотрю на доску в самой уединенной доступной комнате для фокусировки. Причина в том, что это помогает мне сосредоточиться; это помогает мне понять более широкую картину; это помогает мне лучше спроектировать решение. И после всех этих лет, как я понял, планирование кода даже важнее, чем собственно кодирование.
Большую часть времени мы, программисты, из энтузиазма и азарта спешим решать проблемы программирования. Как только документ с требованиями будет доступен, как только критерии приемки будут добавлены в пользовательскую историю, как только собрание закончится, мы просто запускаем IDE и начинаем кодирование, не так ли? Я был таким раньше, в течение первых двух лет моей карьеры. Потом я понял, что эта привычка на самом деле замедляет меня, а не ускоряет решение проблем. Вот как.
Возьмем пример - допустим, у нас есть простая проблема - прочитать данные из базы данных, отфильтровать / преобразовать / смоделировать их и показать пользователю на веб-странице. Чтобы это произошло, несколько лет назад я бы сделал следующее: 1. Создание классов модели данных, 2. Создание класса службы / оболочки базы данных, 3. Получение данных из базы данных в классе обслуживания с использованием моделей данных, а затем передача его на веб-страницу с помощью объекта модели представления. И вуаля, работа сделана, и я могу пойти домой и поиграть со своей собакой. :)
Теперь давайте посмотрим, что могло быть лучше в приведенном выше решении и что я пропустил - я не пытался найти, есть ли уже класс службы / оболочки, доступный в решении, который можно использовать повторно, я не проверял, есть ли модели могут быть повторно использованы или получены из любых существующих классов, я не думал о расширяемости, масштабируемости и производительности приложения, я не думал об использовании правильных структур данных, шаблонов проектирования и структурирования кода. Что ж, похоже, я многое пропустил только потому, что был слишком взволнован, чтобы решить проблему.
Если бы я подумал обо всем этом, приложение в целом было бы гораздо более организованным, стабильным и производительным, если не сказать больше. В большинстве случаев, когда мы спешим писать код, не думая и не планируя должным образом, мы упускаем все эти вещи, а когда приходит время выпустить биты в производство, мы сталкиваемся со всеми ошибками, связанными с производительностью и регрессом. Это в конечном итоге замедляет работу и задерживает доставку.
Теперь, осознав это, я попытался изменить свой подход к решению задач программирования. Что я делаю сейчас, так это то, что мне нужно время, прежде чем я начну писать код. Прежде всего, я пытаюсь выяснить, существует ли существующее решение проблемы, которую я пытаюсь решить. Иногда решение находится в той же базе кода, и нам просто нужно его искать, иначе Интернет / Google / stack overflow всегда готовы помочь. Затем, если доступно несколько решений, я пытаюсь выяснить, какое из них лучше всего соответствует существующей кодовой базе и срокам.
А затем начинается самое интересное - я обычно пишу формулировку проблемы, затем рисую возможные решения на белой доске, а затем смотрю на них, чтобы получить более широкую картину. Когда у меня в голове появляется эта большая картина, я гуляю и думаю о плюсах и минусах этих вариантов решения. К тому времени, как я добираюсь до своего стола, у меня обычно есть решение и окончательное решение для кода. Этот подход помог мне решить некоторые из самых сложных проблем с наиболее удовлетворительными решениями. В конце концов, я думаю, все мы хотим получить удовольствие от своей работы, не так ли?
Эта статья впервые была опубликована на gautamdhameja.com.
