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

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

Неоправданная оптимизация

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

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

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

Излишнее абстрагирование

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

Вывод: не делайте абстракции ради абстракций. Лучше сделать проще, чем создать универсальное решение и использовать 30% процентов от его функционала.

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

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

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

Вывод: держаться посередине. Выделите время, которое будет отводиться на рефакторинг в обязательном порядке, например руководствуйтесь правилом 20/80. Когда обнаружится недостаток, подумайте, так ли он важен чтобы исправлять его прямо сейчас. Примите, что переписывать проект с нуля – крайняя мера, но иногда это придется делать.

Технологии и инструменты

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

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

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

Идеальное решение

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

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

Кроссплатформенность

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

Вывод: определитесь с основной платформой. Сделайте стабильно работающее приложение, а потом занимайтесь портированием на другие ОС и платформы.

Защита

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

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

Откладывание на потом

Еще одна непростая ловушка, найти баланс в которой сложно. Если в коде множатся отметки TODO, а реализация отложенного функционала так и не приходит – значит что-то не так.

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

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

Другие статьи по теме

Как научиться учиться?

Как понять программиста: ТОП важных вещей о программировании