Какие привычки программистов мешают писать хороший код и как от них избавиться — отвечают эксперты

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

Александр Патлух

разработчик образовательных программ в «Яндекс.Практикуме»

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

Есть другая сторона медали. Встречаются новички, которые боятся ошибок, а они случаются у всех. Часто ребята опускают руки, понимая, что код постоянно не работает. На самом деле ошибки — это помощники программиста. С ними нужно учиться работать, как и с любыми технологиями. Профессионалы больше проводят времени с нерабочим проектом, чем с рабочим, ведь в этом и есть цель — включить что-то неработающее или исправить проблему.

Третья группа заблуждений связана с самими технологиями. Для большинства задач уже написаны библиотеки, которые упрощают написание кода. Но это не значит, что надо сфокусироваться на изучении библиотек. Если ты действительно хорошо знаешь JavaScript и добавляешь к этому базу computer science, тебе не важно React, Vue, Angular или новенький Svetle указан в ТЗ. Просто нужно время на чтение документации. Словом, нужно всегда стараться смотреть на более низкий уровень технологий и разбираться, как всё работает «под капотом».

Есть ещё проблема нежелания расширять кругозор, предпочитая учить что-то одно. Безусловно, на старте нужно привыкнуть к новому синтаксису или особенностям какого-то языка программирования или фреймворка. Но на самом деле учиться надо программировать, а не писать на чем-либо. Программирование — это не про конкретный язык, это про то, как писать инструкции компьютерам. Человечество многогранно изучило этот вопрос ещё до появления JS или Python. Парадигмы, паттерны, структуры данных, алгоритмы — это всё великое наследие, не стоит им пренебрегать.

Отдельно в этом контексте хочется отметить новичков, которым нравится верстать, но они не могут назвать хотя бы три студии или дизайнера, чьи работы их вдохновляют.

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

Наталья Тищенко

SMM-специалист в компании Seven Winds Studio

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

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

У начинающих разработчиков, узнавших о новом фреймворке или изучавших новый язык программирования, часто возникает непреодолимое желание прямо здесь и сейчас переписать проект с нуля, «теперь-то уже точно правильно». Поспешим расстроить — это плохая практика. Реальность такова, что за каждым проектом обычно стоят бюджеты и сроки. Остановка разработки на несколько месяцев при переписывании проекта обычно никому не нужна. Постепенное переделывание проекта по модулям — хорошо. Снос до основания и переделывание с нуля — плохо.

Ещё один из немаловажных вопросов — стоит ли бояться костылей? Нет, но к ним нужно относиться настороженно. Это рабочий, но не универсальный код, который желательно отметить комментарием. Костыли могут теряться со временем и при расширении/увеличении программы костыль скорее всего сломается/придётся от него избавиться. Костыли — это меньшее зло. Большее — сорвать сроки!

Любому программисту всегда следует читать мануалы. Мануалы — любая литература/статьи/обзоры/видео по той теме которую делаешь. Причем начинать можно с азов: if, переменные, память, — и до чего-то объёмного: паттерны, архитектуры кода и что-то обособленное — VR, вёрстка, оптимизация. Если застряли — спрашивайте у опытных товарищей или на форуме. Можно сначала поискать информацию в интернете, а можно сразу бежать за советом — это вопрос совести.

Чужой код — это ловушка. Если вы не знаете, как это работает, — значит, не знаете и результат работы кода.

Плагин = чужой код, который ты не знаешь.

Будьте всегда готовы, что ОНО обновится и отвалится. Поэтому плагины стоит использовать с осторожностью.

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

• Следуйте стандартным правилам оформления кода.
• Пишите комментарии к своему коду в процессе написания. Что делает каждая из функций, её положительные и отрицательные стороны. Также стоит помнить, что лучший комментарий — это говорящие сами за себя названия функций и переменных.
• Не копируйте чужой код. Вместо этого изучите его. Как он работает и будет ли он полезен вам?
• Избегайте использования аналогичных кусков кода.
• Не забывайте проверять свой код на наличие ошибок.
• Проектируйте код с расчётом на дальнейшее расширение функциональности.
• Не полагайтесь на то, что определённые типы данных (integer, указатели и временные метки) будут иметь конкретную длину (например 32 бита), потому что этот параметр отличается на разных платформах.

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

Михаил Андрейков

Senior .NET Developer в «Циан»

Перфекционизм

