Почему разработчики бывают такими злыми?

Работа с непонятным кодом

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

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

Есть разработчики-педанты: в их программах все подписано, проккоментировано, названо емко и логично, архитектура очевидна. Как понимаете, с таким кодом приятно иметь дело. 

Однако чаще всего программист за работой торопится: если и начинает хорошо, то под конец, из-за нехватки времени перед дедлайном, делает все впопыхах. Полученные программы в последствии приходится поддерживать другим айтишникам, и они с трудом разбираются в этой “каше”. Естественно, от такого любой человек начнет злиться.

Некачественная программа от предыдущего специалиста

И если непривычно устроенный код другого разработчика — это еще полбеды, то ПО с большим количеством “костылей” — настоящее испытание на прочность. 

Костылем называются “уродливые” быстрые решения, к которым разработчики прибегают, когда не хотят или не умеют справиться с проблемой грамотно. Это как если бы входная дверь в вашу комнату закрывалась с помощью петли, на которой висит огромная гиря. В результате-то все работает, но гиря мешает, да и пользоваться таким приспособлением неудобно. 

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

Не дают достаточно времени, чтобы сделать хорошо

Предположим, что разработчика просят добавить на веб-страницу новую кнопку. Непосвященному кажется, что это пустяковое дело. Поэтому исполнителю дают на все про все полдня или день — максимум. 

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

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

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

Что делать?

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