Witajcie koledzy i koleżanki,
Chciałbym poruszyć dość powszechny problem, jakim jest tworzenie kodu pozbawionego głupich błędów.

Otóż pisząc tego posta opieram się na własnych doświadczeniach w tym zakresie. Pracując jako programista PHP, zwykle mam do wykonania jakiś moduł. W momencie testowania napisanego kodu według specyfikacji, okazuje się że wychodzi wiele głupich błędów, w tej chwili nie posiadam żadnych konkretnych przykładów, ale chodzi tutaj o takie elementy które powodują że w danych sytuacjach aplikacja po prostu się wysypuje, zwraca/zapisuje do bazy złe dane oraz nie działa jak powinna. Po przetestowaniu wydaje mi się że wszystko jest ok. Jednak już po krótkim czasie dostaje od innej osoby testującej listę błędów przekraczającej kartkę A4 :/
Czym to może być spowodowane? Jak walczyć z tego typu dolegliwością? Czy może to być spowodowane po prostu brakiem talentu do programowania?
Co robić?

Jak wygląda u Was podobna sytuacja? Czy napisany i przetestowany kod działa poprawnie i zawiera tylko drobne błędy, które każdemu mogły się przytrafić. Czy może także po napisaniu kodu, połowa rzeczy się sypie? Proszę nie pisać o pisaniu testów bo to jest oczywiste, jednak bez testów także można pisać kod pozbawiony błędów lub zawierający ich mała ilość.
Można powiedzieć że wpadłem w depresję i boję się że pracodawca może mi podziękować za współpracę prędzej czy później za dziurawe aplikacje.

Jak zrobisz testy jednostkowe (bądź funkcjonalne) ze 100% pokryciem kodu szansa wystąpienia błędu znacznie się zmniejsza.
Poczytaj o PHPUnit

Odpowiem uzywajac zaslyszanej ostatnio anegotki - otoz w pewnej firmie, swiezo upieczony manadżer widząc wyniki finansowe i nakłady jakie firma ponosi na testowanie swoich produktów, wpadł na genialny pomysł - zwolnimy wszystkich testerów i zatrudnimy programistów, którzy piszą bez błędów...

Zaznaczam jeszcze raz, że to anegotka - a ty jako autor po prostu nie jesteś w stanie pewnych przypadków opracować, a jeszcze jak się przywiązujesz emocjonalnie do swoich rozwiązań (tak jak autor tego posta ) to wręcz nawet zakładasz, że przecież napisałeś takie cudo, że to nie może nie działać. Głowa do góry, nie ma ludzi nieomylnych.

E tam ;] Większość błędów przy programowaniu czegoś większego niż hello world to malutkie niedoróbki, ja przykładowo dzisiaj siedziałem 4h zanim odkryłem błąd. Polegał na tym, że zamaist if($fSignature === 1) miałem if($fSignature == 1), przez jeden znak w 300 linijkowym kodzie rezultat (spakowane archiwum z update) nadawało się do kosza bo metadane o plikach nie pokrywały się kolejnością z ich zapisem
Jednym słowem - to norma

Nikt nie jest w stanie przewidzieć tego co użytkownik docelowy zrobi z aplikacją. Ty piszesz sobie pomalutku, analizujesz, testujesz na bieżąco z upływem czasu nabierasz coraz więskzego przekonania że wszystko jest ok. Dopiero w praniu wychodzi wszystko. Dla mnie, amatora i hobbysty to jest naturalne i akceptuje to (czasem naprawienie czegoś to więcej frajdy niż większa część kodu). Nie wiem jak jest na zawodowym stopniu programowania ale podejrzewam że nie da się błędów wykluczyć już na etapie pisania.

A niby dlaczego choćby do Windowsa wychodzi tyle poprawek ? Nie da się wyeliminować błędów, od ich wykrywania są automatyczne testy i testerzy.

Błędy to też dla nas okazja do zarobku, większość to po prostu zwykłe luki w specyfikacji
Najlepiej by aplikacja była odbierana etapami przez analityka wspartego grupą zwykłych użytkowników (najlepiej klikających we wszystko co się da jak dzikie małpy), jeśli dziś działa a już jutro nie działa to znaczy, że jakiś użytkownik ją zepsuł
Można też odpalić kilka botów testujących do np. wykrywania złych linków.
Nikt nie jest w stanie wychwycić wszystkich błędów, bo możliwości jest po prostu zbyt wiele, często nie jesteśmy w stanie nawet stwierdzić, co jest nie tak (zawsze ktoś tam nie może się zalogować i bądź mądry).

