Вы или ваши коллеги считаете тесты 2nd class Citizens?

Kevlin Henney в своем недавнем выступлении убедит вас почему тесты лучше писать вместе с продакшен кодом. И более того, покажет почему тесты пишутся не только для компьютера, но и в НЕ меньшей степени для людей. + Огромное количество рекомендаций по лучшим практикам написания тестов.

Приятного просмотра! https://www.youtube.com/watch?v=MWsk1h8pv2Q

Мы строили, строили и наконец, построили.

Всем привет! На прошлой неделе у нас не было постов, потому что мы готовили документы для формального учереждения организации и таки учередили ее.
Теперь мы не просто канал, а целая региональная общественная организация "Объединение ИТ-Архитекторов".
Учередители:

- Баранов Сергей @sergey486
- Геннадий Круглов @GKruglov
- Лукьянов Евгений @elukianov
- Закревский Иван @emacsway

Почитать устав и ознакомиться с целями можно тут. По вопросам вступления обращаться в Joining Bot: @ru_arc_bot

Новое видео: 8 моих принципов эффективного рефакторинг
https://youtu.be/1pZ6UvyIfdY

1. Выработайте общий вектор рефакторинга
2. Начните с тестов
3. Переписать все - плохая идея
4. Двигайтесь маленькими шажками
5. Составьте план Рефакторинга
6. У вас должна быть веская причина для рефакторинга
7. Новая технология не повод!
8. Примите неудачи

Актуальное! Релокация в Сингапур для Программистов.
Если вы Сеньор разработчик и знаете английский - то это видео точно будет вам полезным https://youtu.be/4pt35Dy5MIk
Узнай как переехать в фантастический Сингапур за месяц!

Code duplication.
Думаю более опытные разработчики на своем опыте уже поняли что дублирование кода - не всегда плохо. Да и Дядюшка Боб в своем SOLID’е об этом же упоминает. Но косвенно. Но молодые разработчики просто одержимы устранением дублирование, которое ведет к увеличению coupling’а.

Если у вас есть в команде такие приверженцы устранения дублирования no matter what Просто дайте им посмотреть это видео https://youtu.be/OkDrlNY5mMc

Выступил сегодня на ArchDays 2022. Спасибо организаторам за такое крутое мероприятие!

Technology Radar 27 released!

На наш взгляд самое интересное в данном выпуске не технологии, а техники.

Path-to-production mapping. Техника, похожая на эвент шторминг, только в результате получается не бизнес-процесс, а процесс доставки софта от ноутбука разработчика до продакшена. Как происходит? В одной комнате запираются все заинтересованные лица: разработчики, дизайнеры, аналитики, можно даже пару пользователей посадить и на доске рисуется процесс доставки, непрерывно задаются вопросы “а зачем так”, “а что, если вот тут произойдет нечто”, “а можно ли лучше”. Практика обещает что таким образом процесс получается более проработанным и всеобъемлющим.

Team cognitive load. Судя по всему продолжение Закона Конвея о том что архитектура ПО повторяет структуру команды. Техника советует при разбиении на команды принимать во внимание размер когнитивной нагрузки на команду и контролировать нагрузку со временем. Команде стало тяжко - дроби. Слишком легко живется - объединяй. Прилагается шаблон для отслеживания когнитивной нагрузки. (Напишите в комментариях если использовали)

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

Observability for CI/CD pipelines - С тем что очень важно понимать что происходит на продавшее вроде уже все смирились. Логи собираются, метрики пишутся, дашборды строятся. Но Не менее важно имплементировать пайплайн таким образом, чтобы было понятно что там внутри происходит, где он отвалился в этот раз и почему. А еще было бы не плохо понимать его эволюцию со временем. Почему вдруг в этом месяце сборка начала занимать в среднем на минуту дольше, а деплой на целых 5.

Thoughtworks Technology Radar https://thght.works/3sw3Hlr

Делитесь в комментариях что интересного нашли вы!

Возможно вы пропустили, но вышел новый отчет State of Devops 🙂 https://services.google.com/fh/files/misc/2022_state_of_devops_report.pdf

Несколько интересных фрагментов
«Надежные (Dependable) команды обеспечивают надежный(Dependable) сервис: творческая командная культура ведет к большей надежности».

Мы видим, что люди с меньшим опытом в целом имеют худшие результаты при использовании trunk based development. (Что и не мудрено. Вы попробуйте trunk based, когда, скажем у вас тестов нет. прим stringconcat)
Хотя она оказывает положительное влияние на общую эффективность организации» (есть предположение о том, что этот результат является неожиданностью, и возможные причины включают гораздо более неопытных участников, чем в предыдущие годы)

«Исследование этого года показало, что loosely-coupled architecture (слабосвязанная архитектура) может способствовать выгоранию команд.
Это удивительное открытие, которое противоречит результатам предыдущих лет. Наш анализ показывает, что стабильно
команды, в которых используется loosely-coupled architecture, имеют более низкий уровень выгорания. Генеративная культура Westrum и стабильность команды поддерживают слабосвязанную архитектуру и снижают выгорание, так что это явно противоречит друг другу. Необходимы дополнительные исследования, прежде чем мы сможем сделать окончательные выводы».

