Заметки ассенизатора.

Сегодня хорошая знакомая спросила меня по скайпу:
- Чем ты занимаешься на проекте?
Я, подумав некоторое время, ответил:
- Ты знаешь, ничего особенного, все как обычно: разгребаю окаменевший навоз.

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

Проблемы типа "сделаем как-нибудь" бывают двух типов:

1. Хорошая архитектура проекта, но собственно, имплементацию тех или иных вещей писали люди без опыта. Например, пару лет тому в одном из проектов, где я работал, один из местных разработчиков, отчаявшись понять, где у него проблема, пригласил меня глянуть в код. Когда я посмотрел, то оторопел: парень написал собственную имплементацию стандартных контейнеров, т.к. просто не знал о существовании STL. Для тех, кто не в курсе: это если бы кто-то сел в автомобиль, и не зная, что в природе существуют моторы, приделал к нему педали. Ко мне он пришел тогда, когда одна из педалей начала заедать.

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

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

В проекте, на котором я сейчас работаю, ситуация номер два тянулась 5 (пять) лет. Месяц назад количество заплаток и подпорок, которые каждый лепил в этом проекте в меру своего разумения и сиюминутных нужд, превысило критическую массу и началось веселье: с одной стороны, в феврале должна быть выпущена новая версия проекта, поддерживающая следующее семейство железок, производимых фирмой, с другой стороны, простое раздувание кода методом copy-paste уже становится невозможным: память в этих самых железках не безразмерная, и счет свободному месту уже идет на килобайты. Надо менять архитектуру.

Смена архитектуры - крайне сложная и болезненная штука, и вот почему:

1. Старая версия пусть кое-как, пусть спотыкаясь и падая, но работает. Новую версию придется полностью тестировать, тратя на это время (деньги) и на этом этапе не получая взамен ничего: в лучшем случае это будет продукт с той же функциональностью, что и старый продукт: мы меняем архитектуру, а не добавляем новые возможности. Кроме того, за грехи старой архитектуры вроде бы как никто не отвечает персонально, "оно само так сделалось", а вот за косяки, неизбежно всплывающие при переписывании готового проекта, будет отвечать конкретный исполнитель и менеджер, над этим исполнителем поставленный.

2. В то время, пока ты переписываешь структуру проекта, остальные разработчики продолжают бодро писать код в старую версию проекта. Именно поэтому такие вещи надо делать, во-первых, очень быстро (иначе сумма изменений, наработанных другими членами команды, просто завалит архитектора с головой) во-вторых - с умом: слишком радикальные изменения могут потребовать запредельных усилий остальных членов команды, и, кроме того, архитектор рискует натолкнуться на стену непонимания. Кроме собственно изменения архитектуры приходится проводить брифинги с коллегами, объясняя, почему это изменили, что это дает и как этим теперь пользоваться. Необходимо донести свою мысль до каждого разработчика в проекте.

3. Менеджмент компании такие вещи понимает плохо. Менеджер верхнего уровня во многом подобен блондинке за рулем: пока колеса крутятся - все хорошо. Идея о том, что машину надо загнать на профилактику, воспринимается "блондинкой" плохо: мне надо ехать, какая, к черту, капиталка мотора и почему надо за что-то платить? Ведь вчера еще все ехало!?

4. Инерция мышления: сидели люди, им было хорошо, тепло, стабильно капала зарплата. Теперь надо как-то меняться, что-то делать, как-то реагировать на чужие изменения. Это, как минимум, дополнительные телодвижения, как максимум - серьезный дискомфорт.

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

Изменение архитектуры готового проекта очень похоже на попытку перестроить жилой дом, не выселяя оттуда жильцов: снести под корень и отстроить заново никто не даст, тетя Хая скандалит за цвет фаянса в своем санузле, Соломон Моисеевич уже 40 лет спит в пятиугольной спальне со скошенными стенами и совершенно не желает покупать нормальные книжные полки, когда стены выровняют, а Фима привыкла, что цепочка для слива воды в унитазе находится на балконе и смутно себе представляет иной порядок вещей. При этом все грозятся снизить квартплату, а домуправление грозится распять того, кто затеял этот бардак, прямо на главных воротах во двор дома.

Самое смешное, что должность архитектора была в каждой или почти в каждой немецкой конторе, где мне довелось трудиться. Правда, именно архитектурой проекта никто из этих ребят не занимался: один из товарищей занимался согласованием "как будет выглядеть морда конечного продукта" с менеджером, второй две недели каждого месяца торчал в Голландии, а две недели обложившись бумагами, сидел в Германии. Молодому человеку было что-то около 28 лет, знающие немецкие реалии уже улыбнулись от уха до уха. Настоящий, классический архитектор проекта был только во времена моей работы на BMW, и это был человек, который действительно занимался своим прямым и непосредственным делом - архитектурой проекта.

Ну и заканчивая: "потом и завтра" не бывает никогда. Это так, в качестве философского окончания.