Nie bez powodu Google prócz inżynierów zatrudnia ludzi 40+, zwykłych Kowalskich. Jeśli oni nie umieją zainstalować i obsłużyć softu albo coś zepsują to wraca spowrotem

Ja od początku programowania aplikacji skupiam się na TYPACH danych o czym wielu programistów bez przeszłości z np. C++ , Java zapomina.

Dokumentowanie każdej metody, każdej klasy. Co przyjmuje i co zwraca - i tutaj dokładnie przypilnowanie aby właśnie zwracała TYLKO to (typ danych) jaki zaplanujemy. Oczywiście jeśli MIXED to również to zaznaczamy.

Ano brak typów danych to najgorsza zmora PHP
Ja zaczynałem naukę programowania od PHP i to był błąd.. przez brak typów łatwo nauczyć się złych nawyków

Pozostaje czekać na PHP 5.4, które częściowo typy wprowadzi.

@Mephistofeles: Czy nie chodzi Ci aby przypadkiem o type hinting dla typów prymitywnych? Z silnym typowaniem to to nie ma wiele wspólnego.

W PHP silnego typowania raczej nigdy nie będzie - zabiłoby to ten język.

Drobne błędy oczywiście, się czasem zdarzają ale bez przesady, ogólnie nie piszę testów i raczej rzadko mi się zdarza żeby coś nie działało, wydaje mi się, że problem może leżeć w samym procesie realizacji: ja np. zanim cokolwiek zacznę pisać(w większych projektach) to sobie spisuje w notatniku wszystkie informacje o projekcie: jakie dane będą przetwarza i przechowywane w bazie, jakie relacje, jakie procesy, wszystkie funkcje dla użytkownika zalogowanego/niezalogowanego/admina/moderatora itp. itd. . Ogólnie tak zauważyłem, że wielu programistów od razu bierze się za pisanie aplikacji kompletnie pomijając fazę projektowania bo ludziom się wydaje, że to strata czasu, ale prawda jest taka że jak spędzisz kilka godzin w fazie projektowania to możesz zaoszczędzić kilkanaście godzin w fazie pisania i debugowania , a potem właśnie wychodzą problemy, że czegoś się nie przewidziało, a drugi powód to złe nawyki w programowaniu

Wiem, dlatego napisałem częściowo. Nie orientuję się co prawda jak będzie wyglądało powiadamianie o złym typie, ale i tak uważam, że to dobre rozwiązanie do kontroli argumentów.

A to czemu niby?

Z tym, że testy jednostkowe też trzeba umieć pisać - i to także nie jest łatwa sztuka.
Raz to przetestować dla dobrych parametrów i tzw. "prawidłowego użycia". Ale też z drugiej strony pisanie testów takich, które starają się "położyć" aplikację - przede wszystkim nieprawidłowe parametry, czy też sprawdzanie, czy metody rzucają odpowiednimi wyjątkami.

Zupełnie inną sprawą jest testowanie kontrolerów - pytanie, czy zaliczymy to do testów jednostkowych czy funkcjonalnych? No chyba, że przyjmiemy założenie, że jak napisane w PHPUnit, to jednostkowe, a jak w Sellenium (dla których PHPUnit i tak ma wsparcie) to funkcjonalne.

@Mephistofeles: O ile dobrze się orientuję nie chodzi o żadne zgłaszanie błędów, a o automatyczne rzutowanie, czyli:

[PHP] pobierz, plaintext 
function abc(int $arg) {
  return $arg * 2;
}
 
abc('23'); // $arg = (int) 23
abc(344.424); // $arg = (int) 344
 
function def(string $arg) {
  return $arg . 'xx';
}
 
def(434); // $arg = (string) "434"
def($myObject); // $arg = (string) $myObject->__toString();
[PHP] pobierz, plaintext 

@Bags_Bunny: poprawione.

@Crozin: w 12 i 13 to chyba Ci o def() chodziło, a nie abc().

@Crozin: dziękuję.

To trochę lipa, mimo wszystko powinno wywalić choćby notice.

Wtedy byś się tych notice'ów nie pozbył za żadną cholerę... Albo ilość jawnych rzutowań przed przekazaniem zmiennej jako argumentu funkcji zaśmieciłaby cały kod. PHP jest dynamicznie typowany i trzeba się z tym pogodzić - jak, nie pasuje to masz przecież alternatywę w postaci chociażby Javy.