?

Log in

No account? Create an account
Main

Победная спешка

Хорошая заметка у Боба Мартина о разнице между "работает" и "сделано"

http://blog.objectmentor.com/articles/2009/06/26/the-rush

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

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

Это еще одна вещь, которую обычно не учитывают, когда устанавливают сроки.

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

Консультант предложил менеджменту вычистить код. Но начальство не проявило энтузиазма. Код работал. Сроки поджимали. И Чистку решили делать когда-нибудь потом.

Консультант поговорил с разработчиками. Программисты были хорошими ребятами и адекватно отнеслись к замечаниям, тем более многое не было их виной. Иногда для того, чтобы увидеть проблему просто нужен свежий взгляд. Программисты потратили два дня на чистку кода, выкинув половину кода, не изменив функциональности. Результат понравился программистам, — код работал быстрее и его было легче понимать и использовать с другими частями системы.

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

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


Мартин Фаулер, предисловие к книге Рефакторинг.

Похожая штука была, видимо, с Copland, — неудавшейся веткой MacOs 8.

Comments

Это как в шахте в Норильске. Начальство за очистку забоев не платит, но очистить требует.
Хорошая аналогия, да.