Wróć na stronę główną

NASA i tworzenie oprogramowania, cz. 2

Napisałem jakiś czas temu o NASA i tworzeniu oprogramowania. Zebrało się pod wpisem parę komentarzy, z których wynikało że mój wpis zupełnie nie oddawał tego, co chciałem powiedzieć. Wyjaśnienie, co naprawdę miałem na myśli warte jest osobnego wpisu.

I wydaje mi się, że pomysł to jedno, ale realizacja to druga sprawa. Można mieć świetny pomysł (Twitter), ale czy koniecznie trzeba go pisać w Assemblerze (da się!) albo w C (też się da!) by zostać docenionym za jakoś? Bez przesady.

Nie chciałem nikogo namawiać do pisania Twittera w C czy assemblerze. Raczej chciałem zniechęcić do zbyt długiego zastanawiania się nad tym, w jakiej technologii napisać swoje nowe dzieło. Byłem świadkiem wielu dyskusji, w których przyszły Bill Gates z przyszłym Stevem Jobsem dyskutowali czy ich “lepsza nasza klasa z różowym tłem, które przyciągnie duużo odwiedzających ™” powinna być napisana w Javie, PHP czy Ruby on Rails. Na co moja odpowiedź jest taka, że to nie ma znaczenia! Poprzedni artykuł miał to zilustrować, pokazując że najbardziej zaawansowana technologia (NASA) często opiera się na bardzo konserwatywnych podstawach (C). Nie wyszło - no cóż, bywa.

Ja właśnie myślę, że teraz w momencie gdy coraz większą wagę przywiązuje się do jakości tworzonego kodu jest czas na to by się pozachwycać środkiem.

Mimo, że będąc programistą często wkurzam się na jakość kodu pisaną przez różnych ludzi naprawdę nie zauważyłem korelacji pomiędzy jakością kodu a jakością produktu. A widziałem już sporo kodu różnych ludzi, w paru firmach, w tym tworzących oprogramowanie z którego wszyscy korzystamy. Często produkty z których korzystają miliony ludzi są napisane naprawde fatalnie.

Widziałem także celowe pogarszanie czytelności kodu ze względu na ochronę intelectual property, ale to już inna bajka.

Twitter w żadnym stopniu nie jest hi-tech, nie ma tam ani jednej skomplikowanej funkcji, której nie napisałoby większość programistów

Twierdzi tak każdy, kto nie napisał programu który musi obsługiwać dziesiątki tysięcy zapytań na sekundę ;-) Nie ma tam może rocket science, ale jest kawałek solidnej inżynierii (w NASA oprócz inżynierii jest i rocket science). Każdy byłby w stanie napisać twittera tak, by działał dla 5 ludzi. Wystarczy trochę pehape i jakiś majsiquel. Te pięćdziesiąt postów na dzień naprawdę łatwo obsłużyć. W momencie gdy tweetów są tysiące na sekundę a każdy musi być dostarczony do dziesiątek ludzi (a niektóre do dziesiątek tysięcy), tu już bym się nie zakładał czy każdy programista by tak potrafił. Ale może. :-)

Koncepcyjnie ten problem jest prosty, w porównaniu z nawigacją w kosmosie i automatycznym lądowaniem na Marsie niemal trywialny. Jednak zaimplementowanie wszystkiego tak, by “po prostu działało” jest sporym wyzwaniem. To jeden komputer jest przeciążony, bo Guy Kawasaki napisał tweet który musi przeczytać 100k ludzi. To inny komputer jest przeciążony, bo obsługiwał tweety 100k ludzi, z których nagle jeden stał się super popularny. A to znowu trzeba zadbać, by nawet jak któryś z komputerów padnie dane nadal były spójne. Wreszczie okazuje się, że MySQL nie wyrabia i trzeba własny backend pisać. No i jakiś Franek z polibudy napisze skrypt w pythonie który przez przypadek z wszystkich komputerów w akademiku zacznie pingować Tweetera. I tak dalej, i tak dalej…

Parę dodatkowych słów o tym jak tworzone jest “kosmiczne” oprogramowie.

Od osób, które pracują w NASA dowiedziałem się, że cokolwiek napiszą przechodzi rygorystyczną kontrolę. Najpierw twój kod jest przeglądany przez bardziej doświadczonego kolegę, który wytknie ci sporo błędów. Potem, gdy już kolega jest zadowolony, do gry wchodzi lider zespołu, który sprawdzi jeszcze raz czy wszystko jest w porządku. Tak jest, gdy twój kod jest “mało ważny”. Dla krytycznie ważnych kawałków kodu (praktycznie wszystko dotyczące nawigacji) dodatkowo co tydzień organizowany przegląd publiczny. Tekst nowego kodu jest wyświetlany na projektorach a autorzy przed audytorium złożonym z 20-30 inżynierów, testerów i menadżerów, z których każdy ma szanse wytknąć w kodzie bugi. Mimo tego, zdarzyły im się interesujące wpadki — jak np. inwersja priorytetów w Mars Pathfinder.

Wpis “NASA i tworzenie oprogramowania, cz. 2” skomentowano 2 razy

  1. Aga pisze:

    Opublikowanie kodu jako open source może ukazać się najlepszym testem na jego jakość:)

  2. coyot pisze:

    ale czy to zle, ze kod jest tak doglebnie testowany?

    z uzywaniem C (czy nawet ass) jest chyba tak, ze zalezy im na wydajnosci - a jezyki wyzszego poziomu nie zapewniaja az takiej “wladzy” nad pamiecia chociazby. oczywiscie moze to prowadzic do wielu bledow - ale taka jest cena w tym wypadku. i prawdopodobnie dlatego ten kod jest tak doglebnie analizowany - ale ludzie, to tylko ludzie, wiec i taki pathfinder im sie zdarzy..;-)

Dodaj komentarz