Czy piszesz zły kod pod presją? [Zamknięte]


14

Kiedy odczuwasz presję, zbliża się termin, a menedżer oddycha ci po szyi, czy zaczynasz pisać zły kod? Czy TDD i najlepsze praktyki wymykają się na bok, aby załatwić sprawę? Co robisz w takich sytuacjach? Jakie były twoje doświadczenia


Pozwól, że rzucę ci wyzwanie w jeden wielki sposób: niektóre z największych, najlepszych innowacji, które wymyśliłem, były wynikiem pilnej potrzeby. Czasami upał bitwy przynosi ostry jak brzytwa nacisk, którego dni i dni pontyfikatu i kunsztu nie inspirują.
user1172763,

Odpowiedzi:


31

Jednym słowem tak. Każdy, kto mówi inaczej, jest w najlepszym razie w błędzie.

Kluczem jest jednak wykorzystanie doświadczenia w pisaniu kodu, który jest mniej zły. Oprzyj się pokusie, aby włożyć coś, co sprawi, że „po prostu zadziała”, jeśli w ogóle będzie to możliwe, ponieważ nie będzie. Nadal musisz postępować zgodnie z jakimś procesem (niezależnie od tego, czy jest to twój, firma, czy też ich mieszanka).

Doświadczenie mówi mi, że o wiele lepiej jest ( wstrzymać się ) przesunąć harmonogram na kilka dni, aby zapobiec tygodniowym poprawkom, szczególnie gdy „pod presją” oznacza przyspieszone uruchomienie produkcji. Jeśli spieszysz się z wydaniem kodu, testerzy prawdopodobnie będą spieszyć się, aby go również usunąć.


Dałbym plus 10 za post, bardzo dobrze powiedziane
maz3tt

16

Jeśli zespół jest w kryzysie, coś zostało zrobione źle.

Niedotrzymanie terminów jest oznaką złego planowania i szacunków. Przyznaj, że termin zostanie przekroczony, i rozwiąż problem. Czasami nie masz kontroli nad planowaniem lub szacowaniem. Zidentyfikuj, kto to robi i upewnij się, że wiedzą, że zostało to zrobione przez pomyłkę.

W sytuacji, gdy termin nie może zostać przesunięty, wybijasz wysoko kofeinowe napoje i spieszycie się. Zidentyfikuj wszystko, co możesz poświęcić, i wytnij je. Weź to, co zostało, i zastosuj jak najszybciej. Spowoduje to takie problemy, jak niestabilność, nieparzyste błędy, nieefektywne praktyki kodowania, poprawki pomocy pasma i wszelkiego rodzaju inne okropności. Niekoniecznie jest to zły kod, ale nie jest idealny .

50% dobre rozwiązanie, które ludzie faktycznie rozwiązują więcej problemów i przetrwa dłużej niż 99% rozwiązanie, którego nikt nie ma, ponieważ jest w twoim laboratorium, gdzie bez końca polerujesz to cholerstwo. Wysyłka jest funkcją .

Od Joela na temat oprogramowania The Duct Tape Programmer .

Nie można sobie poradzić z idealnym kodem, jeśli się nim zajmie . Kod, który nie został rozwiązany, gromadzi się, co powoduje, że dodatkowe zmiany są trudniejsze, jeśli nie niemożliwe. Może dojść do momentu, w którym aplikacja jest tak wzajemnie zależna od siebie, że dodawanie może być wykonane tylko przez najbardziej ostrożnych programistów, przy ogromnym koszcie czasu. Podczas gdy wysyłka jest funkcją, więc jest łatwa w utrzymaniu.


1
Jedyne, co chciałbym zmienić, to słowo „ty” w twoim głównym punkcie. Twierdzę, że dla każdego członka twojego zespołu istnieje mnożnik czynników, które mogą pójść nie tak, a dla każdej zależności zewnętrznej istnieje pewien wykładniczy czynnik rzeczy, które mogą się nie udać. Lub odwrotnie. ;)
Wonko the Sane

2
@ysolik: Zobacz przeredagowanie. To może nie być twoja wina, że ​​planowanie lub szacunek były FUBAR.
Josh K

2
@ysolik: Piszesz mniej niż idealny kod, aby dotrzymać terminu i modlisz się, abyś miał szansę go naprawić później. Przy odpowiednim planowaniu tak się nigdy nie dzieje.
Josh K

2
Nigdy nie mów nigdy ... :)
Wonko the Sane

