Чтобы понять, как плохой код влияет на компании, давайте рассмотрим несколько примеров.
Я читал об одной компании, которая в конце 80-х написала убийственное приложение. он был очень популярен, и многие профессионалы купили и использовали его. Но потом циклы выпуска стали растягиваться. Ошибки не исправлялись от одного релиза к другому. Время загрузки увеличилось, а сбои увеличились. И вскоре после этого компания прекратила свою деятельность. После обсуждения с одним из сотрудников стало известно, что они поторопились с выпуском продукта на рынок и устроили огромный беспорядок в коде. По мере того, как они добавляли все больше и больше функций, код становился все хуже и хуже, пока они просто не могли больше им управлять.
«Плохой код обрушил компанию».
Вам когда-нибудь сильно мешал плохой код? По моему мнению, каждому разработчику мешал плохой код. Тогда зачем мы это написали?
Может быть много оправданий, например, мы чувствовали, что у нас не было времени хорошо поработать; что ваш босс рассердится на вас, если вы потратите время на очистку своего кода. Или, может быть, вы подумали, что позвольте мне взять другую задачу, и я вместе почищу код для этих задач. Мы все посмотрели на беспорядок, который мы только что устроили, а затем решили оставить его на другой день. Мы все говорили, что вернемся и очистим это позже, но «Позже равно никогда».
Если вы работаете программистом более двух лет, возможно, вас тормозил беспорядочный код. По мере нарастания беспорядка продуктивность команды продолжает снижаться, асимптотически приближаясь к нулю.
По мере снижения производительности руководство добавляет в проект дополнительных сотрудников в надежде повысить производительность. Но этот новый персонал не разбирается в устройстве системы. Они не знают разницы между изменением, соответствующим замыслу проекта. Кроме того, они и все остальные в команде находятся под ужасным давлением, чтобы повысить производительность. Таким образом, они все больше и больше беспорядка. В конце концов команда бунтует. Они сообщают руководству, что не могут продолжать разработку в этой кодовой базе. Требуют переоформления. Менеджмент не хочет редизайна, но не может отрицать, что производительность ужасна.
Менеджмент не заменит старую систему, пока новая система не сможет делать все то же, что и старая. Поэтому им нужно создать новую команду для перепроектирования системы. Теперь обе команды участвуют в гонке. Новая команда должна построить новую систему, которая будет делать все то же, что и старая. Мало того, они также должны идти в ногу с изменениями, которые постоянно вносятся в старую систему.
Эта гонка может продолжаться очень долго. Было замечено, что этот тип процесса занимает 10 лет. И к тому времени, когда это будет сделано, первоначальные члены новой команды уже давно ушли, а нынешние требуют перепроектировать новую систему, потому что она такая неразбериха.
Если вы испытали хотя бы одну маленькую часть описанной выше истории, то вы уже знаете, что тратить время на поддержание чистоты вашего кода не только выгодно с точки зрения затрат; это вопрос профессионального выживания.
Весь контент этого блога взят из книги «Чистый код» Роберта К. Мартина.
