Не волнуйтесь, потому что каждый великий программист когда-то был неопытен
Опыт – самый трудный учитель. Сначала вам дается тест, а потом – урок. Эта цитата Оскара Уайльда очень хорошо описывает жизнь неопытного программиста.
Вы учитесь на практике. Пачкаете руки. И в процессе выполнения вы будете делать ошибки, и это нормально, если вы учитесь на своих ошибках. Так вы набираетесь опыта.
Как неопытный разработчик, вы будете проходить такие тесты ежедневно. Но как распознать неопытного разработчика? Вот четыре признака, которые показывают некоторые характеристики неопытного разработчика.
Написание неструктурированного кода – это то, что вы ожидаете от неопытного разработчика. Если он немного структурирован, это уже большая победа. Причина, по которой неопытные разработчики пишут неструктурированный код, заключается в том, что они сильно сосредоточены на том, чтобы заставить его работать. Более опытные разработчики знают, что быть разработчиком – это еще не все.
Написание кода и его работа – такая крошечная часть вашей работы как разработчика. Хотя неопытные разработчики считают, что это большая часть их работы. По мере того, как вы набираетесь опыта, вы поймете, что большая часть вашей работы состоит в поддержке проектов, а не в создании новых проектов с нуля.
Как только вы начнете понимать это, вы будете кодировать совершенно по-другому. Вы начинаете кодировать таким образом, чтобы ваш код был более удобным и понятным для других разработчиков.
Неспособность понять это приведет к таким вещам, как функции размером с эссе. У этого есть много недостатков – например, тестируемость. Как вы можете протестировать функцию, которая выполняет пять разных функций и имеет размер эссе?
Когда цель состоит в том, чтобы заставить его работать, проблема в том, что в большинстве случаев код не является хорошо продуманным. От этого страдает качество кода. Этот тип кода часто выглядит как процедурный код, который не придерживается принципов кодирования, таких как принцип единой ответственности. Как только такой код входит в фазу обслуживания, вы начинаете ощущать его некачественность.
БАХ!
Ладно, не сработало.
БАХ!
Ладно, это тоже не сработало.
Когда неопытные разработчики сталкиваются с проблемой, они чаще всего начинают отладку с дебаггером (отладчиком) – они случайным образом меняют некоторые элементы кода в надежде, что это решит их проблему, не зная, в чем заключается настоящая проблема.
Очевидно, в большинстве случаев это не работает. Скорее всего, внесением этих случайных изменений вы только добавите больше ошибок. Что вам следует сделать, вместо отладки дебаггером, так это собрать больше информации о проблеме.
Когда дело доходит до отладки кода, есть способы получше. Первое, что вам нужно сделать, это выяснить, как воспроизвести проблему. Убедитесь, что вы знаете, как это сделать, прежде чем начинать вносить какие-либо изменения в свой код.
Открытие файлов журнала (надеюсь, у вас есть) может стать хорошим началом вашего пути отладки. Посмотрите, сможете ли вы найти полезную информацию, которая может направить вас в правильном направлении. Перед тем, как приступить к изменению кода, важно собрать информацию, чтобы понять, что на самом деле вызывает ошибку.
После того как вы нашли причину ошибки и исправили ее, вы еще не закончили. Если вы действительно хотите, чтобы все было хорошо, вам следует написать хотя бы один тест для исправления. Таким образом вы будете защищены, когда в будущем дела пойдут плохо.
Неопытные разработчики все еще учатся своему ремеслу. Поэтому их основное внимание уделяется тому, чтобы стать мастерами своего технического стека. В этом есть смысл, потому что если вы хотите стать отличным разработчиком, вам нужно освоить свой технический стек. Но вам следует сосредоточиться не только на технологиях.
Изучая все тонкости технического стека, вы не должны терять бизнес из виду. Вот почему вы здесь в первую очередь. Это причина того, что у вас есть эта работа.
То, над чем вы работаете, создает ценность для бизнеса, или вы тратите слишком много времени на то, что не имеет отношения к бизнесу? Это важный вопрос, который вы должны постоянно задавать себе.
Быть разработчиком – это значит не просто интересоваться техническими аспектами работы. Имейте в виду, что деловые и экономические факторы являются факторами, оправдывающими существование вашей работы.
Работая в команде, вы можете обнаружить неопытного разработчика, выполняющего действия, немного отличные от остальной команды. Неопытные разработчики склонны делать что-то по-своему, а не так, как все остальные.
Иногда это происходит непреднамеренно. Неопытный не может распознать определенные закономерности в решениях. Если это звучит для вас знакомо, есть кое-что, что вы могли бы сделать, чтобы помочь вам в будущем.
Чтобы действовать так же, как и все остальные в команде, вы можете просмотреть все создаваемые запросы на вытягивание. Вам не обязательно просматривать все из них, просто убедитесь, что вы посмотрите, как другие разработчики решают определенные проблемы. Их решение похоже на то, как вы бы решили проблему? Если нет, спросите, почему они выбрали свое решение, и рассматривали ли они ваше решение.