Можно сказать, что все навыки программирования приходят с опытом. При этом важно понимать, что опыт — это не число в резюме. А что тогда?
Петя с горящими глазами бросается решать задачу. Он только-только закончил ВУЗ и пришел в свой первый офис. Перед ним кружка, которая теперь будет долгие годы кочевать с ним с одного места работы, на другое. А еще перед ним задача, которую хочется решить как можно скорее. Нет, думать он будет позже. Сейчас нужно писать.
Через пару недель приходят правки и пожелания. По неопытности Петя снова хватает задачу — с энтузиазмом, но не подумав. Он привинчивает вентилятор к тостеру самыми длинными саморезами, а сверху заботливо накладывает три слоя синей изоленты. С каждыми правками/обновлениями/дополнениями костылей становится больше. Разумеется, все это нагромождается на старый код.
Проходит год, и проект становится настолько нестабильным, что даже сам Петя уже не может внести незначительные изменения, не отхлебнув ушат боли и непонимания. Часы дебаггера, grep логов, отладочных принтов решают вопрос только на время.
Кульминацией этой истории можно считать полное переписывание проекта на новую архитектуру. И так будет несколько раз. Зато после Петя перестанет доклеивать слои синей изоленты и будет стоить всё так, чтобы архитектура выдержала изменения. В случае чего, он сможет перестроить эту самую архитектуру в процессе, чтобы решение максимально соответствовало целям.
Существует мнение, что корреляция между навыками и опытом отсутствует. Особенно, если последний оценивается годами в резюме. Убежденные заявляют, что для программиста главное — это умение и желание быстро осваивать новое. С выходом свежего фреймворка существует вероятность, что сеньор и джун окажутся на одном уровне. Меньше чем за полгода, программист может освоить незнакомый стек технологий и будет не хуже других. Заключением к подобным заявлениям часто бывает то, что постоянное обучение и готовность к новому важнее конкретных технических знаний. При этом стоит делать акцент не только на теорию, но и на практику.
С опытом вы начинаете чувствовать, что что-то может пойти не так. Это происходит в любой деятельности. Чем больше ошибок вы проанализировали и больше ситуаций видели, тем богаче будет ваша собственная библиотека того, с чего начинаются лажи. С ней вы сможете еще на начальном этапе заметить проблему и оперативно ее устранить. Также вы научитесь писать архитектурные решения, которые при эволюции кода или исправлении багов не будут нарушать стабильность работы.
Начинающих часто поглощает исследовательский интерес, что мешает выполнению конкретного задания. Но даже самые отчаянные исследователи не протянут долго без ощутимого результата. С опытом приходит самоконтроль, позволяющий балансировать между творчеством и эффективностью.
С опытом хороший разработчик обрастает не только глубокими знаниями в своей сфере, но и навыками смежных направлений. Он видит задачу не в рамках своей узкой специализации, а целостно, что позволяет ему принимать более взвешенные решения, анализировать их и работать не только со своим участком.
Приходит осознание, что сложный код никому не сделает хорошо, а даже наоборот. Хорошим кодом становится не сложный, а достаточный, понятный и максимально простой.
Умение охватывать всё более сложные задачи и на ходу разбивать их на мелкие пункты, простые для выполнения. При этом типовые сразу бросаются в глаза, а в голове возникает оптимальное решение.
О многом говорит расширяемость кода. Часто новички переписывают свой же код из-за невозможности модифицировать его под новые требования.
Помимо технической базы и постоянной практики, стоит обращать внимание на умение взаимодействовать в команде и soft skills. Цените и уважайте своих коллег, заказчиков и людей. Также на пользу пойдут мысли о ценности вашего продукта и деятельности компании в целом.
Учитесь создавать что-то совместно. Со временем вы научитесь понятный для другого разработчика код. Это важно потому, что человек, который в дальнейшем будет работать с вашим кодом, мог внести изменения в систему, а не переписывать все заново. Для этого нужно понимать как будет мыслить разработчик, в нужных местах оставлять комментарии и выбирать подходящие названия для классов.
Через какое-то время вы поймете, что простых задач не бывает. Придет умение видеть подводные камни, правильно задавать вопросы, правильно выставлять дед-лайны, закладывать резервное время и управлять рисками. Максимализм, обычно, к этому времени отступает и стремление сделать все в сжатые сроки, не учитывая при этом свои реальные возможности.
Код со временем становится более аккуратным и чистым — начинает не только выполнять необходимое, но и ходить на своих двоих, без костылей. Обращайте внимание на переменные, классы, контакты между составляющими приложения, интерфейсами взаимодействия — со временем вся эта радость станет более понятной другим людям, а построенная вами архитектура — прозрачной. Старайтесь понять как код работает на самом деле и как один блок влияет на другой и картину в целом. Стремитесь к пониманию физических процессов в самом компьютере. Избегайте лишних ресурсоемких запросов.
Время и практика приносит умение строить большие надежные дома, а не куличики в песочнице. Шаблоны проектирования и правильно подобранные архитектурные паттерны играют в этом не последнюю роль.
Опытный разработчик не будет рваться создавать «велосипеды», а новая задача не будет казаться ему «новой» в полном смысле этого слова. Изучив вводные, можно подобрать готовые решения, максимально соответствующие условиям и применить уже наработанные паттерны. На руку играет то, что большинство современных задач типовые. Это существенно сокращает цену, сроки и повышает надежность. Последнее происходит потому, что над решением еще до вас поработали несколько профессионалов, тысячу раз усовершенствовали и оптимизировали. Другим программистам тоже будет проще взаимодействовать с такими заготовками, так как у них есть документация или комьюнити. В начале пути стоит постараться перенять у более опытных коллег лучшие практики проектирования.
С опытом вы станете быстрее ориентироваться между готовыми решениями перебирать в голове модели кода. У вас уже будет готовая база полезных данных или сможете из своих же проектов выдернуть пару-тройку некогда найденных отличных идей — для них уже установлен инструментарий и вы знаете как с этим всем работать. Когда же осваиваешь новое, хороший кусок времени уходит на установку и обучение. Плюс вам не нужно перелопачивать горы гайдов, в которых простое решение могут объяснять больше часа.
Со временем вы все меньше обращаетесь к таким вот времязатратным методам и используете собственную документацию или сохраненные исходники. Важно делать базу максимально понятной, структурированной и обновлять инструменты. Решения становятся более взвешенными, а работа качественной.
