Все
Дизайн
Код
Геймдев
Бизнес
Маркетинг
Управление
Кино и музыка
Фотография
Развитие
Здоровье
Деньги
Образование
EdTech
Корп. обучение
Блог Skillbox
Спецпроекты
Профориентация
Как правильно использовать костыли в разработке и не наплодить ошибок
В любом серьёзном проекте разработки найдутся костыли. Это естественный элемент пейзажа и процесса. Рассказываю, как ставить их правильно.
Костыльное программирование — это, мягко говоря, не идеальное решение. Костыль чаще всего не оптимизирован с точки зрения эффективности и производительности. И всё-таки иногда они нужны. Причин, по которым костыли появляются в коде, великое множество. Чаще всего их используют для быстрого и простого исправления ошибки, чтобы не переписывать половину модуля. Но бывают и другие случаи.
Костыляем правильно
Виртуальный график количества костылей ко времени в коде живого проекта напоминает пилу, у которой каждый зубчик — итерация. Цикл итераций выглядит примерно так:
- Внедрили костыли.
- Накопили в определённой части проекта некую критическую массу костылей.
- Провели рефакторинг, встроили костыли в логику, переписав часть кода.
Помните, что рефакторинг — достаточно затратный процесс, так как на этом этапе нужно понять статус и общую картину, расписать текущий алгоритм, проверить все точки соединения с другими частями проекта и с внешними ресурсами, провести миграцию существующих данных.
Тестирование отрефакторенного проекта — это отдельная задача неочевидной на первый взгляд сложности. Следует проверить, не потеряли ли мы что-нибудь нужное в процессе отработки наших костылей.
Когда вы работаете на молодой развивающийся проект, создавайте набор точечных и специфичных утилит — такой вариант разработки долгое время будет одним из наиболее эффективных:
- Мы достаточно оперативно получаем рабочие инструменты, которыми бизнес может пользоваться.
- Мы копим данные в нашей базе.
- Мы получаем фидбек от бизнеса.
- Бизнес адаптирует свои процессы под наши инструменты и уточняет ТЗ на будущую разработку до того, как мы всё сделали по-своему.
В проекте, где бизнес-процессы неустойчивы, сложное целостное программное решение продержится до первой непредугаданной «хотелки» заказчика. А она прилетит очень скоро.
Архитектура кода не может быть стройнее и сложнее архитектуры бизнеса.
Стройная и красивая архитектура возможна только в случае, когда вы сразу видите полный объём решаемых задач. Для эволюционирующего бизнеса это условие практически невыполнимое. Поэтому очередной рефакторинг стоит проводить тогда, когда вы заново качественно переосмыслили, как должна работать определённая часть проекта.
Костыль усложняет и восприятие кода — код, напичканный обработчиками частных случаев, очень сложно поддерживать. И в какой-то момент такой код становится невозможно развивать.
Если ваш костыль живёт в коде достаточно долго, а тем более если он обрастает братьями и сёстрами, — следует запланировать рефакторинг в одной из ближайших итераций.
Когда пригодятся костыли
Такие частные решения всё-таки находят свое применение:
- Позволяют решать задачи и тушить пожары при недостаточности ресурсов разработчиков.
- Помогают, когда заказчик хочет протестировать какую-то гипотезу.
Так мы можем «быстро накостылять, а потом, если идея сработает, выпилить костыль и написать код с нуля как следует» — это хорошее решение для лёгких быстрых проектов. Но если речь идёт о высоконагруженных проектах, то неоптимизированный и не доведённый до ума код может поставить под угрозу работу всей системы.
И помните, что даже костыль нужно писать аккуратно, грамотно, соблюдая стилистику и максимально подробно описывая причину, по которой он создавался. Это нужно, чтобы, вернувшись к своему же коду год-два спустя, вы не испытывали неловкость, найдя ответ на вопрос «Кто писал этот бред?».
