[elektro] nalatok ? -)

[Ábrahám Gábor]

Szia!

> Hibajavításra meglévő (esetleg legacy) kódban ez a legjobb minőséget
> biztosító módszer (Ericsson?).

Igen. Itt már több ezer példányban futó programokról van szó,
ahol egy elrontott frissítéstől egy szolgáltató országos hálózata is 
leállhatna.

> Na de mi van az új feature fejlesztéssel
> amikor valaki berak 30 új osztályt? Azt ki és hogy nézi át?

A új fejlesztésnél egyrészt iszonyatos az adminisztráció, dokumentálás,
amit nagyon utál az ember, amikor csinálni kell. Hardware, software nem 
különbözik.

Sok egyéb mellett van egy design doksi arról, hogy mit akarunk csinálni,
egy implementációs dokumentáció arról, hogy mi sikerült.
(Ami elkészült, miért úgy, ami kimaradt, miért nem lett megoldva, hogy 
lehetne később pótolni.)
Van egy verifikációs dokumentum, ami arról szól, hogy hogy kell
egy frissen elkészült vagy módosított darabról eldönteni, hogy megfelelően 
működik-e.

Ma pont az egyik kártya HW verifikációs doksiját olvasgattam.
Van egy általános, file, amiben van tömbvázlat, és eligazítás, hogy melyik 
rész mérési
utasítása, melyik file-ban található. Van belőlük 14 db. (Tápok és reset, 
CPU- és memória
táp, lassú interface-ek, gyors interface-ek, memória, clock, stb.)
Az órajelekkel foglakozó kb. 50 oldal. Az elején leírja, hogy milyen 
műszerek kellenek
a méréshez, és azokkal hogyan mérjünk, aztán sorra veszi a jeleket:
Pl. eth_clk_25. Leírja, hogy ez egy Ethernet chip órajele, amit az U22 14-es 
lábán kell mérni.
Leírja a frekvenciáját, feszültségét, kitöltési tényezőjét, meg minden 
egyebet, ami ott fontos.
(pontosság, jitter, felfutás, túllövés stb.) Ez nyilván jelenként eltér.
Minden jelnél ott van az adott IC adatlapjából a jelre vonatkozó adatrész, 
ha van, akkor ábra is.

A programokhoz is hasonló dokumentációk készülnek.

A kisebb csoportoknak 3-5 fő van napi 10-15 perces meeting. Itt mindenki 
elmondja,
hogy előző nap éppen mit csinált, hol tart. Ilyenkor osztjuk el egymás 
között a feladatokat is.
Egyik nap elmondom, hogy milyen a feladattal foglalkozom, de még nem tudom,
hogy milyen megoldást fogok választani, mert ezek a lehetőségek. Másnap 
elmondom,
hogy mit választottam, harmadnap meg azt, hogy az miért nem vált be :)
Ha valakinek problémája van, segítünk egymásnak, ha kell össze lehet ülni 
azzal,
akinek van ötlete.
Régebben is sokszor tapasztaltam, hogy egy probléma megoldásához az is elég,
ha valakinek el lehet mondani. Az, hogy egy külső szemlélőnek, érthető módon 
el kell
magyarázni, kizökkent abból a körből, ami miatt nem találja az ember a 
megoldást.

A forrásokban igyekszik mindenki betartani formai követelményeket is, mivel 
valószínű,
hogy ha vége a fejlesztésnek, üzemeltetni más fogja.

Van egy csomó kommunikációs eszköz, project wiki-től a körlevelekig.
(Kié az xxxx struktúra, amit sok helyen használunk, mert szeretnék a végére 
tenni
egy 10 elemű karakter tömböt ami az 1234aaa bővítéshez kellene és az akármi 
nevét
tartalmazná? Odamásolva a struktúra, pirossal kiegészítve.)

Természetesen verziókövetés van, a program forrásokra pont úgy,
mint mondjuk az alkatrészlistákra vagy a NYÁK tervekre, vagy egy 
konfigurációs EEPROM
tartalmára. (Nem csak a tartalom van tárolva, de arról is van doksi, hogy 
milyen
módosítások történtek mondjuk egy hálózati kártya gyári konfigurációjához 
képest és miért.)

A nagyobb csapatnak 20-25 fő heti meeting van, ahol a magasabb szintű 
problémákat,
lehet megbeszélni. De bárkitől, bármikor, bármit lehet kérni, igazán 
segítőkész csapat.

