Где-то я слышал, что в психотерапии существует следующая методика работы с пациентом – пациенту предлагают сесть и написать в свободной, «потоковой» форме все что накипело, волнует, будоражит сознание и, отражаясь на подсознании, не дает спать по ночам. Применительно к этому есть хорошее, нежно ласкающее слух слово – фрирайтинг.

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

Первое о чем думаешь – может инженерия уже мертва и миром правит маркетинг — не важно как написано, спроектировано, спроектировано ли вообще, главное продать, всучить, впарить? А инженерия как таковая, отошла на второй план, и настоящие «креативщики» – это эти прыткие молодые люди, менеджеры по продажам, пронырливые и настойчивые как таксы, достающие барсука из норы? Это мысль сама по себе дикая крамола, но она приходит в голову раз за разом, когда наблюдаешь происходящее.

Теперь подробно о том, что собственно происходит. Происходит то, что инженерная деятельность оказалась служанкой бизнеса. Что самое парадоксальное даже в тех случаях, когда основной продаваемый продукт/сервис компании является программным продуктом. Бизнес диктует свои правила, бизнес ограничивает, подгоняет, бизнес благосклонно относится к тем людям из технической «обоймы», которые готовы действовать ради него в ущерб качеству и дизайну. В этом случае менеджмент напоминает недалекого человека, который сидит на суку и потихоньку этот сук подпиливает, толи из-за недостатка знаний, толи сегодня прибыль, а завтра хоть трава не расти.

Впрочем, «особенности национального менеджемента» — это тема для отдельного, большого и довольно грустного разговора…

Бизнес вообще напоминает прожорливое чудовище, которое к тому же имеет свойство поедать и самого себя.

Замечательное понятие – технический долг, всем знакомо, все читали, кое-кто даже реально представляет себе что это. Но число реальных проектов, которые ведутся с учетом этого понятия на мой субъективный взгляд, пренебрежимо мало.
Причина проста – технический долг очень не нравится бизнесу, он его ненавидит, ненавидит даже разговоры о нем.

Бизнес полюбил скрам – но очень странной любовью. Скрам в большинстве случаев это просто превосходная соковыжималка. Кто в роли фруктов и овощей? Конечно разработчики. Более того, скрам используется в качестве своеобразного «фигового листочка», прикрывающего несостоятельный подход к множеству технических вопросов. Из скрама берется все, касающееся части «навесим побольше функционала и сделаем это побыстрее». Я имею ввиду прежде всего порции новых фич, реализация которых вешается на каждый новый спринт. Но все практики, касающиеся качества кода и продукта в целом, достижения и поддержания устойчивого к изменениям, легко тестируемого и сопровождаемого дизайна – в большинстве случаев просто отбрасываются.

Тут надо оговориться – я не хочу обобщать всех и все, я говорю про тенденции, которые объективно существуют на сегодняшний день.

Далее – QA. Понятия обеспечение качества и контроль качества для огромного количества проектов является чем-то далеким и загадочным, как туманность андромеды. И это напрямую вытекает из неполноценного использования скрам-практик. Если continuous testing не реализован на проекте именно как один из процессов жизненного цикла ПО – даже если есть люди, которые в ручном режиме пытаются «нащелкать» баги в UI, такое тестирование иначе чем профанацией назвать нельзя. Результат – баги, выпорхнувшие в релиз из-за такого отношения к QA, наносят такой репутационный и финансовый ущерб компании, по сравнению с которыми затраты на постановку реально эффективного процесса работы с качеством продукта покажутся мизерными.

Но опять-таки – кто занимается этими метриками, этими подсчетами, этими соотношениями затраченных ресурсов…

Документирование бизнес тоже не любит, затрачиваемые ресурсы серьезны, эффект неочевидный, да и вообще тут тоже можно прикрыться скрамом: «у нас скрам, тесная коммуникация к группе, нам это не нужно».

Это при том, что проект досконально знают в лучшем случае 2-3 человека из группы, остальные знают его в общих чертах и/или фрагментарно, как следствие если эти, обладающие «тайным» знанием люди выходят из игры, то проще переписать все заново, что повлечет затраты, несопоставимые с затратами на документирование. Плюс к этому – возможность анализа системы на предмет рефакторинга кода или более серьезного реинжиниринга. Плюс к этому – к примеру, вход нового человека в проект. Насколько быстрее оно произойдет, насколько быстрее человек станет эффективным, если с самого начала начнет работать с задокументированной системой.

И хорошо еще, если на проекте присутствует code review, адекватно реализованная модульная архитектура на базе SOLID принципов, нормальная нотация для структурирования, форматирования, именования переменных разных уровней, классов, методов – это в значительной степени может компенсировать отсутствие документации, но думаю описанная выше идеальная ситуация – скорее исключение из правил…

Как лечить все эти негативные тенденции в индустрии разработки ПО?

Как мне видится, главная таблетка тут – образование.
Чем быстрее многоуважаемое академическое сообщество дозреет до осознания программной инженерии как самодостаточной инженерной дисциплины, а не вечной «падчерицы» у «мачехи»-математики, тем быстрее будут скорректированы учебные программы, надеюсь, больше людей будут приходить из реальной разработки в качестве преподавателей в ВУЗы.

Самое главное, что должно давать профильное образование в области разработки ПО — это объемное виденье процесса разработки, если люди имеют такое виденье, они с вероятностью близкой к единице смогут правильно расставить акценты и максимально гармонизировать требования бизнеса со своей деятельностью.

Автор:

Источник