Перевод статьи “Clean Code, bullshit or common sense?”.
Обычная история
Боб приступил к работе в новой компании. Вскоре он понял, что его работа во многом будет связана с очень старой и сложной legacy-системой. Это был анемичный код без тестов. Документации тоже не было. Никаких пояснений рабочих процессов, которые должны были представлять собой решения, принятые и реализованные для удовлетворения бизнес-требований одного из сособственников. А теперь этого сособственника в компании больше не было, как и первых разработчиков кода.
То, что должно называться доменом, всегда было тесно связано с проблемами инфраструктуры… многие классы имели больше тысячи строк… в методах было слишком много if-предложений, создающих слишком много путей… пространства имен с 10-уровневой иерархией… широкое использование расширений классов…
Почти каждая задача касалась устранения какого-нибудь бага. Некоторые из этих багов были созданы давным-давно, другие появились недавно вследствие новых правок. Попытка изучить историю кода чтобы понять причины некоторых изменений и то, как они связаны с другими частями кода, оказалась бесполезной из-за плохой организации коммитов и недостатка сообщений…
Чтобы внести маленькое изменение в поведение системы приходилось проводить часы за отладкой и попытками понять, что написано в коде. После целого дня работы результат иногда состоял в добавлении или изменении примерно 10 строк. Большая часть нового кода была еще одним if-предложением, призванным обновить некоторые значения, потому что они были неверными и это каким-то образом приводило к багам… повсюду были геттеры и сеттеры.
Он имел дело с плохим кодом…
Почему это случается так часто?
Не поймите меня неправильно! Я не хочу сказать, что это просто говнокод, и не виню разработчиков или компании, потому что это ни к чему не приведет. Это правда, у нас действительно есть много непрофессиональных разработчиков, но сваливать всю вину на них это не выход. Нам нужно посмотреть на эту картину более широко.
Итак, почему это случается?
Тут играют роль многие факторы. Давайте представим компанию. Она растет, нанимает больше работников для ускорения своего роста. Новые разработчики приходят, старые уходят. Динамика бизнеса достаточно постоянно меняет требования, а с коммуникацией между IT и бизнесом есть проблемы. Разработчики сосредоточены на выполнении заданий спринта, а спешка давит на всех, работающих над проектом. Никто не считает нужным изучать взаимоотношения пользователя и продукта, никто не позаботился о написании тестов. Разработчики не могут проектировать, поскольку это не обещает отдачи в краткосрочной перспективе. Разработка через тестирование это нечто философское, а компания не выделяет время на обучение своих команд. Самая ценная практика – та, что решает сегодняшние проблемы. Растет культура героев. Нам нужно все больше логов, чтобы понять, что происходит. Нам нужно лидировать на рынке…
Я могу выразить это короче: проблема в спешке и отсутствии обучения.
При таком сценарии плохой код на выходе целиком закономерен. Наш мир порой не является прекрасным местом и с этой реальностью нужно смириться.
Тогда в чем смысл?
Я писал эту статью не для того, чтобы выдать вам простое решение. Такового просто не существует.
Цель этого поста – ответить человеку, который в ответ на жалобы разработчиков на плохой код имеет готовый ответ: «Послушайте… Система работает и приносит компании деньги. Именно это имеет значение. А разработчикам платят за то, чтобы они эту систему поддерживали».
Окей… Я уловил суть и согласен с тем, что «главной ценностью является работающая программа». Это звучит как волшебство и успокаивает нас, разработчиков. Но проблема от этого никуда не девается.
На самом ли деле главная ценность в рабочем ПО?
Компания, сильно зависящая от исправной работы какой-то технологии и желающая быть инновационной никогда не достигнет своих целей, если программное обеспечение превратится в проблему поддержки вместо того чтобы толкать бизнес вперед. Вернемся к ситуации с Бобом. Что-то добавлять в приложение или изменять его поведение практически невозможно. Каким образом тогда осуществить выпуск новой необходимой функции так, чтобы не сломать все остальное? Риск слишком велик, неизвестные побочные эффекты могут быть катастрофическими, а компания может оказаться на грани выживания вместо того чтобы стать инновационной. А конкуренты не спят.
Как по мне, с таким сценарием тяжело представить увеличение стоимости.
То, что программа делает деньги сегодня, еще не значит, что она будет делать их в будущем.
Плохой код может разрушать солидные компании и приводить к преждевременной смерти стартапов, и то, что мы, разработчики, остаемся за кадром, не означает, что в таких поражениях нет нашей вины.
Чистый код, т. е., забота о коде, т. е., изначальное тестирование – это путь к получению такого ПО, с которым бизнес действительно может расти. Так давайте учиться, давайте оттачивать свое мастерство, давайте узнавать способы справляться со спешкой!
Писать чистый код это наша ответственность как разработчиков. Смысл не в том, чтобы быстрее достигнуть завтрашних целей, смысл в том, чтобы достигнуть целей следующего года быстрее и безопаснее…
Вы когда-нибудь задумывались о том, чего ждет от вас ваш менеджер? Можете угадать ответ в краткосрочной и долгосрочной перспективе?
Я знаю, знаю… Совершенство недостижимо. Иногда нам приходится работать над срочными задачами. Но все равно моя идея в том, что мы не должны смиряться с плохим кодом и просто учиться с ним жить…
О чем говорит мой опыт?
У меня был реальный случай, когда мы потратили много времени в начале на достижение хорошего соотношения среды разработки и производства, создание полностью изолированных баз данных для каждого рабочего экземпляра проекта, написание сквозных тестов для всего приложения, функциональных и модульных тестов для каждой кодовой базы, создание автоматического развертывания и многих других вещей, которые многими считаются сложными, недостижимыми, да и ненужными.
Это было непросто. Но результатом нашей работы стал продукт почти без багов. При обнаружении нового бага пишется новый тестовый сценарий. Развертывание проходит быстро, безопасно и может выполняться в любое время. Новые свойства легко добавляются, а старые легко изменяются – это преимущества разработки через тестирование и agile-команды.
Мы должны бороться с плохим кодом и стараться писать его как можно лучше. Здесь можно сделать только одну ошибку: даже не попытаться.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]