Mozno sa testovalo rovno na produkcnom systeme .... kto by udrziaval testovaci :) ... okrem toho sa na testovacom zanasa bordel, deploy-uje sa tam krizom krazom ... Nie som toho zastancom, ale u nas to tak obcas robime tiez :)
ale pri takychto cislach .... minimalne by som vypol autocommit :)
taka banka nie je amazon ani youtube, ich databaza by nemala byt radovo vacsia ako par TB. urobit kopiu produkcie na testovanie by nemal byt ziaden problem. podla mna sa jednoducho dostal bug na produkciu, ktory nezachytili pri testovani. aj ked testujes dokladne nemas sancu otestovat vsetky mozne scenaria. stava sa.
s ako citlivými dátami pracuješ. Ja pracujem v energetike a keby som im do produkcie zavliekol niečo, na čo nemám "štempel" od vlastníka procesu, vlastníka systému a kľúčového užívateľa, tak by som ako dodávateľ do jedného dňa od odhalenia skončil.
testovat na produkcii bankove systemy to myslis vazne? A bordel na testovacom prostredi je chyba lenivych a amaterskych programatorov, nikoho ineho.. Len ich samych.. My vyvijame na lokalnych masinach, mame dve testovacie prostredia a jedno produkcne. localhost -> dev -> uat -> prod. Ano, proces je pomalsi ako hala bala deployovat ale mame to pretestovane my a zakaznik tiez.
Vo fintech to tak nefunguje - to by nepresli audit - to mozem garantovat. V podstate BA (Business Analyst) a PM (Project Manager) zadaju programatorovi nejaku ulohu. Ak je to klasicky developer a nie System Analyst, tak v podstate nema ani moc sajnu co vlastne programuje. BA a PM mu v podstate ukazu co ma jeho kod robit. Ked je kod hotovi ide na testing do QA (Quality Assurance). QA vytvori regression test plan a testuje krok po kroku - Ak najdu defect poslu to nas5 programatorovi, ak nie daju sign off. Ako tu kolega spominal ak je change vyziadana zakaznikom nasleduje UAT (User Acceptance Testing). A az ked vsetko dobre funguje (QA team/zakaznik (v pripade UAT) da sign off) az potom sa otvara change ticket na deployment do produkcie. Change ticket musi byt approvnuty tem leadeom/line manager a prebraty na CAB (Change Advisory Board) meetingu. No a po vsetkej tejto torture sa otvara ticket do Production Deployment teamu, ktory to deplojuje do produkcie (tym iba chcem povedat, ze v pripade napr PLSQL change autocommit v ziadnom pripade nehrozi). Takto to funguje vo Fintech. Samozrejme v online betting/ gaming industry to tak nieje - tam musia byt flexibilni - inak by ich konkurencia rozbila - tam musi byt novinka v produkcii okamzite (Ked zavedie nieco cool Victor Chandler (Bet Victor) WilliamHill to musi matt cca do tyzdna inak straca zakaznikov a naopak - tam su postupi ine.) Ale vo Fintechu deployment do produkcie je velice dlhy a bolavy proces. Samozrejme chyba sa moze stat - ale je to malo pravdepodobne. co sa tyka Environmentov napr u nas vo firme mame Test Env/Dev Env/QA Env/DR Env a Prod Env. Dev Env je delene na cca 15 klonov - tj. kazdy projekt ma vlastne Dev Env. Tak to bol maly uvod do toho ako funguje Fintech.
skor to vyzera tak,z e sikovny programator prepasoval bug tak, aby pri tych x mld prehodenych kade-tade sa par mil stratilo pri zaokruhlovani na spravny ucet ;)
V zdravotnickej technike musí developer obhájiť zmenu ešte pred tým, ako ju napíše do kódu. Teda nepostupuje sa metódou - napíšem niečo a testujem, čo to robí, ale diskutuje sa ešte pred implementáciou o tom, čo keď urobíme aké to bude mať dôsledky. Spôsob implementácie je teda odsúhlasený vopred. Kvalitári nám tvrdili, že objavenie chyby v štádiu designu je najlacnejšie objavenie chyby.
V zdravotníckom softwari sa o každej zmene napíše podrobná správa - ja tam uvedený každý zmenený alebo pridaný riadok aj s vysvetlením prečo to bolo tak urobené.
aj rozumiem tomu, že chyby sa robia a niekedy sa odhalia až v produkcii. Mňa len zarazila časť nadpisu "chybu urobil programátor" . Ako keby sa na vývoji danej funkčnosti podieľali iba programátori a nikto iný.Samozrejme, že programátori robia chyby, veď sú ľudia. Ale sú tam ďalší ľudia, ktorých úlohou je tieto chyby odhaliť a eliminovať. Veď by tam mali byť nejaké interné testy, integračné testy, užívateľské akceptačné testy až následne by to malo ísť do produkcie. Teda zvaliť celú vinu na programátora je hlúposť. Skôr naopak. Ak sa v produkcii objavia chyby, je to predovšetkým maslo na hlave ľudí zodpovedných za proces testovania.
Iba ze by bol pan programator firemny guru, tester, sef atd. v jednej osobe ... Teda osoba, ktora chyby nerobi, a ked robi, tak sa o nich nediskutuje. Bo su aj taki ...
ale ved aj vo VW vraj za ten emisny skandal mohol nejaky programator. vedenie o to nic nevedel, proste len ten programatro bol az prilis aktivny. veduci chyby nerobia.
Inak keď sa diskutuje pri článku o tom, že banky zvyšujú poplatky, tak tam niektorí inteligenti tvrdia, že bankové transakcie realizuje softvér automaticky, tak prečo si vlastne banka za to účtuje poplatok. No preto, že ten softvér je drahý a je náročné to implementovať a otestovať to tak aby sa nestávali podobné kiksy ako tento.
Programátor?!?!? Neexistuje. Mohla to preklepnúť účtovníčka, čo sa už stalo. Jednalo sa o 1 milión korún. Príjemca ho v dobrej viere okamžite vybral z účtu a roztočil.
Nepresúva sa žiadny fyzický tovar ako zlato, platina, diamanty a podobne. Len sa presunú čísla z jedného účtu na druhý. Takže to nie je až také obtiažne to získať naspäť. Veď v podstate ti opäť len niekto zmení čísla, ktoré sa viažu k tvojmu účtu.
???
Nie som toho zastancom, ale u nas to tak obcas robime tiez :)
ale pri takychto cislach .... minimalne by som vypol autocommit :)
záleží na tom,
ste amateri
V podstate BA (Business Analyst) a PM (Project Manager) zadaju programatorovi nejaku ulohu. Ak je to klasicky developer a nie System Analyst, tak v podstate nema ani moc sajnu co vlastne programuje. BA a PM mu v podstate ukazu co ma jeho kod robit. Ked je kod hotovi ide na testing do QA (Quality Assurance). QA vytvori regression test plan a testuje krok po kroku - Ak najdu defect poslu to nas5 programatorovi, ak nie daju sign off. Ako tu kolega spominal ak je change vyziadana zakaznikom nasleduje UAT (User Acceptance Testing). A az ked vsetko dobre funguje (QA team/zakaznik (v pripade UAT) da sign off) az potom sa otvara change ticket na deployment do produkcie. Change ticket musi byt approvnuty tem leadeom/line manager a prebraty na CAB (Change Advisory Board) meetingu. No a po vsetkej tejto torture sa otvara ticket do Production Deployment teamu, ktory to deplojuje do produkcie (tym iba chcem povedat, ze v pripade napr PLSQL change autocommit v ziadnom pripade nehrozi).
Takto to funguje vo Fintech. Samozrejme v online betting/ gaming industry to tak nieje - tam musia byt flexibilni - inak by ich konkurencia rozbila - tam musi byt novinka v produkcii okamzite (Ked zavedie nieco cool Victor Chandler (Bet Victor) WilliamHill to musi matt cca do tyzdna inak straca zakaznikov a naopak - tam su postupi ine.) Ale vo Fintechu deployment do produkcie je velice dlhy a bolavy proces. Samozrejme chyba sa moze stat - ale je to malo pravdepodobne.
co sa tyka Environmentov napr u nas vo firme mame Test Env/Dev Env/QA Env/DR Env a Prod Env. Dev Env je delene na cca 15 klonov - tj. kazdy projekt ma vlastne Dev Env.
Tak to bol maly uvod do toho ako funguje Fintech.
V zdravotníckom softwari sa o každej zmene napíše podrobná správa - ja tam uvedený každý zmenený alebo pridaný riadok aj s vysvetlením prečo to bolo tak urobené.
áno programujem
haha
Inak keď sa diskutuje pri článku o tom, že banky zvyšujú poplatky, tak tam niektorí inteligenti tvrdia, že bankové transakcie realizuje softvér automaticky, tak prečo si vlastne banka za to účtuje poplatok. No preto, že ten softvér je drahý a je náročné to implementovať a otestovať to tak aby sa nestávali podobné kiksy ako tento.