Nový projekt vs. cizí kód

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Nový projekt vs. cizí kód
« Odpověď #90 kdy: 14. 09. 2020, 15:43:08 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ptal jsem se z pohledu architektury, nikoliv z pohledu zvolené technologie. Viz kontext jeho příspěvku.


Re:Nový projekt vs. cizí kód
« Odpověď #91 kdy: 14. 09. 2020, 16:24:28 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ok, asi se pouštím  na tenký led (protože jsem ovlivněný tím, že dělám "vícevrstvé" aplikace, kde business logiku mám v aplikační vrstvě a db je prostě úložiště a tím, že PL/SQL tolik neznám), ale nepřišla mi databáze zrovna na tohle ideální nástroj.

Už jen ta SOAP/HTTP komunikace byla hodně low-level, přes nějaký utility balík se ručně skládal request (hlavičky, xml skládání ze stringů atd. (xml injection? ;-))), co by asi šlo abstrahovat a zapouzdřit do nějaké šablony, ale to se nestalo a tak se boiler-plate kód táhnul těmi procedurami... možná že existují nějaké pokročilejší tooly a jde to řešit elegantně, ale nevím. Také se mi nelíbilo, z pohledu architektury, že stejná db instance, která řeší úložiště dat, řeší i složitou business logiku zahrnující cally na web servisy.. (blokující a dlouho trvající). Také ta aplikace měla problémy s performance, ale jestli to bylo zrovna kvůli tomuhle, nevím.

Takže škálování a udržovatelnost. Když otočím otázku, proč to mít v databázi?


Re:Nový projekt vs. cizí kód
« Odpověď #92 kdy: 14. 09. 2020, 16:26:55 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ptal jsem se z pohledu architektury, nikoliv z pohledu zvolené technologie. Viz kontext jeho příspěvku.
No architekturně mi přijde, že je to hodně neočekávané chování databáze. Databáze je úložiště, které obsluhuje požadavky. Od PL/SQL věcí bych čekal, že budou nějak přežvykovat data v rámci té databáze.

Kdybych hledal místo, kde se rozesílají notifikace nebo přeposílají data, tak je databáze jedno z posledních míst, kam bych se díval.

Re:Nový projekt vs. cizí kód
« Odpověď #93 kdy: 14. 09. 2020, 16:41:16 »
...
To je prave to co tady resim.
...
Ale ty jsi se ptal na preference vývojářů. Tahleta špinavá taktika je spíš manažerské rozhodnutí.

Pravda ze sem chtel resil predevsim tu motivaci odspodu.
To manazerske rozhodnuti je ale vyvojari vitano a podporovano (vetsinou) a proto tam vidim souvislost.

Nevim uplne co je pricina a nasledek...
Jestli programatori nechteji delat na legacy a proto nejdou sehnat lidi a tak se porad offshoruje...
Nebo jestli manazeri tlaci na offshoring kvuli vetsim ziskum za vyvoj noveho a proto vyvojari zanedbavaji kvalitu, protoze vedi ze to nebudou muset udrzovat...
Ještě je tu třetí možnost. O nějaký tlak na vývoj nového nejde. A je to akorát důsledek krátkodobého tlaku na minimální cenu, bez nějaké dlouhodobější vize.

Ale to uz potom nema nic spolecneho s tou spinavou managerskou taktikou ne?
Nemá. Tu ale IMO předpokládal už tvůj příspěvek z 12:48.
Já osobně bych se spíš přikláněl k "po čtvrtletní uzávěrce potopa" bez nějakých dlouhodobějších zlých plánů.

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Nový projekt vs. cizí kód
« Odpověď #94 kdy: 14. 09. 2020, 17:40:22 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Rád dělám nižší vrstvu business logiky přímo v DB. Pokud ta vrstva dělá ucelenou činnost, tak s přenositelností na jinou DB (kdo z vás to dělá?) jsou zpravidla menší potíže.

