nawet jak się pojawi to jednorazowo, nie będzie aktualizowana, i mało kto ją przeczyta
@oslet: Jak nie będzie aktualizowana to nikt jej nie będzie czytał, wot odkrycie xD Krótka piłka - idzie commit, razem z kodem musi lecieć zmiana w dokumentacji.
@SaintWykopek i słusznie. Każdy chce niby tej dokumentacji ale przecież każdy i tak doskonale wie, że nawet jak się pojawi to jednorazowo, nie będzie aktualizowana, i mało kto ją przeczyta. Nie po to są nowoczesne środki porozumienia się żeby pisać do, siebie wielostronicowe listy jak w średniowieczu.
@oslet szczegolnie jest to nieprzydatne w przypadku architektury systemow, rodzaju zaleznosci miedzy elementami. Ale kto by sie tam przejmowal, hit commit i do domku xD
@oslet: dokumentacja powinna przede wszystkim dotyczyć stabilnych elementów takich jak architektura systemu czy opracowane procesy. Dzięki temu może służyć jako gwarancja stosowania przyjętych praktyk i utrzymania wizji projektu. Nie powinna tym samym zbyt często podlegać zmianom. Brak odpowiedniej dokumentacji promuje chaos w zespole i bałagan w produkcie.
Poza tym nie da się zapamiętać wszystkiego, po to jest dokumentacja.
Nie chciałbym z Tobą pracować xD
Każdy poważny inżynier zaczyna od zapoznania się z docsami i API...
@oslet: Jak nie będzie aktualizowana to nikt jej nie będzie czytał, wot odkrycie xD Krótka piłka - idzie commit, razem z kodem musi lecieć zmiana w dokumentacji.
Proszę prosty przykład. Co zwraca funkcja f?
int f(int n) { return (n==1 || n==0) ? 1: n * f(n - 1); }