«Самый важный фактор, который мы обнаружили, был вовсе не техническим, а скорее культурным: организации, наиболее близкие к «генеративной» культурной группе Westrum, значительно чаще говорили, что у них широко распространены методы обеспечения безопасности, как это определено в рамках SLSA».

Если вам не знаком термин Westrum Cultrue (как и мне), то вот тут сам Профессор Westrum объясняет. https://youtu.be/gKH3Y4G8TfI?t=107 К слову, многие интуитивно чувствовали это при выборе компании. Но вот оказывается есть четкое определение

Закончил краткий пересказ статьи «Microservices: The Evolution and Extinction of Web Services?» за авторством Luciano Baresi и Martin Garriga 👌

abstract
Еще 20 лет назад SOA и Web Services были на пике популярности. Это был самый настоящий хайп. Особенность хайпа в том, что его применяют ради хайпа, а не для пользы дела, в массе своей даже не разобравшись в сути явления или технологии. Такое положение дел привело к тому, что количество определений и трактовок SOA и Web Services было примерно равно количеству внедрений Это, в свою очередь, приводило к тому, что проблема подгонялась под решение. Сегодня то же самое происходит с микросервисами. Авторы статьи исследуют эволюционный путь от SOA к микросервисам на основе анализа литературы, как академической, так и научно-популярной.

http://agilemindset.ru/история-микросервисов/

Приятного чтения 🧠

Давненько ничего не писал, был завален работой. Наконец-то полегчало, поэтому пару слов

Завершили очередной этап работы по проекту, где я участвую. Длился он несколько месяцев и нам удалось применить почти все лучшие практики, про которые мы с Сережей неустанно рассказываем. Несколько микросервисов, немного изолированого легаси. Сознательно не говнокодили, придерижвались правил. Какие основные выводы от этого этапа:

1) Практически не теряли время просто так и шли на максимальной скорости. Никаких ожиданий пока соберется сборка где-то там на билд-сервере, протыкиваний вручную или поиски нужного параметра, чтобы запустить проги локально. Но потребовало напряжения в самом начале. CI должен быть вашим внутренним продуктом с соответствующим отношением.
2) Благодаря тестам интеграция разных частей системы прошла лучше чем ожидалось. Сидеть втроем и пялить в дебаг не нужно
3) Анемичная модель - зло. Только нормальная инкапсуляция помогает справиться со сложностью предметки. При анемии уже через месяц получается непролазная каша
4) Гексогональная/чистая архитектуры - сложная для понимания концепция, особенно если привык клепать круды в слоенках

Обо всем этом я рассказывал в том числе на ArchDays 2022, ждем когда подвезут видео, не переключайтесь.

Zero trust. Подборка документации для архитектора.

https://www.redhat.com/architect/what-is-zero-trust

В комментах к предыдущему посту был хороший вопрос, а как понять, что у нас предметная область сложная и нужно все вот это ваше ДэДэДэ, а когда можно и без него?

Первое, что может помочь - это определение типа ограниченого контекста. Если контекст не основной, а скажем неспециализированый (деятельность, которая одинаковая для разных компаний), то можно найти под него готовое решение и вообще не мучиться. Например взять какой-нибудь keycloak для управления доступом пользователей и не мучиться. Если контекст основной (основная деятельность компании, то чем она отличается от остальных и зарабатывает деньги) или специализированый, но он выглядит как максимально простой CRUD, то можно заиспользовать Spring Data Rest или же вообще взять что-то из Almost Zero Code вроде Retool. Получаем быстрый старт и проверку гипотезы о сложности предметной области. Если почувствовали, что штаны становятся маловаты, значит пришло время перейти на что-то посложнее.

Хороший обзорный пост про функциональное программирование https://habr.com/ru/company/jugru/blog/553028/

Чем нам грозит GPT

Последние недели в интернетах только и разговоров, что о ChatGPT. Для тех кто не в курсе, это такая продвинутая языковая модель от OpenAI, которая показала впечатляющие результаты. Если брать конкретно нашу отрасль, то с помощью нее уже и требования составили и кодили и даже виртуальную машину сделали

И если встарину разработчики на вопрос о замене человека ИИ лишь снисходительно улыбались и говорили «мы будем последние кого заменят», то теперь некоторые наблюдают за этой шайтан-машиной крепко сжав булки. Только на прошлой неделе получил несколько сообщений в личку вроде «ТЫ ВИДЕЛ????777 НАС ЩАС ВСЕХ УВОЛЯТ!!111адинадин». Но давайте не будем паниковать и подумаем, какие последствия могут быть для нашей уютной айтишечки.

Если брать весь процесс целиком, то нужно вспомнить, что разработка не состоит только из одного программирования. Тут вам и разработка требований и проектирование и обеспечение инфраструктуры и CI и тестирование и эксплуатация и много чего еще. Не сильно ошибусь, если скажу, что программирование занимает не больше половины от всего процесса. И собрать в кучу данные этапы и получить непрерывный конвейер по производству изменений (результат нашей работы не софт как таковой, а его изменения) не всегда могут даже целые коллективы не самых глупых людей. Это очень сложная и слабо формализованная штука и на данном этапе я сильно сомневаюсь, что машина может с этим всем справиться.

