RE: Czy i jak dokumentować kod część I
Fajnie podkreśliłeś, że dokumentacja to nie tylko sztywne pliki tekstowe, ale też struktura folderów, komentarze, testy, czy po prostu dobrze napisany kod...
Jeśli planujesz dalszy ciąg serii, polecam zachaczyć kiedyś o RAML - sam z nim nie pracowałem, ale słyszałem, że pozwala na "zaprojektowanie API w metodologii Documentation-First" i nie znam osoby, która po spróbowaniu by nie zachwalała.
A co do tych komentarzy - ja uważam, że lepiej gdy kod traktuje jako infantylnego głuptasa, niż turbo seniora... Linus Torvalds (chyba on) powiedział, że bardziej od stażystów nie znosi dobrych programistów, bo myślą, że każdy jest tak dobry jak oni i można pisać turbo nieczyteln kod... W JSie gdy spotykasz callback hell, albo znestowane w sobie 3 reducy dobrze nazwane parametry callbacków i chociaż kila słów w komentarzu potrafią uratować dupsko.
Dziękuję. Sprawdzę RAML. Nie korzystałem z tego nigdy. Jest bardzo dużo racji w tym co piszesz. Zawsze obawiam się że różne sztuczki, które się stosuje na codzień nie są zbyt czytelne dla początkujących. Pamiętam, że jak zaczynałem programowanie to strasznie denerwowało mnie, jak ktoś używał skróconego zapisu 'if'
condition ? 'when_true' : 'when_false'. Musiałem sobie to wtedy przetransformować to w głowie na standardowego if-a. Teraz sam zawsze używam skróconej wersji.Jak chcesz kogoś nauczyć ternary expression - blamuj każdego ifa jakiego znajdziej u kogoś w kodzie. To może wydać się lekko nazi, ale mi tak robili i refaktorując ify bardzo szybo nauczyłem się TE. Wiedziałem, że muszę to zrobić, bo commity z ifa mój mentor mi blokował. Kilka dni męki, ale patrząc z perspektywy czasu teraz mu dziękuję. Wiem kiedy użyć jednego, a kiedy drugiego (tak, potem kazał mi refaktorować bezsensowne TE :D) i czytelność skoczyła bardzo do góry, szczgólnie w programowaniu funkcyjnym.