Недавно на сайте была статья о том как айтишники "сами вырыли себе профессиональные могилы" открыто делясь информацией. Я в корне не согласен с этим тезисом - доступность информации помогает только тем кто и так бы учился и работал, остальным же ничего не поможет. Но вот кое-в-чем наш брат все же сам себе усложнил жизнь, о чем и хочется высказаться.
Как-то очень плавно в стандарт разработки вошло как само собой разумеющееся требование: любые изменения возможны на любой стадии разработки. Причем в идеале любые изменения должны дорабатываться крайне быстро. Если к этому добавить экономию на аналитике (точнее, программист сам обязан разобраться во всех тонкостях предметной области и бизнес-правил продукта, а ТЗ обычно ограничивается словами "чтобы все работало как надо и ничего не работало как не надо" (кроме шуток, именно так мне сформулировали задачу по поддержанию корпоративного софта)) то получается просто звездное комбо.
При строительстве моста закладываются определенные характеристики по допустимой нагрузке, ширине, сроке службы и т.п. Внезапное требование пересмотреть характеристики сразу же приведет к пересмотру сроков, бюджетов и так далее. Но в айти внесение любых правок на любом этапе - норма. От тебя просто требуют чтобы ты поправил все - здесь и сейчас. Автор этих строк только что написал сервис в котором регистрируются договора и доп.договора. По здравому смыслу - доп.договор не может появиться в системе до договора - каково же было его изумление когда при заполнении продовыми данными такие случаи объявились. Как такое возможно? А вот оказывается возможно - договор толи пропотеряли, толи еще что-то - и вводят задним числом. "просто добавьте эту возможность" - сказали мне. Добавить-то можно, конечно - но уже была строгая модель - с констреинтами, валидаторами. А тут приходится срочно вводить "фиктивный" договор (и возникает куча вопросов - должен ли он фигурировать в статистике, можно ли в нем что-то заполнять), связывать его с доп договором, "подменять" на настоящий, отслеживать случаи когда "настоящий" так и не объявится. По хорошему там одной аналитики и согласования дня на три - дня три на проектирование, потом день кодинга - а дальше тестирование. Я же слышу "а что такого, просто добавьте возможность вводить доп.договора без основного, ничего сложного".
И вот в том, что так вышло, виноваты мы сами. Бизнес хотел иметь возможность вносить изменения быстро и дешево. Гуру айти - Блох, Лисков, Фаулер, Дядюшка Боб, Банда4х и т.д. пошли им навстречу, предложив SOLID, паттерны и фреймворки, главной целью которых было сделать возможность быстрых изменений. Тут мы декорируем объект и меняем логику программы. Тут мы переставляем аннотации и достигаем того, на что раньше уходили сотни строк кода. Мы можем выполнять все хотелки бизнеса в реальном времени! Быстро и дешево! И миллионы последователей гуру подхватили призыв: да, мы готовы на любой стадии проекта подменить источник данных. Перейти от асинхронной к синхронной обработке и наоборот. Переписать модель, переписать логику. Чего еще изволите-с. Мы ж программисты, эксперты и фанаты своего дела, мы можем все и нам это только в радость!
Понятно, что внести изменение в код легче, чем в физический агрегат, но далеко не настолько легче как с подачи гуру "чистой архитектуры" навязывают это сегодня. Беда в том, что "помогающие" быстро менять логику фреймворки сами вносят дополнительный уровень сложности в проект, а патерны далеко не панацея, если вносятся существенные требования в бизнес-правила. Мы же как будто забываем это и готовы исполнять любые хотелки. Заявить "это небыло предусмотрено, доработки потребуют существенное время" сегодня - все равно что признаться в профнепригодности (плохо спроектировал, не предусмотрел, не умеешь в функциональное программирование), хотя в общем-то это более чем нормально. Новое требование должно означать пересмотр сроков, причем порой "простое" требование может на деле стоить не человеко-часы а человеко-недели даже.
Так что если чему-то и нужно нам поучиться у других инженерных профессий - так это требовать четкое ТЗ вначале и дополнительные ресурсы на их любые изменения.
Комментарии (129)