Даже плохой код может работать. Но если код не чист, он может поставить компанию-разработчика на колени. Каждый год из-за плохо написанного кода теряется бесчисленное количество часов и значительные ресурсы. Но так быть не должно. Роберт Мартин в своей книге-бестселлере Чистый код доводит это до сути.

ОБЩАЯ СТОИМОСТЬ ИСПОЛЬЗОВАНИЯ MESSY CODE

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

БОЛЬШОЙ РЕДИЗАЙН В НЕБЕ

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

ОТНОШЕНИЕ

Вы когда-нибудь пробирались через беспорядок, настолько серьезный, что на то, что должны были уходить часы, уходили недели? Вы видели, что должно было быть однострочным изменением, вместо этого сделанным в сотнях различных модулей? Эти симптомы слишком часты. Почему это происходит с кодом? Почему хороший код так быстро превращается в плохой? У нас есть множество объяснений этому. Мы жалуемся, что требования изменились таким образом, что нарушили первоначальный дизайн. Мы сожалеем о том, что графики были слишком плотными, чтобы все делать правильно. Мы болтаем о глупых менеджерах и нетерпимых клиентах, о бесполезных маркетинговых приемах и средствах для дезинфекции телефонов. Но вина, дорогой Дилберт, не в наших звездах, а в нас самих. Мы непрофессиональны. Это может быть горькая пилюля, которую стоит проглотить. Как в этом беспорядке могла быть наша вина? А как насчет требований? А как насчет расписания? А как насчет глупых менеджеров и бесполезных маркетологов? Разве они не виноваты? Нет. Менеджеры и маркетологи обращаются к нам за информацией, необходимой им для выполнения обещаний и обязательств; и даже когда они не смотрят на нас, мы не должны стесняться говорить им, что мы думаем. Пользователи обращаются к нам, чтобы проверить, как требования будут вписываться в систему. Руководители проектов обращаются к нам за помощью в составлении графика.

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