Корабль Тесея и Рефакторинг

Я всегда питал слабость к Греческой мифологии. Сегодня я показал дочери старый советский мультфильм "Лабиринт" (всем кстати рекомендую), основанный на легенде о Тесее, победителе Минотавра. И собственно просмотр этого мультфильма напомнил мне легенду о корабле Тесея. По приданию, после того как Тесей вернулся с Крита, его корабль очень долго хранился в Афинах как местная реликвия и каждый год в период разнообразных празднеств выставлялся напоказ. Однако, с течением времени корабль стал ветшать: доски гнили, паруса рвались, в общем проявлялись все признаки времени. Греческие умельцы латка за латкой стали обновлять корабль: сначала заменили одну доску, затем вторую, после третью, переткали паруса и понеслось. В итоге от оригинального корабля не осталось ничего. И греческие философы (наиболее прогрессивные в то время) задались вопросом: "А тот ли это корабль, на котором плавал Тесей или уже совсем другой? Новый?".  Философы, как у них водится, тут же поделились на два лагеря: одни утверждали, мол, форма та, используется он для того же, значит корабль тот; другие — кричали, да какой же это корабль Тесея, если "все украдено до нас", не осталось в нем духа Тесея. В общем идеалисты и материалисты сошлись в примерно равном бою. А мастера в это время продолжали спокойно менять доски, перекраивать паруса, подкрашивать ростр, и радовать горожан, обновляемым перед каждым праздником, кораблем Тесея.
Этот философский спор как нельзя лучше иллюстрирует конфликт "заказчик-разработчик".

Разработчики всегда идеалисты. Сколько senior developer на собеседовании не рассказывает про то, что необходимо учитывать цели заказчика, не перечисляет наиболее распространенные причины провала проектов и рассказывает, как их избежать, не отвечает на вопрос: "Какой вариант выберите, если вы дали изначальную оценку в два дня? Потом поняли, то, что не масштабируемо, сделаете за один, а масшабируемое —  за два.". Он всегда думает: "Сделаю лучше и дольше, в крайнем случае чаю попью". Он все равно идеалист. Да оно и правильно, его работа этого требует, нельзя создавать (читать, творить), видя только сроки и ограничения. Его цель —  не просто сдать в срок, не уменьшить количество дефектов, не увеличить статистику коэффициента достоверности эстимейта. Его цель —  получить моральное удовлетворение, ну и зарплату конечно.
На страже всегда остаются материалисты. И их целая толпа: заказчики, продажники, менеджеры проектов и, кстати, даже менеджеры по персоналу, у них то тоже сроки, им тоже нужно вакансию закрыть. И они нужны, и именно такими — прагматичными.
Эту систему нельзя назвать лучше, чем это сделал Джон Локк — Система сдержек и противовесов. У каждого в ней свои инструменты воздействия и свои правила игры. И инструментарий разработчика намного богаче инструментария заказчика (и всех, кто на его стороне). Разработчик единственный, кто действительно знает систему. Только разработчик может предположить, когда все рухнет и где подпереть, и более того, он должен об этом всегда думать. Разработчик видел десяток таких кораблей и знает, что кончается все либо разбиванием бутылки Шампанского, либо полной (под ноль) выработкой инвестиций.
Так к чему это я? Ах да, я это к рефакторингу. Типичная ошибка, которую, кстати, совершил не так давно я, ожидать, что заказчик поймет, зачем менять киль. Для него это все тот же корабль. Он делает все тоже. Заказчик не увидит, что он станет лучше плавать, его не перестанет штормить, он не превратится в самолет. Для заказчика это все тот же корабль Тесея, только подорожавший на 160 человеко×часов. Он материалист. И только разработчик поймет, что благодаря этим изменениям корабль стал совсем другим, он не трещит при ходе, в трюме не появляются пробоины после каждого шторма, при сильном ветре не рвутся паруса. Так вот по моему, безусловно личному мнению, не следует пытаться объяснить заказчику все это, он не поймет. В лучшем случае, он покивает, скажет, что все это нужно, скажет, что да время, выделим, если он умный заказчик, конечно. В худшем случае — месячные баталии без победителей и побежденных. Но у него всегда останутся приоритеты. И он от них не откажется и пока то, что вы считаете проблемой, он не осознает как проблему свою, она не станет для него приоритетной. А человеческая природа такова, что он ее не осознает, пока, все не накроется... (подставить по-вкусу).
Из всего выше изложенного я пришел к выводу, что у разработчика в такой ситуации два варианта поведения:
  • подождать, пока все накроется... но он идеалист и такое себе вряд ли позволит, а если позволит, то скорее всего забыл, что у него инструментов больше
  • менять, менять на ходу, планомерно и нагло
Микро-рефакторить, так сказать. Об этом мощном инструменте не стоит забывать. Конечно, если система доведена до такого состояния, что это уже не помогает, то создавал ее скорее всего не идеалист. Однако, большинство систем — реанимируемы, шаг за шагом (еще раз — планомерно и нагло).  Только разработчик знает, сколько времени займет задача, и если заказчик постоянно: раз за разом требует альтернативу, и каждый раз выбирает менее затратную альтернативу, пора перестать ее ему давать. Вот так банально, ибо я уже подошел к этому рубежу — давать альтернативу по определению хуже для него. Хороший хирург же не предлагает оставить гниющую конечность и попить антибиотики (авось поможет), потому, что так дешевле. Плохой, кстати предлагает.
И это реализуемо, даже в аутсорсинге, по одной простой причине — инструментарий разработчика намного богаче инструментария заказчика.