S
тут в чятике выше написали же, теперь будут знать, карты раскрыты
ну дык, плох тот джун, кто не мечтает стать архитектором
Size: a a a
2019 October 25
AP
ну и зачем нам тогда архитектор? задавать вопросы гуглу и джун сможет
потому что архитектура это не разработка. Системная архитектура - ну да, она ещё про разработку.
А солюшен или энтерпрайз вообще не про разработку, он про управление изменениями с технической стороны, выбор решений, создание продукта и прочее.
Пару дней назад уже подробно холиварили, впрочем.
А солюшен или энтерпрайз вообще не про разработку, он про управление изменениями с технической стороны, выбор решений, создание продукта и прочее.
Пару дней назад уже подробно холиварили, впрочем.
AS
Ну, я хочу понять, есть ли практики / методологии характерные для выделенной роли архитектора. Я как тимлид конечно немного изучал и теорию управления проектами и архитектурные решения принимал и с заказчиками коммуницировал. Но то колхозное самообучение, а может есть общепризнанные авторитеты/стандарты/методологии/книги и тп
Читать нужно все и много Для общего кругозора полезна вот эта книга, хоть немного и устарела. И еще Release it. https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives/dp/0321112296
AS
Тут где-то было обсуждение литературы неплохое. Опять же все, что читают разработчики тоже необходимо плюсь еще разные Accelerate
S
была когда-то книга "Жемчужины Программирования", там набор интересных случаев из практики как раз был. Тоже пригодится архитекторам
KG
россыпь жемчуга в компостной яме существовать не может
KG
все подряд кстати тоже читать не стоит. очень быстро устаешь
AK
потому что архитектура это не разработка. Системная архитектура - ну да, она ещё про разработку.
А солюшен или энтерпрайз вообще не про разработку, он про управление изменениями с технической стороны, выбор решений, создание продукта и прочее.
Пару дней назад уже подробно холиварили, впрочем.
А солюшен или энтерпрайз вообще не про разработку, он про управление изменениями с технической стороны, выбор решений, создание продукта и прочее.
Пару дней назад уже подробно холиварили, впрочем.
Ну тут всегда будут холиварить, т.к. есть два стула - enterprise и technical. Последний, например, никогда не согласится, что первый может выбирать технические решения и имеет для этого компетенцию.
KG
надо взять какое направление, например, в котором сейчас ничего не понимаешь, и копать в него
AS
все подряд кстати тоже читать не стоит. очень быстро устаешь
Я имел в виду литературу по архитектуре, разработке, DevOps и менеджменту
KG
если у тебя плохо с кодом, то наверно почитать про алгоритмы можно
GK
Мне особенно нравится, когда есть статьи, почему этот инструмент вам не подойдёт. А то везде пишут: увау, мы тут придумали 1001й инструмент, который делает работу лучше чем остальные. И одни плюсы. А минусы можно узнать только когда сам пробуешь в реальной жизни.
Такие статьи тоже нуже аккуратно читать. Часто люди бездумно и не к месту используют какую-нибудь технологию, и потом по-своему интерпретируют результаты. Утюг вещь бесполезная, потому что мы жарили на нём омлет, и он получился не очень. А кроме того, держать ручкой вниз утюг неудобно и он тяжёлый.
AS
если у тебя плохо с кодом, то наверно почитать про алгоритмы можно
Если бы это помогало. Алгоритмистика в реальности это самый нижний уровень дизайна ПО. Соответствественно при правильном проектировании и использовании TDD замена одного алгоритма на другой это самое дешевое, что может быть в архитектуре системы
AP
Ну тут всегда будут холиварить, т.к. есть два стула - enterprise и technical. Последний, например, никогда не согласится, что первый может выбирать технические решения и имеет для этого компетенцию.
Что забавно, первый тоже никогда не согласится, что второй может выбирать технические решения (потому что не учитывает кучу факторов, типа юридических, процессных, миссию компании, рынок и т.п.)
KG
Если бы это помогало. Алгоритмистика в реальности это самый нижний уровень дизайна ПО. Соответствественно при правильном проектировании и использовании TDD замена одного алгоритма на другой это самое дешевое, что может быть в архитектуре системы
ну я не про конкретные алгоритмы, а скорее про подход к решению общих задач, которые есть в любой ИС
KG
ну это все лирика
AS
ну я не про конкретные алгоритмы, а скорее про подход к решению общих задач, которые есть в любой ИС
Это называется паттерны. Для этого другие книжки есть.
KG
что такое хеш таблицы и зачем их применять. не паттерны
AK
Что забавно, первый тоже никогда не согласится, что второй может выбирать технические решения (потому что не учитывает кучу факторов, типа юридических, процессных, миссию компании, рынок и т.п.)
таки да. в итоге это всё остаётся на откуп управленцев повыше, которые решают как них в конторе будет принято, единых стандратов нет
KG
мне вот эти ваши фасады вобще не интересны