Какие хорошие привычки должны быть у программиста?

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

Поверьте, это позитивно скажется не только на вас самих, но и на тех, кто вас окружает.

1. Не повторяйтесь

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

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

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

2. Завершили проект? Займитесь рефакторингом

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

Перед тем, как сдавать программу и приступать к написанию следующей, стоит заняться рефакторингом. 

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

3. Обращайте внимание на ценность своей работы

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

Прежде чем тратить время и усилия на любой проект, подумайте: позволит ли ваша работа сделать нечто действительно значимое для бизнеса?

4. Маленькие коммиты

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

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

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

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

5. Будьте постоянным

Если при объявлении переменных вы начали использовать “ВерблюжийСтиль”, то продолжайте придерживаться его до конца кода. Предпочитаете ставить пробелы вместо применения табуляции? Прекрасно! Но раз уж решили что-то делать в коде одним способом, делайте так всегда.

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

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

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

6. Не откладывайте на потом

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

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

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

7. Продолжайте учиться

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