Жизненный цикл программного обеспечения известен большинству современных программистов.
Даже школьник, написав свою первую программу
<?php
echo "Hello! На пхп"
?>
или
fprintf( 'Привет Хабр на Матлабе!n');
понимает технологический процесс.
- Думает над задачей — этап появления идеи
- Думает над задачей и каким способом её нужно реализовать — Анализ и проработка требований,
построение программной модели и плана на реализацию. Короче, архитектурный этап. - Программирование.
- Тестирование. «А что там получилось»
- Эксплуатация.
Между 1-5 этапами нитиобразно мы имеем непрерывно взаимодействующие процессы.
Для этого существуют всякие Водопады, Скрамы итд.
Так вот дело в том, что когда у вас проект раздувается до нескольких типов фронтэнда,
как требует современный IT мир заказчику хочется максимально покруть аудиторию для максимизации собственной прибыли.
И по этой причине мы все наблюдаем обилие проектов, в которых одновременно существуют несколько типов фронэндов, взаимодействующих по API с централизованным бэкэндом.
Вообще говоря, «стандартный сильный проект» обладает тремя типами фронтов:
- Сайт
- Мобильное приложение на Андроиде
- Мобильное приложение на iOS
При едином разработанном API для обмена данными через REST.
Хорошим примером, на который я буду опираться являются социальные медиа (см. мою предыдущую статью про собственный плеер на основе видосов из YouTube)
У большого проекта есть три варианта получения прибыли или любого критерия, которые
условно Веб, яблоко и андроид.
Программистам удобно взаимодействовать с централизованной архитектурой бэкенда и концентрироваться на своем личном фронте, который они разрабатывают.
И вот здесь появляется изюминка статьи.
Дело в том, что на верхнем уровне принятия решений среди начальства
формируется новая фича, которая идет в бэк. Но так как «начальник» — человек несовершенный,
то ему приходится вниз спускать полномочия на нижние уровни.
Поэтому, в нашем случае, как правило, над каждым фронтом тоже появляются свои «низкоуровневые» начальники по иерархическим, или формальным признакам. Что-то
типа тимлидов для простоты.
И задача разработки большого проекта в виде некоего «жизненного цикла» разработки
и эксплуатации ПО делится на свои жизненные циклы.
И появляется вопрос в синхронизации процессов «мини» жизненных циклов, потому что при опережении, например, веб-разработчика новой фичи, приходится ждать мобильного девелопера.
Иначе теряется смысл новой фичи как таковой по приоритету, потому что мы все сейчас и в вебе и в мобильных приложениях со смартфонов.
Давайте подумаем, как оценить факт внедрения новых фич, для того чтобы минимизировать человеко-ресурсы в такой ситуации.
Здесь я озвучу тезисы:
- При реализации некоторой фичи в одном из фронтов нам необходимо учитывать циклы других фронтов, либо программировать стандартные заглушки, чтобы потом «догнать» по фичам другие фронты и выровняться.
- Можно построить схему цикла разработки ПО в целом так, что все будут условно успевать, тогда фича будет внедрена вовремя, но, как минимум, теряется независимость фронтэндных команд между собой — тогда скарм и аджайл для всей системы теряют свою актуальность, либо увеличивают время итерации на разработку. Короче будет происходить больше болтовни и код пишется медленнее.
- Изолированные фронты в принципе работают быстрее, но тогда нужно более человекозатратное интеграционное тестирование.
- Реализуемые сейчас схемы — каждый фронт разрабатывается отдельно и независимо друг от друга с минимумом взаимодействий, но тут теряется некоторые основы IT — мы так или иначе поолучаем ненулевую группу пользователей, которая будет иногда видеть баги.
Тут философия вопроса такова, что пользователям не нравятся баги по определению. А заказчик гонется за максимизацией прибыли, поэтому большое усложнение системы так или иначе будет приводить к торможению той самой максимизаии, потому что это конечный процесс-жизненный цикл ПО.
В более маленьких проектах этот процесс происходит еще хуже — многие заказчики отдают на удаленку мобильную разработку, хотя бэк и веб ведется своими силами, и регулярно получают равномерное торможение по внедрению фич.
С другой стороны есть опасная прерада для формальной автоматизации процесса внедрения — среди разработчиков принято спрашивать о накатываемых обновлениях у пользователя, так что в тихом режиме докатывать изменения без согласия не получится.
Моей идеей является такая мысль — при сохранении основного типа жизненного цикла и имея подтипы в данном случае независимых фронтов нужно иметь ввиду один приоритетный
тип фронта (по баблу, историческим причинам или иное), но они должны быть на условную единицу ниже более высокоуровнего типа цикла.
Т.е если приоритетный веб-фронт работает по недельному скраму, то внутренний скрам на мобильном фронте должен иметь при себе двойной первый скрам, двухнедельный, иначе
начнется путаница. Но выкатывание общей большой версии фронтов необходимо делать одновременно, иначе у вас появится автор статьи, который это пишет. Давайте подумаем…
Автор: ShapitoS999
