Как писать красивый код?

Один мой друг и коллега спросил меня — «Как тебе удается с первого раза писать красивый код?». На самом деле, сразу скажу, что «красивый» код получается у меня гораздо реже, чем не «красивый». В большинстве случаев, это становится понятно после дюжины изменений по требованию заказчика. Проблем не лишены и программы, написанные для себя. В обоих случаях, скорее всего проблема общая — плохо сформированные или плохо понятые требования.

С первым бороться сложнее чем со вторым, так как эта проблема находится не совсем на уровне разработчика, а исходит откуда-то от начальства, менеджмента, заказчика. Тут, по моему единственный выход, это валить их глупыми вопросами (правда прежде, часто стоит спросить себя, насколько это нужно 😉 ).

Во второй проблеме можно винить (ну или хвалить) только себя самого. Я говорю сейчас не о языковых или территориальных проблемах, а о проблемах архитектуры. Посчитайте, сколько в вашем проекте занимает кодирование от всего процесса, а сколько должно? А должно не больше 30-25%. + 30-25% тестирование, и 40-50% это работа с требованиями. О последнем часто забывают разработчики, считая, что их работа сосредоточена в 25% процесса разработки.

Прежде чем писать программу или какой-либо модуль, отобразите его на бумаге. Для этого не нужно знание UML или Блок-схем. Если вы вообще не умеете рисовать, просто напишите, как должна работать программа. Представьте себе как вы нажимаете на средства управления вашей новой программы, как данные переходят от одного блока к другому. Подумайте, что может не хватать или что можно добавить в будущем, если не уверенны, покажите схему коллеге, или на крайний случай расскажите ее своему плюшевому мишке (кто не знает, это такая техника). И не надо спешить, на этой стадии исправить все гораздо легче чем на стадии разработки или тестирования.

Что делать если программа почти закончена а архитектура страдает, переписывать заново? Конечно нет, помните, в большинстве случаев заказчик никогда не увидит код а соответственно не похвалит или отругает. Ему более интересен результат, ведь именно за него были заплачены деньги. Не впадайте в архитектурный фанатизм, если бы на земле были бы универсальные инструменты разработки, программисты просто бы лишились работы.

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

Метки:разработка, обо мне