Бывало ли у вас такое, что вы пишете код, потом понимаете, что могли бы сделать его более понятным или производительным, а потом начинаете усердно перерабатывать эти строки кода? Загвоздка заключается в том, что вас вновь не устраивает полученный результат, и вы думаете про себя: «Тут можно лучше назвать переменную, это лучше вынести в функцию», — и далее по списку. В итоге вы тратите много времени, а код становится лишь более понятным. Получается, что вы придерживаетесь «перевёрнутого» правило Парето: тратите 80 % усилий и получаете 20 % результата. Я ни в коем разе не призываю не рефакторить код во время его написания, но нужно держать во уме ту грань времени, после которой вы честно можете себе сказать, что нельзя сейчас всё сделать идеально и что будете двигаться дальше в решении задачи, а по прошествии времени, когда вы вновь столкнётесь с этим кодом, у вас уже может быть другое мнение о том, как организовать этот участок кода, и тогда вы сделаете это быстро.

Ранние оптимизации

Иногда программист, прочитав статью «трюки и оптимизации», начинает повсеместно использовать найденные решения, не задумываясь о недостатках приёмов. Оптимизация является противоположностью рефакторинга, т. к. оптимизации делают код более простым для понимания компьютера, а рефакторинг — для человека. И каждый раз, когда вы будете заменять деление на два на смещение или хитро храните два значения в одном поле, стоит понимать, что вы сохраните 1 байт памяти или наносекунды процессорного времени, но потеряете в лёгкости чтения кода, что усложнит поддержку компонента.

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

«Велосипеды»

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

Пренебрежение трендами

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

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

«Одинокий рейнджер»

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

Заал Льянов

директор по управлению проектами, руководитель тренинг-центра ЕРАМ в Санкт-Петербурге

Не практиковаться ежедневно

Писать код нужно ежедневно, как и делать утреннюю зарядку. Любое действие должно обязательно сопровождаться практикой: изучил теорию — попрактиковался. Причем важно также упражняться в тех вещах, которые прямо сейчас в проекте не задействованы, но которые позволяют держать пальцы «разогретыми».

Не делать физическую зарядку

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

Пытаться сначала всё до конца продумать в голове и только потом писать

Необходимо постоянно пытаться что-то делать, действовать методом проб и ошибок. Должны быть короткие циклы разработки: придумал, написал, попробовал. Понравилось — оставил, не понравилось — придумал что-то новое.

Цепляться за первоначальный вариант

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

Не общаться с себе подобными, замыкаться в себе

Нужно обязательно посещать мероприятия, участвовать в жизни сообщества, желательно поработать на open-source-проектах, с другими разработчиками, послушать замечания других о своём коде — это очень сильно помогает развиваться.

Сергей Ширкин

декан факультета Искусственного Интеллекта в онлайн-университете GeekUniversity

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

Код без комментариев

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

Ненужное усложнение

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

Неоттестированный код

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

Незнание алгоритмов и структур данных

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

Неумение пользоваться IDE

Не обязательно знать среду разработки в совершенстве, достаточно знать то, что пригодится в ежедневной работе. Например, для программиста Python умение пользоваться такими возможностями PyCharm, как удалённая отладка, поддержка Git, автоматический рефакторинг, горячие клавиши для повторяющихся действий, значительно ускорит работу с кодом и позволит не тратить время на второстепенные вещи.

Неумение пользоваться Git

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

Неумение искать информацию

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

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

Юрий Пономарев

консультант по программным продуктам Oracle Центра технической поддержки компании РДТЕХ

Самая плохая привычка — не вносить изменения в документацию. Проектное время должно расходоваться преимущественно на создание кода. И начинающие программисты часто задаются вопросом: зачем вообще нужна документация и строгая нумерация в ней, зачем нужны отметки об исполнении не только в Jira, но и на бумаге. По итогу человек, не придерживающийся технологии работы с кодом, может украсть 2–3 дня квалифицированной команды, которая, конечно, разберётся, что и как сделано, но слов ругательных скажет много.

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

Ещё про костыли. Есть наборы продуктов, которые без костылей не запустить никак. Более того, сочетание версий костылей библиотеках Python 2 и 3 — отдельная тема на многих конференциях для разработчиков. Даже крупные вендоры выпускают патчи при смене парадигмы костылей. Поэтому исправление плохой привычки следующее: используешь костыль — отладь, оттестируй, выступи в группе или на форуме. Можешь создать бескостыльную систему — делай. И документируй. Не будь отрицательным примером!

