Комментарии 22
Цикл статей довольно интересный, спасибо. Смутили только примеры кода разделе Золотые шестёрки.
Поэтому чувствуя, что дом уже стоит, и нужно только обустроиться внутри, эффективные люди начинают оптимизировать пространство, снося стены.
Дабы не быть голословным:
Я думаю примеры высосаны из пальца. Можно написать лучше? Да (хотя с логгером я думаю и так все в порядке). Относятся ли эти примеры кода хоть на тысячную долю процента к архитектурным "стенам", которые сносят? Нет. Стены - это интерфейсы. Реализация этих интерфейсов может быть сколь угодно плохой, но если она инкапсулирована под хорошо спроектированным интерфейсом, то для неё а) можно написать хорошие автотесты б) в любой момент ЖЦ системы можно переписать эту реализацию на более красивую и/или эффективную.
Примеры из того, что нашлось на диске и они подтверждают отношение людей к реализации: вокруг меня непонятно что, я вставил свой кусочек с закрытыми глазами - работает да и ладно. Допустим в примере с циклом падали юнит тесты и разработчик их просто заигнорил. Так что никаких тестов - их становится только меньше и никаких переписать, так как это "слишком сложно", ведь надо изменять то, что есть.
Из того, что я очень вижу часто - это всякие NewЧто-то. Копипаста класса, поля, интерфейса, контракта в новую реализацию и изменениями (тот самый холодильник на балконе). Последний пример у меня в голове - логин. Был сервис логин с паролем. Потом нужна была магнитная карта-ключ. Затем NFC. Как это реализовали в легаси? LoginService, LoginServiceNew, LoginServiceNew2. 3 разных API, вместо обновления и рефакторинга одного. Оно в принципе работало, просто пользователи жаловались, что при ошибках их кидает в обычный LoginService, который не всегда доступен, так как не везде была клавиатура или тачскрин. Выровнять это стоило кучу времени, и конечно, делали это на стороне клиента (5 разных клиентов, причем в части клиентов есть больше одного режима). А когда встала необходимость поменять алгоритм безопасности, то вместо одного места пришлось искать все эти копипасты. И нет, никто так и не отрефакторил : "уже столько сил положили, вряд ли будут еще измения". А потом появились мобилки с биометрией и, конечно, LoginBSerivce. Причем вот так, с опечаткой и исправить её не решались, так как заметили после того как API уже стал публичным.
Примеры из того, что нашлось на диске и они подтверждают отношение людей к реализации: вокруг меня непонятно что, я вставил свой кусочек с закрытыми глазами - работает да и ладно.
Мне кажется такие люди есть на любом жизненном этапе проекта. Задача архитектора и руководства в том, чтобы таких людей вовремя останавливать. В нормальных проектах они обычно или перевоспитываются или увольняются. Если архитектора не слушают или вовсе увольняют, то тут конечно руководство с гнильцой и ничего с этим особо не поделать т.к. если в мозгу компании опухоль, то ожидать, что она когда-нибудь излечится слишком наивно.
3 разных API, вместо обновления и рефакторинга одного
Я про это же. Когда начинают в обход существующего API рядом пристраивать "такие же, но чуть другие" т.к. в старом или лень или страшно разбираться архитектура начинает разваливаться. В то же время если мы залоггируем как-то не так сообщение, то архитектура никак не пострадает.
Вот тут важное уточнение. Я (благодаря периодическим слияниям и покупкам компаний в которых я работал) видел легаси десятка крупных корпораций. Они все одинаковые. Дело не в руководстве с гнильцой, а общих заблуждениях о том, что работа выполнена и дальше всё равно как - лишь бы больше прибыли. Об этом я и пытался сказать в первой части этого поста. И если все в этой благодатной атмосфере, то мнение против просто тонет в потоке поддакивания.
И если все в этой благодатной атмосфере, то мнение против просто тонет в потоке поддакивания.
Если мнение хирурга тонет в потоке поддакивания ординаторов, то все же это косяк начальства. Другое дело если на должности хирурга сидит человек с улицы, который хорошо имитирует работу хирурга. Но этот сценарий мы вроде не рассматриваем.
Дело не в руководстве с гнильцой, а общих заблуждениях о том, что работа выполнена и дальше всё равно как - лишь бы больше прибыли.
Тут думаю есть два варианта:
Руководство осознает риски в долгосрочной перспективе угробить проект, но принимает их и просто качает деньги. Такой сценарий возможен и не сказал бы, что он совсем ужасен с т.з. бизнеса. Он отвратителен и неприятен до дрожи в коленях для IT отдела, что выливается в большую текучку кадров, но в то же время и поток денег никуда не пропадает, а зачастую и даже усиливается. В этом сценарии руководство играет в краткосрочную с перспективой либо разорвать отношения с заказчиком, либо начать разработку с нуля (опять же за доп. деньги от заказчика).
Во втором сценарии руководство не осознает риски и считает, что архитектор - это пятое колесо в системе, которая вышла в прод и стабилизировалась. И вот тут я никак не могу назвать такое начальство компетентными людьми. Все равно что начальник больницы скажет, что хирургов в штате держать слишком дорого и пусть операции делают медсестры.
И вот на эти два случая может быть две точки зрения:
Архитектор: 1 и 2 - начальство с гнильцой, которое не дает выполнять свою работу;
Бизнес: 1 - удовлетворительная стратегия, которая приносит деньги. 2 - некомпетентное руководство, которому затмили глаза деньги (как в золотой антилопе). На первый взгляд между 1 и 2 разница небольшая, но во втором случае некомпетентность часто выражается и в других аспектах ведения бизнеса, что скорее всего рано или поздно приведет к краху компании.
Сравнение с хирургом приятно, но ошибочно. У должности архитектора есть 2 плохие особенности:
За всё отвечает, никем не управляет. Да, у вас много обязанностей, но нет конкретных инструментов воплощать их. Вы не можете просто сказать, что мы будем делать вот так. Архитектор просто даёт советы, так как исполнять или нет зависит от менеджмента разработки.
Отложенный результат. Ваши советы не дают моментальных плодов, а в индустрии очень много альтернативных подходов и точек зрения.
У хирурга своя команда и все его действия имеют моментальный эффект. Так как последствия будут видны через год-джва года, то начальство "думает своей головой". Во второй статье я как раз хотел дать обзор того, что у больших компаний большая инерция и эгоцентричность. Плюс естественный фокус на каденцию директоров. Если решения проявятся только через несколько лет, то либо шах либо ишак.
Компетенции начальства тоже интересный вопрос. В паре компаний я лично наблюдал то, что описывает @sasha_firsova. Ситуация изменилась, требуются новые компетенции, а люди всё те же. И прошлый успех мешает им принять ситуацию.
у вас много обязанностей, но нет конкретных инструментов воплощать их
Что Вы думаете про концепцию Architectural Fitness Functions? По мне, это вполне выглядит как способ создания подходящих под конкретную среду инструментов. Но этот подход, кажется, ещё не особо широко известен. Ничего похожего Вам не попадалось?
Подход стандартный. Тут скорее не известен новый базворд, который кто то придумал, чтоб продать то, что остальные давно используют.
В пятой части я как раз говорил об автоматическом тестировании архитектурных концептов для создания жёстких рамок. Нормального фреймворка для этого я не встречал, поэтому лет 10 назад начал писать кастомные правила для сонара (то что бежит раз в день) и юнит-тесты (каждый билд) проверяющие все проекты в монорепозитории на соответствие основным конвенциям.
Таким нехитрым способом можно не дать зачекинить код без разметки документации или класс из верхнего уровня бизнес модели с референсом структуры из базы данных.
Как правило, все проблемы идут из того, что доработки нужны "здесь и сейчас" (что, в принципе, понятно и ожидаемо).
Я не встречал разработчиков, который хотели сделать плохо, чтобы потом было чем заняться на досуге... Но вот недостаток опыта, понимания, времени, ресурсов - сплошь и рядом...
И костыли в ПО пользователю не сильно-то и глаза колят - потому как они скрыты внутри... Костыли - это скорее про замедление скорости разработки и доработки. И только когда этих костылей становится слишком много и/или им не уделяют должного внимания - они начинают оказывать влияние на продукт с пользовательской точки зрения...
Вы абсолютно правы:
Костыли - это скорее про замедление скорости разработки и доработки. И только когда этих костылей становится слишком много и/или им не уделяют должного внимания - они начинают оказывать влияние на продукт с пользовательской точки зрения.
Это и есть единственная причина помимо официального конца обслуживания (который всегда можно сдвинуть), почему клиент хочет перейти. Количество костылей делает систему "старой". И уроборос в том, что эти костыли с радостью ставят в течении нескольких лет. Как-будто никогда не знали чем закончится. И так каждый раз в каждой системе.
Прочитал все статьи разом. Спасибо большое за труд.
Да, чувствуется опыт... И начинаешь чувствовать себя старым - просто потому, что понимаешь о чем говорит автор и сталкивался в том или ином виде.
Впрочем, это все характерно для любого не-нового проекта - а не только для тех, которым "пора на пенсию".
Но должен сказать, что обычно не все так однозначно.
В том же примере с форматированием, использование форматирования - это про читаемость в 1ю очередь, а не про ненужность форматирования.
Лично я вижу проблему скорее в области производительности. Форматтер, как правило, достаточно нетривиально работает и занимает много времени на выполнение. Поэтому обычно логгер имеет свой форматтер, который отрабатывает только в том в случае, если сообщение действительно попадет в лог. И использование "стороннего" форматтера тут излишне.
И в примере с замком тоже не все так однозначно. Я бывал в роли Николая из "игры престолов". В том числе сталкивался и с тем, что через ген.директора пытались "продавить" "очень важные и жизненно необходимые функции". Но зачастую справедлива фраза "просто было на бумаге, да забыли про овраги". И опытный разработчик может очень грамотно и по пунктам разложить почему именно он это не хочет это делать, а не просто "не хочу и все".
Или плохое понимание что именно надо или как именно это должно работать, которое очень сильно не соответствует тому, что реально происходит в системе. Или необходимы неоправданно большие изменения кода (к слову, привет "очередным NewЧтоТоТам" и "тестов нет, но вы держитесь"). Или это уже есть в чуть другом виде (например, уже есть функция "закрыть замок" помимо "открыть замок" и "открыть крышку").
И что самое веселое - в итоге эти "очень важные и жизненно необходимые функции" очень часто оказываются никому не нужными (просто потому, что нашли более простой и прямой путь сделать то, что хотели) дурно пахнущими кусками кода "висящими на балансе" проекта (потому что удаление чего-либо из работающией системы - это еще более нетривиальная задача, чем добавление нового кода).
И использование "стороннего" форматтера тут излишне.
Конечно, но фокус на том, что данную строку писали в 5 заходов 5 разработчиков. Каждый внёс что то своё, не удосужившись выровнять. Всего одна строка! Такое впечатление, что люди боятся лишний символ посмотреть.
А насчёт "Николая", то тут дело как в "не хочу и все". Было бы объяснение - искали бы альтернативы и компромиссы. И тогда это был бы не "Коля", а хороший инженер.
Про Архитектуру писать нужно и полезно! Автору "+"...
Но я затрону проблемную часть Архитектуризации... это стандарты (ГОСТы)
Почему нет ни одной ссылки? Как можно заниматься созданием сложных систем, веря только в свой "Великий мозг" (сарказм)? Как можно Знать всё и сразу, и помнить всё это?! Слезайте с тяжелых наркотиков!!!
И я, говорю о стандартах именно по ЖЦ ИТ систем, без учета стандартов на виды деятельности, которые вы автоматизируйте. Как можно отличить Некомпетентного руководителя от компетентного, если не знаешь Как он должен 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: Слишком близко к сердцу не принимайте...
Ну мне RFC ближе ГОСТ-ов. Есть и стандарты, особенно это актуально для отдельных индустрий. Есть для ритейла, финтеха, нефтегаз и тд. Но в любом случае - это даже не шаблоны, а своеобразный чеклист. Я смотрю их для лучшего понимания бизнеса. Люди уже сталкивались с кучей проблем в предметной области и предлагают варианты решения. Ну и плюс - это обычно публичные ресурсы и на них хорошо ссылаться при интеграции (почему так - вот стандарт рекомендует), упрощает доказательную часть решения.
особенно это актуально для отдельных индустрий.
Да, соглашусь, что популярные ст-ты именно индустриальные. Но я про СИСТЕМНЫЕ стандарты, те которые говорят, как сделать Успешную систему (системная и программная инженерия).
Но в любом случае - это даже не шаблоны, а своеобразный чеклист.
Именно!)) Компания то ведь ваша, а продукт, будут потреблять те, кто Должен быть уверен в их безопасности... Те, то ЧТО вы произведете (если требований нет), всем всё ровно, но вот на сколько безопасно вы будете это делать (для потребителя, сотрудника, общества) Я должен быть в этом уверен, а я это Общество.
Я смотрю их для лучшего понимания бизнеса.
Ну? и кто у нас работает по стандарту?)) из руководителей, таких не видел...
я так вообще ушел от Бизнес требований, у меня есть ГОСТ на систему в кот. они действуют, есть профст-т, какими навыками они должны обладать и есть структура объектов с которыми они что то делают... я, всё это могу вытащить из ОКВЭДа...
Кто из них понимает что такое исо 9001 или 15288(57193)?? А без этого руководить организацией нельзя, только управлять.
А к стати, вся оборонка и АЭС это один большой ГОСТ... Поэтому в Этом Мы Лучшие, благо военные не взяли практику Сбера и Газпрома...
PS: ГОСТ Р ИСО 19439-2008 Интеграция предприятия. Основа моделирования предприятия (GERA)
почему так - вот стандарт рекомендует
А вот в этом главная проблема, стандарт - рекомендует.
стандарт- образец, эталон, модель, принимаемые за исходные для сопоставления с ними других подобных объектов.
Тогда можно Рекомендовать всем работать хорошо... Рекомендовать соблюдать скорость, а если у вас есть дети, то можно Рекомендовать произв-лям детского питания соблюдать требования безопасности...
Ах да... забыл совсем... В "Храмой лошади" и "Зимней вишне" там рекомендации были не выполнены или не по Стандарту было всё организовано?! И почему то мне кажется, что в большом ТЦ ОТиПБ и ПожБез были, хоть как то, но автоматизированы...
В 21 веке, почти каждая смерть по неосторожности на руках Айтишника.
Тут на самом деле важным моментом является заинтересованность заказчика.
Я должен быть в этом уверен, а я это Общество.
В коммерческой разработке государство тоже участник. Так что уже на первом этапе, при объявлении тендера, прописаны необходимые стандарты с сертификацией. То есть не просто "мы ознакомились с рекомендациями", а "у нас была комиссия/аудит и по результатам мы соответствуем такому-то стандарту такой то версии".
Сейчас в каждом RFP будет требование ISO/IEC 27К, 9К, GDPR, если платежи то PCI 3.2+ и так далее. Поэтому, чтоб сделать планшет официанту в кафе на заправке вам придётся пройтись по всему, включая индустрию Hospitality и Retail с их NRF, Fuel с IFSF, плюс от государства Fiscal/Tax, Privacy со всякими CСPA/GDPR в добавку к тем же ISO для вашей организации. И ни один стандарт не учитывает требования других стандартов.
Тут на самом деле важным моментом является заинтересованность заказчика.
И да, и нет) В "одном" проекте по автоматизации процесса согласования 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 название говорит само, за себя (там много материала!).
"+" за чтение документации
.
Огромное спасибо за весьма особый цикл статей.
Любопытно, конечно, применимо ли в таком раскладе понятие архитектора ПО к свободному ПО?
Ведь там явным образом софт не создаётся для зарабатывания денег на его продаже.
Архитектура не про деньги, а про оптимизацию. Баланс усилий и пользы. В бизнесе и свободном ПО этот баланс обычно смещён в сторону пользы. И разница лишь в определении этой самой пользы. Для бизнеса - приоритет в получении денег, а для свободного ПО - приоритет в пользе. Так мы можем получить убогий по содержанию коммерческий продукт с рекламной компанией и отличным юзибилити, против свободного скомпилируй-сам консольного приложения с гибкой настройкой и кучей функций.
Архитектура Архитектуры. Шаг 10. Это конец