Бизнес vs программная инженерия
Где-то я слышал, что в психотерапии существует следующая методика работы с пациентом — пациенту предлагают сесть и написать в свободной, «потоковой» форме все что накипело, волнует, будоражит сознание и, отражаясь на подсознании, не дает спать по ночам. Применительно к этому есть хорошее, нежно ласкающее слух слово — фрирайтинг.Итак, почему я решил это написать — когда сталкиваешься с полным пренебрежением к проектированию ПО как таковому, пренебрежением к качеству и соблюдению хоть какой-нибудь методологии разработки, всегда удивляешься. Когда сталкиваешься с этим раз за разом, об этом уже хочется написать.
Первое о чем думаешь — может инженерия уже мертва и миром правит маркетинг — не важно как написано, спроектировано, спроектировано ли вообще, главное продать, всучить, впарить? А инженерия как таковая, отошла на второй план, и настоящие «креативщики» — это эти прыткие молодые люди, менеджеры по продажам, пронырливые и настойчивые как таксы, достающие барсука из норы? Это мысль сама по себе дикая крамола, но она приходит в голову раз за разом, когда наблюдаешь происходящее.
Теперь подробно о том, что собственно происходит. Происходит то, что инженерная деятельность оказалась служанкой бизнеса. Что самое парадоксальное даже в тех случаях, когда основной продаваемый продукт/сервис компании является программным продуктом. Бизнес диктует свои правила, бизнес ограничивает, подгоняет, бизнес благосклонно относится к тем людям из технической «обоймы», которые готовы действовать ради него в ущерб качеству и дизайну. В этом случае менеджмент напоминает недалекого человека, который сидит на суку и потихоньку этот сук подпиливает, толи из-за недостатка знаний, толи сегодня прибыль, а завтра хоть трава не расти.
Впрочем, «особенности национального менеджемента» — это тема для отдельного, большого и довольно грустного разговора…
Бизнес вообще напоминает прожорливое чудовище, которое к тому же имеет свойство поедать и самого себя.
Замечательное понятие — технический долг, всем знакомо, все читали, кое-кто даже реально представляет себе что это. Но число реальных проектов, которые ведутся с учетом этого понятия на мой субъективный взгляд, пренебрежимо мало.Причина проста — технический долг очень не нравится бизнесу, он его ненавидит, ненавидит даже разговоры о нем.
Бизнес полюбил скрам –, но очень странной любовью. Скрам в большинстве случаев это просто превосходная соковыжималка. Кто в роли фруктов и овощей? Конечно разработчики. Более того, скрам используется в качестве своеобразного «фигового листочка», прикрывающего несостоятельный подход к множеству технических вопросов. Из скрама берется все, касающееся части «навесим побольше функционала и сделаем это побыстрее». Я имею ввиду прежде всего порции новых фич, реализация которых вешается на каждый новый спринт. Но все практики, касающиеся качества кода и продукта в целом, достижения и поддержания устойчивого к изменениям, легко тестируемого и сопровождаемого дизайна — в большинстве случаев просто отбрасываются.
Тут надо оговориться — я не хочу обобщать всех и все, я говорю про тенденции, которые объективно существуют на сегодняшний день.
Далее — QA. Понятия обеспечение качества и контроль качества для огромного количества проектов является чем-то далеким и загадочным, как туманность андромеды. И это напрямую вытекает из неполноценного использования скрам-практик. Если continuous testing не реализован на проекте именно как один из процессов жизненного цикла ПО — даже если есть люди, которые в ручном режиме пытаются «нащелкать» баги в UI, такое тестирование иначе чем профанацией назвать нельзя. Результат — баги, выпорхнувшие в релиз из-за такого отношения к QA, наносят такой репутационный и финансовый ущерб компании, по сравнению с которыми затраты на постановку реально эффективного процесса работы с качеством продукта покажутся мизерными.
Но опять-таки — кто занимается этими метриками, этими подсчетами, этими соотношениями затраченных ресурсов…
Документирование бизнес тоже не любит, затрачиваемые ресурсы серьезны, эффект неочевидный, да и вообще тут тоже можно прикрыться скрамом: «у нас скрам, тесная коммуникация к группе, нам это не нужно».
Это при том, что проект досконально знают в лучшем случае 2–3 человека из группы, остальные знают его в общих чертах и/или фрагментарно, как следствие если эти, обладающие «тайным» знанием люди выходят из игры, то проще переписать все заново, что повлечет затраты, несопоставимые с затратами на документирование. Плюс к этому — возможность анализа системы на предмет рефакторинга кода или более серьезного реинжиниринга. Плюс к этому — к примеру, вход нового человека в проект. Насколько быстрее оно произойдет, насколько быстрее человек станет эффективным, если с самого начала начнет работать с задокументированной системой.
И хорошо еще, если на проекте присутствует code review, адекватно реализованная модульная архитектура на базе SOLID принципов, нормальная нотация для структурирования, форматирования, именования переменных разных уровней, классов, методов — это в значительной степени может компенсировать отсутствие документации, но думаю описанная выше идеальная ситуация — скорее исключение из правил…
Как лечить все эти негативные тенденции в индустрии разработки ПО?
Как мне видится, главная таблетка тут — образование.Чем быстрее многоуважаемое академическое сообщество дозреет до осознания программной инженерии как самодостаточной инженерной дисциплины, а не вечной «падчерицы» у «мачехи»-математики, тем быстрее будут скорректированы учебные программы, надеюсь, больше людей будут приходить из реальной разработки в качестве преподавателей в ВУЗы.
Самое главное, что должно давать профильное образование в области разработки ПО — это объемное виденье процесса разработки, если люди имеют такое виденье, они с вероятностью близкой к единице смогут правильно расставить акценты и максимально гармонизировать требования бизнеса со своей деятельностью.
