Автор материала: Anatoliy Fedorenko, golang backend developer в Mad Devs

Все мы когда-то были джунами. Скажу даже больше, когда-то мы были совсем новичками в том, что мы делаем. И, оглядываясь назад, мы понимаем, что в начале пути качество работы оставляло желать лучшего. Именно поэтому новичков не берут на работу или платят гроши.

Самый распространенный способ исправить положение — это делать проекты. Так сказать “набивать руку”, увеличивать портфолио, набираться опыта. При этом надо понимать, что проекты бывают разные и, зачастую, просто писать какой-нибудь код не принесет пользы. Наоборот, это еще больше убедит работодателей отказаться от услуг неумелого разработчика.

Поэтому хочется показать некоторые отличия проектов новичков и тех, кто уже ценится на рынке за свои навыки, ведь знания об ошибках и разнице в подходах помогут понять, что нужно изучить получше, чтобы приносить реальную пользу.

Цель проекта просто написать “что-нибудь”

Новички пишут код в основном чтобы “набить руку”. Зачастую реализуются проекты, которые никто использовать не будет. Они пишутся просто так, чтобы было. В этом и заключается самое ужасное. Когда делаешь что-то просто так, обязательно делаешь это абы как. Когда кодом или софтом начнет пользоваться хотя бы один человек, и код ему действительно будет нужен, проект сразу же изменится. Голова кругом пойдет от комментариев, замечаний, хотелок и претензий “клиента”.

Одиночество в сети

Новички не пишут проекты, которые были бы рассчитаны на дальнейшее использование другими разработчиками. Новичкам глубоко плевать на качественную документацию (а кто её нафиг будет читать?). Им плевать на банально хороший README.md файлик, который раскроет “секреты” того, как проект вообще запустить. Они не пишут “самодокументируемый” код. Не оставляют комментарии, там где они реально нужны, чтобы другой человек смог разобраться со всем. Они не делают понятных коммитов, так как всё равно в проекте один разработчик и, скорее всего, проект больше никто не увидит. В итоге, проект представляет из себя один большой непонятный черный ящик, в который никто не захочет заглядывать.

Как только код будет писаться в группе или с целью его кому-либо передать на дальнейшую поддержку и развитие, все вышесказанное изменится. Вопросы, комментарии, непонятный код, названия переменных сразу же буду переписанны так, чтобы другие поняли, как с кодом работать. Запомните, большую часть времени разработчики читают чужой код, а не пишут свой.

Проект настроен только на локальный запуск

Новички не думают о том, что у других программистов стоят другие системы, что у других разработчиков развернуто иное окружение. Они не думают о том, как вообще код будет работать на сервере, где он будет выполнять конкретные задачи для “клиентов”. Эти недочеты делают проект бесполезным. Если его невозможно запустить, какую пользу он может принести? Забудьте про фразу “у меня локально всё работает”. Как только проект будет распространён хотя бы на несколько других машин, сразу выявятся все проблемы кода и настроек. Молитесь, если это произойдет до того как проект зальют в production, иначе вам не избежать бессоных ночей и очень серьезной работы над багами.

Тестов либо нет, либо они написаны для галочки

Новички никогда не будут заморачиваться с тестами. А зачем? Ведь если всё работает — это значит, что и проблем нет, и багов нет. Следовательно, и тестить нечего/нет необходимости. Конечно, проекты новичков обычно маленькие и там всё видно как на ладони, НО это не может быть оправданием. Тесты это показатель того, что разработчик отвечает за свой код. Это гарантия надежности, гарантия того, что если после изменений что-то сломается, об этом сразу же можно будет узнать при настроенном CI. Пока новички будут просто сосать лапу и ждать момента когда их проект все-таки упадет, не-новички заранее обезопасят себя тестами и будут и дальше спокойно изменять и дорабатывать функционал.

Настройка CI/CD

Новички обычно не заморачиваются настройками автоматических систем, предпочитая всё протыкивать самим. Они тратят на это кучу времени, в то время как не-новички экономят это время, используя автоматические инструменты тестирования, деплоя и т.д. Вместо того, чтобы 10 раз перепроверять руками, лучше 1 раз настроить инструмент и он сам будет перепроверять сотни раз, если это нужно. Это экономит время, а время — это главный ресурс специалиста.

Хлам и нелогичность

Известна проблема, когда не знаешь, как назвать переменную, метод, структуру, пакет, функцию и так далее. Более того, известны проблемы, когда в поиске багов участвует огромное количество логов, которые потом навсегда становятся частью проекта и, смотря на логи, хочется умереть. Проект новичка полон нелогичных названий, лишних функций и кучи логов, которые никаким образом не приближают разработчика к разгадке великой тайны о месте расположения бага.

Не-новички знают как правильно организовать логгирование в проекте, чтобы было всё понятно. Плюс они знают, что название переменных и функций зачастую играют решающую роль в понимании проекта. Учиться этому надо. А для этого нужно больше читать открытый код крутых проектов доступных в github.com

Отсутствие инструментов отслеживания ошибок

Когда в коде кроются баги, на сервере, куда положили проект, непременно будут проблемы. Но новички о них никогда не узнают до тех пор, пока однажды не откроют браузер и не увидят там 500 Server Error или еще хуже, получат гневное письмо от своего заказчика. Тогда и придет понимание, что надо было использовать инструменты вроде Sentry чтобы отслеживать ошибки и узнавать о них первыми. Во всех проектах есть ошибки, идеальных проектов нет.

Зачастую разница между новичком и не-новичком не в том, сколько ошибок производит их говнокод, а как быстро ошибка может быть выявлена, обработана и устранена прежде чем её вообще кто-либо заметит.

Боязнь показать код широкой аудитории и получить обратную связь

Код новичка никогда никто не посмотрит. Зачастую, потому что сам создатель об этом не заботится. Мало того, что продукт никому не нужен, так еще и сам новичок его запрячет очень далеко. Иногда проекты не покидают ноутбуков новичков и никогда не попадают в в открытые опенсорс сервисы. Это о многом говорит. Боязнь ошибок, неуверенность, страх перед оценкой — это самые большие препятствия на пути к росту. 

Да, вы получите не хвалебные отзывы, да, от комментов иногда будет становится страшно, стыдно, жутко, но, как, если не так, мы растем? Рост происходит через боль, постоянную работу над ошибками и бесконечное количество повторений.

В итоге хочется сказать, что выбор правильного проекта для самообразования может сыграть решающую роль в развитии навыков и трудоустройстве. Выбирайте нужный проект, даже если он нужен только вашей маме или братику. Сделайте так, чтобы ваш проект можно было понять и запустить. Позаботьтесь о документации и инструментах, которые сэкономят вам время при написании кода. И обязательно общайтесь с другими разработчиками, показывайте свой код, просите комментариев и оценок. Всё это поднимет вас на новый уровень и вы гораздо быстрее вырастите в хорошего разработчика.

Сам список отличий, конечно, этими пунктами не ограничивается. Жду ваших вопросов, дополнений и замечаний в комментариях.