Więcej bugów, proszę

Bug jest czymś, co znajdujemy w rozwijanym oprogramowaniu. Czymś, co nie wygląda dobrze - to moja prywatna definicja. Może być ukryty lub widoczny, już naprawiony albo wciąż istniejący. Bug krytyczny, tylko kosmetyczny, pilny do naprawienia lub bug niskiego priorytetu.

Liczy się to, że im więcej błędów uda się nam znaleźć i naprawić zanim pojawią się przed oczami naszych klientów, tym wyżej postrzegana będzie jakość produktu. Mówiąc prosto, błędy to dobra rzecz - o ile to my je znajdziemy, nie nasi klienci. Gdzie i jak je znajdować? Oto ściągawka dla developerów.

Brak funkcjonalności

Jeśli klasa (yegor256/cactoos#558) lub cały moduł (yegor256/cactoos#399) nie zapewniają oczekiwanej przez Ciebie funkcjonalności - jest to bug.

Brak testów

Jeśli nie przeprowadzano testów jednostkowych klasy (yegor256/takes#43) albo nie obejmują one kluczowych aspektów klasy (yegor256/cactoos#375) - jest to bug.

Brak dokumentacji

Jeśli - powiedzmy - fragment Javadoc dotyczący klasy nie tłumaczy jasno jak jej używać, albo nie mamy właściwej dokumentacji dla całego modułu (yegor256/takes#790) - jest to bug.

Nieoptymalna implementacja

Jeśli fragment kodu na Twoje oko nie wygląda dobrze i uważasz, że można by go zrefaktorować, by wyglądał lepiej - jest to bug.

Brak spójności projektu

Jeśli zauważasz nielogiczność (yegor256/cactoos#436) i wiesz, jak można ją zniwelować - jest to bug. 

Dziwne nazewnictwo

Jeśli nazwy klas, zmiennych lub pakietów nie są nadawane konsekwentnie i jasno, a do tego wiesz, jak to naprawić (yegor256/cactoos#274) - jest to bug.

Zmienny wynik testów jednostkowych

Jeśli test jednostkowy niekiedy zawodzi (yegor256/takes#506) lub nie uruchamia się w jakimś konkretnym środowisku (yegor256/jpeek#151) - jest to bug. 

Jeśli chcesz posunąć naprzód rozwój projektu pamiętaj, by zgłaszać błędy we właściwy sposób.