Természetesen a határidő itt is a végén szűk, de az elején van idő a 
gondolkodásra.
Most indul egy kb. két éves fejlesztés, én egy hónapja csak a olvasok, 
készülök rá.
Van napi meeting, ahol a termék korábbi, jelenleg futó verzióját ismerjük 
meg,
van heti, ahol a tervezett architektúra tisztázása, átbeszélése folyik.
Van heti egy alkalom, ahol az alkatrész gyártó mérnökeivel lehet 
konzultálni.
(Én kicsit speciális helyzetben vagyok, mert a hardware és a software csapat
összejöveteleire is járok, mivel jelenleg nincs más futó feladatom.)


Gábor





2014. március 24. 20:51 Ábrahám Gábor írta, <agabor2 at gmail.com>:

> Sziasztok!
>
> Nálunk úgy van, hogy ha én kijavítok egy hibát, azt letesztelem.
> Ha működik, akkor beleírom a forrásba, a kötelező megjegyzéseket.
> Minden módosított részhez ki, mikor, milyen hibaszám alapján nyúlt bele.
> Forrás fileok elejére, összefoglalva, hogy mi változott.
>
> A hiba lezárásához van template. Ebben le kell írni, hogy mi volt a hiba,
> nem a jelenség, ami a bejelentésben szerepel, hanem a tényleges hiba.
> Le kell írni, hogy mi volt a megoldás, mit módosítottam. Hogy lehet
> ellenőrizni a javítás sikerességét, logok csatolva.
>
> Ha ez megvan, egy kollégámnak ellenőriznie-kell.
> Ami azt jelenti, hogy a forrásoknak úgy kell kommentezve lenni,
> hogy némi magyarázat után, ő (aki lehet, hogy éppen kínai),
> el tudja dönteni, hogy a program tényleg azt csinálja-e, amit kell.
> (Ha akarja, ki is próbálja, tesztelgeti.) Végül a nevét adja hozzá,
> hogy  ellenőrizte és jó. Ekkor lehet a hibát lezárni.
>
> Ezután amikor új verzió születik, a javított források összevonásakor
> (merge),
> még egyszer átnézzük, akkor már hárman, hogy értelmes-e ami ott áll.
> Néha még itt is kerül bele javítás, komment, ha valami nem egyértelmű.
> (Pl. valahol nem szimbolikus konstans szerepel, hanem egy fix érték,
> amiről nem lehet tudni, hogy miért pont annyi. Normálisan mindenütt
> #define van, kommentben mondjuk az adatlap neve, oldalszám, ahonnan
> kitaláltam.)
>
> Ezután ha elkészült a verzió, van egy basic teszt, amit közülünk csinál
> valaki,
> és ha ez sikeresen lement, megy a tesztelőkhöz, ahol az összes hardware
> variánssal tesztelik. Ez kb. két hét. Ha nem találtak hibát, akkor lesz
> hivatalos.
>
> Természetesen, ha nem hiba, hanem fejlesztés miatt változott a program,
> az új részekhez tartozó tesztelési eljárások beépülnek a tesztsorozatba.
>
> Ezen kívül, a felmerülő problémákról is születnek papírok.
> Pl. az adott hibát ugyan javítja, vagy a feladatot megoldja a módosítás,
> de a megoldás nem általános, mert ahhoz még egy csomó dolgot meg kéne
> csinálni.
> Később meg kell vizsgálni, hogy erre ténylegesen szükség van-e?
>
> Régen mondták, hogy az IBM-nél egy programozó átlag napi 30 sor kódot ír
> le.
> Ez nem azért van, mert buta, vagy lusta, hanem a fent leírtak miatt.
>
> Gábor
>
>
>
>
> ----- Eredeti üzenet -----
> From: Erdos Zoltan
> Sent: Monday, March 24, 2014 7:06 PM
> To: elektro at tesla.hu
> Subject: [elektro] nalatok ? -)
>
> http://ajtiscsavo.blog.hu/2014/03/24/habozas_nelkul
>
> -----------------------------------------
>           elektro[-flame|-etc]
>
>
>
> -----
> A(z)  uzenetben nem talalhato virus.
> Ellenorizte: AVG - www.avg.com
> Verzio: 2014.0.4354 / Virus adatbazis: 3722/7241 - Kiadas datuma:
> 2014.03.24.
>
> -----------------------------------------
>           elektro[-flame|-etc]
-----------------------------------------
          elektro[-flame|-etc]



-----
A(z)  üzenetben nem található vírus.
Ellenőrizte: AVG - www.avg.com
Verzió: 2014.0.4354 / Vírus adatbázis: 3722/7241 - Kiadás dátuma: 
2014.03.24.