Аутсорсинг в Україні — це раби, компанії хваляться рейтингом рабів — Макс Поляков

цей нонсенс навіть коментувати нічого. Аутсорс чи продукт мене як розробника не хвилює взагалі. Це відповідальність інших людей. Може проблема в тому що я не хочу виторгувати еквіті в офері? Так це не тому що я неосвідчена макака, а мій вибір. Я вже зважив всі за і проти партнерства, включаючи потенційний шанс стати мільйонером і вирішив взяти баксами. Мій вибір. Захочу ризикнути — куплю акцій сам.

якщо комусь цікаво в чому проблема — це дуже небезпечно. Вже не один випадок був коли знайомих грабували після операцій з банківськими рахунками. Банки і люди різні а результат один: зняття суми в банку для переказу на інший рахунок, або на ремонт = пограбування дому через 1-2 дні. В поліції результау 0, ну це очевидно. Це не жарти, всі операції і рахунки мають бути закритими, ніяких звітів без судових постанов не має бути. Весь доступ до фінансових даних має проходити аудит, і якщо будь-який зв’язок між злочинами і перевіркою рахунків — має за фактом відкриватись провадження на перевіряючого.

стратегія не понижати планку працює і стратегія понизити планку працює.

Можна звичайно на 3 абзаци написати і спробувати переконати людину понизити стандати і купити глобус. Я би порадив не понижувати в навпаки порахувати всі витрати які будуть і тримати планку. Набагато простіше сторгуватися з роботодавцем один раз, ніж потім намагатись виторгувати собі скидку на житло, машину, і відповитись від смузі.

питання було:

Реально всі нормальні зп, які будуть відчутно вищими ніж те, що ми отримуємо в Україні, це лише США? Чи на хорошу вакансію в linkedin не пишуть, а це все відбувається по знайомству-рекомендації?

відповідь: купи собі глобус...

якщо не знаєш відповіді — просто промовчи.

Юрій, з досвіду причина в тому що в Києві в спецшколах дуже гарно організований процесс. Я б навіть сказав що навіть рівень унівеситетів не дотягує до них.

Андрій дуже хороший інженер і лідер. Явно є глибоке розуміння особливостей роботи і вміння доносити хороші ідеї до людей. Респект

в Україні є свої бізнес традиції, одна з них — всі бізнеси мають працювати по сірому або по чорному. Кожні ~ 6 місяців — 1 рік в кілька етапів відбувається атака на всі білі бізнеси, які ± заробляють якісь гроші. В ЗМІ починають розказувати які несправедливі там умови, і як мало вони платять податків і як потрібно відрегулювати і навести ’справедливість’. Ключові тези в ЗМІ: ’неврегульовані’, ’бюджет недоотримує’, ’будівництво доріг’, ’зарплати вчителям’. Притому всі ЗМІ роблять це в один час і повторюють одні і ті ж тези чим створюють ілюзію масової підтримки. Нові умови завжи висуваються так що бізнесу можна або закриватись або перейти на сірі схеми. Потім з залежності від домовленостей, або дають задню і повертаються через пів року або створюють і продають нову посаду/орган, яка буде ’регулювати’ нові правила. Якийсь кац назвав цей паттерн ’Наїзд-відкат-від’їзд’ по якому силовики і законотворці ’спілкуються’ з бізнесом і до нас підходить.

архітектор який розуміє що в нього в проект спроектований на 3 з 10 не буде читати книги. Як тільки він підніме кваліфікацію оцінка проекту знизиться до 1 з 10 і буде геть сумно.

нетипізовані вказівники callback* це жесть, я уявляю якщо розвести по 2 командах, і використовувати різні версії + параметри змінювати. Це неможливо підтримувати.

Олексій, думаю автор мав на увазі що при керуванні проектом краще мати ситуацію коли менеджер приймає менше рішень а більше розставляє пріорітети і прояснює обмеження. Кількість різних рішень на проекті дуже велика і кількість факторів які впливають на рішення також велика, багато з них вимагають специфічної експертизи. Тому прийняття рішень менеджером звучить нереалістично через обмеженість його ресурсу. Звісно менеджер може прийняти рішення і без повноти картини, але цінність таких рішень менша.

Для цього одна людина має знати, як оті усі модулі працюють. А потім — мержи та пулл реквести та код ревью. І треш затягнеться на тиждень на рівному місці.

