Metodologie vývoje komplikované funkcionality v komplikované komponentě

anonymni

Tohle zna vetsina vyvojaru pracujicich na komplexnich backendovych slozitych komponentach.

Alokuji vas na projekt, kde mate za ukol spravu a vyvoj slozite komponenty, kterou uplne neznate a nikdy vlastne uplne detailne znat nebudete.

Dostanete od analytika za ukol implementaci netrivialni funkcionality, ktera neni zadana uplne 100% - nejsou v ni jeste rozresene uplne vsechny detaily, cast vykrystalizuje az v prubehu samotne implememntace.

Komponenta samotna je slozita a castecne je to legacy, vy se v ni tak dobr neorientujete, a ukol, ktery mate zadany, bude zasahovat do mnoha jejich ruznych casti, ktere uplne nevite, jak vlastne funguji.

To znamena, ze je to celkove slozita prace, ktera skrz na skrz obsahuje mnoho navzajem souvisejicich neznamych.


Moje otazka je, jak k tomu vlastne pristupovat. Je to tak standardni situace, ze jsem si rikal, ze by k tomu mohla byt formalizovana nejaka metodologie prace.


Ja se snazim delat tohle, ale myslim, ze to neni uplne optimalni:

1. Udelam si zakladni analyzu kodu, co kde a jak budu implementovat a jak to funguje doposud. Tahle cast je dost time-consuming a spatne se trackuje jeji progres, protoze zavery z ni dokazi byt vysoce promenlive s tim, jak clovek jde hloubeji do kodu. V podstate nema pevne hranice toho, kdy je vlastne skoncena, protoze komponenta muze byt slozita, ze by mohlo trvat tydny dostat z toho nejaky definitivni zaver. Takze tady se nesmi stravit mnoho casu.

2. Ta nova funkcionalita zpravidla reaguje na nejaky vstup a ma mit nejaky vystup. Proto nejprve se zkusim zamerit na napsani testu - TDD, coz jsou moje prvni krucky ke konkretni implementaci, pomuze mi to problem uchopit za nejaku konkretni konec a zacit neco konecne delat. Udelam tedy par novych testu, ktere budou do dilcich casti komponent strkat nova vstupni data.

3. V prubehu celeho tohoto procesu postupne vykrystalizuji dilci ukoly, ze kterych se bude implementace skladat. Tyto ukoly si sepisu do seznamu.

4. Jak prace zacne narustat a komplikuje se, musim si vezt nejaky dokument, kde si eviduju poznamky ke kodu a ruzna zjisteni a TODO, protoze jinak bych se v tom vsem proste za par dni ztratil.


Ted v tomto celem procesu klasicky existuji prvky, ktere znemoznuji nejake normalni postupny progress. Zpravidla ruzne male blockery, vetsinou zpusobene tim, ze se na neco potrebuju nekoho zeptat a ten nekdo nevi, popr. jeste nevi, nebo nema cas. Kvuli toho nejen ze musim resit slozity ukol, ale jeste musim ruzne klickovat mezi pod-ukoly a pracovat se spoustou neznamych tak, aby prace nestala.

Nakonec je z toho zamotane klubko vseho mozneho a me v tom chybi nejaka poradne formalizovana metodologie prace, ktera by pomohla nejen to klubko nejak standardne rozmotavat, ale jeste navic i praci dobre trackovat, napr. do JIRA, aby sel nejakym zpusobem videt den za dnem progres.

Ja nastesti mam praci takovou, ze na me nikdo nejak extra netlaci, a kdyz neco jeste neni, tak to proste neni, a nikdo me nebuzeruje. Ale jsou i prace, kde se progres musi spravne trackovat a jeste navic se musi odhadovat narocnost. A myslim si, ze to uz chce mit nejakou poradnou robustni metodologii.

Existuje neco takoveho?

Diky
« Poslední změna: 05. 12. 2018, 16:33:21 od Petr Krčmář »


