Сейчас я все больше осознаю свою цель.

Я вижу три проблемы, которые сложились в ИТ-отрасли:

1. Многие специалисты неудовлетворены условиями работы. По результатам опроса 2/3 неудовлетворены условиями работы, а каждый пятый регулярно испытывает желание уволиться. Недавно "проголосовал ногами" мой товарищ, достаточно сильный специалист.

2. Остутствие корреляции между реальным уровнем квалификации и уровнем зарплаты, в силу проблемы, известной в математике как "проблема лимонов и персиков". В силу этого, квалификация на рынке труда стремится к исчезновению, что отражается на снижении качества програмных продуктов.

3. Квалифицированные специалисты боятся выходить на коммерческий рынок, освобождая место для деятельности шарлатанов. Об этом я говорил в черновике своего доклада. Даже несмотря на то, что маржинальность коммерческого рынка раз в 20 больше чем у трудового рынка.

Все более отчетливо я вижу свою цель в создании такого маркетплейса услуг Consulting, Enabling, Audit, Outstuff, Outsource, Part-time, где грамотные специалисты смогли бы зарабатывать по достоинству благодаря решению "проблемы лимонов и персиков".

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

Все-таки, Жюль Верн был пророком. Роман "Путешествие и приключения капитана Гаттераса" - это, как мне кажется, про среднестатистический ИТ-проект.

На примере доктора Клоубонни хорошо показана функция архитектора - удерживать бриг и его команду от распада, неминуемого от маниакальных действий капитана, и хоть как-то уравновешивать одержимость капитана "бизнес-целью". Короче, лечить капитана от одержимости, а команду - от капитана.

Просрав команду и бриг, движимый "бизнес-целями" капитан попробует даже влезть в огненную лаву вулкана, за что поплатится здравым рассудком и уступит первенство капитану конкурирующего судна из США.

Команда тоже хороша. Во-первых, как это часто бывает в ИТ, она "проголосует ногами", и даже северный полюс ей в этом не преграда. Как истинные ИТ-шники, они сожгут свой бриг перед тем, как свалить. А потом начнут поедать друг друга, выпивая кровь своих коллег, подобно ИТ-шникам в процессе WTF.

Но доктор Клоубонни оказался "пишущим архом", и смог справиться сам, реализовав бизнес-цель без всей этой оравы поедающих друг друга разгильдяев и вопреки маниакальной одержимости капитана.

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

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

Коллеги, с Праздником! Ярких побед и высоких достижений!
Вот это песня, как мне кажется, тоже про среднестатистического ИТ-шника:
https://youtu.be/yr0QwWJPIZM?si=wMroDcSFXpq9yxBK
Ведь "Software design is a constant battle with complexity" — Eric Evans.

Знаете, какое профессиональное качество я больше всего не терплю? Лицемерие. Внешний конформизм. Бесхребетность. Когда человек говорит одно, а думает другое. Когда в лицо говорит одно, а за спиной - другое. Когда личные амбиции ставятся выше общих интересов дела. Когда у человека белое - это черное, а черное - это белое, и ты не знаешь, когда и что от него можно ожидать. Сегодня эту гнилость принято маскировать под новомодными терминами "софт скиллов" и "эмоционального интеллекта".

Вспоминаю песню В.С.Высоцкого:

Но не все, оставаясь живыми,
В доброте сохраняли сердца,
Защитив свое доброе имя
От заведомой лжи подлеца.
Хорошо, если конь закусил удила
И рука на копьё поудобней легла,
Хорошо, если знаешь, откуда стрела,
Хуже, если по-подлому, из-за угла.

В свое время Н.Я.Азаров сказал, что опереться можно только на то, что сопротивляется. Бумажный стол бесполезен - он сразу прогнется. Беспринципный человек не может стать опорой коллектива.

Был у меня один программист, который был слишком прямолинеен. Не все хотели с ним работать. Он не старался скрывать своего отношения.

Это был один из самых лучших программистов за всю мою практику. Грамотный, дерзкий, смелый. Не боялся никаких задач. За неделю он написал собственную реализацию Production Rule System (DSL-интерпретатор). Схватывал все на лету. Когда он впервые услышал про CQRS, то через неделю это было уже в коде, еще через неделю в коде были уже доменные события, а еще через неделю он уже спрашивал у меня про проектирование m2m связей в агрегатах.

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

Он не боялся задавать неудобные вопросы, чем развивал мои способности аргументать. У нас были честные профессиональные отношения. И мы делали такие вещи, про которые многие и не слышали. Это был человек дела. С таким можно и в огонь и в воду. Я бы с удовольствием поработал с ним снова.

Это называется профессионализм.

Но некоторых профессинализм пугает, потому что на его фоне обнажается их ущербность. И они придумывают разные отмазки, типа "важны командные качества", подразумевая уважение к собственной безграмотности. Сборище бездарей - это не команда. Важно не объединение людей само по себе, а те принципы, на которых оно основано.

