OT historicke paralely (8051)

[Zdenek]

Pěkně jste popsal ukázkový průběh vývoje, který jsem také používal jako
systémový analytik. Ve firmě, kde se na stejném projektu podílelo více lidí
(analytik, designer, developer, tester...) to byla nutnost už kvůli
zdokumentování projektu a předávání informací. Nikdy mi ale nepřišlo
smysluplné, používat tento robustní proces v případě, kdy celý vývoj
provádím sám. Sice znám vhodné metodiky a nástroje, takže odpadá nutnost
učení, ale přišlo mi to jako jít s kanónem na vrabce. Takže nakonec se
dokopu maximálně ke komentářům a i k tomu jsem se musel dopracovat až časem,
když jsem zjistil, že po několika letech se nevyznám ani ve vlastním kódu...

-----Original Message-----
From: Hw-list [mailto:hw-list-bounces na list.hw.cz] On Behalf Of František
Burian
Sent: Sunday, August 21, 2022 11:14 PM
To: hw-list na list.hw.cz
Subject: Re: OT historicke paralely (8051)

Ahoj,

  Dřív jsem to taky nechápal, hrnul se ke kompilátoru a ladil a ladil a furt
nějaké problémy a chyby ... Dneska už ne.

  Já už taky pomalu dokonvergoval do tohoto stavu. Nejdřív mám nějaké
požadavky a z nich udělám návrh aplikace (StarUml).
Až si myslím že jsem popsal všechny potřeby co to má dělat a jak to má dělat
(tedy od use case po doménový graf) tak teprve
začínám psát kód (nebo kreslit plošák), a je jedno jestli zrovna
implementuju tlačítka v UI, nebo nějakou pod-podfunkci, či návrh
API - prostě jen "napíšu co jsem navrhl", je to dost odpočinková a rychlá
záležitost, při které objevuju chyby návrhu a zpětně
koriguju návrh. Vpodstatě to můžou pak dělat opice...

  Navíc mi z návrhu vyplynou nějaké vlastnosti, které mohu konzultovat se
zákazníkem ještě předtím než napíšu řádek kódu,
které při první diskusi nebyly zřejmé a zákazník sám si může říct zdali mu
vyhovují nebo jsou nepřijatelné ještě před zahájením
implementace - takže to šetří ve výsledku peníze. No to za předpokladu že
zákazník ví co chce.

  A protože většinou něco nemám tak to nemám na čem ladit takže jen "buším"
a kontroluju že to jde zkompilovat, a až přijde
nějaký ten HW tak to většinou spustím a jede to na poprvé tak jak jsem
navrhl. Většinou po spuštění objevuju chyby v návrhu
ale tím že už četnost klesá, asi stárnu ... (to mi říkal moudře děda, že
četnosti obecně s věkem klesají ...). Obrovskou výhodu
má řízení času, když vím že jej mám málo tak si vezmu malou funkcičku, když
víc, vezmu větší .... neodcházím od nerozdělané
práce. A když někdo vyruší mimo periodu tak jej odkážu na čas kdy budu mít
doděláno a může otravovat. No a návrh většinou
dělám v posteli, vedle postele papír a tužka ... tam nikdo nikdy nevyrušuje.
To taky říkal děda, že to nejlepší ve svým životě
co dělal tak bylo v posteli. Tak to dělám taky tak a funguje to :-)

  Zde jsem si ještě neosvojil psaní testů, které sice přímo plynou z návrhu
ale protože mi většinou funguje napoprvé, tak
"who cares". Něco jiného je spolupráce s cizím nedokumentovaným zařízením
ale to většinou mám čas na pořádnou
knihovničku a testování.

  No a pak přijde zákazník a kouká že něco chtěl jinak - tj mění požadavky,
musím strukturu návrhu ohnout a po asi třetím či
čtvrtém styku se zákazníkem dospěju k tomu, že to celé musím napsat znovu.
Ne návrh, ale kód. A protože už něco je, tak
různě použiju co už je, takže úplně nový kód je docela rychle (možná by se
dal ze starého dělat refactoringem). Jenže tady
už při kopírování přesně nekontroluju co to dělá a musím se naučit ty testy.

  Takže - ano, na čistém stole a s dobře definovanými požadavky se píše