це був найпростіший синтетичний приклад. В найпростішому випадку коли в людини є код вона зможе розібратися. Трохи складніший — подивитись в коді хто працював з функціоналом і запитати поради, наприклад додавши в пулл реквест, ще складніший варіант — написати частину коду самому і запитавши відразу деталі по незрозумілій частині, і т.д.

В мікросервісах всі умовні 50% делегуються відразу іншій команді, в якій свої пріорітети, і в найпростішому випадку в Вас задача сформулювати вимоги, і домовитись з іншою командою і чекати. В складніший — гра в пінгпонг і поламаний телефон.

А ще є такий цікавий процес, як зміна інтерфейсу. В моноліті, зазвичай, здається, інтерфейси не версіоновані.

в моноліті більшіть інтерфейсів працюють через пам’ять а не мережу. Версіонування їх не потрібне, тому що консистентність таких інтерфейсів зашита на рівні коду. Є компілятор який стежить за цим.

Відповідно, щоб змінити інтерфейс модуля, команда має домовитись з усіма іншими командами, що його використовують, і одночасно провести й закомітити зміни. Легко зробити таке, скажімо, для 5 команд, в кожної з котрих горять свої задачі?

Це може зробити одна людина, зробивши зміни в усі модулі. Запустивши білд, тести і почитавши код навіть одна людина зможе це зробити.
З мікросервісами ви маєте іншу команду, код який не знаєте і набір інтерфейсів. Блекбокс. Якщо хочете деталей — пишети листи.

в мене моноліт, і тому все консистентно. всі модулі робочі і працюють. Навантаження на систему я знімаю лоад балансером. Де я зекономлю на мікросервісах? 150 МБ жорсткого диску ? ) Модуль навіть не завантажується в пам’ять якщо його не використовувати. Не говорячи про CPU. Виходить я трохи місця на жорсткому диску зекономив?

Має значення не розмір коду, а оперативка та проц. В моноліті купа модулів завантажені, кожний тримає свій стан.

ок. я горизонтально масштабую моноліт через лоад балансер. Завантажую ті модулі які хочу на кожній ноді. Що мені заважає?

в моноліті усім командам треба домовлятись про зміни

Бо моноліт може не влазити в один бокс,

особливо ці два аргументи про-мс мене радують. Як можна не розуміти що при мс домовлятись потрібно набагато більше і ’якісніше’, з меншим набором інструментів і з набагато більшою вірогідністю щось може піти не так.

а не влазити в один бокс... не знаю в скількох % проектів розмір артифактів dll має значення. Це мають бути гігабайти dll. Ніхто не згадує про кеш і лоад балансери.

погано те що дуже прості сценарії перестають бути такими з мікросервісами. Тут приводили статтю dwmkerr.com/...​oservice-madness-in-2018
Але простіше я вже говорив: 2 менші системи в загальному випадку складніше ніж одна для розробки і деплойменту. При тому значно складніше. Прості сценарії: невідповідність в DTO, пейджинація, невідповідність реквайрментів і коду. В монолітах таких проблем або немає за дизайном або вони вирішуються на етапі компіляції.

Не можна сказати що варто або ні запихати в один солюшен. Потрібні деталі. Але точто можна сказати коли що одну схему в одні базі підтримувати простіше ніж 2 схеми в двох базах які посилаються на одні дані. В загальному випадку неможливо навіть пейджинацію зробити. З цього можна картину малювати «адепт мікросервісу пояснює чому не можна заімплементити пейджинацію», з хмарками : гугл, амазон, майкрософт!!!!

Ви не знаєте точних умов. Суть в тому щоб сказати що краще, 1 солюшен на 20 проектів, на якому є умовний білд + тести, або 2 солюшени по 10 проектів.

можна уявити середній солюшен 20 проектів розбити на 2 по 10, закинути їх в 2 різні репозиторії і поєднати через json/xml. Спочатку це буде один розробник, і не буде складності з комунікацією. В якому випадку буде більше фейлів? Тепер переходимо від одного розробника до команд 5-10. Малюємо варіанти. А тепер уявити що склеювати до купи це все також будуть треті люди, які не знають деталей ні першого ні другого, обмежені в часі, і яким не можна або складно відмовити.

Сам по собі підхід один великий антипатерн. А систематизація і виділення окремих антипатернів це ще один антипатерн, який полягає в відмові визнати проблему, і переносі відповідальності на виконавців.