Jaká jsou úskalí Quick-and-Dirty-Programming a jak se jim vyhnout? Část 7:. Proč je v SW firmách tak rozšířen zlozvyk tvořit paskvilný SW „Dirty Code“ ?

Nedávno jsem obdržel tento mail (publikuji bez úprav):

Vazeny pan Kraval,

cital som Vas serial Quick-and-Dirty-Programming a som rad ze o tom niekto pise.

Som v situacii, kde model projektu neexistuje a vsetko sa zistuje reverznym inzinieringom a samozrejme opatovne vzdy, ked sa v danej casti aplikacie robia zmeny. Frustrujuca situacia, hlavne ked sa jedna o dlhodoby projekt, ktory sa postupne vyvija.

Myslim, ze problem je v tom, ze vacsinou ludia nemaju skusenosti s inym ako quick and dirty vyvojom. Profesia vyvojara je stale „profesiou z garaze“. Na vykonavanie tejto profesia by to chcelo znalostne skusky, napr. ako v medicine 🙂

prajem Vam krasny den,
K. F.

Shodou okolností jsem v některých posledních zakázkách narazil na podobný problém a to hned v několika firmách: Vytvářel se v nich kód jako typický paskvil, tj.

  • neexistoval žádný analytický model (resp. odevzdávaly se dokumenty nazývané jako „analýza“, ale byly úplně mimo potřeby návrhu SW),
  • neprovádělo se žádné posouzení čistoty návrhu,
  • nezkoumala se správnost vrstev atd.
  • a k tomu samozřejmě vzájemná spolupráce programátorů byla minimální, tedy spíše nulová…

Zajímavé je, že v těchto firmách jsem narazil na určitou formu odporu vůči metodám, které by měly vést k lepšímu výsledku, a to i přesto, že mnozí opravdu zainteresovaní vývojáři volali po změnách, protože tento stav byl pro ně neúnosný.

Celou situaci dobře vyjadřuje tento sice starý, ale velmi výstižný kreslený vtip:

Poslední odstavec mailu týkající se znalostí vývojářů spolu se zkušenostmi z těchto firem mne přivedl k otázce:

Jaké jsou vlastně překážky ve firmách, které brání tomu, aby se firma vyvarovala tvorbě „Dirty Code“?

Myslím, že je to velmi dobrý námět k diskusi. Osobně jsem narazil na tyto základní překážky pro zavedení správných postupů ve firmě:

  • Nechuť vedení k jakýmkoliv změnám. Většinou managment odborně hodně vzdálený od postupů tvorby SW vůbec nechápe, v jakých problémech se firma nachází a z toho důvodu se vedení jakýmkoliv změnám brání. Pokud by ale dotyční „výše postavení“ tušili, do jaké žumpy se tímto firma topí, asi by tak trochu zpanikařili (pokud se tedy vedení neřídí principem „po nás potopa“).
  • Touha po nezastupitelnosti některých vývojářů, zejména dlouholetých programátorů, kteří nechtějí nikoho pustit na svůj „píseček“. Vzpomínám si při této příležitosti na jednu charakteristickou situaci v jedné firmě: V rámci školení jsme dokončili jako ukázku jeden analytický model agendy, o které se před tím hovořilo „až s posvátnou úctou“. Cestou k vrátnici jsem ve výtahu ke kolegovi jen tak mimochodem prohodil: „Ona ta agenda není až tak složitá, jak se mi zdála na počátku…“ A dotyčný kolega mi na to odpověděl: „Víte, ony se u nás ty agendy tak trochu démonizují…“
  • Neznalost vývojářů. Protože nejsou žádné tlaky, není ani touha se v tomto směru vzdělávat. Zkratky jako SOLID, GOF, DRY apod. jsou víceméně španělskou vesnicí. Právě o tom píše kolega v mailu a myslím, že je to jen jedna z částí problému v celém kontextu.

Rád bych na toto téma zahájil diskusi.

Obracím se na čtenáře s těmito otázkami:

  • Není tu snad ještě něco, co jsem přehlédl?
  • Jaké máte vy zkušenosti s těmito situacemi?
  • Který z těchto vyjmenovaných bodů je asi nejhorší?
  • A hlavně: Jaké si myslíte, že to má řešení?

Budu se těšit na vaše příspěvky v diskusi pod článkem!


od

Komentáře

