Многих программистов начального и среднего уровней поражает способность некоторых индивидов писать код, который с первого раза не то, чтобы компилируется, но и работает без нареканий. И речь идет конечно же не про методы уровня "hello world", а про целые классы или компоненты! После некоторых размышлений приходит в голову мысль, что это какая-то особая способность, которая либо есть у человека, либо её нет. Я уверенно могу заявить, что это не так.
Зачем это нужно?
- Экономит время разработки - время, затраченное на разборы компенсируется с лихвой.
- Повышает качество кода - читабельность, масштабируемость и поддерживаемость.
- Показывает уровень разработчика.
В чем секрет?
За наличие этой "суперспособности" отвечает выполнение следующих условий:
- Вы полностью понимаете, как именно работает каждая строка кода (будь то вызов стандартного метода, применение оператора или операции).
- Вы четко понимаете, что конкретно вам нужно сделать, зачем и, немаловажно, что стало причиной этой доработки.
- У вас полное понимание архитектуры части проекта, с которой работаете (за что отвечает какой класс, его свойство, поле, событие и для чего они сделаны именно так).
- В вашей "оперативной памяти" в уме есть детальная модель (картина) той части системы, с которой вам предстоит работать.
- У вас развитое архитектурное видение.
- Бесконечный рефакторинг.
- Отладка кода в уме.
Теперь подробно по каждому пункту.
Разумеется, если разработчик не до конца понимает, как отработает та или иная команда, то ошибки неизбежны. Тут не о чем говорить.
Если нет четкого видения того, чем это будет в итоге, очень сложно в принципе начать писать, не то чтобы без ошибок. Необходимо разобраться в задаче, начиная с "зачем?" и заканчивая "как?". Возможно, уже на этом этапе вы обнаружите, что задача поставлена неправильно, недостижима этим путем или более подходящий вариант её решения. Зачастую это значительно экономит время дальнейшей разработки. Ваша задача составить краткий план того, что нужно сделать, чтобы добиться цели. Записать или запомнить независимые блоки, из которых состоит решение.
Казалось бы, можно приступать непосредственно к написанию кода. Но не тут-то было. Куда писать, что писать? Часто программист бегло осматривает место предстоящей правки, делает поспешные выводы о том, что ему нужно сделать и бросается в бой. А после тратит кучу времени на обход в отладке и разбора "что пошло не так". Чтобы этого избежать, нужно проанализировать часть проекта, в которую будут вноситься доработки. В процессе разбора в голове появится картина происходящего, придет понимание архитектуры, станет ясно для чего предназначено те или иные свойство/событие/поле/метод. Этому определенно нужно учиться. Если человек всегда писал программы экспромтом, то ему будет сложно удержать эту картину в памяти. В таком случае нужно её подробно куда-нибудь записать. При этом уровень детализации играет очень важную роль. На этом этапе учитываются все нюансы, если их не записать (запомнить), потом на каждом шаге нужно будет осмысливать это все заново. С опытом записи не понадобятся (за исключением действительно больших проектов), хотя и лишними никогда не будут. Если лень заниматься записями (как обычно бывает) нужно сразу полагаться на память. Со временем она натренируется. Без этого этапа добиться цели (код без ошибок) никак не получится.
На предыдущем шаге у вас должна была сложиться "модель" системы. Если этого не произошло - пробуйте снова. С каждым новым повтором она будет становиться четче. Затем приступая к каждому новому пункту вы будете ясно видеть, что нужно написать, чтобы не нарушить работу системы, а дополнить её.
Для более-менее простых задач предыдущих пунктов достаточно. Если же необходимо добавить значительный функционал, написать новый класс (или несколько), спроектировать компонент, то важную роль играет архитектурное мышление. В этом случае важно знать какие паттерны решений приняты в вашей команде, да бы не нарушать логику проекта. Чтобы натренировать это мышление нужно для хорошо владеть ООП, постоянно работать с чужим (в идеале с заведомо высококачественным) кодом, например, со сторонними библиотеками, анализировать их подходы, вникать, разбираться, искать более изящные варианты решений. Очень хорошим стартом в этой области будет изучение паттернов проектирования. На этапе, когда нет ясного понимания предназначения ООП они покажут все его прелести.
После написания кода в каждом конкретном месте следует провести рефакторинг. Это очень важный процесс, во время которого обнаруживается 90% допущенных ошибок. Затем сделать это снова и так до тех пор, пока не останется нареканий.
Заключительный этап - отладка кода в уме. Перед запуском нужно ещё раз пройтись по всем методам, проанализировать мысленно все пути прохождения алгоритмов. Это умение нужно тренировать, со временем отладка кода в уме становится настолько ясной и очевидной, что реальный отладчик пригождается лишь в особо неявных случаях. Этот этап также следует проводить на каждой внесенной правки сразу же после её написания.
Резюмирую: чтобы написать код без ошибок должно быть полное глубокое понимание происходящего. В этом случае мозг работает и как отладчик и как виртуальная машина. И этому нужно учиться.
Спасибо за внимание!
Предложения и замечания принимаются.
Понравилась статья? Ставьте лайк :)