Ovšem mám své hranice. Kompozici HTML a XML v DB jsem si zkusil a zjistil jsem, že tudy cesta nevede. DB totiž nenabízí ani substituci znaků "<&>' apod. Takže ani SOAP nebrat. Podobně ani e-maily by moc dobře nefungovaly, zejména pokud text byl jiný než ASCII.

Na druhou stranu vidím, že si někdo nenechá zformátovat ani datum, agregovat data, sečíst hodnoty v sousedních sloupcích apod. To je zase obrácený extrém. Proč by si databáze nemohla přepočítat částku na faktuře, když změníme položky?


BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Nový projekt vs. cizí kód
« Odpověď #95 kdy: 14. 09. 2020, 19:17:31 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ok, asi se pouštím  na tenký led (protože jsem ovlivněný tím, že dělám "vícevrstvé" aplikace, kde business logiku mám v aplikační vrstvě a db je prostě úložiště a tím, že PL/SQL tolik neznám), ale nepřišla mi databáze zrovna na tohle ideální nástroj.

Už jen ta SOAP/HTTP komunikace byla hodně low-level, přes nějaký utility balík se ručně skládal request (hlavičky, xml skládání ze stringů atd. (xml injection? ;-))), co by asi šlo abstrahovat a zapouzdřit do nějaké šablony, ale to se nestalo a tak se boiler-plate kód táhnul těmi procedurami... možná že existují nějaké pokročilejší tooly a jde to řešit elegantně, ale nevím. Také se mi nelíbilo, z pohledu architektury, že stejná db instance, která řeší úložiště dat, řeší i složitou business logiku zahrnující cally na web servisy.. (blokující a dlouho trvající). Také ta aplikace měla problémy s performance, ale jestli to bylo zrovna kvůli tomuhle, nevím.

Takže škálování a udržovatelnost. Když otočím otázku, proč to mít v databázi?
Když máš dvě vrstvy a ta druhá je prezentační...

Jako já vůbec neřeším, zda takto dvojvrstvá aplikace je dobrej nápad (dokonce by i mohl).
Určitě by bylo vhodnější udělat ten SOAP a posílání mailů jako nějakou service, etc. Protože otestování, a tak. Ale nakonec by to stejně skončilo v db, protože posílání mailu i SOAP je práce s daty.

Čímž nijak nezpochybňuji, že ten kód musel být hroznej. Ono, někdy jdou věci dělat velmi netradičně a přitom vlastně dobře. Pokud k tomu přistupuje dotyčný s tou ideou a nesnaží se jít proti ní, protože tak se to přeci nedělá.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Nový projekt vs. cizí kód
« Odpověď #96 kdy: 14. 09. 2020, 19:18:38 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ptal jsem se z pohledu architektury, nikoliv z pohledu zvolené technologie. Viz kontext jeho příspěvku.
No architekturně mi přijde, že je to hodně neočekávané chování databáze. Databáze je úložiště, které obsluhuje požadavky. Od PL/SQL věcí bych čekal, že budou nějak přežvykovat data v rámci té databáze.

Kdybych hledal místo, kde se rozesílají notifikace nebo přeposílají data, tak je databáze jedno z posledních míst, kam bych se díval.
Vzhledem k návrhu aplikace, jak tu byla popsána nemohu souhlasit.

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Nový projekt vs. cizí kód
« Odpověď #97 kdy: 14. 09. 2020, 21:24:01 »
...

Takže škálování a udržovatelnost. Když otočím otázku, proč to mít v databázi?
Když máš dvě vrstvy a ta druhá je prezentační...

Jako já vůbec neřeším, zda takto dvojvrstvá aplikace je dobrej nápad (dokonce by i mohl).
Určitě by bylo vhodnější udělat ten SOAP a posílání mailů jako nějakou service, etc. Protože otestování, a tak. Ale nakonec by to stejně skončilo v db, protože posílání mailu i SOAP je práce s daty.

