Костыли для заказчика

С костылями (в программерском смысле) я сталкиваюсь довольно часто.

Уж сколько раз твердили миру, что костыли — это зло, но разработчики продолжают применять эту мерзость в своей работе.

Но костыль программиста не просто так называется костылём. Костыль «здорового человека» — это прежде всего инструмент. Инструмент, позволяющий больному или покалеченному ходить прямо (а не сидя или лёжа). Человек на костылях пройдет там, где не пройдёт инвалидная коляска. Сам видел.

https://www.youtube.com/watch?v=5_kMKgYM9dI

Но почему же в IT-сфере так не любят костыли?

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

Я видел, как серьезная софтверная контора, имеющая собственный, уникальный, фреймворк, потеряла клиента размером с танкер только из за того, что каждая новая хотелка делалась всё дольше и дольше, а софт, при этом, работал всё хуже и хуже. Дошло до того, что после устранения любого бага, отдел тестирования выявлял от трех до девяти новых!

А причина была в костылях, которые множились и плодились.

Тогда по каким причинам костыли продолжают применять?

Ответа три.

1. Из за некомпетентности разработчика

Да! Разработчик тоже человек и не может всё знать и уметь, а кушать хочется.

Заказчик не заметит, начальник не узнает, а дело будет сделано.

Многие новички грешат этим. Это не страшно.

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

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

Скупой, как известно, платит с процентами.

2. Из за некомпетентности руководства

О да! Канбан, аджайл, эстимации, таймменеджмент и прочие, невероятно полезные изобретения, которые некоторые руководители с умным видом используют не по назначению.

Насмотрелся, нахлебался и знаю чем рано или поздно такое заканчивается. При том, сталкивался лично.

Приведу пример.

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

А что из этого вышло?

Каждая задача стала оцениваться по времени.

Само по себе это не плохо. Но когда поощряешь скорость в разработке, программист просто вынужден использовать костыли. Ну а как еще, если ты оценил задачу в 2 дня, а коллега говорит, что справится за час. Задачу отдают ему, а тебя ставят на заметку. В итоге ты либо уходишь из конторы, либо начинаешь лепить костыли со словами «да ямбись оно всё хореем».

А еще, отчеты с каждого сотрудника. Нужно ежедневно проставлять сколько времени на что тратится. Для работы это, поверьте, не важно. А вот для менеджеров и их отчетов — архинужно и архиважно. И на эти отчеты тратится время и нервы.

Ты засек время на нужной задаче? Ты включил таймер? А выключил? Все в конце недели убедились, что время проставлено? Ну и т.д.

Сроки начали подгоняться под реальность задним числом.

Если теория не соответствует практике, ее можно отбросить. Но ведь вместе с теорией будет выброшена и репутация теоретика. Поэтому, теоретик подгоняет данные эксперимента под свою теорию. Т.е. врёт? Нееееет!)

Сроки можно выставить одни, а потом, если не хватает времени, накидать подзадач и уже их оценить по времени. А можно на ежедневных брифингах назадавать уточнающих вопросов и, сделав вид что «концепция поменялась», оценить задачу уже на другое время. Или взять, и сделать одну задачу быстрее, а на вторую потратить времени больше.

Т.е. вроде задача оценена, клиенту выкатили счет, а потом — ой, сволочной отдел разработки опять требует больше времени. Почему? А потому, что кто-то виноват. Например, заказчик не описал задачу как следует, менеджер не собрал нужную информацию, форс мажор, усушка, утряска, понос, золотуха. Надо ли говорить, что командной работе это явно не способствует, да и руководство начинает что-то подозревать. Ведь нет четкости, которой хотели. Впрочем, это уже совсем другая история.

Менеджер замкнул на себя все процессы.

Взаимодействие между отделами стало вестись только через менеджера (либо при его непосредственном участии). Оно и понятно. Зато англичане перестали слышать критику. Вместо нее — профессиональные отчеты. Вот только дело почти перестало делаться, ведь брифинги, согласования, пережевывание ТЗ по 100 раз, смена концепций и т.д не способствуют.

Закономерный итог.

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

Прогноз.

Я уверен, эти конкретные англичане либо разорятся, либо продадутся. Скорее второе, но время покажет. Пока они существуют за счет поддержки уже имеющихся клиентов, но… костылей в их софте будет всё больше, поскольку полностью переписать фреймворк, это вам не на муравейник помочиться. Это расходы. При том, расходы серьезные. А значит, улучшать функционал и латать баги продолжат костылями.

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