Теперь касательно велосипедов. Конечно, на собеседовании и тестовых примерах можете демонстрировать хоть знание Кнута, Ахо, Страуструпа или иных гуру. Но как только написано «алгоритм должен/может/обязан», — конец творчеству, конец велосипедам. Берём мануалы по языку, библиотекам, на худой конец идём на курсы. Мы физически не можем закладывать логическую бомбу внутрь промышленного изделия. Иначе восьмёрки на колесах нашего велосипеда могут подорвать любой бэкенд. Пример: на ряде промышленных систем чёрный цвет на снимках фотограмметрии стал серым, так как никто не мог додуматься, что при смене архитектуры чипа может поменяться алгоритм закраски фона белым цветом. Тут нужна комплексная борьба — так как графические системы ваяются чуть ли не на коленках. И велосипед одних может врезаться в дерево других.

Александр Лебедев

тимлид фронтенд команды «МойОфис»

У большинства ошибок начинающего программиста общая причина — привычка сразу браться за работу без предварительного обдумывания задачи. Как это проявляется?

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

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

Евгений Лопатин

директор департамента разработки «Инфосистемы Джет»

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

Второе пагубное влечение — мы не любим читать требования. Они такие длинные, такие детальные, в них порой всё так подробно написано и разжёвано… но мы-то лучше знаем, как надо или просто лень… Ах да, если что — перепишем. Как следствие из этого недуга вытекает ещё один: «Я всё понял, завтра уже закончу и выдам код». Спешка в нашем деле лишняя, а постановка задачи не зря занимает столько страниц.

Ещё одно довольно странное явление встречается уже реже: не пользоваться средствами отладки и профилирования. Я не спорю, ошибки, конечно, можно найти, вдумчиво рассматривая код. Но всё же, все современные IDE обладают весьма богатыми средствами отладки. Это удобно и практично.

Следующая пагубная для окружающих привычка — «а я так привык» или «мой код правильнее»… Сначала я думал, что это бывает только «по молодости», но, к сожалению, встречаю такое и у более опытных коллег. Поэтому не принимать во внимание текущие стандарты и локальные практики заказчика становится той самой плохой привычкой.

Дмитрий Машкарин

программист группы разработки и сопровождения приложений «Манго Телеком»

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

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

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

Конечно, второй Билл Гейтс для компании ценный кадр. Но когда новичок с высоким самомнением считает себя «богом кодинга», это значительно снижает его шансы на успех. Даже если он тысячу раз талантлив, его неспособность коммуницировать на равных с другими людьми может убить все старания, породить кучу костылей в коде, привести к багам, а ещё хуже — к недопониманию в команде.

Екатерина Акимова

руководитель группы разработки Тверского Технологического центра Accenture в России

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

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

Чтобы этого избежать, необходимо постоянно технически развиваться, изучать разные проекты с простой и сложной архитектурой. Применять best practices, паттерны. Думать о производительности с учётом мощностей пользовательских рабочих мест.

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

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

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

Как избежать этого — проводить ревью своего и чужого кода. Больше работать с чужим кодом. Обсуждать с коллегами проблемы, возникшие при разработке. Быть дружелюбным.

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

Итак, какие плохие привычки бывают у программистов и что с ними делать?

Программисты порой:

• Не документируют код и/или не вносят изменения в документацию.
• Пишут лишние велосипеды.
• Не практикуются в написании кода регулярно.
• Игнорируют физические активности.
• Пытаются продумать все детали программы перед её реализацией.
• Сразу пробуют решить задачу, не узнав о всех нюансах вроде своего видения решения задачи у заказчика.
• Не читают требования.
• Пытаются отрефакторить плохой код, не вникая, почему его написали именно так.
• Излишне усложняют код.
• Не умеют искать информацию.
• Не знают и доли возможностей своей IDE.
• Не общаются с единомышленниками и замыкаются в себе.
• Игнорируют общепринятые практики и делают всё в стиле «я так привык» или «я лучше знаю».
• Пытаются сделать всё сами.

Что с этими привычками делать? Не переставайте развиваться. Вам не обязательно писать на всех фреймворках, пихать в каждый проект все паттерны проектирования и т. д., но знание того, какие вещи вообще существуют в мире программирования и как их реализуют другие люди, может сильно вам помочь. Для каких-то привычек нужно просто перебороть и заставить себя сделать «как надо». Ну а если вы где-то работаете, то некоторые хорошие привычки вам привьют волей-неволей. Кроме того, в этом деле может помочь опыт коллег, которые проходили через то же самое.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.