Если вы встретили разозлённого программиста, почти наверняка причина в одной из этих ситуаций. Будьте готовы к ним, если доведётся взаимодействовать с разработчиками. Сразу станете своим. А если вы сами программист, эти ситуации, скорее всего, были или обязательно будут у вас.
В работу попал непонятный код
Например, IT-специалист трудится в интернет-магазине. Он написал программу для обслуживания заказов с нуля, он знает все её модули и понимает внутреннюю логику. Если что-то идёт не так, он мгновенно решает проблему.
Но программисты не всегда имеют дело со своими программами. Часто приходится вникать в чужие: дорабатывать, поддерживать, добавлять новые возможности. Когда код писал другой человек, у него какая-то своя организация, иначе устроены блоки, как-то по-своему решены задачи. Как будто пытаешься приготовить что-то на чужой кухне, только, чтобы найти нож или кастрюлю, нужно посмотреть не в пяти ящиках, а в 50.
Есть программисты-педанты: у них все «ящики» подписаны, функции и переменные названы понятно, архитектура кода очевидная. С такими вариантами приятно работать.
Но чаще так: программист выполняет задачу в условиях нехватки времени, и начинает он с понятного кода, а ближе к концу проекта всё сделано на скорую руку. И потом эти программы достаются на поддержку другим разработчикам, и они не могут в них ничего найти. Неудивительно, что они злятся.
Плохо сделанный код от предыдущего разработчика
Одно дело — когда код от другого специалиста просто устроен непривычно. Другое дело — когда он написан с огромным количеством «костылей».
Костыль в программировании — это когда, чтобы что-то работало, его подпирают чем-то неприспособленным. Представьте, что дверь в ванную закрывается на резинку, к которой привязана 100-килограммовая гиря. В итоге дверь работает, но гиря занимает место, и об неё все спотыкаются.
Так же в программировании: если у разработчика не было времени, он мог решить какую-то простую задачу быстрым обходным путём. Или прописать какие-то важные параметры не в отдельном конфигурационном файле, а прямо внутри кода — и пойди теперь найди, где этот параметр задаётся.
И вот старого разработчика уже и след простыл, а новому нужно погрузиться в спагетти-код и понять, что эта светлая голова имела в виду. Сложно сохранять самообладание.
Не дают времени сделать нормально
Допустим, программисту в интернет-магазине нужно добавить на сайт новую кнопку. Со стороны кажется, что кнопка — это легко. Программисту дают на задачу максимум день, а то и до обеда.
Когда разработчик разворачивает задачу, становится очевидно, что кнопкой дело не ограничится. Нужно написать внутренний модуль для магазина, переделать логику в другом месте, в третьем подключить более современные библиотеки, то есть работы дня на полтора. Плюс протестировать саму кнопку, плюс протестировать всю систему с ней, мало ли что. То есть работы на два дня, но зато программа будет логичной, устойчивой и хорошо задокументированной.
Это если делать нормально.
А можно сделать быстро: срезать углы, скопипастить чужой код, подключить тяжеловесные библиотеки, нагородить костылей, и кнопка тоже заработает. Это будет чертовски неэлегантно и менее надёжно, но быстро. И, если потом этот код придётся кому-то поддерживать, он хлебнёт там горя.
Хорошо, если руководитель понимает ценность нормальной разработки и даст на эту кнопку два дня, а то и три. Но чаще начальству нужно быстрее и «лишь бы работало». В итоге специалиста подгоняют, он вынужден срезать углы. И он сам понимает, что получается спагетти из кода, но переделка всегда откладывается на потом. Технический долг копится, никакого кайфа от работы.
Бонус: он просто не спал
Менеджер делал ночью презентацию, инженер чертил чертёж, а разработчик готовил релиз. В последний день перед запуском всегда что-то не так: нашли ошибку, она превратилась в три ошибки, они переросли в бесконечный каскад проблем, упал сервер, сгорели резервные копии — всё как в любой работе с дедлайном.
Что делать
Если вы встретили расстроенного разработчика — дайте ему осознать, что вы понимаете его боль. А если вы сами программист — прокачивайте навык переговоров, чтобы добиваться дополнительного времени на задачи и не брать в работу чужой бракованный код. Сил вам!
