Pull to refresh

Comments 23

Крайне желательно раз в несколько месяцев делать руками полный цикл изменения кода. Обычно это выглядит так:
Взять в спринте маленькую задачу на час-другой работы...

Вы не могли бы привести пример использования такого подхода, в котором были выявлены и идентифицированы пробелы в дизайне?

Опишу случай из предыдущего проекта. Приложение в числе прочего может редактировать контакты, денормализованые данные должны асинхронно посылаться через Кафку в другой сервис который делает другая команда. Мы с ними вроде как это проговаривали и все должно быть норм.

Делаю кусок в 40 строк кода который обогащает поля контакта перед сохранением. Начинаю тестировать. Выясняется, что соседняя команда которая это делала полный цикл end-to-end не прогоняла. Хотя по идее должна бы, но их это почему-то не беспокоит и вообще им некогда. Начинаю выяснять почему так и как мне end-to-end сделать, выясняется, что конктракт на формат записи постоянно мутирует, контракт живет в библиотеке и она меняется два раза на день, разработчики это знают, но наверх это не идет, иду выяснять, отчего все мутирует, выясняется, что данные там лежат в Элесадре (https://www.elassandra.io) и там "есть проблемы".

Дальше в общем начинается нормальная работа с выяснением где искрит и вообще что за фигня. Но до момента, пока я не залез в код - все упорно молчали по разным причинам.

Нас всех учат не выносить сор из избы. В текущем мире, если будешь рассказывать о проблемах, то тебя запишут в токсики.

Это не значит, что архитектор должен заменять собой тимлида, но строить
взаимодействие с командой (командами) надо.

А где техлиды, старшие и ведущие разработчики, которые и отвечают за качество реализации?

Нас всех учат не выносить сор из избы. В текущем мире, если будешь рассказывать о проблемах, то тебя запишут в токсики.

Вы вроде бы все понимаете.

А где техлиды, старшие и ведущие разработчики, которые и отвечают за качество реализации?

Но в то же время демонстрируете признаки глубокого непонимания.

>Нас всех учат не выносить сор из избы. В текущем мире, если будешь рассказывать о проблемах, то тебя запишут в токсики.

Построение архитектуры решения практически единственное место, где можно говорить о проблемах. Ну и потом, я же не для западного ресурса статью пишу. На английский язык проблема переводится как challenge

>А где техлиды, старшие и ведущие разработчики, которые и отвечают за качество реализации?

Вот и у меня такой же вопрос. Если серьезно на него есть два ответа, выбирайте какой больше нравится

  1. в FAANG-ах

  2. На самом деле, когда система достаточно большая, невозможно объять ее всю и если у тебя в руках молоток, то много какие части системы видятся как гвоздь. Перефразируя из разных ролей картинка немного разная и задача архитектора смотреть на задачу широко. У тех лидов и старших разработчиков задачи другие и взгляд несколько другой

Очень хороший пример и этот подход работает практически во всех областях.

Самый обыденный вариант - архитектура не описывает инструментарий. Сам писать какой-нибудь кусок я буду только для POC, но то что постоянно вижу на ревью - разработчики пишут кучу вспомогательных библиотек под себя и редко смотрят, что уже есть в солюшине. Так что есть дублирование примерно 50% вспомогательных фунций и всякого сахара, в котором тоже накапливаются ошибки и костыли. Очень классно, когда архитектор, видя этот зоопарк, вводит новый гайдлайн и стандаритизирует утилиты.

Тоже самое с тестами - их пишут как говнокод, а там тоже можно дать дизайн и создать фреймворк. Разработчик смотрит на свою задачу, а архитектор на весь проект целиком.

Или вот 30 мин назад - смотрю в чате разработчики планируют использовать спринговую аннотацию @DependsOn - это прям плохой знак. Звонюсь с командой, выясняю для чего они хотят это сделать, объясняю как работат в этом месте спринг, надобность в @DependsOn отпадает.

Если бы я их за руку не поймал бы, то это бы всплыло только в процессе ревью PR, а учитывая, что не каждый PR я просмотриваю, все же это работа лида - это могло всплыть через значительное время какой-то странной проблемой.

Все верно и по делу, автору + за хорошие формулировки.

Предлагая альтернативы решений надо избегать ситуации, когда клиент не делает выбор сам, а переносит ответственность за это на архитектора. Помимо самого себя, в аутсорсе вы еще представляете всю свою компанию. Это оч.удобная позиция. Ведь, если выбор удачный, то тот самый менеджер со стороны клиента оденет на себя лавровый венок, а если возникнут проблемы, то "так нам посоветовали сранные специалисты из %имярек%"

Не знаю, мой опыт говорит, что когда что-то пошло не так, не важно кто предложил и как оно там все было политически сделано. Фэйл есть фэйл.

Фейл архитектора - это такая редкость, что больше похоже на черного лебедя, чем на риск для проекта. Архитектор обычно специалист с богатым опытом. И решение которое он предлагает - не единственно верное, а оптимальное в плане сложности и затрат в конкретном контексте и требованиях. Успех же проекта - усилия всей команды и прозрачность процессов.

Чтоб не вращать коней в вакууме: заказчик хочет микросервисы в облаках и чтоб всё на mssql. Архитектор из консалтинга даёт типичное решение, но предлагает заменить дорогущие инстансы ms на монгу. "Экономия денег? Конечно мы за!" - говорит управляющий со стороны заказчика. Потом, конечно, выясняется, что надо обучить нюансам х разработчиков. Но опыт и команда у консалтеров есть, так что немного денег и времени - всё равно экономия огромна. Когда проект почти готов, выясняется, что у них есть отдел с тоннами инструментария и внутренних продуктов именно под ms sql enterprise. Так что либо переделывать проект либо всю их внутреннюю кухню. Официально требования в контракте никто не менял, так что "нас обманули" и вся фигня. В моей практике это не единичный случай, так что важно чтоб принятие альтернативы исходило от заказчика формально и архитектура соответствовала задокументированным решениям.

Мне кажется тут сильно зависит от компании. В моей практике всегда было так, что роль архитектора ходит по краю с ролью engineering менеджера, который отвественен вообще за все.

Ну просто не понятно - вот я чувак с 25+ годами опыта, нарисовал архитектуру которая не может сфэлится и спокойно сижу и смотрю как группа товарищией упорно ведет проект на кладбище.

Можно конечно сказать, что к архитектуре вопросов нет, я весь в белом. Но пофакту граница очень размыта.

Вот в том-то и дело, что архитекторов обычно воспринимают как «пришел-вник-рассказал-ушел», а он должен постоянно быть на проекте (как в случае с аннотацией @DependsOn). Но это слишком дорого, поэтому он сначала работает целый день, а потом только по запросу. Вот и теряется контроль за проектом.

Именно так. К счастью пока мне удавалось работать в проектах где говорят "Ну нам надо спроектировать арихитектуру и надо чтобы ты потом 2-3 месяца с нами был и потом хотя бы 2 часа в день присматривал".

Но я понимаю, что это далеко не вся наблюдаемая вселенная.

Граница ожиданий очень размыта. По факту у меня никогда не было узд правления. Уж не знаю какой ваш опыт. Да, я открываю баги, пишу сториз в техдолг и спорю на совещаниях, но у меня в подчинении никого нет. Бюджета тоже нет. Так что если кто-то выше принял решение бежать к обрыву, то я максимум что могу - зажечь огни и расставить флажки в попытке предупредить остальное стадо.

Так что я видел проекты по дороге на кладбище, которые удалось спасти переубдив менеджмент, но видел и те, которые разваливались. Политика, эго, слабоумие, а иногда и просто не удачное стечение обстоятельств.

У меня было ровно обратно. Узд правления всегда заметно больше чем хочется и приходится часть из этих рычагов акуратно выдвать людям которые более или менее в адеквате.

Но я понимаю, что это сильно зависит от рабочего контекста. Подозреваю, что как раз в больших копорациях роль архитектора может быть сильно лимитирована.

Хотя я видел как это сделано в одном из проектов и там вроде как архитектор вполне обладал исполнительной властью.

Блин да что там говоить. В прошлом проекте я "уволил" тим лида одной из команд заказчика за некомпетентность.

Маленькая байка. В самом начале нулевых я, аспирант второго года, решил немного подзаработать. Мне нужен был мопед и не хватало 500 баксов (большие деньги по тем временам). Через знакомого в IRC (тогда всё так делалось) нашлась халтурка -- надо было сделать систему по приему платежей за мобилную связь. Это сейчас можно оплатить телефон не поднимая пятую точку с дивана, а тогда надо было пойти 5 километров в гору в ближайший салон и там твои наличные конвертируются в у.е. на счету мобильного. У фирмы, которой меня сосватали, был диллерский вход на сервера всяких MTS и Билайнов, но они опасались давать его всем работникам на точках приема платежей. За пару недель я настроил им сервер на FreeBSD (линукс тогда не принимали всерьез), написал фронтенд на PHP и бэк на Perl, который пропихивал платежи на сервера операторов, имитируя веб-сессию диллерского интерфейса. Казалось бы, что тут может пойти не так? Я забыл спросить, сколько у этой фирмы точек в Москве. Нет, моя система работала как швейцарские часы. Но начал падать сервер MTS, куда мой бэк пытался запихивать все приходящие платежи в параллель)

