Jak pisać programy

Po długich bojach doszedłem że mniej więcej tak powinien wyglądać cykl deweloperki kawałka aplikacji. Kawałka czyli jakiejś funkcjonalności, klasy. Ogólnie ma być to na tyle nieskomplikowane żeby dało się to objąć umysłem na raz.

  1. Wiedzenie co kod ma robić. Wiedza ta może przybrać formę specyfikacji, ale nie musi — to ty musisz wiedzieć co piszesz
  2. Pisanie kodu
  3. Pisanie testów. I testowanie.
  4. Usunięcie wszystkich warningów
  5. Przelecenie się FindBugiem po kodzie. To takie fajne narzędzie pozwalające wykryć dziwne ciężko testowalne bugi (w stylu nie zamknięcie OutputStreama).
  6. Poprawki kodu tak żeby findbug nie dawał errorów.
  7. Pisanie dokumentacji.

Ja wiem że są ludzie którzy by to odwrócili — 'najpierw napisz testy', 'jak nie jesteś w stanie napisać testów, to znaczy że niedostatecznie wyspecyfikowałeś aplikację', 'najpierw specyfikacja API'.

Ale ja nie jestem dobry na tyle żeby z powietrza tak wyspecyfikować program żebym najpierw pisał dokumentację, a potem implementację. Co więcej kiedy mam pracujący kod mogę łatwo go ulepszać i wychodzi (moim zdaniem) lepszy niż to co wymyślałem na początku.

Idea jest taka że w każdym kroku możesz zmieniać to co powstało w krokach poprzednich - pisząc testy (jak znajdziesz buga) zmieniasz kod, tak samo jak usuwasz warningi. Odwrócenie tego powoduje zwiększoną ilość pracy — jeśli masz dokumentację, testy i kod bez warningów i coś zmieniasz w nim to trzeba zmienić i testy i dokumentacjię i … .

O ile nie zaznaczono inaczej, treść tej strony objęta jest licencją Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License