Nový projekt vs. cizí kód

[listoper]

Mam zkusenost, ze spousta vyvojaru se brani praci na softwaru ktery je uz nejakou dobu na svete a preferuji praci na projektech kde se zacina od nuly.

Zajimalo by me proc to tak je.
A taky u tech co to tak nemaji, co se jim libi na udrzbe a rozvoji starsiho softwaru.

Ja mam zkusenosti z obou stran a nemuzu rict, ze bych spatroval u GF vyvoje nejake vyhody.

Co ostatni?

[Reklama]

[RDa]

To je asi jednoduchy - protoze do existujiciho projektu je potreba pridat malou featuru, coz znamena male penize. Neni zde prostor (casovy, financni) na to, aby to bylo udelano spravne - tj. se to cele predelalo, takze se kupi zaplata na zaplatu.. az je z toho neudrzovatelny bastl.

Pri vyvoji z nuly je zadavateli jasne, ze to bude stat hodne, takze jsou vsechny strany v pohode.

A kdo jiz neco delal.. vi ze az bude muset delat neco noveho, tak to udela spis jinak - protoze ma ty zkusenosti. A toto lze aplikovat jen u toho noveho projektu. Nelze ocekavat od programatoru, ze daj neco napoprve dobre - takze bud se jim poskytne prostor to udelat znova.. nebo se holt vsichni dohodnou, ze to bude holt meh.. a nikoho to trapit "nebude".

[listoper]

To je asi jednoduchy - protoze do existujiciho projektu je potreba pridat malou featuru, coz znamena male penize. Neni zde prostor (casovy, financni) na to, aby to bylo udelano spravne - tj. se to cele predelalo, takze se kupi zaplata na zaplatu.. az je z toho neudrzovatelny bastl.

Ale tak to vubec nemusi byt. Zazil sem projekty ktery startovali v devadesatkach a porad se do nich investuji velky penize.

Pri vyvoji z nuly je zadavateli jasne, ze to bude stat hodne, takze jsou vsechny strany v pohode.

...
Nelze ocekavat od programatoru, ze daj neco napoprve dobre - takze bud se jim poskytne prostor to udelat znova.. nebo se holt vsichni dohodnou, ze to bude holt meh.. a nikoho to trapit "nebude".

Software se snad jmenuje "soft" proto ze ho jde snadno(levne) zmenit... na rozdil od hardware ktery se musi vetsinou vymenit.... Uz sme se dostali tak daleko, ze i software se musi zahodit a prepsat?

[by_cx]

Je projekt a projekt. Pokud nejsou nějaké tlaky na tým, že se nesmí refactorovat ať už databáze nebo kód samotný, případně když ten kód není dvě dekády staré abstraktní umění, tak nemám problém se zapojit do vývoje. Ale projekty, firmy i lidé jsou různí, takže tak :-)

[tomas88]

Mě to příjde jasné. Člověka obecně baví něco budovat. A programování je dosti (někdy bohužel) kreativní činnost. No a ta kreativita v případě přebírání projektu jaksi odpadá.

[Reklama]

[redustin]

IMO především záleží na majiteli kódu, zda si ohlídá, aby byl kód dlouhodobě udržovatelný, nebo na to rezignuje. Netypované jazyky, zbytečné míchání různých jazyků v projektu, s tím související pravidelné naskakování na aktuální hype, ale i házení klacků pod nohy kontrolám kompilátoru a IDE (často zbytečné používání reflexe, míchání kódu a nikdy nevyužitých XML konfigurací s názvy programových prvků), nepřesné názvy, duplikace kódu místo vytažení do generického předka, hashmapy místo konkrétních datových struktur, atd atd. Klasika.

[Mlocik97]

80% projektov, ktoré sú hodne staré, a boli xyz krát plátané majú taký kód, s ktorým pracovať vyzerá asi tak, že zmažeš medzeru v komentári, a namiesto programu pre otváranie archívov máš program, ktorý ti zahrá na husličky "error". Hlavne keď sa tam vystrieda stovka programátorov, ktorý spolu ani nerobili, a tak jeden nevie akú štruktúru udržoval pôvodný tvorca kódu.

U nových projektov môžeš rovno ako vývojár navrhnúť týmu štuktúru, princípi atp, ktorej budú všetci tý čo boli pri vytváraní projektu rozumieť.

Najhoršie je to u projektov, kde úplne chýba systémová príručka a dokumentácia kódu.

[listoper]

80% projektov, ktoré sú hodne staré, a boli xyz krát plátané majú taký kód, s ktorým pracovať vyzerá asi tak, že zmažeš medzeru v komentári, a namiesto programu pre otváranie archívov máš program, ktorý ti zahrá na husličky "error". Hlavne keď sa tam vystrieda stovka programátorov, ktorý spolu ani nerobili, a tak jeden nevie akú štruktúru udržoval pôvodný tvorca kódu.

