Хороший плохой код

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

За свою рабочую карьеру Василий повидал всякое: огромные файлы по несколько тысяч строк; мудрое переиспользование кода посредством копирования; хитроумные оптимизации, которые не давали прироста производительности. А однажды в проекте на FORTRAN ему показалось, что он даже отыскал следы динозавров. Но новый проект был настолько уникален в своём роде, что Василий впервые задумался о выходе на пенсию, до которой ему оставалось всего чуть более тридцати лет.

Что же такое плохой код?

А я в детстве в деревне вычищал навоз в коровнике. Вырос, стал программистом, а ничего не поменялось.

Взято с bash.im

Само по себе понятие плохого кода очень субъективно. Каждый разработчик может мысленно разделить кодовую базу на две части: свой собственный код и отвратительное нагромождение конструкций, которое по нелепой случайности именуется кодом.

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

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

Как появляется плохой код?

Разобрались! Плохой код — это любой исходный файл вашего коллеги! Следуя изумительному выводу, на этом можно было бы закончить и посоветовать менеджеру выгнать остальных разработчиков из команды (пока они вас не опередили). Но решило бы это проблему, даже если на время отбросить в сторону фактор автобуса? К сожалению, нет.

Разработка программного обеспечения в подавляющем большинстве случаев не является источником доходов сама по себе, а призвана закрывать проблемы и оптимизировать решения бизнеса. Сложно представить, как главный инвестор с бокалом хорошего виски листает исходники, достигая нирваны от совершенства. Гораздо более вероятно, что вы участвуете в очередном виде безнадёжного проекта из замечательной книги «Путь камикадзе» Э. Йордона, когда закрыть задачу нужно ещё вчера, а менеджер уверяет, что в этот раз достаточно обойтись временным решением.

Деградация по спирали

Временных решений становится всё больше, они образуют ядро проекта. Через год уже сложно поверить, что этот код был написан вами. В проекте постоянно что-то ломается, времени на внесение новых изменений не остаётся.

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

Постепенно проект явным или неявным образом разделяется на зоны ответственности между разработчиками. Ввиду отсутствия общего подхода (спагетти-код не в счёт), каждая часть развивается отдельно и независимо. И всё движется по спирали:

• Разработчики мысленно начинают делить кодовую базу на описанные ранее две части;
• Появляются срочные задачи, которые закрыть нужно ещё вчера;
• Каждый разработчик начинает вносить временные решения в свою часть кода…

И что же делать?

Пишите код так, как будто поддерживать его будет склонный к насилию психопат, который знает, где вы живёте.

Джон Вудс

У предложенного подхода Джона Вудса есть один недостаток: разработчики бы быстро закончились, поэтому попробуем поискать ещё.

Современные методы разработки предполагают частое внесение изменений с возможностью разворота проекта в любой момент на 180 градусов. При этом изначальная архитектура скорее не сможет поддержать такой разворот, но времени на переписывание с нуля, конечно, нет. Да и кто даст гарантию, что через день всё не повторится опять?

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

Именно поэтому необходимо делать паузы и выделять время на рефакторинг, который поможет сделать какие-то части кода более надёжными и удобными для изменений. Поскольку времени на полную переработку не будет, этот код скорее всего будет идти вразрез с изначальной архитектурой. И как бы вы не были довольны полученному результату, стороннему наблюдателю он может всё равно казаться плохим: ему не будут очевидны все тонкости и причины внесённых изменений. Отсюда и получается, что код одновременно и хороший, и плохой, — а мы все пишем хороший плохой код.