В какие ловушки может угодить человек, увлекающийся программированием, сам того не понимая? Давайте разберемся и заодно выясним, как из них выбраться.
Каждый программист время от времени может столкнуться с проблемами, которые не кажутся таковыми на первый взгляд. Например, оптимизировать код – это хорошо, но иногда это может оказаться неоправданным. Пробовать новые инструменты тоже нужно, но когда каждый проект начинается с нового стека – значит что-то пошло не так.
Иногда, знание эффективных алгоритмов и глубокое понимание принципа работы процессора, заставляют программиста думать, что код должен быть совершенным на каждом этапе. И вместо расширения функционала, разработчик занимается совершенствованием того, что уже есть, пока не наступит момент удовлетворения или дедлайн.
Чтобы не попасть в эту ловушку, нужно стараться трезво смотреть на код. Если что-то работает не идеально, но прямо сейчас этого достаточно, значит это не нужно доводить до совершенства. У этой ловушки есть и обратная сторона – слишком поздняя оптимизация из-за откладывания на потом.
Вывод: нужно стараться находить баланс. Смотреть на код со стороны и принимать взвешенное решение, без увлечения.
Абстракции – великолепный инструмент, который позволил вывести программирование с написания двоичного кода и машинных инструкций на высоты ООП. Но увлечение этим паттерном может привести к нечитаемости кода не только сторонним разработчиком, но и самим автором по прошествии времени. Нагромождение абстракций и универсальные функции увеличивают кодовую базу и усложняют поддержку.
Вывод: не делайте абстракции ради абстракций. Лучше сделать проще, чем создать универсальное решение и использовать 30% процентов от его функционала.
Длительное обдумывание архитектуры, детальное проектирование и вера в то, что можно написать идеальный код за разумное время, как и в случае с ловушкой оптимизации, приводят к внезапному дедлайну.
У этой ловушки также есть вторая сторона. Полный отказ от рефакторинга, вера в то, что читаемость кода не так и важна, довольствие минимально приемлемым результатом обязательно принесут проблемы если не в ближайшем времени, но на этапе поддержки и расширения функционала.
Вывод: держаться посередине. Выделите время, которое будет отводиться на рефакторинг в обязательном порядке, например руководствуйтесь правилом 20/80. Когда обнаружится недостаток, подумайте, так ли он важен чтобы исправлять его прямо сейчас. Примите, что переписывать проект с нуля – крайняя мера, но иногда это придется делать.
Использовать инструменты для облегчения своей работы, конечно же, важная часть работы программиста. Но иногда это начинает работать по принципу «забивать гвозди микроскопом». Если вы разрабатываете сайты, и привыкли включать jQuery под каждый чих – нужно задуматься, не стоит ли написать на несколько строк больше на чистом JavaScript и не тянуть ради ерунды целую библиотеку.
И опять же, полный отказ от полезного набора инструментов приводит к трате времени, лишним сложностям при разработке и созданию велосипедов.
Вывод: используйте сторонние инструменты соразмерно проекту. Знакомьтесь с новыми инструментами и пользуйтесь старыми, но не делайте это бездумно – в некоторых проектах можно обойтись и без них.
Это сложная ловушка, попав в которую, можно этого и не осознать. Применив однажды удачно набор инструментов, или паттерн проектирования, или даже язык программирования, разработчик решает, что этот джентльменский набор будет работать одинаково хорошо везде и всегда. А это может привести к проблемам ловушки технологий и инструментов – полный отказ от разнообразия в средствах разработки или же отсутствие отказа от некоторых из них будет мешать продуктивной работе.
Вывод: если у вас есть любимый язык программирования, изучите еще один, постарайтесь применить его в новом проекте. Узнайте, какие фреймворки популярны в сообществе разработчиков этого языка, разберитесь в них и попробуйте что-то с их помощью создать.
Некоторые разработчики пытаются сразу сделать так, чтобы приложение работало везде и сразу – и на десктопах, и на смартфоне, и чтобы еще веб-версия была. Это может привести к тому, что программа толком нигде работать не будет. Процесс исправления багов и расширения функциональности растягивается и конца работы не видно даже в планах.
Вывод: определитесь с основной платформой. Сделайте стабильно работающее приложение, а потом занимайтесь портированием на другие ОС и платформы.
Не писать тесты – плохо. Писать много тестов для заведомо работающего приложения и ронять его при малейших ошибках – едва ли не хуже. Если ваш код не покрывается тестами в важных частях или если вы пишите в лог консоли все, что происходит с приложением, значит вы в ловушке.
Вывод: не пытайтесь проверить все, тщательно обдумывайте, что стоит проверять, а что нет. Основное внимание при проверках уделяйте пользовательскому вводу и внешним ресурсам.
Еще одна непростая ловушка, найти баланс в которой сложно. Если в коде множатся отметки TODO, а реализация отложенного функционала так и не приходит – значит что-то не так.
С другой стороны, если вам кажется, что вы многозадачны и легко переключаетесь с одной фичи на другую – вероятно, вы тоже в ловушке, потому что постоянное переключение на побочный функционал сбивает с написания основного и отнимает много сил.
Вывод: перед тем, как ставить TODO, подумайте, нельзя ли вместо этого максимально быстро разобраться с этой проблемой. И наоборот, если вы привыкли делать мелочи сразу, по ходу дела, задумайтесь, так ли оно прямо сейчас надо? Возможно, стоит вернуться к этому коду позже.