"Строя дизайн системы надо точно понимать какие у нас конкретные
проблемы, в конкретных подробностях и сколько у нас всего проблем. Т.е.
желательно иметь полный список, а не решать каждую из проблем по
отдельности, по мере их появления" - увы, крайне редко такое бывает в современном мире.

ну я скажу и да и и нет. С одной стороны действительно всего не угадаешь. Хотя и надо стараться учесть все, что можно учесть. С другой стороны внезапно все системы довольно похожи друг на друга и большая часть проектов укладывается в несколько десятков типовых архитектур с типовыми же проблемами. По крайней мере это верно для новых проектов.

При рефакторинге старых систем все несколько сложнее. Там в коде 10-20 летней давности может быть зарыто что-то очень экзотическое.

Но повторюсь - с новыми системам набор типовых архитектур не так уж велик.

Скажем говорит заказчик - я хочу mobile-only соц сеть где пользователи будут постить картинки с геолокацией и назначать календарные события к будущим эвентам. Список вопросов по NFR и ключевых элементов решения можно за час нарисовать. И за несколько дней дообсуждать до состояния когда можно прям начинать кодить. 95% граблей на этой тропинке за нас уже собрано.

UPD т..е понятно, что какая-то дичь все равно всплывет, но надо стараться на этапе проектирования процент дичи минимизировать.

А где можно посмотреть на этот десяток типовых архитектур?

Вот прямо готового одним куском у меня нет. Я когда-то начинал писать про это статью, но получается объемно и все как-то руки не доходят.

Наверное лучший ответ это полистать Хабр тут регулярно пробегают описание типовых архитектур.

UPD: Можно еще сюда заглянуть https://github.com/donnemartin/system-design-primer

Sign up to leave a comment.

Articles