Komentáře k článku

Technický dluh

Každý kdo nějakou dobu programuje, to už nejspíš zažil – v kódu je absolutní chaos, úpravy trvají déle, než kdo předpokládal, noví programátoři se zaučují čtvrt roku, a když už se konečně podaří něco dokončit, tak je to samá chyba.

Zpět na článek

23 komentářů k článku Technický dluh:

  1. Oldřich Vetešník

    Hezké, díky za článek. :) Bohužel mám zkušenost až tak děsivou, že ten kód, se kterým jsem se setkal, byl už tak špatný, že nejen že se kdokoliv bál tam cokoliv dělat, ale ani ty testy na to nešly napsat. Takovou tu nálepku „dobrý kód = drahý kód“ nejspíš dostal v momentě, kdy si někdo řekl „dost“, a do špatného kódu udělal něco dobře.

    Poznámka: Je tam asi typo ve větě „Platí vás tvrdou skutečnými penězi“.

    1. JakubTesarek

      Re:
      Díky, to je dobrý postřeh. Co dělat s kódem, který už je v tak otřesném stavu, že s ním nikdo nechce mít nic společného jsem schválně nerozebíral. Článek by byl příliš obsáhlý. Pokud by tě to zajímalo, tak na příští Poslední sobotě o tom budu přednášet. Budu moc rád když se přijdeš podívat, můžeme o tom klidně potom hodit řeč.

        1. JakubTesarek

          Re:
          Pro ty, kteří se nebudou moci dostavit chystáme záznam. Z materiálů, které se mi do přednášky nevejdou buď sepíšu nějaký další článek a nebo vytvořím videa na youtube :-)

          A rozlučková je proto, že David Grudl oznámil, že končí s vývojem Nette.

      1. dmatej

        Re: Otřesný kód
        Já říkávám, že permanentně „utíkáme exekutorovi z lopaty“. Musím o tom něco sepsat, myslím, že už jsme tak říkajíc evolučně vyvinuli slušné strategie, jak se s tou železnou koulí na noze posouvat směrem ke kvalitě.
        Když se chce, tak to jde, jen si musíte zahrát na „rytíře“, který ví, co dělá, nesejde z cesty, a nenechá se „zlákat ďáblem“. Jinak řečeno, cokoliv nového musí být napsáno dobře, neexistuje „dolepování“.
        To je na tom nejtěžší, odpadla už spousta lidí, kteří nakonec podlehli a přizpůsobili svoje psaní tomu, co bylo kolem a do špaget nastrkali ještě drátky (a jiní nitě). Projekt je zahubil strašlivou smrtí!
        Testy psát vždycky nejde, protože pokud máte 3000 řádkovou metodu (automat!), první věc, kterou při refaktoringu uděláte, je, že budete muset přepsat testy. Někdy se ale i takové testy napsat stejně hodí …

        Zkrátka, je tam spousta nuancí, zkoumání slepých uliček, práce pyrotechnika, hodináře, leckdy naopak kopáče s krumpáčem a lopatou, to když víte, že z těch 1000 řádek je kopií jiných 1000 řádek a stačí vám dva parametry, abyste žádnou kopii nepotřebovali …

        Ani neočekávejte, že to bude bez chyb. Ale je třeba je minimalizovat – a nakonec opravit.

        P.S.: Naše aplikace má kolem 500 000 řádek kódu jen v javovské části – od roku 2007 dělá tak 5x víc věcí, ale počet řádek nevzrostl snad ani o 5%.

    2. MarianSchubert

      Re:
      Pokud clovek pracuje s tak spatnym kodem, tak doporucuji knizku „Working Effectively with Legacy Code“. Bezpecne zmeny lze provadet i v extremne spatneho kodu relativne jednoduse.

      1. shady

        Re:
        jj, si pamatam ze vytiahnut cas kodu v ktorom chcem robit zmeny von, spravit na to testy, a potom v nom robit zmeny

      1. Oldřich Vetešník

        Re:
        Hahaha :D, jo no, naštěstí už jsem jinde. Ne že by se to nějak nedalo, to jen ta kupa hnoje je prostě tak strašně velká, že jeden člověk na to nestačí. A ani toho by nikdo nezaplatil. :(

  2. sachy

    Děsivý kod
    On ten kód nemusí být děsivý „by design“, ale prostě 2x starší než průměr věku vývojářů, časem se samozřejmě dokoupily a integrovaly externi moduly/produkty. Pak učící křivka vypadá jak rampa pro kočárky a tak se vesele bastlí protože deadline…

    1. patriksima

      Re: Děsivý kod
      Asi by se mělo definovat co je „děsivý“. Protože někoho děsí v html použití značky místo , a přitom to není nic proti ničemu. Takže u některých věci je to pohled od pohledu.

    2. dmatej

      Re: Děsivý kod
      Ano, programátoři často řvou, že „je to děsně předpotopní kód“, ale – věk kódu nic s čistotou ani udržovatelností nemá společného. Znám lidi, kteří dělali v Cobolu nebo assembleru – zatraceně dobře ví, co je udržovatelnost.

      Myslím si, že v podstatě je to všechno pořád o jednom – schopnosti určit hranice (tj. dovnitř patří to, co všechno potřebuji, aby to udělalo, co má, ven pak patří všechno ostatní, zbytek jsoucna :-) ) a pak definovat rozhraní, pokud možno co nejjednoznačněji (potřebné zdroje, parametry, výstupy, důsledky, možné chyby).

      S bastlením se dá kdykoliv přestat, ať mi věříte, nebo ne, nikdy to není dražší. Panika je naopak drahá vždycky – a lajdáctví nebezpečné.

      1. Oldřich Vetešník

        Re: Děsivý kod
        Ne že bych assembler uměl, spíš jsem si ho vyzkoušel, ale cosi mi říká, že by bylo fajn, kdyby každej programátor dostal nějakej úkol v tom napsat a chvíli udržovat, jestli by ho to nedonutilo psát líp.

  3. fish

    Cisty kod
    V podstate vytah ze skvele knihy „Cisty kod“, kterou by si mel precist kazdy programator. Ale i tak diky za strucny vytah ;)

  4. patriksima

    Zkušenost manažera
    Já to vidím tak, že každý nový programátor by to udělal líp než ten předchozí. A výsledkem je mnoho práce a málo muziky.

    Málokdo píše testy a dokumentaci jednoduše proto, že si neumí stanovit správnou cenu. A pak se jim to tam prostě „nevleze“.

    Sekundární problém je v nesprávné komunikaci. Soft-skills jsou obecně problémem tohoto odvětví.

    1. dmatej

      Re: Zkušenost manažera
      S prvním odstavečkem nesouhlasím, resp. ano, chápu, jak to myslíte a je na tom kousek pravdy, ale mezi řádky je to spíš trochu příznak bezradnosti. Jedna věc jsou „tlučhubové“, což jsme asi skoro všichni, a druhá věc je konstruktivní pohled, který dnes lidi (nejen programátoři) moc neumí: Co je na tom špatně? Jak by to mělo být dobře? Kolik práce to bude? – a pak je na řadě zvážit, jestli to stojí za to (dá se stihnout, resp. závisí na tom další rozvoj). Přitom jako u všeho je třeba počítat s tím, že se to může zkomplikovat, např. že se nakonec ukáže, že původní řešení bylo hnusné, ale 1000x rychlejší (proč?), atd.

      Druhý odstaveček je pravdivý – nicméně dokud to není, není to hotové. Tečka. I kdyby měl být přesčas, i kdyby PM musel obhajovat tým u šéfů. U nás jsem trochu ve výhodě – šéfové už se spálili.

      Třetí je také trefný – nikdo nejsme dokonalý, nejhorší je ale rezignace na komunikaci.

    2. arron

      Re: Zkušenost manažera
      O bývá často také problém na straně těch manažerů, kteří chtějí po programátorech věci, které neumí. Například odhadování náročnosti. To, co řekne programátor je v drtivé většině případů nutné vynásobit minimálně dvěma :-) Spíš ale dvěma a půl, někdy i víc.

      A na druhou stranu, manažer by si naopak měl uvědomovat, že projekt nějakou dobu poběží a bude potřeba ho udržovat a sám by měl programátory tlačit do toho, aby ta údržba byla v budoucnu co nejjednodušší a daly se na tom vyvařit nějaké peníze. Krom toho s čistým kódem a testy roste přímo úměrně spokojenost klienta (když nic jiného, tak méně bugů) :-)

      1. Jirka

        Re: Zkušenost manažera
        Odhadování pracnosti je schopnost, kterou by se měl programátor naučit. A jde to, pokud se dokáže poučit z předchozího odhadu a skutečného odpracovaného času (např. ten dvojnásobek :-) ).

        Odhadování by podle mě měl dělat právě vývojář, protože je ten jediný, kdo má technickou představu o daném požadavku a o zbytku systému. PM nebo zkušenější kolega ho může korigovat, dávat mu vhodné otázky jestli na něco nezapomněl, ale odhad by měl sestavit ten, kdo to bude programovat.

    3. Pavel Bina

      Re: Zkušenost manažera
      Znám a vím, a pokud manažer ví, že ti před tím nebyli úplní chlíváci, neměl by svolit.

  5. Petr

    A není vlastně lehce špinavý kód správně?
    Refaktoring znamená změna. Změna znamená možné zanesení chyby. Chyba stojí peníze a hledá se viník. Takže se do refaktoringu nikdo nepouští, pokud není už vyloženě v úzkých.

    Ale… není to nakonec dobře? Totiž je zbytečné čistit kód ad absurdum. Stojí to peníze a zákazníkovi to stejně nic nepřinese.

    1. bodo

      Re: A není vlastně lehce špinavý kód správně?
      Spravne. Nemali by sme cistit ani zachod, stoji to peniaze a nikomu to nic neprinesie, zachod nezmeni svoj tvar ani nezlepsi svoju funkciu.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=10965