В продолжение темы. Говорят, что ум человека видно по его вопросам, а не по его ответам. В команде моего текущего проекта есть программист, не сильно опытный, но я его ценю потому, что он прямой и открытый, не стесняется задавать неудобных вопросов, которые делают меня умнее. И он не отцепится до тех пор, пока не выяснит все неясности. Именно он задал вопрос, в результате которого возник этот опрос (и этот). Как видите, если правильно сформулировать вопрос, то ответ будет очевидным для большинства опрошенных. И этот ответ не будет совпадать с подавляющим большинством эталонно-демонстрационных приложений, даже таких авторитетных, как от Microsoft. Этот программист обнаружил ошибку, которую не заметили в компании с самой высокой архитектурной культурой в мире, и над документацией которой работало 2599 контрибьюторов.

Будь на его месте какой-нибудь бесхребетный соплежуй после псевдософтскилловых курсов, то я бы даже не задумался об этом, и не обнаружил бы нестыковку.

А между тем, согласно диалектике, синтез возникает там, где вскрываются противоречия. На этом основан диалектический метод познания. Иными словами, без противоречий не будет развития. Само слово "развитие", происходит от слова "вить" (витая пара), и означает "расплести" противоречия. Сокрытие противоречий приводит к интеллектуальной деградации коллектива.

вот даже книжку подвалили: https://www.ozon.ru/product/kak-ubedit-teh-kogo-hochetsya-pribit-pravila-produktivnogo-spora-bez-agressii-i-perehoda-1212729149/?

)

Вот хорошая книга про конфронтации и споры.

https://www.ozon.ru/product/dzhedayskie-tehniki-konstruktivnogo-obshcheniya-orlov-aleksandr-elektronnaya-audiokniga-917253665/?asb=Be%252FFUBK71EHhLQk04ZAlECN22i2r54PLYZjRAV%252FwRMo%253D&asb2=b3hGw0AlGeI7bXnX6OqomduBi5-hpqViN4jaN8zk1g--XB946T70msRJKBytJvo9&avtc=1&avte=2&avts=1696928187&keywords=%D0%B4%D0%B6%D0%B5%D0%B4%D0%B0%D0%B9%D1%81%D0%BA%D0%B8%D0%B5+%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D0%BA%D0%B8

Ну и еще ряд сообщений, начиная отсюда (обсуждали ранее):
https://www.tgoop.com/emacsway_log/450

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

Именно об этом гласит один из 12 принципов Agile-manifesto:
💬 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Я всегда испытываю неподдельное восхищение от таких грамотных обсуждений. Не буду скрывать, что такие обсуждения делают меня умнее. Особенно радует, когда моя библиотека пополняется превосходными книгами.

Основных участников обсуждения я знаю уже более 4 лет, и они существенно повлияли на становление меня как специалиста.

Отдельно хочу выделить Дениса Бескова - человека с уникальной грамотностью. Его проницательность всегда заставляет меня задуматься (иногда не сразу). А ведь было бы так удобно и комфортно считать себя "самым-самым" и избавиться от всех раздражителей своей зоны комфорта, заклеймив их. Это путь деградации. И именно об этом был мой пост.

Путь развития требует определенных морально-психологических и волевых качеств. Если бы это было не так, то сегодня профессоров было бы больше, чем грузчиков.

Групповое поведение в организации.


https://xn--80aabdcpejeebhqo2afglbd3b9w.xn--p1ai/%D0%BC%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D1%8B/160/525

Поведенческие отношения в организации.

https://инклюзивноеобразование.рф/материалы/160/523

Искренне поздравляю @vladik_kh !!! 🎉🍾
https://learning.oreilly.com/library/view/balancing-coupling-in/9780137353514/

Монументальный, титанический труд, который под силу только Настоящему Титану! Дейкстра современности!

Книга уже признана такими авторитетами, как Gregor Hohpe, который в восторге от неё!

Это даже не луч света в темном царстве спагетти-кода. Это настоящий прожектор путеводного маяка в океане архитектуры!

Это не самая удачная запись. Здесь лучше:

https://youtu.be/6indW7BSGZI?si=EZvt-9PjkaQjsWzg

Запись расширенной версии доклада есть с ddd europe 2023

Если почитать внимательно оригинальную статью "Pattern: Backends For Frontends" by Sam Newman, то в главе "General Perimeter Concerns" можно заметить, что он рекомендует размещать BFF после "generic perimeter concerns, such as authentication/authorisation or request logging". Т.е. после "Gateway Offloading pattern".

Проблема в том, что конструктивно "Gateway Offloading pattern" и "Gateway Routing pattern" реализуются на практике одним и тем же решением, например, KrakenD.

В свою очередь, "Gateway Routing pattern" решает проблему "the client must be updated when services are added or removed."

Vlad Khononov возлагает на api-gateway еще и функции "Anticorruption layer":
💬 "Anticorruption layers implemented using an API gateway can be consumed by multiple downstream bounded contexts." (для frontend это особенный вопрос).

Таким образом, получается, что размещение BFF за API-Gateway будет противодействовать назначению API-Gateway в устранении связанности между API микросервисов и их внешними клиентами.

Другой аргумент заключается в том, что BFF нуждается в агрегации, а не наоборот.

Ну и в таком случае он не сможет решать проблему "causing the backend to become a bottleneck in the development process."

Выгдядит так, что BFF должен располагаться, всё-таки, перед api-gateway. Какие существуют еще аргументы или контр-аргументы?