U nových projektov môžeš rovno ako vývojár navrhnúť týmu štuktúru, princípi atp, ktorej budú všetci tý čo boli pri vytváraní projektu rozumieť.

Najhoršie je to u projektov, kde úplne chýba systémová príručka a dokumentácia kódu.

Takze zivotnost projektu je stejna jako teamu lidi co u toho byl kdyz to zacalo?
Pokud se obmeni tym tak uz nema cenu to dal udrzovat a musi se to prepsat?

[Mlocik97]

80% projektov, ktoré sú hodne staré, a boli xyz krát plátané majú taký kód, s ktorým pracovať vyzerá asi tak, že zmažeš medzeru v komentári, a namiesto programu pre otváranie archívov máš program, ktorý ti zahrá na husličky "error". Hlavne keď sa tam vystrieda stovka programátorov, ktorý spolu ani nerobili, a tak jeden nevie akú štruktúru udržoval pôvodný tvorca kódu.

U nových projektov môžeš rovno ako vývojár navrhnúť týmu štuktúru, princípi atp, ktorej budú všetci tý čo boli pri vytváraní projektu rozumieť.

Najhoršie je to u projektov, kde úplne chýba systémová príručka a dokumentácia kódu.

Takze zivotnost projektu je stejna jako team lidi co u toho byl kdyz to zacalo?
Pokud se obmeni tym tak uz nema cenu to dal udrzovat a musi se to prepsat?

Ne úplne, záleží od viacerých faktorov, a to predovšetkým aká je štruktúra, a či je ľahko pochopitelná pre nových programátorov v týme, či je zdrojový kód zdokumentovaný, alebo aj od zloženia samotného týmu. Vo väčšine prípadov ak je štruktúra rozumne navrhnutá a ľahko pochopitelná a navyše dobre zdokumentovaná, tak ďalší programátor vie na to naviazať tak, že tú štruktúru zachová... ak je situácia opačná tak ani tak to hneď neznamená že sa nedá s tým pracovať, ale časom ako sa začne štruktúra čím viac miešať a komplikovať, tým je to horšie.

Je bežné že nový programátor v týme dostáva čas na preštudovanie štruktúry a dokumentácie, a z počiatku pracuje na len konkrétnych metódach/funkciách, a má predpripravené tie najkomplikovanejšie štrukturálne časti od senior programátora, ktorý v týme je už nejaký čas.

[Mlocik97]

A tiež na to vplýva aj refaktorizácia, a koľko času sa tomu venuje.

[listoper]

80% projektov, ktoré sú hodne staré, a boli xyz krát plátané majú taký kód, s ktorým pracovať vyzerá asi tak, že zmažeš medzeru v komentári, a namiesto programu pre otváranie archívov máš program, ktorý ti zahrá na husličky "error". Hlavne keď sa tam vystrieda stovka programátorov, ktorý spolu ani nerobili, a tak jeden nevie akú štruktúru udržoval pôvodný tvorca kódu.

U nových projektov môžeš rovno ako vývojár navrhnúť týmu štuktúru, princípi atp, ktorej budú všetci tý čo boli pri vytváraní projektu rozumieť.

Najhoršie je to u projektov, kde úplne chýba systémová príručka a dokumentácia kódu.

Takze zivotnost projektu je stejna jako team lidi co u toho byl kdyz to zacalo?
Pokud se obmeni tym tak uz nema cenu to dal udrzovat a musi se to prepsat?

Ne úplne, záleží od viacerých faktorov, a to predovšetkým aká je štruktúra, a či je ľahko pochopitelná pre nových programátorov v týme, či je zdrojový kód zdokumentovaný, alebo aj od zloženia samotného týmu. Vo väčšine prípadov ak je štruktúra rozumne navrhnutá a ľahko pochopitelná a navyše dobre zdokumentovaná, tak ďalší programátor vie na to naviazať tak, že tú štruktúru zachová... ak je situácia opačná tak ani tak to hneď neznamená že sa nedá s tým pracovať, ale časom ako sa začne štruktúra čím viac miešať a komplikovať, tým je to horšie.

Je bežné že nový programátor v týme dostáva čas na preštudovanie štruktúry a dokumentácie, a z počiatku pracuje na len konkrétnych metódach/funkciách, a má predpripravené tie najkomplikovanejšie štrukturálne časti od senior programátora, ktorý v týme je už nejaký čas.

Z toho co rikas mi vyplyva, ze pokud mam dobre programatory (kteri udrzuji strukturu, dokumentuji....) muzu si dovolit delat i na starsim kodu.
Pokud mam spatne programatory tak je z toho vzdycky hnuj a musi se to prepsat... ale nutne z toho bude zase hnuj... dokud nenajdu dobre programatory.

OK. takze odpoved na moji otazku z toho by byla...
"Na dlouhobezicich projektech se stihne vystridat vic lidi, a proto logicky i vic spatnych programatoru, a proto je to logicky vetsi hnuj a proto to nikdo nechce delat."