Čímž nijak nezpochybňuji, že ten kód musel být hroznej. Ono, někdy jdou věci dělat velmi netradičně a přitom vlastně dobře. Pokud k tomu přistupuje dotyčný s tou ideou a nesnaží se jít proti ní, protože tak se to přeci nedělá.

Pokud by model byl implementován v databázi, což by neměl být problém, tak stačí kolem ní udělat prezenter. Takhle se dá krásně sdílet databáze mezi více aplikacemi, API jako její součást. Takový model by však měl být jen komponentou, která pracuje s daty té databáze. Pár výjimek by se našlo - například používám databázi jako zdroj přesného času.

Není ani problém SOAP a mejly strčit do prezenteru nebo ještě lépe do samostatných vrstev na úrovni modelu.

Re:Nový projekt vs. cizí kód
« Odpověď #98 kdy: 15. 09. 2020, 09:02:37 »
...

Ten software "tam" uz vznikal? Nebo "tam" byl predan na udrzbu (a rozvoj)?

To byva taktika jak donutit zakaznika aby zaplatil prepis...
  • Poradim at si snizi naklady offshoringem
  • Az zjisti, ze naklady jsou o trosku nizsi, ale nic mu nefunguje tak mu nabidnu, ze to predelam...
  • profit

To je prave to co tady resim.
Jednak to vede k tomu, ze se snizuje tlak na kvalitu tady, protoze "stejne to budeme za chvilku predelavat"...
a jednak to dela spatnou povest vyvojarum tam... protoze, z toho za par susni proste bic neupletes.... Nic se nenaucis... renome si nezlepsis... a priste zas nic nevydelas...

Je to takovy moderni kolonialismus.

Prave ze vydelas. Vydelaji "vsechny zucastnene strany". Jinak by se to takhle nevedlo. Nevim proc to nevidis. :) Jako je to cele spatne to je jasne. Ja se jen snazim dat pohled proc se tomu tak deje. Hlavni pricina je, ze vetsina tech lidi co se v zakazkach podileji maji stanovene kvartalni cile, nebo max. rocni. O co myslis ze jde projekt managerum na obou stranach. Oni nejsou hodnoceny podle toho co bude za pet let. A pokud firma napr. poslednich 10+ let jenom rostla, tak se snad necha rict, ze svuj business dela dobre. A o nic jineho nikomu nejde. Bavim se stale o takovem tom klasickem zakazkovem vyvoji. Kdyz ses google nebo netflix a delas si systemy sam pro sebe, tak to asi vypada trochu jinak.

Re:Nový projekt vs. cizí kód
« Odpověď #99 kdy: 15. 09. 2020, 09:33:51 »
...

Ten software "tam" uz vznikal? Nebo "tam" byl predan na udrzbu (a rozvoj)?

To byva taktika jak donutit zakaznika aby zaplatil prepis...
  • Poradim at si snizi naklady offshoringem
  • Az zjisti, ze naklady jsou o trosku nizsi, ale nic mu nefunguje tak mu nabidnu, ze to predelam...
  • profit

To je prave to co tady resim.
Jednak to vede k tomu, ze se snizuje tlak na kvalitu tady, protoze "stejne to budeme za chvilku predelavat"...
a jednak to dela spatnou povest vyvojarum tam... protoze, z toho za par susni proste bic neupletes.... Nic se nenaucis... renome si nezlepsis... a priste zas nic nevydelas...

Je to takovy moderni kolonialismus.

Prave ze vydelas. Vydelaji "vsechny zucastnene strany". Jinak by se to takhle nevedlo. Nevim proc to nevidis. :) Jako je to cele spatne to je jasne. Ja se jen snazim dat pohled proc se tomu tak deje. Hlavni pricina je, ze vetsina tech lidi co se v zakazkach podileji maji stanovene kvartalni cile, nebo max. rocni. O co myslis ze jde projekt managerum na obou stranach. Oni nejsou hodnoceny podle toho co bude za pet let. A pokud firma napr. poslednich 10+ let jenom rostla, tak se snad necha rict, ze svuj business dela dobre. A o nic jineho nikomu nejde. Bavim se stale o takovem tom klasickem zakazkovem vyvoji. Kdyz ses google nebo netflix a delas si systemy sam pro sebe, tak to asi vypada trochu jinak.