Na to je takáto metodika: začneš vytlačením tej úlohy od analytika. Následne mu výtlačok otlčieš o hlavu za tú úlohu-neúlohu. Potom vytlačíš zdroják tej komponenty. Ním zas umlátiš jeho autora za ten prehľadný kód. No a napokon vytlačíš túto otázku a ňou zas vytrieskaš seba, napríklad za nápad zasahovať do kódu ktorý ani nevieš ako funguje.

Prepáč, ale na túto zbierku nezmyslov sa nedá inak reagovať. Nenapísal si ani jazyk, ani úlohu, ako keby existovala jednotná, univerzálna metodika bez ohľadu na možnosti konkrétneho jazyka, konkrétnej úlohy - domény problému, atď. Nič také neexistuje. A ani nemusí, takto choro to asi funguje len u vás.

PS: Tak ma napadá ... ak hľadáš len zbierku generických, pseudoodborných žvástov bez praktického úžitku, potom si vlastne na správnom mieste...

Okoloiduci

Waldemar ty oPica. Reagujes ako cisty troll co nemal v zivote otvoreny IDE a v nom velky zasrackovany projekt.

Ano aj velke zasrackovane projekty su krutou realitou denneho chleba programatora.

Celkom by ma tiez zaujimalo ako sa riesia alebo ako ini riesia taketo ulohy.

dfasdfasdf


1. Udelam si zakladni analyzu kodu, co kde a jak budu implementovat a jak to funguje doposud. Tahle cast je dost time-consuming a spatne se trackuje jeji progres, protoze zavery z ni dokazi byt vysoce promenlive s tim, jak clovek jde hloubeji do kodu. V podstate nema pevne hranice toho, kdy je vlastne skoncena, protoze komponenta muze byt slozita, ze by mohlo trvat tydny dostat z toho nejaky definitivni zaver. Takze tady se nesmi stravit mnoho casu.

2. Ta nova funkcionalita zpravidla reaguje na nejaky vstup a ma mit nejaky vystup. Proto nejprve se zkusim zamerit na napsani testu - TDD, coz jsou moje prvni krucky ke konkretni implementaci, pomuze mi to problem uchopit za nejaku konkretni konec a zacit neco konecne delat. Udelam tedy par novych testu, ktere budou do dilcich casti komponent strkat nova vstupni data.

3. V prubehu celeho tohoto procesu postupne vykrystalizuji dilci ukoly, ze kterych se bude implementace skladat. Tyto ukoly si sepisu do seznamu.

4. Jak prace zacne narustat a komplikuje se, musim si vezt nejaky dokument, kde si eviduju poznamky ke kodu a ruzna zjisteni a TODO, protoze jinak bych se v tom vsem proste za par dni ztratil.


ad 1) udelas si svoji pracovni vetev v gitu a ke kazdemu modulu, metode si pri studiu napises v kodu komentare,
co jsi zjistil, tak nezapomenes co jsi zjistil. takze mas to primo v kodu a nemusis udrzovat dokumentaci jinde.

ad 2) mozna neni treba hned zkouset vstupy a vystupy, ale spise si udelat testovaci kod pro nejdulezitejsi/nejslozitejsi
metody co potrebujes pochopit.

ad 3) primo do kodu si muzes psat TODO komenty, pak staci vygrepovat.

ad 4) jsem pro to si to vsecko komentovat primo do kodu a pak doxygenem vygenerovat dokumentaci, ktera se
bude hodit tobe i dalsim lide, tridy, metody, vazby mezi tridama.

pomuze malovani grafu propojeni trid a metod, na stenu si nalep velikansky papir a tam si postupne maluj moduly/ tridy/metody. kdyz ti nejaka cas nebude sedet, tak ji prelep cistou A4 a kus prekresli.

nejaky zaslouzily programator (snad linus torvalds) rikal, ze ve slozitem projektu je nejlepsi pochopit jaka je struktura trid, struktur, objektu a az potom algoritmy.



Waldemar ty oPica. Reagujes ako cisty troll co nemal v zivote otvoreny IDE a v nom velky zasrackovany projekt.