Chapu te spravne?

[Jiří Havel]

Software se snad jmenuje "soft" proto ze ho jde snadno(levne) zmenit... na rozdil od hardware ktery se musi vetsinou vymenit.... Uz sme se dostali tak daleko, ze i software se musi zahodit a prepsat?

Odkud se vzalo slovo software je zajímavá otázka.

Ale že by se dal software nějak snadno a levně měnit je dost úsměvné. Vždyť spousta věcí změnit vůbec nejde, protože by to bylo tak drahé, že to nikdo nezaplatí. Právě z tohohle důvodu je spousta legacy systémů hromada rovnáků na vohejbáky na předchozí rovnáky. Nasbírat nesplatitelný technologický dluh je strašně jednoduché. Vlastně stačí předpokládat, že změny jsou jednoduché a tlačit na to aby byly i levné.

Změny jsou brutálně drahé. A čím dál je ta změna od původního návrhu, tím je dražší. Agilní metodika dělá změny trochu zvládnutelnější, ale i tak to není žádná hitparáda.

[Jiří Havel]

OK. takze odpoved na moji otazku z toho by byla...
"Na dlouhobezicich projektech se stihne vystridat vic lidi, a proto logicky i vic spatnych programatoru, a proto je to logicky vetsi hnuj a proto to nikdo nechce delat."

Chapu te spravne?

Ono to není primárně o kvalitě jednotlivých programátorů, ale procesu jako celku. Tým mizerných programátorů dobrý proces nespáchá. Ale dobří senioři zvládnou využít i mizerného programátora (samozřejmě v mezích).

Jak dobrý byl původní návrh? Každou chybějící informaci si musel tým vycucat z prstu.
Jak moc se nové požadavky odchýlily od původního návrhu? Vždycky je to o kompromisu a nedá se připravit na všecny možné změny.
Jak moc se tlačilo na čas a kašlalo na technologický dluh?
Jak dobře je zvládnuté testování? Bez pořádných testů se do kódu nedá v podstatě hrábnout.

[listoper]

Software se snad jmenuje "soft" proto ze ho jde snadno(levne) zmenit... na rozdil od hardware ktery se musi vetsinou vymenit.... Uz sme se dostali tak daleko, ze i software se musi zahodit a prepsat?

Ale že by se dal software nějak snadno a levně měnit je dost úsměvné.

levne mysleno pri srovnani s HW.
Aby uz nemuseli vznikat jednoucelove pocitace ale jedna masina zvladala vic veci podle toho co ji podstrcim za "kod/binarku/EPROM"

Sice uz sem dobu kdy se rozvazeli po telefonich ustrednach sady ROMek na vymenu nezazil ale cetl jsem o tom ;-)

Kdyby nebyl software a kazda zmena by znamenala vyhodit a nakoupit nove pocitace "na kterych to bezi" vyslo by to zatracene draz... (krome pripadu kdy bezi jednotky instanci)

[listoper]

OK. takze odpoved na moji otazku z toho by byla...
"Na dlouhobezicich projektech se stihne vystridat vic lidi, a proto logicky i vic spatnych programatoru, a proto je to logicky vetsi hnuj a proto to nikdo nechce delat."

Chapu te spravne?

Ono to není primárně o kvalitě jednotlivých programátorů, ale procesu jako celku. Tým mizerných programátorů dobrý proces nespáchá. Ale dobří senioři zvládnou využít i mizerného programátora (samozřejmě v mezích).

Jak dobrý byl původní návrh? Každou chybějící informaci si musel tým vycucat z prstu.
Jak moc se nové požadavky odchýlily od původního návrhu? Vždycky je to o kompromisu a nedá se připravit na všecny možné změny.
Jak moc se tlačilo na čas a kašlalo na technologický dluh?
Jak dobře je zvládnuté testování? Bez pořádných testů se do kódu nedá v podstatě hrábnout.

Dobre... zpet k zakladni otazce a motivaci k ni.
Myslim, ze dlouhodobe neni udrzitelne kazde 2 roky vsechno prepisovat.

Myslim, ze to, ze se s tim vlastne pocita, protoze na starsich projektech nechce nikdo delat a zakaznici uz si zvykli platit kazde 2 roky za prepis.... vede k tomu, ze uz ani neni treba se snazit aby to k necemu bylo. A proto neni... A proto se to musi prepsat... a tak porad dokolecka.

Chapu, ze se to muze libit manazerum v bodyshop firmach... protoze maji porad vejvar na dalsich a dalsich prepisech kde prodavaji juniory za seniorni rate....

Ale uz nechapu, ze se na tom divadle chce podilet nekdo z vyvojaru... (proto ma puvodni ta otazka)
A hlavne nechapu, ze si to nechaji libit ti co za to plati...