3
@Wonko: Prawidłowo, przy odpowiednim planowaniu zdarza się to rzadko .
Josh K

7

Jestem wielkim fanem kunsztu programistycznego - piszę czysty kod najlepiej jak potrafię itp., Ale czasami musiałem spieszyć się w momentach, w których czas jest krótki i zbliża się termin. Naprawdę staram się nie robić tego najlepiej jak potrafię, ale czasami nie da się od tego uciec.

Niektórzy powiedzą „Cóż, to życie, musisz wysłać”, ale ja naprawdę nie zgadzam się z tym podejściem.

Pisząc pośpieszny kod, możesz skończyć z terminowym usuwaniem oprogramowania, ale co się stanie, gdy w ciągu kilku następnych dni otrzymasz połączenia z pomocą techniczną dotyczące błędów w oprogramowaniu (te błędy żyją w tym samym kawałku kodu, który rzuciłeś, aby zakończyć). A może wściekły klient dzwoni do ciebie z pytaniem, dlaczego jego moduł raportowania już nie działa, nawet jeśli obiecałeś, że będzie dobrze w dniu premiery?

Wszystko to bardzo dobrze mówi „musisz wysłać” , ale istnieje różnica między wyglądaniem wydajnym a wyglądaniem jak niechlujny pracownik.


5

Tak. Ale zawsze wraca, by prześladować mnie później.


2

Kiedy jestem w trudnej sytuacji, mój kod ma na celu wykonanie pracy. Otóż ​​to. W mojej opinii nie koncentruję się na wydajności i innych problemach, które są złe.

Popracuję jednak nad tym.


Spraw, by działało, Napraw
Juha Untinen

1

Nie sądzę, że osobiście piszę znacznie gorszy kod, ale dostarczam gorszy produkt.

W obliczu arbitralnego i niemożliwego terminu oszczędzamy na procesie rozwoju. Dokonujemy bardziej powierzchownych recenzji kodu (lub pomijamy je całkowicie). Mniej testujemy, omijamy szczegółowe testy jednostkowe testów integracyjnych typu spot-check, a następnie próbujemy liczyć test integracyjny jako formalną kwalifikację. Często pomijamy anomalie podczas testowania, jeśli nie są one bezpośrednio powiązane z kryteriami pozytywnego wyniku. Pomijamy aktualizacje dokumentacji, nie sprawdzamy podwójnie informacji o wydaniu, zapomnij przeszukać listę materiałów dostarczanych w poszukiwaniu plików, które nie są już potrzebne.

Kod źródłowy, który piszesz podczas kryzysu, może być wysokiej jakości, ale prawie na pewno zostanie wysłany jako część tandetnego produktu.


0

Zależy.

Czy presja wynika z faktu, że nie można zrobić wszystkiego, a główne nowe funkcje są dodawane na kilka godzin przed wydaniem?

Nadchodzi zły kod!

Ale jeśli dzieje się tak, ponieważ harmonogram jest po prostu naprawdę bardzo napięty, ale ogólny plan jest solidny i po prostu muszę pracować znacznie ciężej niż zwykle i ciągle się koncentrować, jednocześnie poprawiając kilka funkcji, słyszę i tam ... Potem produkuję znacznie lepszy kod niż jeśli harmonogram pozwala na mnóstwo czasu. Nawet jeśli oznacza to, że nie wypisuję wszystkich testów jednostkowych, ale obejmują główne części kodu.


Oooh - dobry komentarz, tyle że ostatnie zdanie trochę mnie przeraża.
Wonko the Sane

Dobrze. To nie znaczy, że nigdy nie zostaną napisani. To przerażające, ale myślę, że to pomaga mi się skupić. I są testy jednostkowe, tylko nie 100% pokrycia. Więcej jak 66%.
ElGringoGrande

Jedynym problemem jest to, że 34%, które nie jest uwzględnione, to nowy kod, który spieszycie się, a nie już ustanowiony kod, który nie jest tak prawdopodobne, że (wszystkie) zepsuje się ze zmianami. Nie mówiąc już o tym, że wszyscy tego nie zrobiliśmy, tylko że jest to przerażająca propozycja.
Wonko the Sane

0

Znam kogoś, kto nigdy nie pisze złego kodu pod presją. Ma też magiczną fasolę, którą możesz być zainteresowany.

Wszyscy czasami piszą zły kod, a zbliżające się terminy są zwykle powodem, sztuczka polega na tym, aby unikać wpadania w tę sytuację (i to też nie jest łatwe).

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.