🚀 go-pugleaf

> > https://fossbytes.com/nasa-coding-programming-rules-critical/
> 
> Ot, bajeczki dla nastolatków.

Nie, po prostu ktoś sobie na blogu napisał. Najprostszy standard kodowania MISRA-C ma 230 stron, ostatnio opublikowany z AUTOSAR dla C++ ma 370 stron. Ten blog nie porusza nawet wierzchołka zagadnienia.

Ogólnie, to nie są jakieś dziwne reguły, właśnie takich należy się spodziewać.
Warto też pamiętać, że pomimo wysokiej popularności NASA jako pop-kulturowego brandu, to nie NASA jest frontem walki o jakość - wynika to z faktu, że w tej branży (podobnie jak w wojsku) nie obowiązują reguły certyfikacji czy homologacji takie jak w cywilnych branżach. Tzn. oni oczywiście dbają o pieniądze podatnika (w sensie - szkoda stracić drogą rakietę) i o swoją reputację (w sensie - jak ją stracą, to kolejnego projektu mogą nie mieć), ale poza tymi dwoma wartościami nie mają o co dbać, bo w szczególności pilot rakiety jest w oczach opinii publicznej bardziej żołnierzem, niż obywatelem, więc jego strata jest przez publiczność postrzegana jako godna ofiara na ołtarzu postępu. Przecież wiedział, że może zginąć, nie?

Inaczej mówiąc 1: publiczna akceptacja fakapu w tej branży jest całkiem wysoka, w odróżnieniu od dziedzin, gdzie się zabija niewinnych obywateli.

Inaczej mówiąc 2: pomimo tego, że te kilka reguł wygląda strasznie dla "normalnego" programisty, to typowy projekt NASA mógłby nie przejść rygoru obowiązującego w lotnictwie cywilnym. No, serio, nie wystarczy mieć funkcje krótsze niż 60 linijek, żeby przejść przez proces certyfikacji[*].

[*] Który to proces właśnie traci reputację przez ostatnie lotnicze fakapy. Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.

> Ciekawe jest to czego w tym nie ma:
> 
> 1. Architektura i wzorce projektowe.
> 2. Statyczna analiza kodu.
> 3. Testy jednostkowe i integracyjne.
> 4. Dokumentacja.
> 5. Audyt. XP
> 6. Metodyka (waterfall ?!?)

Ale chyba nie o tym był ten blog. Natomiast warto zauważyć, że standard kodowania jest właśnie po to, żeby zrobić punkt 2 powyżej i żeby sobie ułatwić osiągnięcie jeszcze kilku innych celów jakościowych. I tylko po to. Gorzej, że z powodu takich blogów ludzie potem myślą, że standard kodowania jest jedyną rzeczą, która odróżnia proces krytyczny od "normalnego" i tylko na nim się skupiają. Tymczasem te "straszne" reguły to jest najmniejszy problem. Klepanie kodu to tylko kilka procent wysiłku, nawet z tymi strasznymi regułami.
Więc bez przesady.

-- 
Maciej Sobczak * http://www.inspirel.com