Григорий Петров: Ползучий фичеризм

Компьютеры вошли в нашу жизнь всего двадцать лет назад, и мы до сих пор не очень хорошо понимаем, как правильно создавать для них программы. Более-менее опытный разработчик — это средневековый алхимик, смешивающий разное, офигевающий от результатов и пытающийся понять, как же оно все работает и что потом делать с тем, что получилось в результате смелых экспериментов. Человеческий мозг постоянно строит модели, пытаясь самым простым способом объяснить окружающий мир. Программы — не исключение. И разработчик, и заказчик, не зная как делать правильно, будут постоянно чувствовать потребность все поменять и “сделать по уму”. Такое фонтанирование идеями, постоянная переделка и “улучшения” программного обеспечения имеет имя. Это имя — “ползучий фичеризм”. По имени можно догадаться, что ничего хорошего оно не обозначает.

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

Во многом “ползучий фичеризм” обусловлен некреативностью нашего воображения. Сторонники “lean startup” не просто так агитируют выходить на улицу и общаться с пользователями. “Мы лучше знаем, что нужно нашим клиентам” — не более чем иллюзия, благодаря которой разрабатываемые программы мечутся между случайными идеями заказчиков и не менее случайными соображениями разработчиков по “правильности архитектуры, гибких настройках и универсальности”.

На десерт — наша невозможность предсказывать будущее и полная уверенность в обратном, продиктованная ретроспективным когнитивным искажением. Мозг устроен так, что, получив новую информацию, мы вначале добавляем ее в картину мира, а потом уже осознаем. Собственно, это прямое следствие того, что мозг воспринимает окружающий мир с помощью моделей: мы просто физиологически не сможем ничего осознать, пока не добавим в модель. Если сказать человеку “один в поле не воин”, то фраза (при условии что он слышит ее первый раз в жизни) будет пропущена через лабиринт воспоминаний, жизненного опыта, настроения, добавлена в картину мира и уже потом воспринята. В большинстве случаев — как истина, потому что общие утверждения хорошо стыкуются с любой картиной мира. Теперь скажем тому же человеку “и один в поле воин” — фраза точно так же будет добавлена и тоже будет воспринята как истина. Дальше — больше. Когда мы смотрим на успех компаний, наш мозг автоматически ищет паттерны, “причины” этого успеха. “Я всегда это знал!” и “Это очевидно!” говорят люди в ответ на услышанное или прочитанное. Хотя, на самом деле, они “узнали” это только что. Просто новая информация была вначале добавлена в картину мира, а потом осознана. Под давлением иллюзии разработчики и менеджеры закладывают при создании проекта множество “фичей”, “настроек” и “гибкости”, уверенные, что могут предсказать будущее по опыту проектов, с которыми они знакомы. Ведь это “очевидно” и они “всегда об этом знали”. На практике же такие фичи могут встать клином в архитектуре и годами преследовать проект, парализуя для него развитие в нужных направлениях.

Почему фичеризм называют “ползучим”? Потому что каждая фича в отдельности наносит немного вреда и “ну давайте сделаем, сложно что ли?” А у нашего сознания, кроме всего уже перечисленного, есть такое когнитивное искажение как “невозможность воспринимать медленные изменения”. Мы неспособны увидеть, как стареют хорошо знакомые люди — для нас это всегда внезапно. Точно так же ползучий фичеризм неотвратимо наползает на проект: новые пользовательские фичи, которых никто не просил, оборонительные сооружения в коде “на всякий случай”, добавление в архитектуру гибкости “про запас” и фичей “а вдруг пригодиться”. Все это повышает сложность проекта и цену добавления тех функций, которые на самом деле нужны пользователям. А в тот момент, когда функциональность вдруг действительно понадобится, оказывается, что проект уже перегружен никому не нужными фечами и цена внесения нужного изменения непомерно высока.

Как бороться с ползучим фичеризмом? Так же как с большинством когнитивных искажений: не верить чуйке и “внутреннему голосу”, все записывать и проверять. Менеджер говорит, что “так сейчас все делают?” Давайте выпишем этих “всех” и посмотрим, есть ли они на самом деле. Разработчик утверждает, что в проекте срочно нужен рефакторинг и новая шина данных? Пусть выпишет в столбик проблемы текущей реализации, как минимум две альтернативы, их сильные и слабые стороны. Скорее всего, в процессе этого выписывания он будет удивлен не меньше вашего когда обнаружит, что все “преимущества” были иллюзией, умело созданной его собственным разумом.

Наш разум — он такой. Обязательно надо проверять. И помнить о Yagni. Потому что не пригодиться.