Откуда можно черпать знания по архитектуре?
Постом выше я скинул видео где есть список того, что должен знать солюшин архитектор. Давайте немного о том, как организовать процесс развития.
Классификация
1. Базовые знания (или "база") - Теория программирования, Информатика, Языки программирования, устройство ОС, системы хранения данных и т.д.
2. Технические навыки (или "опыт") - это углубление знаний и реальный опыт работы, автоматизация своих навыков, развитие "ощущения" языка программирования, когда вы понимаете где "хорошо", "где плохо" и т.д.
3. Специализированные знания (или "специализация") - это когда вы находите конкретную область, которая вам интересна и получаете знания, которые релевантны только в этой области, они могут быть как технические, так и бизнесовые
4. Архитектурная карьера - карьерный переход из разработчика в Архитекторы, приоритет на проектирование и построение системы в целом, а не на детали.
Абстрактные советы
1. База
Базовые знания проще всего получать по готовым программам (ВУЗы, Курсы), имея на руках программу для изучения, можно подобрать книги для самостоятельного обучения, а можно пойти на курсы или в ВУЗ. Мой совет - ВУЗ с хорошими отзывами.
ВУЗ не отменяет дополнительно самообразование через литературу.
Самая большая проблема - как найти годные ВУЗы, Курсы и книги. Тут нет простых решений, наверное, проще всего искать единомышленников, вступать в сообщества, читать тематические группы, чтобы получить разные отзывы. Есть готовые подборки книг, которые можно искать поиском.
Построение базы занимает от 3-5 лет.
2. Опыт
Теория без практики мертва. Поэтому важно продумать свой карьерный план - найти перспективные компании, которые интересны, понять как требования для трудоустройства, с учетом этого расставить приоритеты изучения по "Базе". Соответственно иметь примерный план развития, на 1-2 года, в процессе которых пытаться искать работу.
Опыт нужен для закрепления навыков разработчика, развития аналитического и абстрактного мышления и т.д. Желательно менять специфику работы, углубляя знания и умения, которые есть.
Стандартная карьерная лестница джун - мидл - сеньер, где каждый уровень 1-2 года, т.е. при хорошей Базе, и нормальной работе можно за 5 лет дорасти до сеньера.
3. Специализация
Важно понять чем конкретно хочется заниматься, понять какая специфика есть в работе, которую выполняешь. Примеры специализаций - банковские системы, интернет магазины, системы мониторинга, навигационные системы и т.д.
Поняв специфику, определить ключевые моменты: какие теоретические знания надо иметь, какие инструменты надо знать, где и как научиться работать с этими инструментами.
4. Архитектура
Карьерный переход - самое сложное, нужно искать возможность перейти из состояния "разработчик" в состояние "архитектор" и это почти всегда "случай". Нужно иметь настрой, транслировать свое желание быть архитектором окружающим, подтягивать свою компетенцию и всячески максимизировать свои шансы стать архитектором.
Конкретика
- Для базовой подготовки хороши курсы CS50, SICP, книги Таненбаума, Маконнела, Роберта Мартина.
- Для развития опыта - МЯСО (МейлРу, Яндекс, Сбер, Озон), системные интеграторы (ИБС, Фактор-ТС и другие, где есть неплохой карьерный рост), государственный сектор (например, ГОСУСЛУГИ), либо компании с историей 5-10 лет и прозрачной карьерной составляющей
- Для быстрого старта, можно рассмотреть всякие буткемпы аля Школа 21
- Для изучения архитектуры см список книг ниже.
Архитектура ПО (первые шаги)
Clean Architecture (Robert C. Martin)
Domain Driven Design (Vaughn Vernon)
Architecting for Scale (Lee Atchison)
Software system architecture (Nick Rozanski, Eoin Woods)
Применение UML 2.0 и шаблонов проектирования (Крэг Ларман)
Monolith to Microservices. Evolutionary Patterns to Transform Your Monolith (Sam Newman)
Software Architecture in practice (Len Bass, Paul Clements, Rick Kazman)
Software Architect's Handbook: Become a successful software architect by implementing effective architecture concepts (Joseph Ingeno)
Постом выше я скинул видео где есть список того, что должен знать солюшин архитектор. Давайте немного о том, как организовать процесс развития.
Классификация
1. Базовые знания (или "база") - Теория программирования, Информатика, Языки программирования, устройство ОС, системы хранения данных и т.д.
2. Технические навыки (или "опыт") - это углубление знаний и реальный опыт работы, автоматизация своих навыков, развитие "ощущения" языка программирования, когда вы понимаете где "хорошо", "где плохо" и т.д.
3. Специализированные знания (или "специализация") - это когда вы находите конкретную область, которая вам интересна и получаете знания, которые релевантны только в этой области, они могут быть как технические, так и бизнесовые
4. Архитектурная карьера - карьерный переход из разработчика в Архитекторы, приоритет на проектирование и построение системы в целом, а не на детали.
Абстрактные советы
1. База
Базовые знания проще всего получать по готовым программам (ВУЗы, Курсы), имея на руках программу для изучения, можно подобрать книги для самостоятельного обучения, а можно пойти на курсы или в ВУЗ. Мой совет - ВУЗ с хорошими отзывами.
ВУЗ не отменяет дополнительно самообразование через литературу.
Самая большая проблема - как найти годные ВУЗы, Курсы и книги. Тут нет простых решений, наверное, проще всего искать единомышленников, вступать в сообщества, читать тематические группы, чтобы получить разные отзывы. Есть готовые подборки книг, которые можно искать поиском.
Построение базы занимает от 3-5 лет.
2. Опыт
Теория без практики мертва. Поэтому важно продумать свой карьерный план - найти перспективные компании, которые интересны, понять как требования для трудоустройства, с учетом этого расставить приоритеты изучения по "Базе". Соответственно иметь примерный план развития, на 1-2 года, в процессе которых пытаться искать работу.
Опыт нужен для закрепления навыков разработчика, развития аналитического и абстрактного мышления и т.д. Желательно менять специфику работы, углубляя знания и умения, которые есть.
Стандартная карьерная лестница джун - мидл - сеньер, где каждый уровень 1-2 года, т.е. при хорошей Базе, и нормальной работе можно за 5 лет дорасти до сеньера.
3. Специализация
Важно понять чем конкретно хочется заниматься, понять какая специфика есть в работе, которую выполняешь. Примеры специализаций - банковские системы, интернет магазины, системы мониторинга, навигационные системы и т.д.
Поняв специфику, определить ключевые моменты: какие теоретические знания надо иметь, какие инструменты надо знать, где и как научиться работать с этими инструментами.
4. Архитектура
Карьерный переход - самое сложное, нужно искать возможность перейти из состояния "разработчик" в состояние "архитектор" и это почти всегда "случай". Нужно иметь настрой, транслировать свое желание быть архитектором окружающим, подтягивать свою компетенцию и всячески максимизировать свои шансы стать архитектором.
Конкретика
- Для базовой подготовки хороши курсы CS50, SICP, книги Таненбаума, Маконнела, Роберта Мартина.
- Для развития опыта - МЯСО (МейлРу, Яндекс, Сбер, Озон), системные интеграторы (ИБС, Фактор-ТС и другие, где есть неплохой карьерный рост), государственный сектор (например, ГОСУСЛУГИ), либо компании с историей 5-10 лет и прозрачной карьерной составляющей
- Для быстрого старта, можно рассмотреть всякие буткемпы аля Школа 21
- Для изучения архитектуры см список книг ниже.
Архитектура ПО (первые шаги)
Clean Architecture (Robert C. Martin)
Domain Driven Design (Vaughn Vernon)
Architecting for Scale (Lee Atchison)
Software system architecture (Nick Rozanski, Eoin Woods)
Применение UML 2.0 и шаблонов проектирования (Крэг Ларман)
Monolith to Microservices. Evolutionary Patterns to Transform Your Monolith (Sam Newman)
Software Architecture in practice (Len Bass, Paul Clements, Rick Kazman)
Software Architect's Handbook: Become a successful software architect by implementing effective architecture concepts (Joseph Ingeno)
🔥95👍20❤7😁3
Субботний стрим 04.11 10:00
Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:
- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают
В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.
Так же можно скинуть ссылки на свои репо, которые я могу посмотреть в прямом эфире и сказать мнение о коде и архитектуре, так же можно скинуть новость или ссылку на ютуб ролик, который можно обсудить в Сплетнях.
Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:
- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают
В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.
Так же можно скинуть ссылки на свои репо, которые я могу посмотреть в прямом эфире и сказать мнение о коде и архитектуре, так же можно скинуть новость или ссылку на ютуб ролик, который можно обсудить в Сплетнях.
👍12
Чистая архитектура на frontend. Что это такое? Особенности, преимущества и недостаткиИнтересный вопрос. Не знаю проголосуют ли за него, чтобы я разобрал на стриме. Но мне кажется в отношении чистой архитектуры нужно понять следующие моменты.
1. Основная идея чистой архитектуры - это управление зависимостями таким образом, чтобы изолировать бизнеслогику от всего кроме непосредственно бизнес-фич
2. Изоляция выполняется через создание интерфейсов, которые формируют границы модулей и позволяют выстраивать логику внутри модуля
3. Роберт Мартин считает, что уровень абстракции тем выше, чем дальше от ввода/вывода данных он находится, таким образом в чистой архитектуре бизнес логика должна быть слабо зацеплена на ввод/вывод
4. Поток управления может не совпадать с зависимостями, а по факту не будет совпадать, так как вызов функций всегда идет между вводом и выводом, посредством слоя бизнес-логики
5. Ядром архитектуры являются - варианты использования и сущности, которые окружены инфраструктурными и управленчискими конструкциями
Таким образом, чтобы фронтенд соотвествовал чистой архитектуре необходимо выполнить следующие шаги:
1. выделить бизнес-логику в виде сущностей и вариантов использования
2. изолировать бизнес логику от низкого уровня (а именно ввод/вывод, проверка и очистка данных)
3. выделить интерфейсы для взаимодействия низкого и высокого уровня абстракции (интерфейсы нужно выделять со стороны бизнес-логики)
4. Для преодоления границы через интерфейсы разработать DTO, которые необходимы только для переноса данных (короткий срок жизни)
5. Сформировать инфраструктурные и управленческие функции отдельно от БЛ
В зависимости от фреймворка можно делать по-разному, например, в ангуляре модуль уже является достаточно изолированным, с сильной границей, поэтому там нужно просто сформировать модули БЛ и инфраструктурные так, чтобы они были отделены друг от друга, а общались посредством интерфейсов.
В реакте наоборот, нужно продумать каким образом провести границы, так чтобы удовлетворять условиям выше.
Но в целом чистая архитектура бэкнеда не сильно отличается от чистой архитектуры фронтенда, обычно границы хорошо видны по файловой структуре проекта, различия есть в источниках данных (БД или HTTP-API) и нюансах инфраструктуры.
🔥49👍10⚡2
Нужно ли версионировать API, если разработка веб-приложения идет в монорепозитории?
Anonymous Poll
48%
Да, изменения API должны отражаться в его версии
12%
Нет, есть актуальный API без версии который все используют
39%
Зависит от ситуации
🤔5
Поднялись сервисы, у меня не работала Яндекс музыка и Яндекс.360, минут 30 где-то
😁23🎉8😱3🔥2🤣1👨💻1
Субботний стрим 11.11 10:00
Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:
- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают
В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.
Так же можно скинуть ссылки на свои репо, которые я могу посмотреть в прямом эфире и сказать мнение о коде и архитектуре, так же можно скинуть новость или ссылку на ютуб ролик, который можно обсудить в Сплетнях.
Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:
- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают
В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.
Так же можно скинуть ссылки на свои репо, которые я могу посмотреть в прямом эфире и сказать мнение о коде и архитектуре, так же можно скинуть новость или ссылку на ютуб ролик, который можно обсудить в Сплетнях.
👍8
Чем занимаются программисты на рабочих местах
В 1994 году была опубликована интересная статья "people organizations and process improvement", в которой авторы рассказывали о результатах исследования по анализу рабочего времени программиста.
Не буду приводить детали исследования, статью легко нагуглить по названию.
Но самое интересное, что написание кода составляло в среднем 40% от рабочего дня программиста. А в оставшееся время программисты тратили огромное количество времени на коммуникации с другими программистами. Причем, основные вопросы - "как работает этот код?", "почему мы приняли такое решение?" т.е. получение информации из коллективного разума проекта, которая редко документируется.
Что-то мне подсказывает, что за более чем 25 лет, прошедших с того времени, особых изменений в процентном соотношении не произошло.
Несмотря на бурное развитие интернета, он по-прежнему не может ответить на вопросы как работает код в нашем проекте, почему принято то или иное решение.
И по-прежнему документирование - это не самая сильная сторона большинства проектов.
А сколько времени в вашем рабочем дне занимает общение с другими программистами?
В 1994 году была опубликована интересная статья "people organizations and process improvement", в которой авторы рассказывали о результатах исследования по анализу рабочего времени программиста.
Не буду приводить детали исследования, статью легко нагуглить по названию.
Но самое интересное, что написание кода составляло в среднем 40% от рабочего дня программиста. А в оставшееся время программисты тратили огромное количество времени на коммуникации с другими программистами. Причем, основные вопросы - "как работает этот код?", "почему мы приняли такое решение?" т.е. получение информации из коллективного разума проекта, которая редко документируется.
Что-то мне подсказывает, что за более чем 25 лет, прошедших с того времени, особых изменений в процентном соотношении не произошло.
Несмотря на бурное развитие интернета, он по-прежнему не может ответить на вопросы как работает код в нашем проекте, почему принято то или иное решение.
И по-прежнему документирование - это не самая сильная сторона большинства проектов.
А сколько времени в вашем рабочем дне занимает общение с другими программистами?
👍56💯10
Через 10 минут начинаю стрим для подписчиков уровня Stream и выше.
Подключиться онлайн можно используя ссылку "Активный архитектурный стрим" https://platform.soer.pro/#!/pages/overview/info
Так же завтра стрим появится в записи в разделе "Материалы" на платформе
Подключиться онлайн можно используя ссылку "Активный архитектурный стрим" https://platform.soer.pro/#!/pages/overview/info
Так же завтра стрим появится в записи в разделе "Материалы" на платформе
👍6🤡4😁1
Сегодня на стриме поговорили про игру для обучения программированию Cyber Cat, вот группа в телеге для тех кто хочет принять участие в разработке игры - https://t.iss.one/+WriN-NDOL_5jYjZi
👍7🤡1
Изучаем DDD
Предметно-ориентированнре проектирование
Влад Хононов
Если сранивать "DDD самое основное" и книгу от Влада, то при сопоставимом объеме книга Влада гораздо полезнее. Мне понравилось, что есть примеры стратегического проектирования на основы поддоменов, с нормальным объяснением чем core от универсального домена отличается.
Понравилось, что приведены основные паттерны для тактического проектирования. Хорошо объяснено про ограничения Transaction Script.
Не очень понравилось как объяснены доменные события и описаны трех-слойная и порты и адаптеры архитектуры, как-то скомкано, без достаточного количества примеров.
По поводу EventSourcing основное сказано, дана оценка по нагрузке и типовые вопросы, все четко и по делу.
В эволюции проектных решений мне не хватило примеров, но в приложениях есть описание примеров использования DDD, что частично компенсирует.
В целом впечатление хорошее - книга годная, охватывает основные вопросы, скорее всего придется еще поискать доп. инфу, но зато как справочник - идеально.
#DDD #книга #отзыв
Предметно-ориентированнре проектирование
Влад Хононов
Если сранивать "DDD самое основное" и книгу от Влада, то при сопоставимом объеме книга Влада гораздо полезнее. Мне понравилось, что есть примеры стратегического проектирования на основы поддоменов, с нормальным объяснением чем core от универсального домена отличается.
Понравилось, что приведены основные паттерны для тактического проектирования. Хорошо объяснено про ограничения Transaction Script.
Не очень понравилось как объяснены доменные события и описаны трех-слойная и порты и адаптеры архитектуры, как-то скомкано, без достаточного количества примеров.
По поводу EventSourcing основное сказано, дана оценка по нагрузке и типовые вопросы, все четко и по делу.
В эволюции проектных решений мне не хватило примеров, но в приложениях есть описание примеров использования DDD, что частично компенсирует.
В целом впечатление хорошее - книга годная, охватывает основные вопросы, скорее всего придется еще поискать доп. инфу, но зато как справочник - идеально.
#DDD #книга #отзыв
👍75❤5
Важное дополнение, как заметили в чате, книга не совсем про ddd, больше чем на половину она включает дополнительные архитектурные темы и шаблоны, но объясняются они через призму ddd.
Мне кажется это гуд, потому что это решает проблему "к пуговицам вопросы есть? Нет? Ну тогда остальное ваши проблемы." Т.е. книга помогает понять не только "что такое ddd", но и помочь в его использовании.
Кстати, Влад правильно высказался про культ "анемичных моделей", за это книге отдельный респект.
Мне кажется это гуд, потому что это решает проблему "к пуговицам вопросы есть? Нет? Ну тогда остальное ваши проблемы." Т.е. книга помогает понять не только "что такое ddd", но и помочь в его использовании.
Кстати, Влад правильно высказался про культ "анемичных моделей", за это книге отдельный респект.
👍45🔥1
"Найду первую работу, а там попрет" - это тот план, который надо сразу выкинуть из головы.
Во-первых, потому что скорее всего не попрет, во-вторых, после устройства на работу самые сложные задачи только появятся.
Рынок устроен так, что 80% сами ищут работу, а 20% приглашают (хантят). Поэтому основная задача попасть из первой группы во вторую.
Если план в том, чтобы всегда искать работу, то вы ставите себя в позицию "ну возьмите меня", а это очень плохо работает на длинной дистанции. Потому что уже на первой работе вы рискуете застрять на полжизни (хороший коллектив, привычные таски, страх что-то менять - это сильно вас затормозит, уж поверьте).
Ну ок, допустим вас взяли на работу, прописали должностные (если вам повезло попасть в нормальное место, где есть должностные), дали хороший оклад и вроде бы жизнь удалась. Но оказывается, что ровно с этого момента вы начали активно деградировать, потому что все новое что вы изучаете - это корпоративные задачи и вещи, выгодные вашему работодателю.
Первое время вам еще предлагают линейные переходы (с мидла, на мидла) и вроде как иллюзия выбора есть. Но через некоторое время и эти предложения иссякнут.
Есть иллюзия, что могут повысить, ведь компания заинтересована в развитии своих сотрудников! Но на практике вы пытаетесь пробиться сквозь менеджмент, который обещает, говорит какой вы молодец, до тех пор пока вы не устанете и не забьете на всякие попытки доказать что хороши.
Никому не надо повышать сотрудников просто так, никому не надо развивать вас как специалиста сверх тех требований, которые есть в компании. Никому кроме вас не интересно качать вашу карьеру и просто устроившись на работу вы не решите следующую задачу - как расти по карьере.
Во-первых, потому что скорее всего не попрет, во-вторых, после устройства на работу самые сложные задачи только появятся.
Рынок устроен так, что 80% сами ищут работу, а 20% приглашают (хантят). Поэтому основная задача попасть из первой группы во вторую.
Если план в том, чтобы всегда искать работу, то вы ставите себя в позицию "ну возьмите меня", а это очень плохо работает на длинной дистанции. Потому что уже на первой работе вы рискуете застрять на полжизни (хороший коллектив, привычные таски, страх что-то менять - это сильно вас затормозит, уж поверьте).
Ну ок, допустим вас взяли на работу, прописали должностные (если вам повезло попасть в нормальное место, где есть должностные), дали хороший оклад и вроде бы жизнь удалась. Но оказывается, что ровно с этого момента вы начали активно деградировать, потому что все новое что вы изучаете - это корпоративные задачи и вещи, выгодные вашему работодателю.
Первое время вам еще предлагают линейные переходы (с мидла, на мидла) и вроде как иллюзия выбора есть. Но через некоторое время и эти предложения иссякнут.
Есть иллюзия, что могут повысить, ведь компания заинтересована в развитии своих сотрудников! Но на практике вы пытаетесь пробиться сквозь менеджмент, который обещает, говорит какой вы молодец, до тех пор пока вы не устанете и не забьете на всякие попытки доказать что хороши.
Никому не надо повышать сотрудников просто так, никому не надо развивать вас как специалиста сверх тех требований, которые есть в компании. Никому кроме вас не интересно качать вашу карьеру и просто устроившись на работу вы не решите следующую задачу - как расти по карьере.
👍130🤔10🔥8❤5👎5🤡5😁1💩1
"А как надо?"
А надо понять свою цель. Если цель устроиться на работу, то это плохая цель, потому что за не ничего нет. Не будет такого, что кто-то за вас начнет ставить новые цели.
Все начинается с момента когда вы начинаете хотеть чего-то еще, а не только "устроиться на работу". Когда появляется "хочу заниматься созданием умных устройств", "хочу строить сложные архитектурные проекты", потом надо разбивать цель на задачи (Event Storming) и когда появится ясность, чего вы хотите, тогда и планов "найду работу, а там как-нибудь что-нибудь придумаю" не будет.
А надо понять свою цель. Если цель устроиться на работу, то это плохая цель, потому что за не ничего нет. Не будет такого, что кто-то за вас начнет ставить новые цели.
Все начинается с момента когда вы начинаете хотеть чего-то еще, а не только "устроиться на работу". Когда появляется "хочу заниматься созданием умных устройств", "хочу строить сложные архитектурные проекты", потом надо разбивать цель на задачи (Event Storming) и когда появится ясность, чего вы хотите, тогда и планов "найду работу, а там как-нибудь что-нибудь придумаю" не будет.
👍59😁10🤡10❤3🔥3💩1
Я не говорю о том, что вы не должны устраиваться на работу. Я говорю о том, что устраиваясь на работу нужно понимать какая работа вам нужна, какие дальнейшие шаги вы будете делать, не засиживаться на уютном месте и т.д.
Самое главное "я пошел куда взяли" - это не стратегия. Вот о чем мои посты. А таких "планов" я встречаю каждый стрим по пять штук. Это не стратегия, не план, это просто "надежда", что все получится само собой.
Самое главное "я пошел куда взяли" - это не стратегия. Вот о чем мои посты. А таких "планов" я встречаю каждый стрим по пять штук. Это не стратегия, не план, это просто "надежда", что все получится само собой.
👍67🤡8🔥7💩1
Субботний стрим 25.11 10:00
Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:
- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают
В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.
Так же можно скинуть ссылки на свои репо, которые я могу посмотреть в прямом эфире и сказать мнение о коде и архитектуре, так же можно скинуть новость или ссылку на ютуб ролик, который можно обсудить в Сплетнях.
Начинаю сбор вопросов на завтрашний стрим, напоминаю, что у нас будет четыре секции:
- Зачем это надо? (ЗЭН)
- Годное чтиво (разбираем книгу корпоративных паттернов)
- Сплетни нашего ютуба
- Донаты решают
В комментарии к этому посту скиньте вопросы на ЗЭН, они должны касаться АйТи.
Так же можно скинуть ссылки на свои репо, которые я могу посмотреть в прямом эфире и сказать мнение о коде и архитектуре, так же можно скинуть новость или ссылку на ютуб ролик, который можно обсудить в Сплетнях.
🔥12👍3