Jasny... stejne tak si vydelaji vsechny zucastnene strany na obchodu s diamanty. Vcetne tech 9-ti letejch deti v dolech.

Ale OK shodneme se, ze je to spatne...
Tak a ted se jen dohodnout jak to zmenime k lepsimu.
Co navrhujes?

Re:Nový projekt vs. cizí kód
« Odpověď #100 kdy: 15. 09. 2020, 11:37:29 »
Ale OK shodneme se, ze je to spatne...
Tak a ted se jen dohodnout jak to zmenime k lepsimu.
Co navrhujes?
Jak "dohodnout se"? ::) tomas88 napsal v podstatě to, že tenhle stav je Nashovo ekvilibrium. Výplatní funkce je daná korporátními směrnicemi. Můžeš leda tak jít hrát jinou hru.

Re:Nový projekt vs. cizí kód
« Odpověď #101 kdy: 15. 09. 2020, 14:23:03 »
Ale OK shodneme se, ze je to spatne...
Tak a ted se jen dohodnout jak to zmenime k lepsimu.
Co navrhujes?
Jak "dohodnout se"? ::) tomas88 napsal v podstatě to, že tenhle stav je Nashovo ekvilibrium. Výplatní funkce je daná korporátními směrnicemi. Můžeš leda tak jít hrát jinou hru.

1. Nevidim, ze by tohle psal
2. Neni to tak

Re:Nový projekt vs. cizí kód
« Odpověď #102 kdy: 16. 09. 2020, 10:11:21 »
plácat se ve starým kodu, kterej si navíc nepsal ty je tragédie...
99 procent firem k tomu nemá žádnej manuál, grafy, apod.
takře pochopení toho co někdo sesmolil před 10 ti lety je horší a často
delší než napsat celej projekt znova...
ideální je když pro opravu starýho kodu máš k dispozici programátora/programátory,
který ho sestavili... pak je to relativně snadnější ...

za posledních 5 let nastaly tak obrovký změny ve vývoji např. u Microsoftu,
že např. v MS VS 2008/10/12/13/15 už dneska nikdo nechce dělat nový projekty ....

Re:Nový projekt vs. cizí kód
« Odpověď #103 kdy: 16. 09. 2020, 11:15:14 »
Jasny... stejne tak si vydelaji vsechny zucastnene strany na obchodu s diamanty. Vcetne tech 9-ti letejch deti v dolech.

Ale OK shodneme se, ze je to spatne...
Tak a ted se jen dohodnout jak to zmenime k lepsimu.
Co navrhujes?

Nenavrhuju nic. Podle me se s tim nic moc delat neda, alespon ne z pozice programatora. Chce to balancovat plusy a minusy tohodle businessu a zmenit hru az minusy zacnou prevazovat. Jinak nevim co s tim :)

Re:Nový projekt vs. cizí kód
« Odpověď #104 kdy: 16. 09. 2020, 12:18:15 »
Proboha, co je to tad za filozofické debaty?

99% Softwaru co se dělá v České Republice (odmyslím si originální software což je to 1%) je sedmkrát přeprodaný produkt od západních (dnes už i východních) nadnárodních korporací, které se 7x přeprodaly jen za jediným účelem - zbavit se zodpovědnosti na straně klienta - product/project managera (menežuje nám to dodavatel X), a cutovat costy (poslali jsem to do ČR kluci, ti to tam zase udělají za 1/4 náklady co u nás, hlupáci).

