Это, конечно, очень репрезентативно взять опыт одного человека (предвзятый, судя по первому сообщению) пятилетней давности и экстраполировать на компанию в 40К человек.
"не вижу ничего уникального в его опыте и он очень легко и хорошо растет в ширину" – а это так вообще песня :)
Привет,
статья интересная. Сразу видна ищущая душа и хороший опыт в разработке.
Для полного ответа нужно писать хорошую статью. Попробую сделать это к/за выходные.
Если же коротко (дальше будет критика и помидоры), то статья написана программистом, хорошим Lead разработчиком, но еще не архитектором.
Было принято вагон решений, практически в каждом абзаце, но они необоснованны. Но я даже больше больше скажу: их невозможно обосновать в данных условиях.
Почему? Нету требований. Особенно нефункциональных (те самые Quality Attributes: https://msdn.microsoft.com/en-us/library/ee658094.aspx).
Без нефункциональных требований (NFR) практически любая архитектура подойдет для озвученной задачи.
С точки зрения снижения стоимости: девушка на телефоне с журналом заявок (даже не экселькой) подходит. Вот и Solution. Забирай, мне не жалко.
Косвенно про NFR было сказано только в секции «Добавление нового типа транспорта в систему». Quality Attribute (QA) называет Modifiability. Рассмотрены два варианта: Runtime configuration и Development. Вариантов намного больше: https://image.slidesharecdn.com/sap3chapter7-140630124448-phpapp02/95/software-architecture-in-practice-chapter-7-4-638.jpg (картинка из Software Architecture in Practice. Обратите внимание на Artifacts (это то, что меняется) и Environment (это когда меняется).
Так же упоминается выбор языка программирования (Conceptual Integrity, Maintainability, Reusability), Отказоустойчивость (Availability и Reliability), мониторинг и логирование (Supportability),… Но без конкретики работать с этим нельзя.
Второй момент — непонятно как вы будете зарабатывать деньги, а если уйти от денег, то как конкретно вы будете приносить пользу клиентам. Т.е. нет описания, хоть поверхностного, бизнесс модели. Без этого есть только система (неважно насколько хорошая), в которую вложили кучу бабла, но еще не поняли как зарабатывать на ней.
Если коротко (еще короче чем выше):
Когда будешь задумываться о нефункциональных требованиях — станешь на путь к System Architect-ору.
Когда будешь задумываться о бизнесе и пользе клиентам — станешь на путь к Solution Architect-ору.
Литература для расширения сознания:
Книга Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives-ebook/dp/B0061LAKW0
В ней про NFR и работу с бизнесом.
Видео: Евгений Кривошеев — Как не угробить архитектуру сразу же https://www.youtube.com/watch?v=_Kex5hwGE-w
В ней как раз о решениях, которые принимает архитектор. Очень доступно.
Видео: Who is solution architect? — Architecture Community Gomel https://www.youtube.com/watch?v=oNFGvEiPFoU
Моя презентация про Solution Architect. В ней тоже про решения и роль архитектора на проекте.
Какая позиция у человека из Киевского EPAM, не подскажете?
class/struct — это уровень Middle/Senior Developer, возможно, Lead Developer. Хотя Lead должен разбираться с интеграциями и понимать варианты как это можно сделать.
> Обучение вещь полезная, но когда учитель имеет больше знаний.
К счастью, таких людей в ЕПАМ достаточно.
Например у меня ментор (программа SA Mentoring) у которого знаний и опыта много больше, чем у меня и мне есть чему поучиться.
SA University позволил систематизировать уже накопленные знания и познакомиться с подходами и Reference Architectures смежных Business Domains и дисциплин.
В феврале я начинаю вести SA School в Гомеле (первый запуск в нашей локации), знакомлюсь с материалами. Материалы очень грамотные и неплохо проработаны. Самому интересно разбираться. Помогает систематизировать знания.
Привет Саша! akava топики назовет ближе к концу недели, как определимся с датой (сейчас думаем между 24 ноября и 1 декабря, все зависит от того успеем ли мы с организацией к 24му).
Хотя,… кто мне мешает тут написать, все равно они известны уже несколько недель) Лови:
• [Theory] Andrei Kavaleu. Who is Solution Architect
• [Technology] Pilip Yaromenka. Essentials for good search engine: content is first, coding is second
• [Case Study] Mikalai Zubok. Customer feedback analysis with advanced technologies
Спасибо! Жаль не подходит по 3му пункту: минимум затрат на поддержку платформы.
А так бы я какой-нибудь workdpress выбрал в качестве платформы для комьюнити.
Архитектурные конференции и сообщества есть и их много, но не у нас, скажем в СНГ, а на западе.
У нас их действительно мало, но они тоже есть. Из конференций сразу же вспоминается недавний Highload++
Сообщества не назову, но иногда проскакивают видео с архитектурных встреч разработчиков. Обычно это Москва.
Хорошие конференции:
https://www.infoq.com/qcon/
http://conferences.oreilly.com/software-architecture/
И дальше по списку: https://www.google.by/search?q=architecture+conference
Да, хотя вход на конференцию и свободный, но все же по приглашению.
Наши сотрудники сейчас заняты проведением IT Week внутри EPAM (который плавно завершится конференцией), поэтому возможны задержки с подтверждением регистрации.
ещё момент, что EPAM в Минске и в Гомеле две разные вещи. штат/оплата/отделы и т.д.
У вас устаревшая информация :)
Понятно, что зарплаты разные — в Минске жизнь дороже и больше конкуренция.
Понятно что штат отличается — 5 000 в Минске против 400 в Гомеле.
Но проекты, отделы,… это все зависит от нас самих, от той работы которую мы можем сами потянуть. Гомельский офис растет, что позволяет нам брать более сложные и интересные проекты.
Например, .net отдел вырос за последние годы до 35 человек и все еще растет.
Так же сильно развивается архитектурное направление (за развитие которого в Гомеле я отвечаю).
Потому что хорошая мысль разместить новость на Хабре возникла только вчера вечером) Свяжусь с ребятами, которые владеют корпоративным блогом, попробую перенести этот пост туда.
EPAM, это не только Жава. Я, например, .net-чик. Есть ребята пишущие на Python, Ruby, у нас сильный UXD департмент (javascript, frontend). Для платформ как e-commerce, adobe marketing cloud,… вопрос языка вторичен (хотя там скорее всего жава).
Конкретно по конференции: доклад, связанный с Жава только один: SOA в проекте онлайн покупки авиа билетов. Да и тот, больше к архитектуре относится, чем к Жава.
Полностью согласен! Люблю IT конференции, тем более те, ради которых не нужно ехать в другой город :)
О конференции было объявлено еще месяц назад через социальные сети и IT площадки Белоруссии.
Хорошая мысль опубликовать новость на Хабре возникла всего лишь на этих выходных.
Для тех кто не сможет придти будет доступна запись. В следующем году мы планируем провести еще одну конференцию.
У каждого ситуация индивидуальна. Могу поделиться своей.
Если коротко, то я бился-бился о потолок. Пробил и обнаружил целую магистраль развития.
Стал развивать это направление не меняя работы, узнал, что в соседней фирме люди делают то же самое и поменял работу. Сейчас полон энтузиазма. А главное, я снова на первом этапе нового витка (+ вернулся на четвертый старого).
Спасибо. Залил ему одну из своих статей.
Оказалось что не каждый текст хорошо воспринимается таким образом.
Например, следующий кусок не воспринялся вообще, хотя его писал я сам и он неплохо воспринимается в тексте:
Разработали, оттестировали на рабочей машине, на тестовом сервере, выкатили на продакшен и… ничего. Программа данные не качает, молчит, а через некоторое время валится с ошибкой.
Наверное, дело в том, что в этом предложении мало связи между словами, что важно для методики.
Похоже тексты для нее нужно будет специально готовить.
У меня приходят с моего номера (типа я сам себе его отправил), но, возможно, это первые дни после регистрации. Ибо:
Сообщения на собственный номер: Так как эти сообщения бесплатные для вас (но платные для нас), мы отправляем их по дешевым каналам. Если ваш номер в МТС, Билайн, Мегафон, то сообщения к вам могут приходить от случайных номеров телефонов.
Это, конечно, очень репрезентативно взять опыт одного человека (предвзятый, судя по первому сообщению) пятилетней давности и экстраполировать на компанию в 40К человек.
"не вижу ничего уникального в его опыте и он очень легко и хорошо растет в ширину" – а это так вообще песня :)
статья интересная. Сразу видна ищущая душа и хороший опыт в разработке.
Для полного ответа нужно писать хорошую статью. Попробую сделать это к/за выходные.
Если же коротко (дальше будет критика и помидоры), то статья написана программистом, хорошим Lead разработчиком, но еще не архитектором.
Было принято вагон решений, практически в каждом абзаце, но они необоснованны. Но я даже больше больше скажу: их невозможно обосновать в данных условиях.
Почему? Нету требований. Особенно нефункциональных (те самые Quality Attributes: https://msdn.microsoft.com/en-us/library/ee658094.aspx).
Без нефункциональных требований (NFR) практически любая архитектура подойдет для озвученной задачи.
С точки зрения снижения стоимости: девушка на телефоне с журналом заявок (даже не экселькой) подходит. Вот и Solution. Забирай, мне не жалко.
Косвенно про NFR было сказано только в секции «Добавление нового типа транспорта в систему». Quality Attribute (QA) называет Modifiability. Рассмотрены два варианта: Runtime configuration и Development. Вариантов намного больше: https://image.slidesharecdn.com/sap3chapter7-140630124448-phpapp02/95/software-architecture-in-practice-chapter-7-4-638.jpg (картинка из Software Architecture in Practice. Обратите внимание на Artifacts (это то, что меняется) и Environment (это когда меняется).
Так же упоминается выбор языка программирования (Conceptual Integrity, Maintainability, Reusability), Отказоустойчивость (Availability и Reliability), мониторинг и логирование (Supportability),… Но без конкретики работать с этим нельзя.
Второй момент — непонятно как вы будете зарабатывать деньги, а если уйти от денег, то как конкретно вы будете приносить пользу клиентам. Т.е. нет описания, хоть поверхностного, бизнесс модели. Без этого есть только система (неважно насколько хорошая), в которую вложили кучу бабла, но еще не поняли как зарабатывать на ней.
Если коротко (еще короче чем выше):
Когда будешь задумываться о нефункциональных требованиях — станешь на путь к System Architect-ору.
Когда будешь задумываться о бизнесе и пользе клиентам — станешь на путь к Solution Architect-ору.
Литература для расширения сознания:
Книга Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives-ebook/dp/B0061LAKW0
В ней про NFR и работу с бизнесом.
Видео: Евгений Кривошеев — Как не угробить архитектуру сразу же https://www.youtube.com/watch?v=_Kex5hwGE-w
В ней как раз о решениях, которые принимает архитектор. Очень доступно.
Видео: Who is solution architect? — Architecture Community Gomel https://www.youtube.com/watch?v=oNFGvEiPFoU
Моя презентация про Solution Architect. В ней тоже про решения и роль архитектора на проекте.
class/struct — это уровень Middle/Senior Developer, возможно, Lead Developer. Хотя Lead должен разбираться с интеграциями и понимать варианты как это можно сделать.
> Обучение вещь полезная, но когда учитель имеет больше знаний.
К счастью, таких людей в ЕПАМ достаточно.
Например у меня ментор (программа SA Mentoring) у которого знаний и опыта много больше, чем у меня и мне есть чему поучиться.
SA University позволил систематизировать уже накопленные знания и познакомиться с подходами и Reference Architectures смежных Business Domains и дисциплин.
В феврале я начинаю вести SA School в Гомеле (первый запуск в нашей локации), знакомлюсь с материалами. Материалы очень грамотные и неплохо проработаны. Самому интересно разбираться. Помогает систематизировать знания.
akava топики назовет ближе к концу недели, как определимся с датой (сейчас думаем между 24 ноября и 1 декабря, все зависит от того успеем ли мы с организацией к 24му).
Хотя,… кто мне мешает тут написать, все равно они известны уже несколько недель) Лови:
• [Theory] Andrei Kavaleu. Who is Solution Architect
• [Technology] Pilip Yaromenka. Essentials for good search engine: content is first, coding is second
• [Case Study] Mikalai Zubok. Customer feedback analysis with advanced technologies
А так бы я какой-нибудь workdpress выбрал в качестве платформы для комьюнити.
У нас их действительно мало, но они тоже есть. Из конференций сразу же вспоминается недавний Highload++
Сообщества не назову, но иногда проскакивают видео с архитектурных встреч разработчиков. Обычно это Москва.
Хорошие конференции:
https://www.infoq.com/qcon/
http://conferences.oreilly.com/software-architecture/
И дальше по списку: https://www.google.by/search?q=architecture+conference
Наши сотрудники сейчас заняты проведением IT Week внутри EPAM (который плавно завершится конференцией), поэтому возможны задержки с подтверждением регистрации.
У вас устаревшая информация :)
Понятно, что зарплаты разные — в Минске жизнь дороже и больше конкуренция.
Понятно что штат отличается — 5 000 в Минске против 400 в Гомеле.
Но проекты, отделы,… это все зависит от нас самих, от той работы которую мы можем сами потянуть. Гомельский офис растет, что позволяет нам брать более сложные и интересные проекты.
Например, .net отдел вырос за последние годы до 35 человек и все еще растет.
Так же сильно развивается архитектурное направление (за развитие которого в Гомеле я отвечаю).
Конкретно по конференции: доклад, связанный с Жава только один: SOA в проекте онлайн покупки авиа билетов. Да и тот, больше к архитектуре относится, чем к Жава.
Полностью согласен! Люблю IT конференции, тем более те, ради которых не нужно ехать в другой город :)
О конференции было объявлено еще месяц назад через социальные сети и IT площадки Белоруссии.
Хорошая мысль опубликовать новость на Хабре возникла всего лишь на этих выходных.
Для тех кто не сможет придти будет доступна запись. В следующем году мы планируем провести еще одну конференцию.
Если коротко, то я бился-бился о потолок. Пробил и обнаружил целую магистраль развития.
Стал развивать это направление не меняя работы, узнал, что в соседней фирме люди делают то же самое и поменял работу. Сейчас полон энтузиазма. А главное, я снова на первом этапе нового витка (+ вернулся на четвертый старого).
Я уже писал об этом на хабре. Возможно вам пригодится.
Андрей
Оказалось что не каждый текст хорошо воспринимается таким образом.
Например, следующий кусок не воспринялся вообще, хотя его писал я сам и он неплохо воспринимается в тексте:
Наверное, дело в том, что в этом предложении мало связи между словами, что важно для методики.
Похоже тексты для нее нужно будет специально готовить.
Если вы автор этого модуля, то спасибо за него.
ПС: 375 это беларусь.
Я, с вашего позволения, воспользуюсь текстом о sms.ru с вашего поста.