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.
Jeśli klasa (yegor256/cactoos#558) lub cały moduł (yegor256/cactoos#399) nie zapewniają oczekiwanej przez Ciebie funkcjonalności - jest to bug.
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.
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.
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.
Jeśli zauważasz nielogiczność (yegor256/cactoos#436) i wiesz, jak można ją zniwelować - jest to bug.
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.
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.