Trzecia kawa Szkolenie Scrum

Dlaczego informatycy są nienormalni?

W „Autobiografii” Joanny Chmielewskiej jest fragment, w którym profesor architektury tłumaczył swoim studentom dlaczego architekci nie są normalni. Sens tego dowodu jest następujący: otóż normalni ludzie myślą o jednej, góra dwóch, rzeczach naraz – natomiast architekt projektując budynek, musi pamiętać trzydziestu różnych rzeczach jednocześnie.

Pomyśl teraz, że jesteś programistą i wprowadzasz jakąś zmianę w systemie informatycznym. Przypuśćmy że masz już określone wymagania użytkownika, wybraną technologię, framework i możesz przystąpić do radosnej twórczości. Musisz pamiętać o:

  1. Zgodności rozwiązania z wymaganiami – to przecież sprawa podstawowa.
  2. Zgodności rozwiązania z przyjętą architekturą systemu.
  3. Wydajności systemu – i to najczęściej w kilku kontekstach: wydajność aplikacji, wydajność bazy danych, wydajność sieci, wydajność interfejsów.
  4. Bezpieczeństwie systemu w kontekście „idiotoodporności” – niestandardowe działania użytkownika nie mogą prowadzić do przypadkowych czy też, co gorsza, destrukcyjnych rezultatów.
  5. Bezpieczeństwie systemu w kontekście odporności na zamierzone działania nastawione na uszkodzenie systemu.
  6. Odporności na sytuacje wyjątkowe – w przypadku współpracy różnych z systemów typową sytuacją wyjątkową do obsłużenia jest przerwanie w dowolnym momencie łączności z innym systemem.
  7. Usability – czyli łatwości i intuicyjności korzystania z systemu.
  8. Dokumentowaniu rozwiązań – w formie komentarzy w kodzie i/lub zewnętrznej dokumentacji.
  9. Tworzeniu testów jednostkowych – bo przecież chcemy je mieć.
  10. Dbaniu o spójność i łatwość utrzymania systemu – bardzo rzadko pierwsze stworzone rozwiązanie jest idealne. W typowych sytuacjach wraz z tworzeniem nowych fragmentów kodu dokonujemy jednoczesnego refactoringu istniejącego kodu.
  11. Koszcie zmian – we wszystkich rzeczywistych sytuacjach budżet projektu jest ograniczony.

Ta lista nie jest pełna – na pewno można byłoby do niej dodać jeszcze kilka elementów…

Wykonując nawet bardzo proste zmiany w systemie musisz pamiętać o wszystkich powyższych aspektach. A zaniedbanie dowolnego z tych aspektów może wpłynąć na niepowodzenie całego projektu.

Także jeżeli za definicję normalności uznajemy zajmowanie się jednocześnie jedną lub tylko kilkoma sprawami na raz – programiści wykonujący zmiany w systemach nie są normalni.

Q.E.D.

Jeden komentarz

  1. Maciej Stachowiak (@mstachowiak) napisał(a):

    Zmierzenie normalności/nienormalności jednym parametrem jest bardzo niebezpieczne – mówiąc po fizycznemu, spolaryzowałeś Drogi Kolego zagadnienie do jednego wymiaru :)

    Z moich obserwacji: najlepsi informatycy to prawdziwi dziwacy – mamy na pokładzie faceta z ADHD [unikam generalizowania i szufladkowania, ale to nie jest tylko moja opinia]. Ma 25lat, jest samoukiem, słucha holenderskiego techno, pracuje w czapeczce z daszkiem, ale tworzy nieprawdopodobne rzeczy w szalenie krótkim czasie.
    Drugi to projektant baz danych – ten to medytuje nad strukturą, przemyślenia ma co najmniej transcendentne i łapie kontekst systemów od razu sięgając na kilka miesięcy do przodu. Budzi we mnie paranoiczny hihot jak z filmu Davida Lycha.

    Ogólniej – najbardziej lubię:
    – optymalizowanie kodu by był wydajniejszy – jak szukanie kwiatu paproci albo jednorożca,
    – kompaktowanie funkcji w kolejnych systemach tak by wykorzystywały jedną możliwie uniwersalną funkcję.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *