0 1
Аха, това обяснява много неща. Дося всички катастрофи ги правеха архитектите. Обаче не мога да си представя баш на тебе някой да ти плаща за такова. Ваш си проблем, не мой.
И къде все пак ползваш висша математика, освен да се докараш пред жена си? Интересно ми е, не съм виждал досега.
Ние в момента работим по мърджването на 3 платформи. Нашите шефове са стиснати, колкото пъти и да предложим да платят на архитект да направи нещата като хората - предложението бива отказано. Оттам PM-то се занимава с това, като пита всички останали програмисти за да можем да се синхронизираме и как ще ни излезе най-лесно разработката + поддържането на текущите платформи.
Моето предложение беше да работим на модули. За сега ПМ-то се съгласи за фронт-енда, който ще е на Ангулар да се прави на модули, та да може всеки да се впише и по-лесно да се разпредели работата.
Разликата при нас е, че ние не го правим за трети лица и докато поддържаме старите платформи ни трябва начин малко по малко да надграждаме мърджнатия продукт. Така всеки екип ще може да работи по частта, която неговата платформа предлага.
Пак си влязъл в някой филм. Чел съм книги за архитектура, в общи линии от простото правят сложно. После ние си чукаме главите да ви уйдисваме на простотиите.
Някоя много изпаднала фирма ще да е, да опре да им правиш архитектурата баш ти.
Ами според мен е добър подход в такава ситуация. Единственото което бих предложил в ситуацията е да се направи roadmap - т.е. кой след кой модул да се мигрира. Съответно където има преплитане на модули от различни платформи да се прави интерплатформна комисия, да се уточнят зависимости и конфликти където ги има.
Аз да си призная нямам много опит със скалирането, не ми се е случвало мой проект да избухне (докато още работя по него), обаче там където ми се е случвало да се одърви работата винаги е било в някаква малка част от проекта. Примерно имам един проект с IoT дето реално има сигурно 30 потребителя дето се логват по 1 път седмично, но устройствата които имат бълват много съобщения. Реално стигнахме до момента да трябва да скейлваме това чудо дето получава и държи съобщенията. Изкарах го на отделен service, на негов си сървър, а в момента го вадя от SQL Server и ще ги ръгам в Cosmos DB тея съобщения. Моето впечатление е че проблемите със скалирането винаги идват така един след друг и имаш време да отлюспваш парченца от монолита 1 по 1 когато има нужда. Според мен в реална среда ако не си Google или Facebook винаги е най-добре да скалираш през монолит + микросървиси около него. Кодът в основното ми приложение с 30 потребителя е много по-сложен от този дето получава съобщения и ако трябваше да го правя на микросървиси всичкия ще ми се отели вола и кой знае колко бъгове щяха да излязат от контрактите между тях, а сега културна работа - refactoring в IDE-то, foreign keys в базата, go to definition...
Това е най-големия проблем в тази фирма. Прави се roadmap, на тези отгоре им скимва нещо друго и roadmap-а се променя. Или 1 седмица по-рано ти казват за даден краен срок, който е бил решен от доста повече време. Нещата при нас се ръшват много, накрая свършваме с бъгав код и си създаваме повече работа отколкото трябва, хаха.
За скалиране не сме мислили толкова задълбочено понеже доста неща вече се знаят и не очакваме експоненциално увеличение на потребители или работа, която сървъра трябва да процесва. Има замисъл да пробваме K8s, но като се замисля, може по-скоро да докара усложнения в момента, отколкото да улесни каквото и да е.
Рабиноиди навсякъде има, но вашия случай мяза повече на интеграция, там има други интересни подходи ако е решен човешкия проблем 
Нова технология в случая е нож с две остриета - от една страна създава чисто технически проблеми, от друга - е чудесен повод да се искат генерални промени в мениджмънта, срокове и т.н. с аргумента че "така работи".
По принцип се старая да следвам съветите на по-умните от мен. Пиша код, който е възможно най-лесен за писане и четене, и (ако не противоречи на предните две) лесно може да се преписва когато се променят изискванията. Фантазиите, че ако свърша малко повече работа днес, това ще ми улесни живота утре досега са ми носили само главоболия.
А на мен безсънни нощи. Особено, когато трябва да променя сериозен процент бизнес логика. И понеже съм лийн методолоджи, това се случва много често. Последно време пиша минимума, щото така или иначе, ще се промени до половин година.
0 1