Comments 44
Когда я изводил себя по поводу названия книги «Архитектура корпоративных программных приложений» (Patterns of Enterprise Application Architectureб Addison-Wesley, 2002), каждый наш рецензент соглашался, что «архитектура» попала в заголовок по праву.
Один мой друг долго ржал над фразой из начала этой книги, звучавшей в первом русском издании 2004 года примерно так «Сложная схема база данных, включающая до 200 таблиц». («We also see a complex database schema with perhaps two hundred tables and connections to packages for asset valuation and pricing.»).
В детстве я мечтал стать агрономом и, возможно из-за этого, аналогия с процессом выращивания деревьев мне казалась более подходящей, чем строительство, для большинства успешных проектов, в которых довелось принять участие. С удовольствием почитал бы статью "Кому нужен садовник?".
Это уже наверное боян, но мало ли кто не видел…
Мне всегда казалось что DB Administrator не то что к разработке софта отношения не имеет никакого, но даже должности такой может не быть в компании разработчике.
DBA — это на продакшине, у разработчиков архитект и девелопер.
А на ссылке — там нет архитекторных решений, а просто автоматизировання поддержка разработки. Судя по имплементации выльется позже в плохую производительность.
Может не быть должности, но может быть роль. И потом — это 2003 и архитектура корпоративных приложений. ;)
По поводу того, что нет архитектуры — ровно об этом и фраза автора. Убираем проблему, не нужно сваливать на архитектуру. Те же микросервисы, кстати, дать инструмент и отодвинуть многие архитектурные решения на уровень выше.
Добавил ссылку на перевод той статьи об эволюционом дизайне БД, кстати, спасибо, что напомнили (https://habrahabr.ru/post/312970/).
В том виде, как их преподносят — Kubernetes и т.п., исходят из принципа «пользователь утрётся» — это допустимо для публикации и просмотра котиков интернете: рубанул оркестратор контейнер с которого фотка скачивалась — ничего страшного пользователь обновит страницу и всё будет чики-пуки. А какая-нибудь медицинская система кого-то убъёт с таким подходом. — кто-то должен об этом подумать и принять решение. Этот человек — архитектор системы. А система — это серверы, данные, базы данных, протоколы, сети, API, представления о бизнес-процессах, знание best practice в смежных областях. Он, конечно, может совмещать эту роль с работой программиста, но совершенно не обязательно.
Абсолютно согласен, у меня там выпало слово "попытка" перед "дать инструмент и отодвинуть решения на уровень выше". Но суть в том, что это всегда было и будет одним из основных способов борьбы со сложностью — стараться абстрагироваться и создавать новые инструменты, которые помогут уводить принятие решений на уровень выше, чтобы не засыпало и все еще иметь возможность управлять все расширяющейся пирамидой под.
Иногда такие инструменты нифига не помогают, конечно ;) Особенно если энтропия берет вверх еще до очередного слоя и пирамида сама расползается на всех нижележащих уровнях.
Принцип "пользователь утрётся" — это тоже архитектурное решение :)
А как же трудозатраты на изменения? А также списанные в убыток трудозатраты на те блоки и части, что не стали использовать, а выкинули и переписали?
Молчу уже про сроки…
Была же на хабре ровно два года назад внятная статья Создание архитектуры программы или как проектировать табуретку
Отличный обзор. Там и про критерии, и много ссылок на другие книги ресурсы и статьи, рекомендую.
Но кому лень лезть читать, основная мысль вот (и с ней я, как бизнесмен, недавно по уши влезший в разработку ПО, согласен на «стопицот процентов»):
Хорошая архитектура это прежде всего выгодная архитектура, делающая процесс разработки и сопровождения программы более простым и эффективным.
Программу с хорошей архитектурой легче расширять и изменять, а также тестировать, отлаживать и понимать.
Собственно, такая постановка вопроса об архитектуре — когда программа не «вещь в себе в вакууме», а находится в реальном мире, имеет цену создания, эксплуатации и сопровождения- дает свои плоды.
И наводит заранее на мысли про риски увязнуть, риски переписывать бесконечно, риски больше или меньшей зависимости от разработчика, и т.д., и т.п.
Отсюда в статье и появляются такие критерии для архитектуры, как хорошая читаемость кода, или что не требуется много менять в программе, если меняется один блок, и пр.
Если то, как организована программа, эти все риски и затраты предотвратить или существенно уменьшить помогает — это хорошая архитектура.
Ну и конкретика, из чего архитектура состоит в техническом плане, тоже подробно разложено в упомянутой статье.
Да, это понятно. Но кто такие архитекторы?
Аналогично архитектор — тот, кто делает такую архитектуру, которая снижает риски и убытки разработки, эксплуатации и сопровождения.
То есть каждый разработчик (строитель), я правильно понимаю?
Речь не о «каждом разработчике», я отвечаю на ваш вопрос «кто такой архитектор».
Если каждый разработчик принимает решения о том, как должен быть организован код — то он в этой части архитектор. И совершенно точно, кто-то конкретный должен отвечать за то, что ВЕСЬ код организован так, чтобы снижать риски и убытки при разработке, эксплуатации и сопровождении. Он тогда главный архитектор.
Иногда позволять делать архитектуру тому кто строит — это очень плохое решение. Личный опыт — работал с человеком, который делал по принципу "делать, что запросят". Давным-давно, когда я ещё не работал в компании — он сделал программку, которая обслуживала клиентов, но этих клиентов было сравнительно немного. В те времена она была достаточно современна и шустра, да и выглядела неплохо (были куплены сторонние компоненты), да и использовалась из офиса 3.5 человеками. Время шло — в программку вносились запрошенные фичи… Вносились-вносились… И на момент моего прихода получилось весёлое состояние:
- Программой уже пользовались примерно 30-40 человек, для заведения тысяч записей в БД ежедневно.
- Часть людей использовала программу с рабочих компов, а часть через терминал
- Базу данных кроме программы — начали пользовать и другие сервисы.
- Всё это нещадно тормозило
- Всё это было трудноподдерживаемо, потому что работало ещё на .NET Framework 1.1
- Использовались сторонние компоненты без сурсов, которые не позволяли применить эволюционный подход и изменить всё постепенно.
- Бизнес откровенно недоумевал на предложения — закрыть нафиг программу и написать что-то более современное под базу данных, потому что "это надо ж новые элементы покупать", это ж "работа будет стоять, а у нас бизнес идёт" и наконец "всё это лишнее, лучше добавьте нам вот ещё вот эту фичу и ещё это и чтобы 7 перпендикулярных линий, две линии синие, одна — прозрачная, а ещё одна линия — в виде котёнка".
Так моё ИМХО: Архитектор, это та "неведома зверушка", правильно применяя которую — подобные ситуации становятся невозможными. Он должен подумать о перспективах роста, должен подумать о сменяемости фреймворков, устаревании и используемости сторонних компонент и авторитетно сказать начальству — как мы будем писать ПО и обслуживать бизнес. Как мы будем прыгать с версии на версию. Как и когда.
В случае "железа" — есть сисадмин, который может "померить графики/трафики" и доказать бизнесу, что "новый сервер нужен", "нужно больше памяти" или "нужно больше золота". В случае программного обеспечения мотив перехода от одной версии фреймворка к другому именно в этот конкретный момент — штука очень важная, но абстрактная для лица непосвящённого, которое относится к коду в стиле "шо ви мене тычете этими аббревиатурами хренворков?", неочевидно. Это подразумевает лишние, с точки зрения бизнеса, затраты и простой, но при этом он нужен. И нужен человек, который выйдет и скажет — мы должны это сделать. И это — Архитектор.
Со всем вышесказанным согласен — с добавкой, что хороший архитектор способен неспециалистам на пальцах объяснить, для чего.
А внятно и объективно.
"Объективно" обычно не получается, потому что то, что для программиста — объективная и аргументированная причина, для бизнеса — фигня какая-то. У них аргумент всех времён и народов "сейчас же всё работает, зачем что-то менять? Ты просто добавь фичу. Ну да… Подтормаживает… Ну мы сервер новый закажем". Для этого и нужна назначенный на должность — "архитектор" с возможностью принимать решение, который авторитетно сказал — "завтра мы меняем, рефакторим, пинаем пинусы, потому что ЭТО НАДО СДЕЛАТЬ", а бизнес — заткнулся и принял как должное. Должности — обычно верят. А вот когда обычный разраб приходит и начинает что-то доказывать — у бизнеса обычно принимается вид "Ах оставьте меня — я в печали".
Если причина объективная — то дело скорее в неумении сформулировать это на бизнес-языке.
В противном случае, как отличить реальную необходимость стратегического плана от простой прихоти?
Допускаю — коммуникативный дефект. Но тебя могут просто не услышать и это аргумент в пользу специальной должности. Т.е. одно дело, когда приходит человек, поставленный и говорит "Нам нужны плановые инфраструктурные изменения, чтобы избежать потенциального трындеца, на который мы обязательно нарвёмся спустя 1-2 года", а совсе другое когда тоже самое говорит обычный разраб. Почему он говорит, а другие — нет? Может быть там не всё так страшно? Может быть он — нагнетает ситуацию? У меняющих регулярно железо админов — есть графики, есть замеры. А как объективно объяснить замену фремворка №1 на версию фрейморка №2? Потому что сейчас — это будет сильно проще, чем если пару лет спустя менять №1 сразу на №5.
А почему разраб не может поднять свой авторитет и быть поставленным, а только лишь кто-то со стороны? Это особенность компании такая?
Увы. Я получил репутацию. Я бы сказал, что как минимум пара человек к моему мнению прислушиваются ибо мне есть что сказать в отдельных случаях. Но вертикаль власти есть вертикаль власти. Если неоднократные разумные доводы "за" начальством не принимаются — то на то оно и начальство. Начать же делать наперекор и, впоследствии, гарантированно огрести — увы это не по мне.
— Трудозатраты на поддержку возрастут если не перейдем. -> Насколько.
— Стоимость доработок все более усложняющейся системы будет выше. -> Насколько.
— Стоимость перехода будет выше. -> Насколько.
— Риски от сохранения старой системы. -> Перечень, объем неприятностей если риск реализуется.
И другая чаша весов:
цена перехода сейчас; срок;
И глядя на это — вопрос ставить не «переходить или не переходить», а «какой критерий будет говорить, что пора»
Типа, если трудозатраты на отработку, а главное на поиск причины бага при все нарастающем количестве этих доработок — больше в три раза, чем сейчас.
Или если прогнозы на предмет того, «что надо параллельно и где поправить чтобы обновление не снесло старые доработки» начинают расходиться с фактом более чем в 1/3 случаев".
Опять же, переходить не в «лучших» традициях — «сразу скопом и потом год расхлебывать», а поэтапно. Готовить, переносить, в фоновом или полуфоновом режиме, с приостановками если ресурса на продолжение подготовки перехода в какие-то месяцы нет.
Это не коммуникативные вопросы, а управленческие, я считаю.
Как и предыдущий комментатор, согласен. По поводу второй части.
А по истории — можно вопросы?
Первый — Вы считаете, что аргумент бизнеса "работа будет стоять, а у нас бизнес идёт" не очень существенен?
Во-вторых, а парень бездельничал, или был загружен? Или умения действительно хватило только на первоначальную версию (успешную в рамках того момента, насколько я понимаю)
Третий, самый интересный для меня, вопрос — Вам лично удалось сыграть роль архитектора? Систему переделали, больше не тормозит? (будет или нет — не спрашиваю)
- Аргумент существенный, потому что обслуживаем интересы бизнеса, чьи действия и обеспечивают нашу зарплату. Тут вопрос в том, что архитектурные решения надо принимать вовремя. А не когда уже всё трындец сливайте воду. А наличие архитектора — как раз и предполагает, что будет лицо, который говорит и этому решению следуют.
- Парень не бездельничал, но нужно ли мне объяснять, что в том же бизнесе, кроме получения непосредственно прибыли и премий необходимо ещё делать и такую неприятную вещь, как — платить налоги? Т.е. есть необходимые вещи, которые тем не менее стоит делать в любой сфере. В программном обеспечении — в результате тратятся ресурсы не только на написание кода, но и на поддержку оного. Улучшение.
- В профессиональном плане нет. Хотя несколько решений по результатам моей настойчивости — приняли. Это были скорее инфраструктурные вещи, н опроцесс они улучшили. Систему в результате просто слили. Она стала настолько legacy, что новый ЛПР от IT — ужаснулся. И продавил решение купить другое. Купить, а не создать самим.
Жму руку за пункт номер три.
А по поводу всего остального — ничего не поделаешь, мне кажется. Бизнес (клиент) is a king. Бывает, что и себе во вред, конечно, обычно-же — как может (успешный — больше, чем можно). Но главное, что Вы пробовали и тренируете навыки общения на понятном для него языке.
Иногда, кстати, купить — выгодный вариант ;)
Да, но следуя изменениям эволюционно — этого можно было избежать. Так сказать — следовало немножечко подумать "на перспективу" вначале иииии… Всё могло быть по другому.
Что касается "купить" — да это порой выгоднее и уж тем более быстрее, но лично меня, как программиста — это коробит. Спрашивается — зачем тогда меня нанимали? Затыкать дыры? Был достойный challenge применять навыки, но его слили кому-то другому. Ведь вначале становления — использовала компания исключительно свой софт. А из-за пролюбливания полимеров — пришлось решать проблему. Т.е. это как бы… щас вот придумал формулировку "чисто профессиональная жадность" — их деньги могли бы быть моими (хотя на самом деле это естественно не так) =))))). Но где-то в глубине души сидит червячок и грызёт. =)
Я уверен, что любой программист, отрывший очень старый код (5+ лет) — может найти то, как его улучшить: чисто стилистически, появились новые структуры новой версии языка или фреймворка, новое видение, убирание старых костылей. Даже свой код. Я однажды открыл код которому было 10 лет и ужаснулся и не поверил — "как я мог это написать?! Да я был дауном!" Это совершенно нормально для того, кто развивается и растёт над собой.
Но именно и поэтому фраза "я должен просмотреть на свой работающий код и поменять его, потому что я вырос профессионально" — скорее всего вгонит бизнес в состояние ступора: "Зачем?" спросит он и будет прав. Эти изменения они накопительные, но их стоит делать. Например сообразно приведённому фреймворку .NET Framework 1.1 -> 2.0: Если мне не изменяет память в этом переходе одним из важнейших изменений было — внедрение Generic классов, позволяющих ускорить код за счёт исключения boxing/unboxing (это изменение совершенно точно было), а дополнительно были изменения в работе классов String и StringBuilder, работа с этими классами в новом фреймворке была оптимизирована и ускоряла процесс обработки строк в 3 — 10 раз. И вот эта вот вторая часть — решалась всего лишь переключением на новый фреймворк и rebuild все проекты и зависимые библиотеки. Для программиста — эти причины могут быть существенными аргументами для смены фреймворка, но вот для бизнеса — тут как посмотреть. Учитывая, что надо перетестировать считай всё приложение.
Ну вот, у меня снова тот же вопрос, а что мешало Вам по чуть-чуть рефакторить, тестировать и потом накатывать в продакшн? (что-то точно должно было мешать)
ну если мне попадался код, который мне можно было улучшить — я так и делал, но переход на фреймворк мог вызвать серьёзные проблемы в 3rd Party коде. Мало того — в фоновом режиме я пробовал сконвертнуть, но там затронуло GUI компоненты (относительно легко решил эту проблему) и компонент протокола передачи данных. Т.е. для разбирания проблемы требовалось приличное время, которое я и хотел получить, но увы.
Кому нужен архитектор?