Работа с непонятным кодом
К примеру, разработчик выполнял проект интернет-магазина, написав с нуля программу для оформления и обработки заказов. Он прекрасно разбирается в ее внутренней структуре, всех нюансах и тонкостях. Если что-то перестает правильно функционировать, он быстро решает любую проблему.
Но далеко не всегда программисты обслуживают свое ПО — часто приходится работать с чужим: изменять его, дорабатывать, поддерживать. И когда код писал кто-то другой, это сразу чувствуется, ведь там своя организация, немного по-другому устроены блоки, используются свои способы решения задач. Это как готовить на чужой кухне, когда не знаешь, где что лежит, и приходится перерывать все ящики в поисках нужного инвентаря.
Есть разработчики-педанты: в их программах все подписано, проккоментировано, названо емко и логично, архитектура очевидна. Как понимаете, с таким кодом приятно иметь дело.
Однако чаще всего программист за работой торопится: если и начинает хорошо, то под конец, из-за нехватки времени перед дедлайном, делает все впопыхах. Полученные программы в последствии приходится поддерживать другим айтишникам, и они с трудом разбираются в этой “каше”. Естественно, от такого любой человек начнет злиться.
Некачественная программа от предыдущего специалиста
И если непривычно устроенный код другого разработчика — это еще полбеды, то ПО с большим количеством “костылей” — настоящее испытание на прочность.
Костылем называются “уродливые” быстрые решения, к которым разработчики прибегают, когда не хотят или не умеют справиться с проблемой грамотно. Это как если бы входная дверь в вашу комнату закрывалась с помощью петли, на которой висит огромная гиря. В результате-то все работает, но гиря мешает, да и пользоваться таким приспособлением неудобно.
То же самое в разработке: если программисту не хватает времени, он может решить даже элементарную задачу не правильным, а обходным, более быстрым путем. И когда этого человека уже и близко нет, новому специалисту приходится погружаться в полученный хаос и пытаться понять, что же там вообще происходит. Конечно же, сохранить самообладание при таком раскладе крайне трудно.
Не дают достаточно времени, чтобы сделать хорошо
Предположим, что разработчика просят добавить на веб-страницу новую кнопку. Непосвященному кажется, что это пустяковое дело. Поэтому исполнителю дают на все про все полдня или день — максимум.
При развертывании задачи программисту становится ясно, что одной кнопкой он не отделается. Приходится также вносить коррективы в другие участки кода, подключать новые библиотеки, обновлять внутренний модуль. Т.е. работы больше, чем на сутки. Плюс нельзя забывать о тестировании. Таким образом, чтобы получить качественную программу, нужно поработать дня два.
Но есть и второй вариант: срезать углы, использовать тяжеловесные библиотеки, скопировать чужой код и наставить костылей, лишь бы кнопка работала. Программа будет очень некрасивой и не такой надежной, как хотелось бы, зато времени на работу уйдет меньше. А еще тому, кто будет потом поддерживать такой код, придется худо.
Прекрасно, когда начальство понимает ценность нормального продукта и дает на его создание достаточный срок. Но чаще всего заказчикам нужно побыстрее и не важно каким образом, лишь бы было сделано. Поэтому специалиста торопят, и ему приходится прибегать к “грязным” приемам. Он сам осознает, что создает спагетти-код, который впоследствии нужно переделывать, но это вечно откладывается на неопределенный срок. Технический долг растет, как снежный ком, из-за чего работа не приносит никакого удовольствия.
Что делать?
Встретив расстроенного или нервного разработчика, просто подарите ему немного понимания! А если им являетесь вы сами, то развивайте свои коммуникативные навыки: учитесь договариваться про адекватные сроки выполнения и не соглашайтесь браться за чужой некачественный код. Всем сил и терпения!