6 komentářů: „Jaká jsou úskalí Quick-and-Dirty-Programming a jak se jim vyhnout? Část 7:. Proč je v SW firmách tak rozšířen zlozvyk tvořit paskvilný SW „Dirty Code“ ?“

  1. Jiří Matějček avatar
    Jiří Matějček

    Děkuji za článek, jako úvod pro diskuzi dobrý.
    Momentálně náš tým spravuje rozsáhlý systém s dvacetiletou historií – cca 5000 db tabulek, mnoho procesů, aplikací, interfaců, automatických úloh. Jednu dobu byl „na odpis“, tedy QaD bylo nařízeno, ale pak se zase rozhodlo, že se bude používat dále. Systém je v dobré kondici, i když se setkáváme se vším, co k QaD patří: mrtvá data, mrtvé kódy, nepoužívané části aplikací, neúplná dokumentace, uzavření vývojáři.
    Co nás drží nad vodou: pamětníci, zdrojové kódy, komentovaný datový model a regresní testy.
    Jeden pamětník neví všechno, ale když se jich pár obejde, tak lze rekonstruovat, jak se systém zhruba chová. Pak vlézt do kódů a postupně si teorii ověřit. Máme tedy high level a low level. Střední vrstva chybí.
    Démonizace je zde opačná – zpočátku se zdá úprava snadná, ale postupně se objevují démoni 🙂
    Myšlenku na vytvoření celkové dokumentace a udržovat ji aktuální již považuji za utopii, není to prostě možné. Pár pokusů tu bylo (ve wordech nebo v EA). Je to natolik rozsáhlé a provázané, že byste tam stejně nenašli informaci, kterou právě potřebujete a aktualizovat dokumentace se nestíhala, vývoj byl vždy o míle napřed, a nebyl dostatek lidských sil na její udržování, a stejně tam byly chyby nebo bílá místa. přitom vedení je dokumentaci nakloněno, podporuje jí, ale v tom objemu se to nedá zvládnout.
    Jak se systém opravdu chová je přesně dáno ve zdrojovém kódu. Jsem vděčný za každý komentář, který pomáhá pochopit, co kód dělá. Toho jsem se chytil a momentálně pracuji na aktivitě, aby se kód dobře strukturoval, pojmenovával a komentoval. Když někdo porvede QaD, aspoň aby to tam napsal (a někteří to tam opravdu napsali, děkuji).
    A dávám tomu nový pohled: Nekomentovat svůj kód, ale kód kolegy, protože svému kódu vývojář perfektně rozumí a nepotřebuje ho moc komentovat. Ovšem, když to louská někdo po něm, některé konstrukce hned nepochopí. A právě zde by měl vyvolat potřebu komentáře.
    Tedy moje low level řešení je „komentovaný kód“, včetně „okomentuji kód, který jsem po někom rozlouskal“.
    Všichni analytici zde umí kód číst, to je předpokladem, jinak to nebude fungovat.
    Chápu, že to není řešení nejlepší, ale lepší jsme do praxe zatím nedokázali zavést.
    Myslím si, že velikost systému hraje zásadní roli při správě dokumentace.U menších systémů (do cca 500 tabulek) jsme vždy aktuální dokumentaci dokázali udržel (EA, wordy, excely), ale zvětšováním systému nestoupá závislost údržby dokumentace lineárně, ale násobně díky vazbám a množstvím jejich kombinací.

  2. Eduard Sovák avatar
    Eduard Sovák

    Přestože pracuji ve velké IT firmě, musel jsem v posledních letech mnohokrát obhajovat potřebu analytického modelování. Problém je v tom, že pokud se analýza provádí rigidně a striktním vodopádem, pak rychlé potřeby byznysu skutečně nestíhá. Na druhou stranu nad dobře vedeným analytickým modelem se snadněji provádí dekompozice systému, takže model jeho jednotlivých části lze udržovat poměrně efektivně tak, aby nepřerostl přes hlavu. Jako problém zejména u mladších analytiků vnímám i to, že se detailně zaměřují především na změnovou dokumentaci. Kvalita modelu, který vyjadřuje celkový stav systému (a měl by motivovat k občas potřebnému refaktoringu), je často opomíjena. Určitě v tom hraje roli i fluktuace, která k udržení dlouhodobé kvality nemotivuje.

  3. Josef Novak avatar
    Josef Novak

    V IT jsem přes 25 let, prošel jsem celkem slušnou řádku menších i velkých firem. Každá firma má svoji metodiku projektové přípravy, vývoje, testování až po delivery. Lepší/horší, je to také o úhlu pohledu a osobních preferencích. Každopádně ale existoval nějaký funkční model pro delivery výsledného produktu.
    Vaše tři body přesně vystihují situaci ve firmě, kde momentálně pracuji. Několik let se tu snažím prosadit lepší vedení projektové přípravy, tvorbu dokumentace, mám na mysli opravdové dokumentace, která bude přínosem, nikoliv to, co děláme – dokumentace jen proto, aby se pokrylo ISO. Bohužel se mi nedaří uspět. Arumentuji efektivitou, přesnějšími kalkulacemi nákladů, stanovením termínů a naplánováním zdrojů, není to nic platné, na moje návrhy je pouze reakce „Ano, máte pravdu…“ a k tomu nějaká sada vět, co by implementace mého návrhu znamenala.
    Já jen neustále vidím, že za současné situace nejsme schopni projekt vůbec správně připravit, natož odhadnout pracnost a náklady, o termínech nemluvě. Je to pro mne frustrujici, vim jak stav zlepsit, ale nevim jak změny protlačit, nevidím žádnou podporu z top managementu.
    Programátoři jsou zvyklí na nedodržení termínu (tak co, posuneme o týden), ani je to nijak netrápí, odhadnutá pracnost (výcuc z prstu) samozřejmě velmi rychle vezme za své.
    Chápu, že dnešní doba jede na trendu agile s krátkými sprinty, byznys požaduje rychlé reakce, někdy je ani netrápí cena, ale ne vždy tomu tak je. Nakonec jednou někdo přijde a řekne „dost, ta věc už stála takových peněz, co jste tam vlastně udělali a na základě jakých zadání“. A končí vcelku „přátelský“ obchodní vztah, vše se otočí o 180°. Dle mého naprosto zbytečně.
    Samozřejmě, analýza, architektura, modelování a vedení celé agendy jsou časově náročné úkony, mnohdy se u malých projektů ani nevyplatí, byznys toto zpravidla vidí ve světle zbytečných nákladů, ale u velkých projektů jsou zmíněné úkony nezbytností a to nejen při zahájení vývoje, hodí se i v případě change requestů, kde dokumentace může výrazně pomoci.

    1. RNDr. Ilja Kraval avatar

      @Josef Novak
      Přesně tak, jen bych chtěl upozornit, že existuje postup, který umožňuje vyhnout se zpomalení vývoje díky Vodopádu, tj. použít agilní techniku (např. SCRUM) a současně neztratit fokus na správné postupy a čistotu kódu včetně BPMN , UCM a Class modelu a vyhnout se Dirty Code…(jak skloubit UML a SCRUM)

      1. Josef Novak avatar
        Josef Novak

        Je to jak říkáte, absolvoval jsem několik Vašich kurzů, mám certifikát PRINCE II, ale firma tyto moje znalosti a zkušenosti z jiných působení naprosto ignoruje. Na poradě vždy padne otázka „a kdy to bude?“, přitom existuje vypracovnaý projektový plán, který je schválený, ale jaksi jsou tendence ten plán nerespektovat a práce hnát do kratších (nesmyslných) termínů. To samozřejmě vede k QaD a to nejen v kódu aplikace, trpí tím i příprava, tedy dokumentace je chabá, mnohdy nesmyslná či neexistující. To následně vede k lavině, kdy vývoj nestíhá, vedou se sáhodlouhé diskuze ohledně vývoje „co to teda vlastně chtějí? jak to má fungovat? atp..“, protože často není dobře pochopený požadavek, natož aby byl zdokumentovaný. Nejsem zastáncem byrokracie, ale z praxe vím, že projektová příprava až po vytvoření detail designu popisujícího, jak bude konkrétní požadavek řešení realizováno, je nezbytností.

        1. RNDr. Ilja Kraval avatar

          @Josef Novak
          Přesně.
          Situace se tak trochu změnila oproti minulosti v tom smyslu, že někteří vedoucí již konečně pochopili, že postupy jsou třeba. Přistoupí tedy na tvorbu modelů, ale z neznalosti spadne tým do pasti : „Modelování pro modelování“, tedy začnou se tvořit jakési modely úplně mimo potřeby vývojářů, jen aby byly…Samozřejmě toto je vyhozená práce a stejně ve vývoji jedou hlubokým černým tunelem…

          Nejhorší na tom je, že toto považují za argument, že nasazení OOP, UML a Clean Code (včetně GOF) selhává… 🙂

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *