Comments 23
Крайне желательно раз в несколько месяцев делать руками полный цикл изменения кода. Обычно это выглядит так:
Взять в спринте маленькую задачу на час-другой работы...
Вы не могли бы привести пример использования такого подхода, в котором были выявлены и идентифицированы пробелы в дизайне?
Опишу случай из предыдущего проекта. Приложение в числе прочего может редактировать контакты, денормализованые данные должны асинхронно посылаться через Кафку в другой сервис который делает другая команда. Мы с ними вроде как это проговаривали и все должно быть норм.
Делаю кусок в 40 строк кода который обогащает поля контакта перед сохранением. Начинаю тестировать. Выясняется, что соседняя команда которая это делала полный цикл end-to-end не прогоняла. Хотя по идее должна бы, но их это почему-то не беспокоит и вообще им некогда. Начинаю выяснять почему так и как мне end-to-end сделать, выясняется, что конктракт на формат записи постоянно мутирует, контракт живет в библиотеке и она меняется два раза на день, разработчики это знают, но наверх это не идет, иду выяснять, отчего все мутирует, выясняется, что данные там лежат в Элесадре (https://www.elassandra.io) и там "есть проблемы".
Дальше в общем начинается нормальная работа с выяснением где искрит и вообще что за фигня. Но до момента, пока я не залез в код - все упорно молчали по разным причинам.
Нас всех учат не выносить сор из избы. В текущем мире, если будешь рассказывать о проблемах, то тебя запишут в токсики.
Это не значит, что архитектор должен заменять собой тимлида, но строить
взаимодействие с командой (командами) надо.
А где техлиды, старшие и ведущие разработчики, которые и отвечают за качество реализации?
Нас всех учат не выносить сор из избы. В текущем мире, если будешь рассказывать о проблемах, то тебя запишут в токсики.
Вы вроде бы все понимаете.
А где техлиды, старшие и ведущие разработчики, которые и отвечают за качество реализации?
Но в то же время демонстрируете признаки глубокого непонимания.
>Нас всех учат не выносить сор из избы. В текущем мире, если будешь рассказывать о проблемах, то тебя запишут в токсики.
Построение архитектуры решения практически единственное место, где можно говорить о проблемах. Ну и потом, я же не для западного ресурса статью пишу. На английский язык проблема переводится как challenge
>А где техлиды, старшие и ведущие разработчики, которые и отвечают за качество реализации?
Вот и у меня такой же вопрос. Если серьезно на него есть два ответа, выбирайте какой больше нравится
в FAANG-ах
На самом деле, когда система достаточно большая, невозможно объять ее всю и если у тебя в руках молоток, то много какие части системы видятся как гвоздь. Перефразируя из разных ролей картинка немного разная и задача архитектора смотреть на задачу широко. У тех лидов и старших разработчиков задачи другие и взгляд несколько другой
Очень хороший пример и этот подход работает практически во всех областях.
Самый обыденный вариант - архитектура не описывает инструментарий. Сам писать какой-нибудь кусок я буду только для POC, но то что постоянно вижу на ревью - разработчики пишут кучу вспомогательных библиотек под себя и редко смотрят, что уже есть в солюшине. Так что есть дублирование примерно 50% вспомогательных фунций и всякого сахара, в котором тоже накапливаются ошибки и костыли. Очень классно, когда архитектор, видя этот зоопарк, вводит новый гайдлайн и стандаритизирует утилиты.
Тоже самое с тестами - их пишут как говнокод, а там тоже можно дать дизайн и создать фреймворк. Разработчик смотрит на свою задачу, а архитектор на весь проект целиком.
Или вот 30 мин назад - смотрю в чате разработчики планируют использовать спринговую аннотацию @DependsOn - это прям плохой знак. Звонюсь с командой, выясняю для чего они хотят это сделать, объясняю как работат в этом месте спринг, надобность в @DependsOn отпадает.
Если бы я их за руку не поймал бы, то это бы всплыло только в процессе ревью PR, а учитывая, что не каждый PR я просмотриваю, все же это работа лида - это могло всплыть через значительное время какой-то странной проблемой.
Все верно и по делу, автору + за хорошие формулировки.
Предлагая альтернативы решений надо избегать ситуации, когда клиент не делает выбор сам, а переносит ответственность за это на архитектора. Помимо самого себя, в аутсорсе вы еще представляете всю свою компанию. Это оч.удобная позиция. Ведь, если выбор удачный, то тот самый менеджер со стороны клиента оденет на себя лавровый венок, а если возникнут проблемы, то "так нам посоветовали сранные специалисты из %имярек%"
Не знаю, мой опыт говорит, что когда что-то пошло не так, не важно кто предложил и как оно там все было политически сделано. Фэйл есть фэйл.
Фейл архитектора - это такая редкость, что больше похоже на черного лебедя, чем на риск для проекта. Архитектор обычно специалист с богатым опытом. И решение которое он предлагает - не единственно верное, а оптимальное в плане сложности и затрат в конкретном контексте и требованиях. Успех же проекта - усилия всей команды и прозрачность процессов.
Чтоб не вращать коней в вакууме: заказчик хочет микросервисы в облаках и чтоб всё на mssql. Архитектор из консалтинга даёт типичное решение, но предлагает заменить дорогущие инстансы ms на монгу. "Экономия денег? Конечно мы за!" - говорит управляющий со стороны заказчика. Потом, конечно, выясняется, что надо обучить нюансам х разработчиков. Но опыт и команда у консалтеров есть, так что немного денег и времени - всё равно экономия огромна. Когда проект почти готов, выясняется, что у них есть отдел с тоннами инструментария и внутренних продуктов именно под ms sql enterprise. Так что либо переделывать проект либо всю их внутреннюю кухню. Официально требования в контракте никто не менял, так что "нас обманули" и вся фигня. В моей практике это не единичный случай, так что важно чтоб принятие альтернативы исходило от заказчика формально и архитектура соответствовала задокументированным решениям.
Мне кажется тут сильно зависит от компании. В моей практике всегда было так, что роль архитектора ходит по краю с ролью engineering менеджера, который отвественен вообще за все.
Ну просто не понятно - вот я чувак с 25+ годами опыта, нарисовал архитектуру которая не может сфэлится и спокойно сижу и смотрю как группа товарищией упорно ведет проект на кладбище.
Можно конечно сказать, что к архитектуре вопросов нет, я весь в белом. Но пофакту граница очень размыта.
Граница ожиданий очень размыта. По факту у меня никогда не было узд правления. Уж не знаю какой ваш опыт. Да, я открываю баги, пишу сториз в техдолг и спорю на совещаниях, но у меня в подчинении никого нет. Бюджета тоже нет. Так что если кто-то выше принял решение бежать к обрыву, то я максимум что могу - зажечь огни и расставить флажки в попытке предупредить остальное стадо.
Так что я видел проекты по дороге на кладбище, которые удалось спасти переубдив менеджмент, но видел и те, которые разваливались. Политика, эго, слабоумие, а иногда и просто не удачное стечение обстоятельств.
У меня было ровно обратно. Узд правления всегда заметно больше чем хочется и приходится часть из этих рычагов акуратно выдвать людям которые более или менее в адеквате.
Но я понимаю, что это сильно зависит от рабочего контекста. Подозреваю, что как раз в больших копорациях роль архитектора может быть сильно лимитирована.
Хотя я видел как это сделано в одном из проектов и там вроде как архитектор вполне обладал исполнительной властью.
Блин да что там говоить. В прошлом проекте я "уволил" тим лида одной из команд заказчика за некомпетентность.
Маленькая байка. В самом начале нулевых я, аспирант второго года, решил немного подзаработать. Мне нужен был мопед и не хватало 500 баксов (большие деньги по тем временам). Через знакомого в IRC (тогда всё так делалось) нашлась халтурка -- надо было сделать систему по приему платежей за мобилную связь. Это сейчас можно оплатить телефон не поднимая пятую точку с дивана, а тогда надо было пойти 5 километров в гору в ближайший салон и там твои наличные конвертируются в у.е. на счету мобильного. У фирмы, которой меня сосватали, был диллерский вход на сервера всяких MTS и Билайнов, но они опасались давать его всем работникам на точках приема платежей. За пару недель я настроил им сервер на FreeBSD (линукс тогда не принимали всерьез), написал фронтенд на PHP и бэк на Perl, который пропихивал платежи на сервера операторов, имитируя веб-сессию диллерского интерфейса. Казалось бы, что тут может пойти не так? Я забыл спросить, сколько у этой фирмы точек в Москве. Нет, моя система работала как швейцарские часы. Но начал падать сервер MTS, куда мой бэк пытался запихивать все приходящие платежи в параллель)
"Строя дизайн системы надо точно понимать какие у нас конкретные
проблемы, в конкретных подробностях и сколько у нас всего проблем. Т.е.
желательно иметь полный список, а не решать каждую из проблем по
отдельности, по мере их появления" - увы, крайне редко такое бывает в современном мире.
ну я скажу и да и и нет. С одной стороны действительно всего не угадаешь. Хотя и надо стараться учесть все, что можно учесть. С другой стороны внезапно все системы довольно похожи друг на друга и большая часть проектов укладывается в несколько десятков типовых архитектур с типовыми же проблемами. По крайней мере это верно для новых проектов.
При рефакторинге старых систем все несколько сложнее. Там в коде 10-20 летней давности может быть зарыто что-то очень экзотическое.
Но повторюсь - с новыми системам набор типовых архитектур не так уж велик.
Скажем говорит заказчик - я хочу mobile-only соц сеть где пользователи будут постить картинки с геолокацией и назначать календарные события к будущим эвентам. Список вопросов по NFR и ключевых элементов решения можно за час нарисовать. И за несколько дней дообсуждать до состояния когда можно прям начинать кодить. 95% граблей на этой тропинке за нас уже собрано.
UPD т..е понятно, что какая-то дичь все равно всплывет, но надо стараться на этапе проектирования процент дичи минимизировать.
А где можно посмотреть на этот десяток типовых архитектур?
Вот прямо готового одним куском у меня нет. Я когда-то начинал писать про это статью, но получается объемно и все как-то руки не доходят.
Наверное лучший ответ это полистать Хабр тут регулярно пробегают описание типовых архитектур.
UPD: Можно еще сюда заглянуть https://github.com/donnemartin/system-design-primer
Памятка архитектору