Sposoby by programista niszczył firmę od środka będąc niezauważonym
Pisanie złego kodu, to wcale nie taka łatwa sprawa. Zły kod musi przecież też przejść code review, wydawać się przydatny a nawet pożądany, a mimo tego musi robić złę rzeczy, które będą latami cieżarem dla projektu. Straszne, prawda? Oczywiśćie, wrzucam po to, by inni mogli się przed tym bronić :)
anonimowy_programista z- #
- #
- #
- #
- #
- 136
Komentarze (136)
najlepsze
Najgorsze co można mieć to zespół zdolnych/ambitnych programistów którzy znają dobre praktyki i się ich przymusza do robienia fixów na szybko, po łebkach, byle by działało, bo termin już dawno jest ustalony przed estymatami.
Tak niestety bywa najczęściej.
Złe praktyki to akurat można wyplenić w średnio dużym zespole, bo wystarczy żeby jedna-dwie-trzy osoby były ogarniętymi seniorami.
Niestety nic nie pomaga jeśli zarządzanie projektem ssie i się wszystko robi
Ileż razy ja się naogladalem super klas co robią wszystko i mają po 1k+ linii kodu. Tego się nie da czytać. A jak jeszcze do tego wrzucone są wątki, które jakoś komunikują się z innymi, równie wielkimi klasami to idzie się tylko pociąć.
Jak dla mnie jeśli klasa ma 1k+ linii (jestem programistą mobilnym w androidzie) to poza nielicznymi przypadkami jest to błędnie napisana klasa. No i jeszcze komentarze typu
//
Ten przykład z bitami zamiast kilku booli też z dupy, albo z ery C. Pisząc w Javie, PHP, JavaScripcie nie widziałem ani razu takiego pomysłu.
Używanie rekurencji zamiast iteracji w prostym forze? Nie widziałem nigdy tak szalonego pomysłu.
Przykład z wieloma zmiennymi jest
np. w rozbijaniu na funkcję, to może to mieć sensu lub nie w zależności od kontekstu np.
jak ta jedna funkcja jest duża, jak np. funkcja ma 5000
`UPDATE [OrdersBody] SET Price = Price*RAND();' xD