Несколько советов начинающим программистам

Данный текст посвящен интернам и джуниорам – вчерашним студентам, которые присоединяются к проектным командам практически сразу же после завершения университетов и тематических курсов. В данной статье мы можем рассказать о некоторых важных моментах и о некоторых проблемах, с которыми сталкиваются начинающие программисты. Отметим, что все эти советы применимы к работе с абсолютно любым языком – потому что все программисты делают практически одно и то же, им необходимо: написать, провести тестирование, выпустить и потом осуществлять поддержку.

Оценка требований

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

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

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

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

Узнавайте об ограничениях – это очень важно в реальном проекте. Нужно уточнять, сколько данных будет поступать на вход приложения, узнать о планируемой нагрузке. Такие данные пригодятся и при проектировании решения, и при его сдаче.

Еще один важный совет – нужно обязательно делать блок-схемы. Очень многие их не рисуют, полагая, что вся эта сортировка «пузырьком» является обычными глупостями. Но в будущем это вам поможет, потому что схематичное описание решения позволит легко донести до ваших коллег ваши идеи.

Просто можно оценить, что сделать легче – нарисовать схему с тремя блоками и проставить связи между ними, либо же исписать наполовину лист А4. Картинку также гораздо проще воспринимать, тогда как читать тексты большого размера особенно никому не хочется. Также стоит обратить внимание на UML – язык, на котором вы можете писать физические модели баз данных, а также концептуальные модели и диаграммы последовательности вызовов и многое иное.

Оценка сложности работы

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

Разработка

Один из главных вопросов – как писать. Есть в среде проджект-менеджеров такое точное выражение – «писать без багов необходимо всегда». Здесь самым главным являются code style и naming convention.

Naming convention (что означает «соглашение об именах») ­– оно требуется для того, чтобы код был читаемым. Это не столь важно в том случае, если речь идет о курсовой или лабораторной работе, однако работать приходится обычно в команде. Кодом владеют все разработчики, а не только лишь те, что сейчас занимаются отдельными компонентами системы. Соглашение об именах же позволяет легко понимать, что именно написали ваши коллеги.

Для той же цели нужен и Code style (стандарт оформления кода) – это стиль оформления кода, который необходим для унификации. Код, который разработан разными программистами, должен читаться так, как будто его писал один человек. Следовательно, приходя в проект, нужно сразу понять, какие code style и naming convention используются в данном проекте. Нужно помнить, что строгое следование им является и знаком уважения вашим коллегам, который наверняка они оценят по достоинству.

Var – отличная практика, позволяющая любому разработчику читать с листа код. Однако многие компании сегодня делают собственные конвенции для проектов.

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

Пишите простой код! Это простой совет, но следовать ему достаточно сложно. Если инженером не до конца продумано решение задачи, если он не смог сделать декомпозицию (не смог разбить задачу на несколько составных частей) то в методе можно увидеть 500 строк кода. Это не очень страшно, однако необходимо вернуться назад и еще раз обдумать композицию.

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

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

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

Unit test

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

Работа над ошибками и изменения требований

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

Что делать в таком случае? Все просто – необходимо вернуться к самому началу и уточнять, что именно не так. Если же поменялись требования, то необходимо их уточнять, после чего – приступать к дальнейшей проработке.