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