3. Костыли по необходимости

Я уже говорил для чего нужны костыли (как инструмент) и для кого. Но давайте приведу пример, для пущей наглядности.

Буквально вчера пришел клиент с проблемой. Ему поставили сбор статистики с формы обратной связи. И всё бы ничего, но при одной отправке формы, статистика фиксирует от ста до трехста отправок с одинаковыми данными.

При этом, иногда верстка формы разъезжается и появляется надпись про спам и необходимость включить JavaScript.

Начинаем копать.

Сайт оказался на довольно устаревшей Джумле. Я с этой CMS сталкиваюсь крайне редко. Долго рылся в админке, а затем по FTP непосредственно в файлах и нашел любопытный скрипт. Код приводить не буду, но скажу принцип.

Значит! Чтобы форма при отправке сообщала данные еще и на сторонний сервис, событие стандартной отправки формы перенаправили в функцию с помощью JS.

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

Это явный костыль, но юмор ситуации в том, что он еще и криво работает. Ведь сразу после аякс-запроса вызывалось событие отправки формы, а оно у нас переопределено. Таким образом, функция начинала вызывать саму себя много-много раз, и сервис получал множество аякс-запросов вместо одного.

Я этот костыль выправил тем, что после валидации и аякс-запроса к сервису, отменял переопределение события отправки формы обратно на стандартное, а затем вызывал событие отправки формы.

Знаю, звучит как «мы умаслили масло масленное», но пытаюсь излагать так, чтобы было понятно.

Следующая проблема — внезапно разъезжающаяся верстка.

Оказалось, на сайте используется плагин, который, найдя на странице e-mail, заменял его на нечитаемые символы и кусок JS-кода. После загрузки страницы в браузер, JS-код восстанавливал e-mail в человекочитаемый вид.

Так вот, в форме обратной связи человек указывает кучу данных, в т.ч. электронную почту и телефон. JS-валидатор пропуска телефон формата +7 (ХХХ) ХХХ-ХХ-ХХ, а вот валидатор на стороне сервера — нет. После оправки формы, он возвращал страницу с уже заполненными полями, а поле с телефоном выделял красным, сопровождая гневным — «Заполните поле!».

Т.е., после получения некорректного, с его точки зрения, телефонного номера, серверный скрипт возвращал страницу. Страницу, на которой есть e-mail, ведь клиент его ввел, и ввел корректно. Ну а раз это страница, то плагин преобразовывал этот e-mail в ссылку с куском JS-скрипта. А поскольку изначально e-mail находился в параметре тэга input (value=»»), то он просто разрывал тэг, из за чего и верстка слетала, и JS-скрипт не работал.

Перерыв кучу файлов, я сделал еще один костыль, который в момент отправки телефонного номера выкусывает из него всё, кроме цифр. Такой номер пропускает и JS-валидатор, и серверный.

Т.е., в данном случае, мы имеем сайт-инвалид. Старенький, немощный, но вполне рабочий.

Да! Переделать его и сменить движок на свежий, суперсовременный — было бы круто. Но! Через 2-3 года этот современный тоже устареет.

Переписывать сайт имеет смысл только тогда, когда реализуешь целый комплекс нововведений, а не из за единичной проблемы с формой обратной связи. В данном случае, чтобы сайт снова нормально «ходил», разумнее дать ему костыль, как заслуженному сайту с ограниченными возможностями. Что и было проделано.

Но рано или поздно — переделывать все-равно придется.

Выводы

Не всякие костыли зло, но не всякие костыли благо.

Костыль, как инструмент, хорош только для тех, кому без него невозможно ходить ногами.

Если в обуви можно передвигаться только на костылях — ну нафиг такую обувь.

Не всякий лорд костылей — говнокодер. Дело может оказаться как в инвалиде умственного труда, который организует работу, так и в нездоровом проекте, который пора выкинуть и купить (создать) новый.

Ну и напоследок, если часто делаешь костыли, пора что-то менять, иначе привыкнешь.

Да, сегодня я обошелся без рецептов, поучений и утилит, а просто высказался о проблеме костылей в среде программистов. Но… а почему бы нет?))

С вами был Доктор Лексиум.
Пусть ваши сайты будут здоровы, веселы, популярны и приносят не только радость, но и доходы, чтобы все это содержать))