Давайте будем честными, никому не нравится, когда их продукт «падает». Это явный признак того, что с нашим кодом что-то не так. И это правда, на которую хотелось бы закрыть глаза.
Независимо от того, новичок ли вы в разработке или «вкатились в ИТ» на заре времён — наверняка вы сталкивались хоть раз с костылями. А дьявол шептал вам на ухо, что нужно использовать хардкод. Это же такое простое решение всех проблем!
Откуда берётся необходимость использовать костыли?
Если отбросить случаи, когда разработчик просто ещё не набрался опыта, то основная причина кроется в том, что невозможно учесть всё на начальной стадии проектирования. По мере реализации проекта в него будут вноситься коррективы. От нового продукта будут требовать то, чего на ранней стадии даже не предполагалось.
Блуждая в окружении переменных, легко забыть, что реальность гораздо сложней. Да, сбой в работе продукта — это плохо, он задевает эго и просто раздражает. Но действительно ли это худшее, что может случиться? Что если ошибка в коде не только приведет к мгновенному сбою, а еще и внесет в систему ненужные данные, широко открывая ворота практически для любого результата, который только можно вообразить, от незначительных сбоев до серьезных уязвимостей безопасности.
В этот момент появляется дилемма: делать патч, т.е. костыль, либо менять кардинальным образом архитектуру, переписывая проект с учётом новых требований. Использовать костыльное решение здесь и сейчас — быстрее и дешевле, чем пересматривать и переписывать продукт целиком. Всё зависит от сроков, затрат и наличия опытных сотрудников. Если горят сроки и важно выпустить детище в свет — пускают в ход костыли и даже хардкодят.
Примеры костылей
Костыль:
Как лучше:
Костыль:
Артикул = Справочники.Номенклатура.НайтиПоНаименованию(“МойТовар”).Артикул;
Как лучше:
Артикул = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Номенклатура, “Артикул”);
А что такое хардкод?
Это страшное слово — хардкод. Все боятся это сделать, но иногда каждый из нас это делает.
Хардкод (от англ. hard code — жёстко кодировать) — способ записи данных или алгоритмов прямо в исходный код без использования переменных.
Он упрощает и ускоряет процесс разработки, но значения в таком коде потом сложно изменить. К тому же программы, написанные таким методом, невозможно настроить под разные среды или пользователей.
Примеры неудачного и исправленного кода
До:
После:
До:
После:
До:
После:
До:
После:
Опасности, которые подстерегают любителей латать дыры на ходу
Согласно закону Мёрфи: «Всё что все, что может пойти не так — пойдёт не так». Но, используя «костыльный код на вентиляторе», мы полностью игнорируем это и надеемся на лучшее.
Давайте остановимся на сценарии, в котором мы получим неожиданные мусорные данные, добавив в наш код «левый кусок», скопированный из другого проекта. В некоторых случаях последствия будут достаточно очевидными и мгновенными, и мы сможем разобраться в этом сразу, но в худшем случае «мусор» сначала останется незамеченным. Возможно, мы работаем с действительными, но устаревшими данными. Возможно, нам это вообще сойдет с рук. Ну, то есть до тех пор, пока код не будет выполняться в совершенно другой среде в первый раз.
Дело в том, что к тому времени, когда мы можем сказать, что наши данные не соответствуют ожиданиям, уже слишком поздно. Обходя симптомы, мы не только вносим ненужную сложность (которую нам, скорее всего, придется тащить за собой в любое другое место, куда передаются данные), но и скрываем реальную проблему. Эта скрытая проблема не исчезнет, если её игнорировать, и рано или поздно она приведет к реальным последствиям.
В худшем случае мы никогда не достигнем цели, а вместо этого продолжаем внедрять костыль за костылём, вращаясь по кругу. А следующая ошибка только и ждёт, чтобы случиться. Мы тихонько ходим на цыпочках вокруг этой проблемы ради поддержания работы программы и игнорируем то, насколько это бесполезно в качестве долгосрочного решения.
Другими словами, потратив несколько минут на такую мелочь, как выполнение надлежащей проверки, мы можем сэкономить часы на долгую и мучительную отладку в будущем.
Альтернативы костылям и хардкоду
Как ни банально это звучит — в первую очередь со своими вопросами лучше всего обратиться к Интернету. Точнее к людям, которые сидят на профессиональных форумах. Существует множество ресурсов, которые могут решить именно вашу проблему. И почти всегда есть разработчик, который уже прошёл по тому же пути и боролся именно с этой проблемой.
Но даже если вы не можете найти решение, вы можете задать вопрос. Не стесняйтесь спрашивать и добавляйте большое количество деталей. Детали очень важны, ведь вы хотите убедиться, что тот, кто вам помогает, сможет точно понять вашу проблему? Разработчики очень тесно сотрудничают между собой, и их общая цель — делиться знаниями, выявлять проблемы и предлагать решения.
Если вы работаете в команде разработчиков, можете попросить одного из членов команды просмотреть ваш код. Часто свежий взгляд приносит простое объяснение вашей проблемы. Или же другой разработчик сможет помочь вам, указав правильное направление для поисков. Этот приём называют «парным программированием». О он может быть наиболее эффективным способом быстрого поиска решения проблемы.
Используя «парное программирование», вы можете обмениваться идеями друг с другом и пробовать новые приёмы.
На войне все средства хороши, и не существует глупых способов найти решение. Знайте, что с каждой неудачей вы приближаетесь к поиску своего решения.
Отладчики — это способ построчно просматривать код. Может быть несколько причин, по которым ваш код не работает, и единственный способ правильно определить, в чем могут заключаться проблемы, — это изучить код строка за строкой. Существует множество отладочных плагинов и программного обеспечения, которые могут помочь в этом процессе.
- Если костыльного кода не избежать, постарайтесь свести на минимум последствия его применения. Для этого следуйте нескольким правилам:
- Весь костыльный код обосабливать от основного — выносить в отдельные функции или даже модуль, оставлять подробное описание.
- Если костылей накапливается критическая масса — проводить профилактику, рефакторинг кода, вычищая костыльную нечисть.
5 лучших практик для предотвращения ошибок
- Документация
Документация помогает корректно писать и читать код, а также помогает обучаться и расти как разработчику. Существует множество книг, описывающих правильное составление документации. Кроме того, написание документации по процессам, которые специфичны для вашей должности или вашей компании, окажется очень полезным в следующий раз, когда вам придется делать то же самое. Это поможет вам избежать одних и тех же ошибок.
2. Храните деньги в сберегательной кассе
Если вы используете репозитории для базы кода, обязательно используйте ветки. Это поможет при проведении тестов, а также позволяют другим разработчикам и членам команды легко просматривать и тестировать код.
3. Часто запускайте свой код
При реализации небольших функций обязательно запускайте код часто по мере внесения изменений. Это гарантирует, что на каждом этапе процесса, если произойдет ошибка, вы будете точно знать, где она находится. Чем больше кода вы напишете и реализуете между тестами, тем больше кода вам потребуется отладить при обнаружении ошибки.
4. Не торопитесь
Банальный совет, который многие игнорируют. Особенно в рамках горящих дедлайнов. Никто не хочет показаться ленивым или работать медленно, но если торопиться, можно упустить важные детали. Или допустить банальную ошибку.
5. Отвлекитесь
Бывают случаи, когда разработчик сидит над кодом не один час. Некоторые особенности работы мозга при этом начинают «блюрить картинку». И программист не может сфокусироваться на буквах и цифрах. Не пренебрегайте отдыхом, отвлекайтесь от работы. Делайте гимнастику для глаз, выйдите на улицу и прогуляйтесь хотя бы 15 минут. Каким бы ни был ваш перерыв, вы оцените эффект от него.