Pokud nejste úplně mimo, a ve firmě se mimo čučení do 10 let starýho monitoru občas zvednete ze židle a kouknete vlevo vpravo, pak si tohoto jistě všimnete.

Z principu věci v těchto "netechnických" korporátech budou za levno vždy vznikat sračky, protože typicky cílem jakéhokoliv manažera je najmout přesně takové lidi, kteří daný úkol zvládnou, ale už ani o vlásek lepší a dražší, pač potřebujeme ušetřit, KPIčka, bonusy, klasika.

Níže popíšu lifecycle takového typického "českého" softwarového projektu, na který vidíte nabídky na všech pracovních portálech v čr.

Korporát "Z" - klient.
Dodavatel "X" - firma pro kterou nějakej chudák programuje.

V korporátu "Z" se nějaký middle manažer+ rozhodne, že chce šplhat po žebříku, vymyslí se nějaký projekt.
Neudělá se žádná analýza, nic, na pár jednáních se pije kafe a melou klasické nesmysly z patra, přičemž máme přebytek musíme investovat tak i sebevětší blbost se nějak protlačí, vrchní 65 let Hanz se stříbrnými vlasy dosrká kafe, řekne "ok kluci, tak pěkná prezentace, zksute to". Agency a stakeholder problém v praxi.

Tadle sračka, bez jakéhokoliv opravdového zadání s tím že "to se nějak potom domyslí a udělá" se dá do výběrka, kde se přihlásí několik klasických lopato-firem, které budou lhát až se jim z uší bude kouřit co všechno za jak málo udělají.
I zamyslí se korporát "Z", a nakonec to dá tomu nejlevnějšímu, nebo nejulhanějšímu, pravděpodobně oboje dohromady.

Hra se přesouvá k dodavateli "X". Ten vytlačí nějaké lži na jobs/startupjobs/linkedin/agenturám a začíná spam na nebožáky "programátory", řekněmě spíš "vývojáře high level webových aplikací za pomocí bazilionu knihoven", hlavně moc nepřemýšlět nebo to chudák ani neslepí.

Následuje výběrko kde 20letá "HR" holka testuje a vyzpovídá starší lidi, div že po nich nevyžaduje vzorek stolice. Následuje přetahovaná v tom, kdo víc zalže a přechytračí toho druhého - nakonec se podávají ruce, nebožák jde za podtržní peníze dělat na "projektu", který nemá žádné zadání.

Nebožák je samozřejmě patlal (protože někoho dražšího přece najímat nebudeme, nevyšel by budget), takže lepí, neví, blbne, plete, až z toho za pár měsíců uplete takovou sračku, že se pakuje pryč z firmy, než to bouchne. Dodavatel "Z" nastoupí do modu "damage control" a nastaví svůj generátor lží na 10x, probíhaj zrychlený výběrka a nabíraj se noví chudáci, kteří při práci na té sračce div, že nevysokčí z okna.

Projekt začíná mít skluz, klient nevrlý, dodavatel už vyčerpal celý zásobník programátorů a blbá situace - tak se udělá meeting a řekne se "no už jsme tenhle projekt milknuli co to dalo, šlo to do zadeke klasicky, lidi co ještě neodešeli jsou brutálně nasraný, tak to pustíme dál jiným dodavatelům, at' si taky užijou". Tak to dodavatel klientovi vrátí, projekták dostane od šéfa u klienta na zadek, tytyty a musíme udělat nové výběrko a jede se dál.

Do měsíce to přebere jiná firma, rinse and repeat.

Během 4 let se na takovém projektu vystřídá těch firem klidně i 5, desítky programátorů.

Zní vám to povědomě? To je 9 z 10 projektů v ČR.

Takže, proto ^ nechci dělat na "legacy" aplikaci.
Ono ani ten "greenfield" bez zadání/se špatným zadáním dopadne úplně stejně.


Tak kluci hodně štěstí, já se jdu věnovat v životě nečemu užitečnějšímu.