Ano aj velke zasrackovane projekty su krutou realitou denneho chleba programatora.

Celkom by ma tiez zaujimalo ako sa riesia alebo ako ini riesia taketo ulohy.

To bude tým, že mojou realitou "zasračkované projekty" nie sú. Čo je zas tým, tak ako frontend musí byť riešený komponentovo, tak aj samotný backend musí byť riešený loose coupled. Zvlášť api gateway či graphql server, biznis logika zvlášť, v kontainerizovaných mikroservisoch, plus nejaká message queue, atď. Nič iné ma nezaujíma, neprehľadné sračky nech si rieši autor, ja tu od toho nie som.

Waldemar ty oPica. Reagujes ako cisty troll co nemal v zivote otvoreny IDE a v nom velky zasrackovany projekt.

Ano aj velke zasrackovane projekty su krutou realitou denneho chleba programatora.

Celkom by ma tiez zaujimalo ako sa riesia alebo ako ini riesia taketo ulohy.

To bude tým, že mojou realitou "zasračkované projekty" nie sú. Čo je zas tým, tak ako frontend musí byť riešený komponentovo, tak aj samotný backend musí byť riešený loose coupled. Zvlášť api gateway či graphql server, biznis logika zvlášť, v kontainerizovaných mikroservisoch, plus nejaká message queue, atď. Nič iné ma nezaujíma, neprehľadné sračky nech si rieši autor, ja tu od toho nie som.

Autor odesel... do jine firmy, do duchodu, do pekla.... Co ted?

anonymni

A kdo rikal ze mam zasrackovany projekt? To ze je neco komplexni s castmi starsiho data neznamena, ze je to sracka.

Nereálné požadavky

Waldemar ty oPica. Reagujes ako cisty troll co nemal v zivote otvoreny IDE a v nom velky zasrackovany projekt.

Ano aj velke zasrackovane projekty su krutou realitou denneho chleba programatora.

Celkom by ma tiez zaujimalo ako sa riesia alebo ako ini riesia taketo ulohy.

To bude tým, že mojou realitou "zasračkované projekty" nie sú. Čo je zas tým, tak ako frontend musí byť riešený komponentovo, tak aj samotný backend musí byť riešený loose coupled. Zvlášť api gateway či graphql server, biznis logika zvlášť, v kontainerizovaných mikroservisoch, plus nejaká message queue, atď. Nič iné ma nezaujíma, neprehľadné sračky nech si rieši autor, ja tu od toho nie som.

Tvojí doménou nejsou zasračkované projekty, ale jako první napíšeš do vlákna, kde se řeší...
Hmm, co kdybys třeba šel na fórum o autech napsat, že jsi volkswagen nikdy neřídil? Nebylo by to pro všechny zde lepší?

dfasdfasdf

a ted se uz vsichni vyserte na trolleni a odpovidejte k tematu.
je to zajimave tema.

Meh

Prepáč, ale na túto zbierku nezmyslov sa nedá inak reagovať. Nenapísal si ani jazyk...

Z textu jasne vyplyva, ze jde o Javu.

Prepáč, ale na túto zbierku nezmyslov sa nedá inak reagovať. Nenapísal si ani jazyk...

Z textu jasne vyplyva, ze jde o Javu.

Leda hovno. Vôbec to z textu nevyplýva a pokojne mohol hovoriť o PHP. A hoci som aj ja hovoril o Jave, tiež to z textu nevyplýva.

Prepáč, ale na túto zbierku nezmyslov sa nedá inak reagovať. Nenapísal si ani jazyk...

Z textu jasne vyplyva, ze jde o Javu.
;D

Prepáč, ale na túto zbierku nezmyslov sa nedá inak reagovať. Nenapísal si ani jazyk...

Z textu jasne vyplyva, ze jde o Javu.

Leda hovno. Vôbec to z textu nevyplýva a pokojne mohol hovoriť o PHP. A hoci som aj ja hovoril o Jave, tiež to z textu nevyplýva.
;D ;D

Zajeď si do Pelhřimova...