Но можно попробовать с помощью нее решить узкоспециализированые и/или рутинные задачи. Например:
- Программирование. Да-да, оно может быть очень скучным и унылым. Если вы придерживаетесь стандартов, о которых я говорил вот в этом ролике, то многие части программы будут выглядеть очень похожими. Можете посмотреть например на юзкейсы в наше референсном проекте. Они достаточно разнообразные, чтобы генерить их шаблонами, но логика очень схожа. Мне кажется самое оно для таких умных штук вроде ChatGPT (а то и проще)
- Разработка небольших прототипов или утилит. Чуть более продвинутая вещь чем предыдущий пункт, но все же очень ограниченная. С тем условием, что на внутреннее качество плевать. Тут может получиться интересно, что слегка умрет рефакторинг, ибо робот не умеет исправлять, ему проще сгенерировать заново.
- Фаззинг при поиске уязвимостей. Подаем на вход валидный запрос, на выходе имеем список пейлоадов.
- Поиск граничных значений и разработка негативных сценариев при тестировании и т.д.

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

З.Ы.: если у вас есть мысли какие действия можно поручить этой шкатулке с чудесами, то делитесь в комментариях, будет интересно почтитать.

Приятно, когда твои ученики растут и начинают участвовать в жизни индустрии.

Небольшая заметка об ADR от нашего студента Дмитрия Абрамова, в которой описывается почему это важно, а не как их готовить

https://dev.to/karvozavr/the-four-horsemen-of-software-complexity-architecture-decision-records-to-the-rescue-1211

Чему мы учим можно посмотреть на специальном лендинге.

А вот и видео подъехало. https://youtu.be/CjWfl4xxQdc

Все о новом годе, а мы о новом курсе! Курсе не рубля и евро, а курсе на прокачку себя и своих знаний.
В студию: Мини курс на пару часов с обратной связью от авторов. Кто-нибудь вам такое дарил? А мы вам его дарим(БЕСПЛАТНО/ДАРОМ/ДАЛЕЕ ПРИДУМАЙТЕ САМИ), потому что сила в нас и нашем окружении. И так курс от нас для вас :Поваренная книга Дядюшки Боба: Как готовить Clean Architecture.

Если у вас и ваших сородичей по шлюпке TDD не применяется и DDD не приживается? Проблема может быть в том, что приложение выглядит как Big Ball of Mud. А с этой напастью отлично борется Clean Architecture.

В курсе мы поговорим о модульности. Как она помогает нам снизить сложность программного обеспечения и как принципы модульности имплементируются с помощью Clean Architecture.

Курс интерактивный. Вы делаете ревью типичного приложения написанного на clean architecture.Мы лично проверяем и говорим какие вы молодцы или разбираем ваши ошибки.
Если вы у нас обучались, то для вас это ужатая версия для повторения.
Если ещё нет, то вы поймёте за что мы топим и почему. Это сохранит вам годы жизни, нервов и не даст превратиться в угли на рабочем месте
Если вы кому-то желаете по настоящему добра, то подарите этот курс поделившись ссылкой.

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

Р.S. Сила в каждом из вас 🫵, да прибудут вам знания.🎄
https://howto.stringconcat.com/book?utm_source=tg

👀 Про эффективных проджект менеджеров.

Сейчас я работаю на Грузовой Порт Сингапура. Они обновляют свою систему, написанную еще при царе горохе на Java 5. И у них встал вопрос "а кого же поставить менеджерами проекта?" Найти на улице менеджеров с IT прошлым или поставить своих?

И они поставили менеджерами проектов людей от сохи. Тех, кто еще недавно занимался планированием погрузки и разгрузки контейнеров. Кто переговаривался с капитанами судов “Судно Hong Yao, заходите в гавань”. В общем тех, кто уже достаточно поварился в этом порту и знает все нюансы работы. Но совершенно не знаком с IT. Ну то-есть на уровне уверенного пользователя iPhone.

И знаете что? Я НИКОГДА не встречал лучших менеджеров!
- Они четко знают что именно нужно от приложения и почему.
- Они способны объяснить любое понятие из доменной области, и Domain-driven Design идет как по маслу.
- Они на короткой ноге с другими пользователями и могут легко и непринужденно выяснить все нюансы работы.

А оказалось что научится рисовать столбики в MS Project и тикеты в jira оформлять - этому можно легко научится. Привет универсальным “эффективным” менеджерам

И как бонус - они понимают что они мало понимают в разработке ПО, поэтому не лезут со своим мнением о том что “рефакторинг нам не нужен, надо было с первого раза правильно писать”. А реально прислушиваются к разработчикам. Так же как и мы к ним. Каждый специалист в своей области - и это прекрасный симбиоз.

P.S. Недавно научил своего менеджера читать JSON 🙂

А вам попадались толковые менеджеры? Поделитесь своей историей в комментарии.