aplikace velmi pěkně a rychle ale klíčem je právě
správně vyzpovídat zákazníka co po mě vlastně chce a to není zrovna
jednoduché. Ani když dělám něco já sám pro sebe ...
Výsledek je v timeline něco jako:

NAVRH - VYROB - PRILEP - PRILEP - ... - VYROB NOVY - PRILEP - PRILEP - VYROB
NOVY - PRODEJ - JED NA DOVOLENOU

  V každém kroku se něco k návrhu přidá a tato část zabere nejvíc času - to
rozmyslet co a kam aby se to nerozbilo. No zde
jsem pochopil proč se software označuje číslem major-minor-build a striktně
to už dodržuju i u HW :o) Poslední bod
timeline se nedaří, většinou mi tam zákazník dá while ... :o)

  Třeba teď dělám na měřicím přístroji kde zaměstnavatel chtěl abych měřil
mezi elektrodami A1:A2 B1:B2 a C1:C2 ale
ve čtvrtek přišel že by rád měřil mezi A1:A2 A1+B1:A2+B2 a musí to být ve
čtvrtek hotové na první měření aby věděl
jestli vůbec změna má vliv na měřené hodnoty. Znamená to novou elektroniku
(další deska s relé), nový software (obsluha
I/O a jiná kalibrace kvůli novým parazitám), nové výpočty. A ejhle, zavedl
jsem požadavky do dokumentace, z ní mi
vyplynulo že úprava sw bude docela jednoduchá a využiju parazitních
vlastností existující elektroniky - nepotřebuju
čipy které nejsou v šuplíku, navrhl jsem DPS a na LPKF fréze do 2 hodin
vyrobil plošák, zatímco se vyráběl jsem objednal
chybějící součástky na TME. O víkendu si jen implementuju změny SW ale
hardware bude zapájený když dobře v úterý
večer, takže nemám vpodstatě na čem ladit. Ve středu to jen rozeběhnu a
vpodstatě budu jen ověřovat že to co to měří
odpovídá fyzikálním zákonům a neudělal jsem nikde botu v návrhu (to jsou ty
testy...). No a ve čtvrtek sedám do auta
a přemisťuju se na místo měření kde ověříme že nápad je OK. Pokud budou
výsledky slibné (ověřuje kolega) tak ten
rychloslepenec musím udělat pořádně tzn vpodstatě nová základní deska, která
ale má čipy které se blbě dají sehnat,
nebo přijdou s jinou modifikací kdy zase přilepím něco jiného na původní HW
(mám diferenci v dokumentaci v GITu
takže vím co jsem přilepil a můžu to zase odlepit).... Možná výhoda toho že
tvořím prototypy a pro ostatní tuto výhodu nemá.

  Naopak docela nechápu lidi, kteří se dokážou vrtat v cizím kódu a lepit
(cizí) knihovny bez rozumné dokumentace přes
sebe tak, aby spolupracovaly, a dokonce celý slepenec ovázaný izolačkou,
postříkaný WD40, pro jistotu omotaný duct
tape a překompilovaný v novém llvm, po čtvrtém pomodlení dělal co má. Takoví
jsou u mě machři a mám je ve velké
úctě. Naštěstí jich kolem mě moc není a tak na mě zbývá práce až až :o) (pro
jistotu si je beru na měření protože to
dokážou kouzla i s mými výtvory když se vše po...)

  Stejně jako mám v úctě lidi, kteří dokážou nalézt chyby v cizím
nedokumentovaném zařízení a ještě je obejít ...

  Ještě se tedy naučit ty testy, zkouším je už od dob MiniLA, stále mi
nevyhovují potřebám testů (ještě mi nikdy nic
neobjevily dřív než objevil zákazník a to je špatně pro testy - zde by se mi
asi hodila praxe v nějakém korporátu nebo
víc školení, možná se na to dívám moc ze špatného pohledu ...)

  Dneska tedy pracuju tak že 60 procent času je analýza, kreslení
souvislostí a závislostí, psaní dokumentace (au!),
30 procent času je vlastní programování a 10 procent jsou chyby a jejich
opravy, doladění drobností. Dá se tedy
říct že 90 procent mého času je psaní do bílého okna, zbytek je ladění s
hardwarem a vším všudy.

S pozdravem,

  František Burian