Процесс цикличен и важно его осуществлять постепенно.
Во-вторых, цена перехода на микросервисы как правило очень высока, и если бизнес испытывает финансовые трудности, то переход только ухудшит ситуацию.
В-третьих, необходимо четко разделять обратимые и необратимые изменения, желательно планировать переход так, чтобы уменьшить количество необратимых изменений, хорошо продумать стратегию «отката» (касается технических решений).
Конкретные шаги для перехода:
1. Внедрение Domain Driver Design
2. Разделение работы на разумные части (знать когда стоит остановиться)
3. Понять сущности своего дизайна и его границы (Event Storming – техника bottom-up анализа при которой определяется доменные события и обсуждается их влияние на систему)
4. Приоритезация задач на основе доменной модели (самые «востребованные» части не следует брать в работу первыми)
5. Проработать «комбинированные» состояния (часть имеющегося в монолите передается на откуп микросервисам)
6. Реорганизация команды
7. Перевод структур
8. Вносите изменения, а не просто копируйте функциональность
9. Развивайте профессиональные навыки
10. Определите контрольные точки (по которым будем понятно, что движение идет в нужном направлении)
11. Определите качественные характеристики (должны быть измеримыми и достижимыми)
12. Проводите регулярные оценки качества
13. Старайтесь рассматривать варианты решений беспристрастно.
#monlith
Во-вторых, цена перехода на микросервисы как правило очень высока, и если бизнес испытывает финансовые трудности, то переход только ухудшит ситуацию.
В-третьих, необходимо четко разделять обратимые и необратимые изменения, желательно планировать переход так, чтобы уменьшить количество необратимых изменений, хорошо продумать стратегию «отката» (касается технических решений).
Конкретные шаги для перехода:
1. Внедрение Domain Driver Design
2. Разделение работы на разумные части (знать когда стоит остановиться)
3. Понять сущности своего дизайна и его границы (Event Storming – техника bottom-up анализа при которой определяется доменные события и обсуждается их влияние на систему)
4. Приоритезация задач на основе доменной модели (самые «востребованные» части не следует брать в работу первыми)
5. Проработать «комбинированные» состояния (часть имеющегося в монолите передается на откуп микросервисам)
6. Реорганизация команды
7. Перевод структур
8. Вносите изменения, а не просто копируйте функциональность
9. Развивайте профессиональные навыки
10. Определите контрольные точки (по которым будем понятно, что движение идет в нужном направлении)
11. Определите качественные характеристики (должны быть измеримыми и достижимыми)
12. Проводите регулярные оценки качества
13. Старайтесь рассматривать варианты решений беспристрастно.
#monlith
У себя в телеграмме Senior Software Vlogger размышляет о том, как мы медленно и верно обучаем роботов делать работу человек. Каптча от Гугл заставляет нас распознавать знаки, светофоры, используя эти знания для обучения своих нейронных сетей и создавая автопилоты.
Уже появляются проекты по автоматизации написания кода, они вроде как созданы помогать нам, но параллельно обучаются у нас же.
То что искусственный интеллект научится писать код это даже не вопрос, а вопрос "когда" он научится это делать. Я как-то уже рассуждал о том, что генерация программы путем полного перебора всех перестановок - это теоретически рабочий вариант, но слишком затратный по ресурсам и времени. Но если задача разрешима за конечное, пусть даже очень большое время, то остается вопрос можно ли ее оптимизировать. И пока складывается ощущение, что возможно.
Наиболее логичным шагом на ближайшее время мне видится замена юнит тестирования нейронными сетями. Например property-based тесты на базе AI. Почему нет? Без решения задачи по "проверке" корректности программы, задача по созданию кода мне кажется сомнительной. Так что ждем бум решений в области тестирования с помощью AI.
Пост Димы - https://news.1rj.ru/str/seniorsoftwarevlogger/650
Уже появляются проекты по автоматизации написания кода, они вроде как созданы помогать нам, но параллельно обучаются у нас же.
То что искусственный интеллект научится писать код это даже не вопрос, а вопрос "когда" он научится это делать. Я как-то уже рассуждал о том, что генерация программы путем полного перебора всех перестановок - это теоретически рабочий вариант, но слишком затратный по ресурсам и времени. Но если задача разрешима за конечное, пусть даже очень большое время, то остается вопрос можно ли ее оптимизировать. И пока складывается ощущение, что возможно.
Наиболее логичным шагом на ближайшее время мне видится замена юнит тестирования нейронными сетями. Например property-based тесты на базе AI. Почему нет? Без решения задачи по "проверке" корректности программы, задача по созданию кода мне кажется сомнительной. Так что ждем бум решений в области тестирования с помощью AI.
Пост Димы - https://news.1rj.ru/str/seniorsoftwarevlogger/650
Telegram
Senior Software Vlogger
В своей книге Who Owns the Future Джарон Ланье рассуждает о том, как компании использую неосознанный вклад людей, чтобы потом этих же людей заменить. Например, как автопилоты сейчас обучаются глядя на живых водителей.
Автор предлагает модель общества, в…
Автор предлагает модель общества, в…
Яндекс продолжает набор на оплачиваемую летнюю стажировку.
Важно: отлично проявившие себя стажеры получат шанс перейти в штат!
Направления: фронтенд- и бэкенд-разработка, машинное обучение, аналитика, мобильная разработка и другие — ознакомиться с ними можно здесь.
Особый формат стажировки — Deep Dive в Яндекс.Маркете.
Сколько длится: от трех до 6 месяцев.
Где: в Москве, Санкт-Петербурге, Екатеринбурге, Нижнем Новгороде, Новосибирске, Сочи, Симферополе и Минске.
Если вы из другого города — Яндекс оплатит дорогу и проживание в Москве.
Что нужно уметь: ждут отличного знания базовых алгоритмов и уверенных навыков программирования на одном из языков.
Как проходит отбор: зависит от направления, но в большинстве случаев нужно будет выполнить тестовое задание, пройти два-три технических интервью, а затем выбрать команду.
Подавайте заявку до 31 мая: https://clck.ru/TgiBN
Важно: отлично проявившие себя стажеры получат шанс перейти в штат!
Направления: фронтенд- и бэкенд-разработка, машинное обучение, аналитика, мобильная разработка и другие — ознакомиться с ними можно здесь.
Особый формат стажировки — Deep Dive в Яндекс.Маркете.
Сколько длится: от трех до 6 месяцев.
Где: в Москве, Санкт-Петербурге, Екатеринбурге, Нижнем Новгороде, Новосибирске, Сочи, Симферополе и Минске.
Если вы из другого города — Яндекс оплатит дорогу и проживание в Москве.
Что нужно уметь: ждут отличного знания базовых алгоритмов и уверенных навыков программирования на одном из языков.
Как проходит отбор: зависит от направления, но в большинстве случаев нужно будет выполнить тестовое задание, пройти два-три технических интервью, а затем выбрать команду.
Подавайте заявку до 31 мая: https://clck.ru/TgiBN
Young&&Yandex ― старт карьеры в Яндексе
Экосистема стажировок и образовательных проектов — можно попробовать себя в IT, прокачать навыки и начать работать в Яндексе
Стоит ли публиковать в этот канал аудио вариант видосов с S0ER TALKS?
Anonymous Poll
51%
Да
16%
Нет
33%
На твое усмотрение
Некоторые интересные моменты, которые стоит зафиксировать из книги Бугаенко "Elegant Objects":
- Не используйте "er" в имени классов (runner, doer и т.д.)
- "Тонкие конструкторы класса" - только инициализации, без логики
- Мелкие классы, лучше крупных (при рефакторинге объединять проще чем делить)
- Не используйте "er" в имени классов (runner, doer и т.д.)
- "Тонкие конструкторы класса" - только инициализации, без логики
- Мелкие классы, лучше крупных (при рефакторинге объединять проще чем делить)
- Максимум 5 публичных методов в классе (помните про комбинатоную сложность, чем больше публичных методов, тем больше комбинаций между классами, использующих эти методы)
- Не используйте статические методы
- Не используйте синглтоны
- Избегайте NULL
- Не используйте статические методы
- Не используйте синглтоны
- Избегайте NULL
С остальными советами не согласен, некоторые нужно доработать, некоторые просто странные.
Интересное обсуждение случилось в дискорде по поводу правила "не используйте -er в именах классов". И тут, видимо, нужны какие-то развернутые пояснения, но лучше чем автор, этого никто не сделает, поэтому посмотрите объяснения у Егора - https://www.yegor256.com/2015/03/09/objects-end-with-er.html
Yegor Bugayenko
Don't Create Objects That End With -ER
Object names that end with -er are indicators of a flawed design in terms of object thinking and should be avoided.
👍2
Ну а мое отношение такое - я считаю, что паттерны (например, Observer) и "поведение" могут быть реализованы через класс, но нужно быть осторожным, так как лучше придерживаться максимально "чистого" ООП и создавать объекты, которые действительно являются объектами, а не абстрактной логикой.
Рома Труфанов написал хороший пост в тему:
Trufanov Roman — Сегодня, в 13:18
Вброшу немного своего мнения xD
Вообще про суффиксы все сказанное кажется немного вырванным из контекста.
Тут нужно строго зафиксировать несколько моментов.
- Мы говорим про ООП, то бишь про объекты и их взаимодействия.
- Также нужно учитывать возможность языка программирования.
- И также нужно учитывать контекст в котором приходится работать.
Если говорить чуть точнее, то нету ничего плохого в использовании каких бы то не было суффиксов. Как по мне, основная проблема это неправильно подобранная абстракция. К примеру если у нас в коде есть класс с названием Manager, то совсем непонятно что это за менеджер такой. Это может быть роль, тогда в таком названии нету ничего особенного. Также это может быть название какой то сущности, о которой говорит заказчик, тут надуманно конечно, но к примеру менеджер = система, которая управляет заказами. А вот что недопустимо, это придумывать класс Менеджер, которого нету в бизнес домене совсем. Ну к примеру у нас есть какая то логика и где же ее нужно разместить, вот и придумывают Менеджеров, Процессеров и прочие -еров.
Что касается использования названий паттернов, то также не обязательно писать суффикс (Adapter, Factroy и т.д.). Помним, что паттерн это не цель, а это то, что уже проявляется в коде. К паттерну приходят либо во время проектирования, когда понимают, что взаимодействие объектов похоже на определенный паттерн. Либо во время рефакторинга, когда получившаяся структура начинает быть похожа на опять определенный паттерн. Вот не разу не было качественного решения, где бы брали и стали пытаться насильно достичь использования конкретных паттернов. Это всегда связано с решаемой задачей и текущей ситуацией в коде.
Trufanov Roman — Сегодня, в 13:18
Вброшу немного своего мнения xD
Вообще про суффиксы все сказанное кажется немного вырванным из контекста.
Тут нужно строго зафиксировать несколько моментов.
- Мы говорим про ООП, то бишь про объекты и их взаимодействия.
- Также нужно учитывать возможность языка программирования.
- И также нужно учитывать контекст в котором приходится работать.
Если говорить чуть точнее, то нету ничего плохого в использовании каких бы то не было суффиксов. Как по мне, основная проблема это неправильно подобранная абстракция. К примеру если у нас в коде есть класс с названием Manager, то совсем непонятно что это за менеджер такой. Это может быть роль, тогда в таком названии нету ничего особенного. Также это может быть название какой то сущности, о которой говорит заказчик, тут надуманно конечно, но к примеру менеджер = система, которая управляет заказами. А вот что недопустимо, это придумывать класс Менеджер, которого нету в бизнес домене совсем. Ну к примеру у нас есть какая то логика и где же ее нужно разместить, вот и придумывают Менеджеров, Процессеров и прочие -еров.
Что касается использования названий паттернов, то также не обязательно писать суффикс (Adapter, Factroy и т.д.). Помним, что паттерн это не цель, а это то, что уже проявляется в коде. К паттерну приходят либо во время проектирования, когда понимают, что взаимодействие объектов похоже на определенный паттерн. Либо во время рефакторинга, когда получившаяся структура начинает быть похожа на опять определенный паттерн. Вот не разу не было качественного решения, где бы брали и стали пытаться насильно достичь использования конкретных паттернов. Это всегда связано с решаемой задачей и текущей ситуацией в коде.
На прошлых выходных участвовал в митапе по обсуждению архитектуры,
такое ощущение, что все специально делают одни и те же ошибки.
такое ощущение, что все специально делают одни и те же ошибки.
Список проблем, который я делал для архитектурных стримов, по прежнему актуален:
1 полный игнор вопросов архитектуры (обычно вспоминают про архитектуру как про палочку-выручалочку когда уже «все плохо»);
2 неформализованные требования и ограничения;
3 отсутствие метрик качества и контроля;
4 приоритет наращивания функциональности (по сути увеличение прибыли, больше возможностей – больше продаж);
5 широкая вариативность повторного использования компонент, переусложненные компоненты с частичным использованием функциональности (одна и та же форма имеет несколько сценариев поведения, определяемых объектами-конфигураторами);
6 недостаток механизмов управления командой (нет разделения ответственности, «мы вам платим, вы нам делаете код»);
7 большое количество «ручного» труда, отсутствие сценариев автоматизации (СI/CD, DevOps);
8 несколько источников «правды» - кто-то пишет в почту, кто-то в мессенджер, кто-то что-то сказал на планерке, вопросы решаются на бегу;
9 отсутствие культуры и технологии разработки (команда преимущественно использует структурный подход к разработке, плохо понимает ООП, не понимает принципы изоляции и публичные интерфейсы, рефакторинг сводится к переименованию методов, а не к «прояснению» логики);
10 не фиксируется технический долг и он обычно уже большой;
11 разработчики плохо представляют что такое архитектура, не умеют мыслить в отрыве от когда, не понимают абстракций, имеют узкую квалификацию (слабое знание инженерных дисциплин);
12 Отсутствие тестирования, рефакторинга и прочих техник;
13 Проблемы при генерации и проверке гипотез (первое решение принимается как правильное).
1 полный игнор вопросов архитектуры (обычно вспоминают про архитектуру как про палочку-выручалочку когда уже «все плохо»);
2 неформализованные требования и ограничения;
3 отсутствие метрик качества и контроля;
4 приоритет наращивания функциональности (по сути увеличение прибыли, больше возможностей – больше продаж);
5 широкая вариативность повторного использования компонент, переусложненные компоненты с частичным использованием функциональности (одна и та же форма имеет несколько сценариев поведения, определяемых объектами-конфигураторами);
6 недостаток механизмов управления командой (нет разделения ответственности, «мы вам платим, вы нам делаете код»);
7 большое количество «ручного» труда, отсутствие сценариев автоматизации (СI/CD, DevOps);
8 несколько источников «правды» - кто-то пишет в почту, кто-то в мессенджер, кто-то что-то сказал на планерке, вопросы решаются на бегу;
9 отсутствие культуры и технологии разработки (команда преимущественно использует структурный подход к разработке, плохо понимает ООП, не понимает принципы изоляции и публичные интерфейсы, рефакторинг сводится к переименованию методов, а не к «прояснению» логики);
10 не фиксируется технический долг и он обычно уже большой;
11 разработчики плохо представляют что такое архитектура, не умеют мыслить в отрыве от когда, не понимают абстракций, имеют узкую квалификацию (слабое знание инженерных дисциплин);
12 Отсутствие тестирования, рефакторинга и прочих техник;
13 Проблемы при генерации и проверке гипотез (первое решение принимается как правильное).
👍2