Продолжение. К предыдущим постам и карте цикла.
Знаете, как называется система, которая приносит постоянную прибыль, работает без особых проблем и обслуживается маленькой командой? Продукт с заканчивающимся сроком обслуживания!
Как в ресторане перед закрытием. Клиентам сообщают, что кухня скоро закроется. Можно еще что-то заказать напоследок, но дальше только бар. Вроде никто их не гонит, и они продолжают трапезу, но столы вокруг начинают освобождать. И вскоре становиться тихо и одиноко. Есть вариант перейти на дорогие и замысловатые коктейли, персональный аккаунт-бармен поможет со вкусом потерять сбережения или сознание. Так что на следующий день у клиента возникает резонный вопрос: «Стоит ли идти в тот же ресторан или же заглянуть в другой?». Но не будем бежать вперёд крыс с камбуза. Пока клиент у вас - горшочек варит.
Уводить на пенсию свои проекты мне еще не доводилось. Однако накопился опыт эвтаназии других продуктов. Чем же славна эпоха заката империи? Конечно же роскошью и развратом! Первое легко приводит ко второму. Период обслуживания славен тем, что клиент платит сбор за поддержку или операционные затраты. Ну, а ваша компания, обычно, тратит много сил на уменьшение затрат. Так что через несколько лет проект начинает приносить чистую прибыль. В довесок к этим деньгам, добавляются заказы на дополнительные функции и всевозможные изменения. Я не встречал ни одного проекта, который к 10–15 годам жизни не превратился в плешивую и хромую курицу, несущую золотые яйца. Именно благодаря этим яйцам (и не важно, что говорит сам сюзерен) ваш директор решается озвучить мечту об некстгене на ежегодном замере харизмы. Следующая версия продукта должна стать следующей курицей и ядра – чистый изумруд!
Важно обратить внимание на то, что это «следующая версия». Не новый продукт. Новое – риск. Начальство риски не любит, потому что никто не умеет их готовить. Рецепт идеального продукта – взять старый и продать еще раз. А значит, что от вас, в первую очередь, ожидают доработанный старый дизайн, но блэкджеком и API-ками! Круг замыкается, и вы опять начинаете с линии и иконостаса. Но, позвольте, ведь старую курицу еще не закопали, так что за ней тоже надо следить. И в идеале, когда кура всё же откинет копыта (а за долгий срок мутаций и не такое вырастет) незаметно подменить на новую, ещё более лучшую, чтоб с урожаями и надоями.
Вот этот самый этап подмены – колдовство архитектора! Так что расчехляем волшебную палочку, и айда ей бить по рукам! За что бить – всегда найдётся. Проект на вольных хлебах и накатанных рельсах. В первое время за ним следили. Ведь в начале были подписаны кучи SLA, а значит в них нужно было укладываться, чтоб не ложиться под… По мере накопления мутаций: изменения законов и регуляций, стандартов и технологий, принципов работы и сливания бизнес-направлений – все принимают факт, что это уже не тот же самый ванильный рожок с добавками. А прямо-таки новое нечто, со своим вкусом и рогами. Поэтому рамки начинают двигать и в конце вообще опускают. Поэтому основой разработки становится клятва Гиппократа. Не навреди! Неважно, как впихнуть очередное изменение и продуктовую деталь, лишь бы не сломалось нажитое непосильным трудом. Сейчас, наверное, уже сложно представить продукт без автоматических тестов, но в легаси такое сплошь и рядом. Ведь если б можно было продолжать эволюционировать, то никакая следующая новая система не нужна.
Из опыта:
Старые системы не так уж и плохи. Они служат верой и прибылью. Нужно понимать, что ваш легаси продукт – является стандартом де-факто для ваших клиентов. Всё, что будет предложено, будет сравниваться с этим стандартом. Победить конкурента бывает легче, чем самого себя. Против вас играет ваше же тесная связь с клиентом и понимание его бизнес процессов. Память всегда защищает нас от тревожных и драматичных моментов прошлого. Ваш клиент будет помнить лишь успехи. И придавать ценность количеством страданий. Тем более, что начальство, ходившее по мукам разработки прошлого продукта, скорее всего уже на других местах. А новички пришли уже в работающую экосистему. Так что первые же упоминания о том, что ваша компания будет разрабатывать что-то новое – вызовет восторженные аплодисменты публично и ноту недоверия за кулисами. Архитектору будут противостоять: низкие требования к железу (чтобы с этих пор по-новому, оставалось все по-старому), большой (очень большой, накопившийся за 10 лет) набор функций и быстродействие (как следствие примитивности). Тут работает знакомое всем определение безумия, с легким капиталистическим штрихом: делать абсолютно другую систему и ожидать того же результата. Эти препятствия не преодолеть технически, так что стоит сразу начать политические баталии. В качестве оружия нужны простые и понятные факты и цифры. Основная идея – за всё нужно платить. Красивая картинка и устойчивое шифрование – больше локальных ресурсов, облачные сервисы – задержка из-за удалённых вызовов, детальные логи и сбор больших данных – больше хранилища и шире каналы, доступ из любого места – больше уровней и периметров безопасности.
Миром правят деньги. И время. И нет, я не про то, что время – деньги. Как в конвенциональной политике, так и в корпоративной, каждый преследует личные цели, прикрываясь лозунгами и заботой об остальных. А значит важно только то время, когда господин на каденции. Так что деньги сейчас. Пусть потом будет меньше, но это уже проблемы тех, кто придёт после. Поэтому волевыми решениями и близким горизонтом начальство продавит «сейчас заделиверим, а тесты никогда потом». Тут ведь как работают с Гиппократом: не пойман – не баг! Поймать что-то в ручном режиме в системе с тысячами сценариев… В конечном итоге и клиент тоже будет проверять так же, поэтому то, что всплывет потом в проде, просто назовут новой проблемой. Отсюда и странное явление старых энтерпрайз продуктов: со временем объем разработки падает, а количество ошибок увеличивается. Технический долг будет расти башней из кубиков, пока не превратит всех в трупиков. Но каждый новый босс, а в легаси проектах они меняются где-то раз в год-два (после того как уйдёт тот, кто курировал проект с начала), будет надеяться, что последний кубик будет не в его смену. Такое отношение порождает два смертных врага архитектуры (и других удивительных тварей):
Любимчики системы. Они делают быстро и точно. Вот как сказали, так и сделают. Золотые руки. И работать руками они любят. Никакой автоматизации. Проверяют вручную, деплоят вручную и думают тоже как-то так. А раз автоматизация им не нужна, то они первые соглашаются на «тесты потом» (последнее читать два раза с ударением на разный слог). И с тем же рвением и удовольствием будут убивать и то, что заскриптили и затестили раньше. Ведь новых фишек не было в старых тестах, а «менять их долго, я лучше ручками». Пик популяции приходится на середину жизненного цикла системы. Когда уже не следят за изначальными обязательствами по контракту, а требования от заказчика всё поступают и поступают. Деньги начинают звенеть прибылью, а не отбиванием расходов на разработку платформы и прототипов. У начальства и других недальновидных участников процесса возникает ощущение свободы действий.
- Клиент уже никуда не денется.
- Архитектура нужна была в платформе, а у нас конкретный проект.
- Мы допиливаем, а не строим.
И всё в духе «Après moi le déluge». Поэтому чувствуя, что дом уже стоит, и нужно только обустроиться внутри, эффективные люди начинают оптимизировать пространство, снося стены. Пока архитектор будет пытаться защитить несущие конструкции и указать, где проходит вода и электропроводка, начальство примет «непростое решение» отказаться от его услуг в этом проекте и направить энергию и опыт в другое русло. И сцену займут те, кто не спорит. Когда в руках только кувалды – что стены, что гвозди…
Дабы не быть голословным:
Как я упоминал, в уходящие проекты я приходил в конце. И чтоб хоть как-то ознакомиться с происходившим, делал код ревью. В последний этап больших изменений почти нет. Собственно, отказываются от легаси именно потому, что изменения почти невозможны. Так что мне хватало день-два, на то, чтоб просмотреть весь прошлый спринт. И тут было так много интересных историй, что я даже сделал дайджест и раз в месяц слал в группу подборку знатных кусков шоколадного кода.
Есть лёгкие глупости типа:
Log.Debug(string.Format("starting visitor: {0}", visitor.GetType().Name));Раньше было больше параметров, но потом золотые руки добрались и убрали лишнее. Оставив при этом ставшее неуместным форматирование.
А есть и хардкор с использованием цикла для одного элемента:
var promoConditionTypes = GetPromotionConditionTypes(promotionRequest)
.FirstOrDefault();
foreach (var promoConditionType in promoConditionTypes)
{
SetThreshold(promoConditionType);
return;
}Если посмотреть коммит, то видно, что последний разработчик просто добавил .FirstOrDefault(); Не утруждаясь изменить следующую строку – он же её не писал, а читать явно не в его стиле. Автор изначальной реализации сделал и юнит тест с проверкой, что код проходит по всей коллекции. Вполне естественно для золотых рук - тесты тупо заигнорили.
Так получаются подобные шедевры:
_stringBuilder.Append(
String.Join(" ",
description.Select(c =>c.Culture+" "+c.Value+" "+c.Type+" ")
.OrderBy(descriptionStr => descriptionStr)));Заметьте, что код писали опытные разработчики, с парой лет опыта в этом проекте.
Откуда растут руки-ноги? Я не менеджер и точно не психолог, но у большинства наблюдаемых похожий симптом: «чукча — не читатель, чукча — писатель». Проект долгий и большой, так что разработчики сидят в своих командах и постоянно варятся в собственных соках. Им дают задания и баги, связанные с этими заданиями. Всё время у них своя экспертиза, предметная область и удобное болото из кода, который они пишут. Родное. Теплое. И почти не пахнет. А потом, вдруг, продуктовый бэклог тает, возникают новые проекты, и многие уходят туда. Но наши герои не любят перемен. Так что, вместо 5 команд остаются 2, почти полностью из заложников зоны комфорта. И тут их мир рушится. Они оставались, чтоб дальше сидеть в своём тёпленьком, а их объединили и перемешали, сделав ответственными за всю кодовую базу. Поэтому сознательно или нет, они работают так, чтоб писать как можно больше своего и меньше разбираться с существующим. Отсюда и желание пробить новый проход, чтоб не искать ключ от двери. И пристраивать балкон для нового холодильника, чтоб не дай бог не двигать мебель на кухне. Конечно, старый холодильник тоже оставим. Максимум - отключим от сети и повесим записку «Балкон ходить».
Расцвет Николаев.
И раз уж вокруг так много костылей, то никак не обойтись без тех, кто может заставить это чудо ходить. Поэтому даже в плодоносящем продукте есть настоящие часовщики и механики – отличные инженеры, знающие весь код и бизнес, с историями и сплетнями. Такие вот титаны, держащие на плечах менеджеров с шестёрками и шестерёнками. Такие люди – единственный шанс увеличить производительность или разработать всё необходимое для новой сертификации в старом проекте. Решения могут быть сложными костылями, но всегда работают, не ломая продукт. Если вам уже стало интересно, почему же солидные доны сидят в старом проекте, а не строят новый ракетный двигатель? Обычно ответ прост. Потому что доны, хоть и ушлые, но токсичные и душные. Никто с ними работать не может. Да и им самим не очень-то и хотелось. Так что остаться в болоте среди тех, кто не хочет понимать продукт – выбор стратегов. Может нелюдимых гениев и сторонятся, но все понимают, что без них накроются медным тазом все должности, где хотелось бы золотой парашют. Как-то раз пришлось писать фасад драйвера спец. клавиатуры (что-то типа программируемого Numpad для монитора), так как оригинальные уже не выпускали. А на месте могли быть и старые и новые устройства. Никто из любимчиков начальства такую задачу взять не согласился. А вот нелюдимый дядя с сигаретой сказал, что это звучит интересно. И осилил несмотря на отсутствие документации у китайских девайсов. Возможно, осознание собственной незаменимости приводит к самокоронации. А любая попытка понять, вмешаться или подправить работу расценивается как агрессия против института самодержавия, либо, что еще хуже, попыткой занять кремниевый трон!
Игры престолов:
В процессе разработки нового продукта возникла необходимость создание адаптера для лёгкого перехода от легаси системы к новому решению. Сама задача не сложная: в новой системе один вызов API, а в старой необходима последовательность двух. Во время параллельной работы (когда на одной точке одновременно работают и новая и старая версия) следует избегать двухголового управления. Если процесс начинает система А, то система Б пассивно исполняет указания. И наоборот. Таким образом в сложной цепочке узлов процесса не возникает разногласий и всяких проблем конкуренции. Как часть установки нового продукта, нужен был патч (upward compatibility) старого контроллера. Что то, что помогло бы создать согласованность действий. Пусть даже не транзактивность, но хотя бы возможность отката команды 1, если команда 2 не прошла. Так вот этот софтверный контроллер уже лет 5 в одиночку поддерживает Николай – последний из первоначальной команды разработчиков. Специалист в предметной области и технологии. Я посылаю ему имейл с парой тройкой вариантов решения и просьбой присоединиться к обсуждению. В ответ получаю просто: «Нет». Я пытаюсь дозвониться – три дня полный игнор по всем каналам. Я подключаю его менеджера и своего (CTO) в придачу. Через пару дней согласовали встречу. На ней Николай сказал, что эти две команды его устраивают в том виде, в котором они есть. А если мы хотим заменить его контроллер, то можем идти и писать свой. Чтоб осознать абсурдность, стоить сказать пару слов о самих командах. В новой системе есть команда «Открыть», а в старой «Открыть замок» и «Открыть крышку». То есть всё что нужно – закрыть замок, если крышка не открылась по какой-то причине. Никаких физических или логических ограничений в ходе обсуждения не выявили. Просто Николай не занимается «ерундой», которая только «портит» его продукт, который «уже 10 лет без нареканий», ради какой-то «новой херни». Я немного опешил, но в конце концов, я архитектор и никем не управляю. Пусть этим занимается начальство. СТО идёт к генеральному. Гендир присылает гневное письмо с вызовом Николая на ковёр и обещанием нашей команде, что всё уладят. Через пару дней всё тот же Великий Завоеватель Рынков, Даймё разработчиков и Отец продажи, уважаемый Ген Дир пишет, что, пожалуй, нам надо как-то продумать альтернативы и обойтись без изменений старого софта…
Так как особо ценные сотрудники не особо ценят всех остальных, то в потоках их гениальности и презрения, обветшалый кораблик начинает кидать из стороны в сторону. Пара корабельных мастеров и матросов способны держать посудину на плаву. Но вот незадача – за фарватером никто не следит. Курс в основном прокладывают крысы – как только они начинают сбегать с корабля, значит пора разворачивать штурвал в другую сторону. Вокруг валяются карты и приборы, но вот кому и зачем они? Пока всё идёт хорошо, начальство видит только то, что штат команды «раздут». И вообще, то, что работает – лучше не трогать. А значит, чем меньше рук, тем меньше и риски. Ириски любят делить на всех. Людей переводят, они и сами уходят, а с ними и знания о недокументированных особенностях и внутренних договорённостях. И каждый кусочек пазла приходится восстанавливать через болезненный опыт. Поменяли старый USB кабель и сожгли контроллер. Сменили операционку и не нашли драйвера. Обновили сторонний пакет программ и всё посыпалось. Граблелицевая археология как модель познания мира. Самый распространённый симптом проблемы – никто не говорит о проблемах. Чаще всего сменяются команды поддержки. Их любят аутсорсить там, где подешевле. Ганг не стоит на месте и текучка кадров большая. А вот конфигурацию, администрирование и техническое обслуживание остаётся близко к клиенту. И изменения в продакшине дело не сиюминутное. Через много месяцев выясняется, что система всё ещё шлёт алерты на какой-нибудь ящик пользователя, который давно покинул компанию, а пароль от дублирующего/основного забыли/потеряли год назад и вообще работают без него. Поэтому обо всех ошибках и потенциальных проблемах никто не знает. Хуже всего, когда забывают узнать у уходящего сотрудника пароль от сертификатов или мастер пароль базы. К сожалению, этим страдают, как и молодые компании, в которых такие процессы еще не налажены, так и крупные компании со сложной иерархией - у семи нянек…
Воспоминания о боли.
Как я и говорил, свои проекты я ещё не увольнял. Но вот похожий казус пережить пришлось. Некстген славен широкой продажей. Куча потенциальных клиентов и демок. Кое где всё решается быстро, а кое где всё затягивается удавкой на шее. Но выбирать клиентов в начале не приходится. На рынок надо пробиться, так что продукт суют везде. Один из потенциальных «потенциальных покупателей» вообще не шибко то и подходил под профиль – мелковат и не богат. Но поморочили они нам голову с годик и дошли до пилотного запуска в паре мест. А потом отказались. Ну вроде бы и разошлись достойно, и головняка меньше. Проходит пару лет и новый менеджмент в увеличившемся бизнесе случайно обратил внимание, что есть более удобная система и в плане отчётов, и в возможностях управления (правильно, мнение работников их вообще не волновало). И вот они приходят с большим чеком и требуют продолжения банкета. Кто ж будет спрашивать архитекторов при таком раскладе? Ну а продукт уже сильно изменился и по возможностям, и по стеку. Там уже никак нормально не замерджить или апгрейднуть не выйдет. Прошла волна крупных и содержательных бесед внутри компании. Так как деньги уже взяли, а мозгов, похоже, никогда и не было, нашли временное решение – взять с гита старый код и собрать ту версию, что еще работает у клиента. Это даст отсрочку и позволит сделать позже нормальный процесс апгрейда. Собрали, отдали, расширили пилот на пару сотен установок, но тут начались проблемы. База как-то быстро росла, локальные данные как-то расходились с центральными отчётами… После тщательного и сложного расследования выяснилось, что команда поддержки новая (и не местная), привыкшая к последней версии софта и другому стеку компонентов, не знала, что DLQ выполнен табличкой в базе данных, а не средствами очереди. Так что ни об ошибках синхронизации, ни об самой очереди недоставленных сообщений никто не заботился – эта часть знаний была утеряна в ходе естественной эволюции.
Я, в силу фокуса на софте, мало привожу примеры про железо, но там в плане магических артефактов всё еще круче. Градус понимания начальства давно ушёл в минус, причем в Кельвинах. Если эффективный менеджер смотрит в код, то обычно его понимание сводиться к чтению по-английски и прецедентному праву: «соседняя команда тоже делала routing и у них был всего 1 sprint в estimation, а вы мне тут в начале года про Q3 втираете!». А вот с периферийкой они же визуально знакомы. «Вот тут кабель HDMI дорогой,а мы у китайцев взяли за 1/3 цены! Представляешь какая экономия для компании с нашими то миллионами устройств!». Представляю. Ведь Мастер по Закупкам просмотрел все спецификации и в какой среде это будет использоваться, а теперь на глазок может определить какой из стандартов нам нужен. И это так мы выучили урок, что не все USB кабели одинаково полезны. Ну, видимо, чтоб научиться определять на глазок, да на зубок, малый совет нашего королевства решил начать с жопы. Так что не удивляйтесь, когда очередной выпускник MBA оповестит вас постфактум, что он решил поменять мониторы с тачем "с убого резистивного, на современный ёмкостный". Да еще за пол цены! А то ведь невозможно нормально пользоваться и презентации отталкивают инвесторов. Теперь у нас как яблоки из силиконовой долины! Большие, круглые и на ощупь неотличимы от настоящих! Особенно в защитных перчатках работника цеха, которому потом этим экраном пришлось бы пользоваться. И всё же у меня потребительское понимание устройств, а когда приходится общаться с нашим отделом разработки контроллеров, то те на комплименты модернизаторам не скупятся. Я быстро стал понимать, почему высадка на луну в 2020 – это разработка с нуля, а не «можем повторить 69-й».
Цикл жизни.
В программном мире, как и в природном, жизнь кратковременна и поколения сменяют поколения, передавая в будущее гены – функции и признаки успеха. Экономическая эффективность же. Новую собаку всегда учат старым трюкам – все простые и грубые решения прошлого. Все как в жизни – низкий интеллект легко масштабируется. Так что, даже если технологически ваш свежий продукт будет совсем другим, все применимые практики перейдут в него из старого софта, всевозможных прототипов и того, что помогает подписывать договора. Ну и каждый клиент, работающий с легаси вашей компании, захочет вытащить из него как можно больше данных в новую систему. Экстракция, сама по себе, не сложная технически задача. И в этом кроется ошибка. Все стараются перевести это в русло чёрной работы – долгий, нудный процесс, но без особой мысли. Любой дурак справится. Наверное, похоже на управление проектом (no pun intended). Однако, несмотря на всю противоречивость моего заявления, советую к нему прислушаться: «экспорт старых данных имеет ценность лишь при возможности их импорта в новый продукт». А это значит, что задача должна перекочевать в продуктовую плоскость. Попытаетесь закопать голову в песок и на каждой стадии вас будут присыпать еще больше, пока окончательно не похоронят в пилотке. Причём продукта нового, так как именно там должны быть продуманы случаи несоответствия ожиданиям:
Неполные данные. Структура данных новых систем обычно сложнее, так как нынешние тенденции — это сбор информации и мультиканальность процессов. Иногда разница просто огромна. В таких вариантах выгрузка вообще имеет мало смысла и тогда используют агрегацию. Некоторым системам просто нужны какие-то стартовые значения. Так что либо последние (если говорим о допустим о позиции манипулятора), либо какие-то средние (когда речь о показателях прибыльности или производительности), а иногда и сумма (состояние сейфа).
Анонимность. В старых системах об обезличивании данных не думали, да и требований таких не было. В новой уже другие условия. Однако для клиента это будет выглядеть потерей функциональности или информации. Я столкнулся с этим в системах оплаты. Легаси тупо хранила номера кредиток и это позволяло проводить транзакции позже, повторить попытку или сделать возврат постфактум. В новой системе была PCI DSS сертификация (вместо номера был хэш и маска) и такая магия уже не работала. Отдел продаж сразу поднял руки, так как у них была официальная LFL стратегия в подходе к существующим аккаунтам. Продакт же настаивал, что это ошибка проектирования.
Разная глубина истории. Исходит из первого пункта, но если перевести на язык таблиц, то первый пункт про столбцы, а этот про строки. В новой системе не может быть заказа без имейла. И все отчеты по импортированным транзакциям со вшитым join-ом по этому полю идут… Ну, в общем, к вам много кто придёт, после тестов – крайний тот, кто «раз такой умный то, чего же не предупредил?».
Регуляции. Особенно тут сложно с фискальными данными. Требование хранить их годами есть везде, где мне приходилось работать. И тут очень важно поднять вопрос о целесообразности импорта как такового. Почти всегда решение – отдельный монолитик со своей базой для листания и распечатки истории, как я и упомянул в предыдущем посте.
В идеале за год до конца службы продукта надо подготовить все инструменты и API. Конечно, никто не готовится заранее, только если это не было оговорено в контракте (ни разу не видел нормальных требований). Но, если вы должны предоставить доступ сторонним участникам, то лучше заранее считать их врагами. Убедитесь, что везде есть авторизация и доступ только на чтение (иногда внутренние инструменты делают без подобающей защиты, а добрый delivery менеджер делиться ими с клиентом и партнерами). Ограничивайте количество данных и запросов, чтоб не нагружать систему. Миграцию обычно отдают джунам-арджунам, а те предпочитают учиться наживую. Лишние стрессы вам не нужны, так что с одной стороны выгрузка должна быть свободно доступна, просто по талонам, а с другой стороны пулемет на вышке пока снимать не стоит. То же самое и к импорту. Мы же не хотим, чтоб после удачной проверки на системе тестировщика, где данных было лишь на пару недель, кто-то бы положил прод попытавшись впихнуть туда базу за годы. А значит не рассчитывайте, что импорт удастся за раз.
Процесс стоит сделать асинхронным и прозрачным (показывать статус, давать возможность прервать или притормозить).
Хорошо бы сделать импорт сегментированым. С возможностью выбора периода и/или типов данных.
Обязательно делать импорт обратимым. Если что-то сорвалось – мы не хотим отравить систему.
И это все, что я могу сказать о войне во Вьетнаме. На правах послесловия:
Но я бедняк и у меня лишь память о некотором дерьме,
Я простираю этот опыт свой тебе под ноги,
Ступай же по нему легко, теперь говно топтать тебе.
Комментарии (16)
SabMakc
27.07.2022 15:52+1Да, чувствуется опыт... И начинаешь чувствовать себя старым - просто потому, что понимаешь о чем говорит автор и сталкивался в том или ином виде.
Впрочем, это все характерно для любого не-нового проекта - а не только для тех, которым "пора на пенсию".
Но должен сказать, что обычно не все так однозначно.
В том же примере с форматированием, использование форматирования - это про читаемость в 1ю очередь, а не про ненужность форматирования.
Лично я вижу проблему скорее в области производительности. Форматтер, как правило, достаточно нетривиально работает и занимает много времени на выполнение. Поэтому обычно логгер имеет свой форматтер, который отрабатывает только в том в случае, если сообщение действительно попадет в лог. И использование "стороннего" форматтера тут излишне.И в примере с замком тоже не все так однозначно. Я бывал в роли Николая из "игры престолов". В том числе сталкивался и с тем, что через ген.директора пытались "продавить" "очень важные и жизненно необходимые функции". Но зачастую справедлива фраза "просто было на бумаге, да забыли про овраги". И опытный разработчик может очень грамотно и по пунктам разложить почему именно он это не хочет это делать, а не просто "не хочу и все".
Или плохое понимание что именно надо или как именно это должно работать, которое очень сильно не соответствует тому, что реально происходит в системе. Или необходимы неоправданно большие изменения кода (к слову, привет "очередным NewЧтоТоТам" и "тестов нет, но вы держитесь"). Или это уже есть в чуть другом виде (например, уже есть функция "закрыть замок" помимо "открыть замок" и "открыть крышку").
И что самое веселое - в итоге эти "очень важные и жизненно необходимые функции" очень часто оказываются никому не нужными (просто потому, что нашли более простой и прямой путь сделать то, что хотели) дурно пахнущими кусками кода "висящими на балансе" проекта (потому что удаление чего-либо из работающией системы - это еще более нетривиальная задача, чем добавление нового кода).
XaBoK Автор
27.07.2022 17:31И использование "стороннего" форматтера тут излишне.
Конечно, но фокус на том, что данную строку писали в 5 заходов 5 разработчиков. Каждый внёс что то своё, не удосужившись выровнять. Всего одна строка! Такое впечатление, что люди боятся лишний символ посмотреть.
А насчёт "Николая", то тут дело как в "не хочу и все". Было бы объяснение - искали бы альтернативы и компромиссы. И тогда это был бы не "Коля", а хороший инженер.
avf48
27.07.2022 16:27+1Про Архитектуру писать нужно и полезно! Автору "+"...
Но я затрону проблемную часть Архитектуризации... это стандарты (ГОСТы)
Почему нет ни одной ссылки? Как можно заниматься созданием сложных систем, веря только в свой "Великий мозг" (сарказм)? Как можно Знать всё и сразу, и помнить всё это?! Слезайте с тяжелых наркотиков!!!
И я, говорю о стандартах именно по ЖЦ ИТ систем, без учета стандартов на виды деятельности, которые вы автоматизируйте. Как можно отличить Некомпетентного руководителя от компетентного, если не знаешь Как он должен PDCA'ить?
Разработчик должен создавать систему, которая будет отвечать Возможностям Заказчика, а не его Хотелкам (мало ли что он хочет...).
Аргументы типа "- А в требованиях на вакансии этого нет.." или "- От нас этого не треюуют" не принимаются, тк что бы создать Культуру разработки на Родине, нужно её СОЗДАВАТЬ, а не делить разработчика на джуна, сеньора или мадаму... Смотри проф стандарт, определяй свою квалификацию по уровням, пиши резюме. Для HR будет попроще нанимать компетентных специалистов без профильного образования... Да и выстраивать разработку в соотв с ЖЦ (12207) будет проще, тк терминология в стандартах хорошо согласована (враки).
Кто хочет Автоваз по ТУ?? или может мед оборудование и расходники по СТО делать??
Кто считает, что ГОСТы это Старьё, у бабки из под юбки, то может написать свой (Описать как он добивается результата в длительном периоде, от Идеи, до утилизации Системы)..
PS: И да, Не смешивайте Стандарты и ГосИнфСистемы, стандарты пишутся, надеюсь, инженерным составом, а ГосПО Проектными менеджерами (свои стандарты они тоже не знают).
Хотите знать ситуацию на своём предприятии со стандартизацией? Узнайте чем занимается инженер по Качеству и есть ли он... Если ничем/его нет, то и не о какой стандартизации речи быть не может, тк это его Работа. А если не он ей занимается или он занимается "бумажками", то тогда Директор не знает, что такое Руководство и Организация, как виды деятельности. Хотя, как Управленец, он может быть и Молодцом и компания будет развиваться (но только при нём).
Стандарты:
ГОСТ Р ИСО 19440-2010 ИНТЕГРАЦИЯ ПРЕДПРИЯТИЯ. Конструкции для моделирования предприятий
ГОСТ Р ИСО 15704-2008 Промышленные автоматизированные системы. ТРЕБОВАНИЯ К СТАНДАРТНЫМ АРХИТЕКТУРАМ И МЕТОДОЛОГИЯМ ПРЕДПРИЯТИЯ
ГОСТ Р ИСО 19439-2008 ИНТЕГРАЦИЯ ПРЕДПРИЯТИЯ. Основа моделирования предприятия
ГОСТ Р 57195-2016 ЯДРО И ЯЗЫК ДЛЯ МЕТОДОВ СИСТЕМНОЙ И ПРОГРАММНОЙ ИНЖЕНЕРИИ. Общие положения
итд...
+ Есть ещё профстандарты, которые Разработчики (ВООБЩЕ ВСЕ, БЕЗ ИСКЛЮЧЕНИЙ) Не знают или не хотят знать!
По Проектам:
ГОСТ Р 56716-2015 Проектный менеджмент. Техника сетевого планирования. Общие положения и терминология
ГОСТ Р 56715.5-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения
ГОСТ Р 56715.4-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 4. Данные и модель данных
ГОСТ Р 56715.3-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 3. Методы
ГОСТ Р 56715.2-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель
ГОСТ Р 56715.1-2015 Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения
ГОСТ Р МЭК 62198-2015 Проектный менеджмент. Руководство по применению менеджмента риска при проектировании
ГОСТ Р МЭК 61160-2015 Проектный менеджмент. Документальный анализ проекта
ГОСТ Р ИСО MEK_TO_16326-2002 РУКОВОДСТВО ПО ПРИМЕНЕНИЮ ГОСТ Р ИСОМЭК 12207 ПРИ УПРАВЛЕНИИ ПРОЕКТОМ
1 ГОСТ Р ИСО 21500-2014 "Руководство по проектному менеджменту";
2 ГОСТ Р 54869-2011 "Проектный менеджмент. Требования к управлению проектом";
3 ГОСТ Р 54871-2011 "Проектный менеджмент. Требования к управлению программой";
4 ГОСТ Р 54870-2011 "Проектный менеджмент. Требования к управлению портфелем проектов".
"Кто не любит ГОСТы, будет есть тараканов с гвоздями...А что, ВАМ же требования не нужны... ВЫ же сами знайте как лучше... вот и тот, кто вас кормит и лечит будет вести себя так же!"
PPS: Слишком близко к сердцу не принимайте...
XaBoK Автор
27.07.2022 17:39Ну мне RFC ближе ГОСТ-ов. Есть и стандарты, особенно это актуально для отдельных индустрий. Есть для ритейла, финтеха, нефтегаз и тд. Но в любом случае - это даже не шаблоны, а своеобразный чеклист. Я смотрю их для лучшего понимания бизнеса. Люди уже сталкивались с кучей проблем в предметной области и предлагают варианты решения. Ну и плюс - это обычно публичные ресурсы и на них хорошо ссылаться при интеграции (почему так - вот стандарт рекомендует), упрощает доказательную часть решения.
avf48
27.07.2022 19:49+1особенно это актуально для отдельных индустрий.
Да, соглашусь, что популярные ст-ты именно индустриальные. Но я про СИСТЕМНЫЕ стандарты, те которые говорят, как сделать Успешную систему (системная и программная инженерия).
Но в любом случае - это даже не шаблоны, а своеобразный чеклист.
Именно!)) Компания то ведь ваша, а продукт, будут потреблять те, кто Должен быть уверен в их безопасности... Те, то ЧТО вы произведете (если требований нет), всем всё ровно, но вот на сколько безопасно вы будете это делать (для потребителя, сотрудника, общества) Я должен быть в этом уверен, а я это Общество.
Я смотрю их для лучшего понимания бизнеса.
Ну? и кто у нас работает по стандарту?)) из руководителей, таких не видел...
я так вообще ушел от Бизнес требований, у меня есть ГОСТ на систему в кот. они действуют, есть профст-т, какими навыками они должны обладать и есть структура объектов с которыми они что то делают... я, всё это могу вытащить из ОКВЭДа...
Кто из них понимает что такое исо 9001 или 15288(57193)?? А без этого руководить организацией нельзя, только управлять.
А к стати, вся оборонка и АЭС это один большой ГОСТ... Поэтому в Этом Мы Лучшие, благо военные не взяли практику Сбера и Газпрома...
PS: ГОСТ Р ИСО 19439-2008 Интеграция предприятия. Основа моделирования предприятия (GERA)
почему так - вот стандарт рекомендует
А вот в этом главная проблема, стандарт - рекомендует.
стандарт- образец, эталон, модель, принимаемые за исходные для сопоставления с ними других подобных объектов.
Тогда можно Рекомендовать всем работать хорошо... Рекомендовать соблюдать скорость, а если у вас есть дети, то можно Рекомендовать произв-лям детского питания соблюдать требования безопасности...
Ах да... забыл совсем... В "Храмой лошади" и "Зимней вишне" там рекомендации были не выполнены или не по Стандарту было всё организовано?! И почему то мне кажется, что в большом ТЦ ОТиПБ и ПожБез были, хоть как то, но автоматизированы...
В 21 веке, почти каждая смерть по неосторожности на руках Айтишника.
XaBoK Автор
27.07.2022 22:39Тут на самом деле важным моментом является заинтересованность заказчика.
Я должен быть в этом уверен, а я это Общество.
В коммерческой разработке государство тоже участник. Так что уже на первом этапе, при объявлении тендера, прописаны необходимые стандарты с сертификацией. То есть не просто "мы ознакомились с рекомендациями", а "у нас была комиссия/аудит и по результатам мы соответствуем такому-то стандарту такой то версии".
Сейчас в каждом RFP будет требование ISO/IEC 27К, 9К, GDPR, если платежи то PCI 3.2+ и так далее. Поэтому, чтоб сделать планшет официанту в кафе на заправке вам придётся пройтись по всему, включая индустрию Hospitality и Retail с их NRF, Fuel с IFSF, плюс от государства Fiscal/Tax, Privacy со всякими CСPA/GDPR в добавку к тем же ISO для вашей организации. И ни один стандарт не учитывает требования других стандартов.
avf48
27.07.2022 23:43+1Тут на самом деле важным моментом является заинтересованность заказчика.
И да, и нет) В "одном" проекте по автоматизации процесса согласования 1 д-тя, я сделал механизм для настройки маршрутов пользователями, в архитектуре, ориентируясь на стандарты, а не БТ. Но в крупных компаниях такое не пройдёт(.
Сейчас в каждом RFP будет требование ISO/IEC 27К, 9К.
Кстати, у 27000, 9000, 14000, 25000 итд все они, когда имеют ввиду систему, говорят про 15288(57193), 57195.
BIAN, pods.org и PPDM это ГОСТ Р ИСО 15704-2008, а вот он уже ссылается на 15288.
*Но и тут есть ложка дёгтя, ТК (тех. комитеты выпускающие отрасл. ст-ты) не всегда, как бы этого хотелось, взаимодействуют между собой. Хороший пример, *тут все хороши, BIM в строительстве.
Проблема ещё в том, что разбираться приходится самому... методических материалов мало, я начинал с замечательного сайта https://cals.ru/ndocs название говорит само, за себя (там много материала!).
"+" за чтение документации
Sipaha
Цикл статей довольно интересный, спасибо. Смутили только примеры кода разделе Золотые шестёрки.
Я думаю примеры высосаны из пальца. Можно написать лучше? Да (хотя с логгером я думаю и так все в порядке). Относятся ли эти примеры кода хоть на тысячную долю процента к архитектурным "стенам", которые сносят? Нет. Стены - это интерфейсы. Реализация этих интерфейсов может быть сколь угодно плохой, но если она инкапсулирована под хорошо спроектированным интерфейсом, то для неё а) можно написать хорошие автотесты б) в любой момент ЖЦ системы можно переписать эту реализацию на более красивую и/или эффективную.
XaBoK Автор
Примеры из того, что нашлось на диске и они подтверждают отношение людей к реализации: вокруг меня непонятно что, я вставил свой кусочек с закрытыми глазами - работает да и ладно. Допустим в примере с циклом падали юнит тесты и разработчик их просто заигнорил. Так что никаких тестов - их становится только меньше и никаких переписать, так как это "слишком сложно", ведь надо изменять то, что есть.
Из того, что я очень вижу часто - это всякие NewЧто-то. Копипаста класса, поля, интерфейса, контракта в новую реализацию и изменениями (тот самый холодильник на балконе). Последний пример у меня в голове - логин. Был сервис логин с паролем. Потом нужна была магнитная карта-ключ. Затем NFC. Как это реализовали в легаси? LoginService, LoginServiceNew, LoginServiceNew2. 3 разных API, вместо обновления и рефакторинга одного. Оно в принципе работало, просто пользователи жаловались, что при ошибках их кидает в обычный LoginService, который не всегда доступен, так как не везде была клавиатура или тачскрин. Выровнять это стоило кучу времени, и конечно, делали это на стороне клиента (5 разных клиентов, причем в части клиентов есть больше одного режима). А когда встала необходимость поменять алгоритм безопасности, то вместо одного места пришлось искать все эти копипасты. И нет, никто так и не отрефакторил : "уже столько сил положили, вряд ли будут еще измения". А потом появились мобилки с биометрией и, конечно, LoginBSerivce. Причем вот так, с опечаткой и исправить её не решались, так как заметили после того как API уже стал публичным.
Sipaha
Мне кажется такие люди есть на любом жизненном этапе проекта. Задача архитектора и руководства в том, чтобы таких людей вовремя останавливать. В нормальных проектах они обычно или перевоспитываются или увольняются. Если архитектора не слушают или вовсе увольняют, то тут конечно руководство с гнильцой и ничего с этим особо не поделать т.к. если в мозгу компании опухоль, то ожидать, что она когда-нибудь излечится слишком наивно.
Я про это же. Когда начинают в обход существующего API рядом пристраивать "такие же, но чуть другие" т.к. в старом или лень или страшно разбираться архитектура начинает разваливаться. В то же время если мы залоггируем как-то не так сообщение, то архитектура никак не пострадает.
XaBoK Автор
Вот тут важное уточнение. Я (благодаря периодическим слияниям и покупкам компаний в которых я работал) видел легаси десятка крупных корпораций. Они все одинаковые. Дело не в руководстве с гнильцой, а общих заблуждениях о том, что работа выполнена и дальше всё равно как - лишь бы больше прибыли. Об этом я и пытался сказать в первой части этого поста. И если все в этой благодатной атмосфере, то мнение против просто тонет в потоке поддакивания.
Sipaha
Если мнение хирурга тонет в потоке поддакивания ординаторов, то все же это косяк начальства. Другое дело если на должности хирурга сидит человек с улицы, который хорошо имитирует работу хирурга. Но этот сценарий мы вроде не рассматриваем.
Тут думаю есть два варианта:
Руководство осознает риски в долгосрочной перспективе угробить проект, но принимает их и просто качает деньги. Такой сценарий возможен и не сказал бы, что он совсем ужасен с т.з. бизнеса. Он отвратителен и неприятен до дрожи в коленях для IT отдела, что выливается в большую текучку кадров, но в то же время и поток денег никуда не пропадает, а зачастую и даже усиливается. В этом сценарии руководство играет в краткосрочную с перспективой либо разорвать отношения с заказчиком, либо начать разработку с нуля (опять же за доп. деньги от заказчика).
Во втором сценарии руководство не осознает риски и считает, что архитектор - это пятое колесо в системе, которая вышла в прод и стабилизировалась. И вот тут я никак не могу назвать такое начальство компетентными людьми. Все равно что начальник больницы скажет, что хирургов в штате держать слишком дорого и пусть операции делают медсестры.
И вот на эти два случая может быть две точки зрения:
Архитектор: 1 и 2 - начальство с гнильцой, которое не дает выполнять свою работу;
Бизнес: 1 - удовлетворительная стратегия, которая приносит деньги. 2 - некомпетентное руководство, которому затмили глаза деньги (как в золотой антилопе). На первый взгляд между 1 и 2 разница небольшая, но во втором случае некомпетентность часто выражается и в других аспектах ведения бизнеса, что скорее всего рано или поздно приведет к краху компании.
XaBoK Автор
Сравнение с хирургом приятно, но ошибочно. У должности архитектора есть 2 плохие особенности:
За всё отвечает, никем не управляет. Да, у вас много обязанностей, но нет конкретных инструментов воплощать их. Вы не можете просто сказать, что мы будем делать вот так. Архитектор просто даёт советы, так как исполнять или нет зависит от менеджмента разработки.
Отложенный результат. Ваши советы не дают моментальных плодов, а в индустрии очень много альтернативных подходов и точек зрения.
У хирурга своя команда и все его действия имеют моментальный эффект. Так как последствия будут видны через год-джва года, то начальство "думает своей головой". Во второй статье я как раз хотел дать обзор того, что у больших компаний большая инерция и эгоцентричность. Плюс естественный фокус на каденцию директоров. Если решения проявятся только через несколько лет, то либо шах либо ишак.
Компетенции начальства тоже интересный вопрос. В паре компаний я лично наблюдал то, что описывает @sasha_firsova. Ситуация изменилась, требуются новые компетенции, а люди всё те же. И прошлый успех мешает им принять ситуацию.
SabMakc
Как правило, все проблемы идут из того, что доработки нужны "здесь и сейчас" (что, в принципе, понятно и ожидаемо).
Я не встречал разработчиков, который хотели сделать плохо, чтобы потом было чем заняться на досуге... Но вот недостаток опыта, понимания, времени, ресурсов - сплошь и рядом...
И костыли в ПО пользователю не сильно-то и глаза колят - потому как они скрыты внутри... Костыли - это скорее про замедление скорости разработки и доработки. И только когда этих костылей становится слишком много и/или им не уделяют должного внимания - они начинают оказывать влияние на продукт с пользовательской точки зрения...
XaBoK Автор
Вы абсолютно правы:
Это и есть единственная причина помимо официального конца обслуживания (который всегда можно сдвинуть), почему клиент хочет перейти. Количество костылей делает систему "старой". И уроборос в том, что эти костыли с радостью ставят в течении нескольких лет. Как-будто никогда не знали чем закончится. И так каждый раз в каждой системе.