12 błędów programistów
-
- Piotr Matuszewski,
- 08.02.2011
Deweloperzy czasami wydają się niezdolni do uwolnienia z błędnego koła wciąż tych samych sposobów programowania.
Błąd nr 1: Pośpiech i niedbałość
Zapominanie o podstawach łatwo prowadzi do mało odpornego kodu i często oznacza przeoczenie akcji użytkownika na program. Czy wprowadzone zero trafi do dzielenia? Czy podany tekst będzie właściwej długości? Czy sprawdzono formaty dat? Czy sprawdzono nazwę użytkownika z bazą danych? Najdrobniejsze błędy prowadzą do załamania programu.
Najgorszą stroną niechlujnego programowania jest to, że unowocześnienia języków mające im zapobiec nie spełniają swojej roli. Na przykład najnowsza wersja języka Java oferuje skróconą składnię dla sprawdzania, czy wskaźnik nie jest równy null. Wystarczy dodać znak zapytania do każdego wywołania metody, co zastąpi gęstwinę wyrażeń warunkowych. Na przykład zamiast:
public String getPostcode(Person person) {
String ans= null;
if (person != null) {
Name nmperson.getName();
if (nm!= null) {
ans= nm.getPostcode();
}
}
return ans
}
napiszemy:
public String getFirstName(Person person) {
return person?.getName()?.getGivenName();
}
Ostatecznie taka składnia może jedynie powstrzymać program przed załamaniem, a nie zapewni użyteczności. Nie usuwa przecież głównego problemu - "rozpełzania się wskaźników na null" pod wpływem pośpiesznego i niedbałego programowania.
Błąd nr 2: Nadmierna szczegółowość
Nadmierna szczegółowość prowadzi do powolnej pracy oprogramowania. Sprawdzenie kilku wskaźników nie robi wielkiej różnicy, ale bywają programy sprawiające wrażenie człowieka z zespołem obsesyjno-kompulsywnym, który musi sprawdzić, czy drzwi są zamknięte (raz za razem), co uniemożliwia mu zaśnięcie.
Nieprzejednana dbałość o szczegóły może nawet zawiesić program, jeśli obsesyjna kontrola wymaga komunikacji z odległym serwerem przez sieć. Taki program nie będzie działać przy wyłączonym interfejsie sieciowym, uparcie próbując zestawić połączenie do zdalnej maszyny.
Prawdziwym wyzwaniem jest zaprojektowanie warstw kodu sprawdzających dane, gdy tylko po raz pierwszy się pojawią. W praktyce trudno jest pamiętać sprawdzenie wskaźnika, szczególnie gdy grupa programistów pracuje nad biblioteką.
Błąd nr 3: Brak uproszczeń kontroli
Programiści zbyt często zapominają o uproszczeniu kontroli nad zadaniami w swoim kodzie. Mike Subelsky, programista Ruby on Rails i jeden z założycieli OtherInBox.com, zaleca, żeby każde zadanie miało przypisane jedno miejsce w kodzie. Jeśli będą dwa, to powstaje możliwość, że ktoś zmieni tylko jedno z nich. Jeśli będzie więcej, rośnie prawdopodobieństwo, że ktoś doprowadzi do odmiennego działania w którymś z nich.
"Przepracowawszy ponad trzy lata nad kodem, najbardziej żałuję, że nie uczyniłem go bardziej modularnym" - mówi Subelsky. "Nauczyłem się boleśnie, czemu zasada pojedynczej odpowiedzialności jest tak ważna. Stosuję ją w nowym kodzie i jest to pierwsza rzecz, którą się zajmuję przy refaktoryzacji starego kodu".
Ruby on Rails zachęca do tworzenia zwartego kodu, zakładając, że większość struktury oprogramowania tworzy znane wzorce. Programiści Rails określają to podejście "konwencja zamiast konfiguracji". Program zakłada, że jeśli ktoś tworzy obiekt typu Name, z dwoma polami first i last, to powinna powstać tabela w bazie, nazwana Name, z dwiema kolumnami first i last. Nazwy są wyszczególnione tylko w jednym miejscu, co pozwala uniknąć kłopotów, gdyby komuś nie udało się utrzymać synchronizacji wszystkich warstw konfiguracji.
