Skąd programiści i programiści wiedzą, że mają rację?


166

Jeśli zapytasz programistów, dlaczego powinni pisać czysty kod, odpowiedzią numer jeden, którą otrzymasz, jest łatwość konserwacji. Chociaż jest to na mojej liście, mój główny powód jest bardziej bezpośredni i mniej altruistyczny: nie mogę powiedzieć, czy mój nowy kod jest poprawny, jeśli jest zbyt brudny. Przekonałem się, że tak bardzo skupiłem się na poszczególnych funkcjach i liniach kodu, że kiedy kończę mój pierwszy szkic i cofam się, aby ponownie spojrzeć na duży obraz, czasami nie pasuje do siebie. Spędzenie godziny lub dwóch refaktoryzacji dla czystości często odkrywa błędy kopiowania / wklejania lub warunki brzegowe, które były bardzo trudne do wykrycia w szorstkim ciągu.

Jednak niektórzy uważają, że czasami celowe jest wpisywanie brudnego kodu w celu wysyłki oprogramowania, z planem „wyczyszczenia go później”. Czy istnieje jakaś praktyczna technika, która daje im pewność co do poprawności kodu, gdy czytelność jest mniejsza niż idealna? Czy to umiejętność, którą warto rozwijać? A może brak zaufania do kodu jest dla niektórych osób łatwiejszy do zaakceptowania?


40
Moja teoria jest taka, że ​​wszyscy koderzy znajdują się gdzieś pomiędzy „zapamiętywaczami” a „programami rozumującymi”, a niewielu potrafi zrobić to dobrze. Im więcej bzdur możesz zapamiętać od razu, tym bardziej niechlujny możesz sobie pozwolić na tworzenie kodu. Czy kod jest czysty, czy nie, spraw, by działał, przetestuj go!
Job

35
Jednak niektórzy uważają, że czasami celowe jest wpisywanie brudnego kodu w celu wysyłki oprogramowania, z planem „wyczyszczenia go później”. heh ... piekło zamarznie, zanim będzie „ później ”…
Carlos Campderrós,

28
Nie wszyscy programiści myślą podobnie - dostałem kod do utrzymania, który nie miał dla mnie sensu przez wiele miesięcy, aż pewnego dnia wyglądało to tak, jakby włączono włącznik światła, gdy zdałem sobie sprawę, jaka była ogólna struktura organizacyjna i wszystko miało sens, dlaczego zrobili to tak, jak zrobili. Czy zrobiłbym to w ten sposób? Nie, ale zadziałało.
Joe

12
@joe - +1 - niektórzy programiści zbyt szybko odrzucają kod, który nie pasuje do tamtejszego osobistego pojęcia „dobrego kodu”. Zawsze powinieneś starać się zrozumieć sposób myślenia o treści kodu i jego stylu, często nauczysz się czegoś pożytecznego.
James Anderson

10
How do quick & dirty programmers know they got it right?Ponieważ to działa :)
Rachel

Odpowiedzi:


100

Kod prawdopodobnie nie jest poprawny.

Może to jednak nie mieć znaczenia.

Szybka i brudna może być właściwą drogą w sytuacjach, gdy:

  • Kod ma krótki czas życia . Na przykład przekształcasz wiele danych w standardowy format za pomocą programu ad-hoc.
  • Negatywny wpływ awarii jest niewielki :
    • Dane, które transformujesz, nie są krytyczne, a błędy w nich można łatwo poprawić
    • Użytkownik końcowy jest sympatycznym programistą, który będzie rozumował komunikaty o błędach i omijał je, powiedzmy, masując dane wejściowe.

Czasami nie jest ważne, aby kod był solidny i obsługiwał wszystkie możliwe dane wejściowe. Czasami musi po prostu obsługiwać znane dane, które masz pod ręką.

W takiej sytuacji, jeśli testy jednostkowe pomogą ci szybciej napisać kod (tak jest w moim przypadku), użyj ich. W przeciwnym razie, kod szybki i brudny, załatw sprawę. Błędy, które się nie uruchamiają, nie mają znaczenia. Błędy, które naprawiasz lub pracujesz w locie, nie mają znaczenia.

To, co absolutnie niezbędne, to to, że nie błędnie zdiagnozujesz te sytuacje. Jeśli kodujesz szybko i nieczysto, ponieważ kod zostanie użyty tylko raz, wówczas ktoś decyduje się na ponowne użycie kodu w jakimś projekcie, który zasługuje na lepszy kod, ten kod zasługuje na większą ostrożność.


24
+1 dla „wpływ awarii jest niski”. Moim ulubionym matematycznym obliczeniem ryzyka jest ryzyko = rzeczywista konsekwencja awarii x prawdopodobieństwo awarii x postrzegana konsekwencja awarii (z mojego doświadczenia wynika , że postrzegane ryzyko, które interesariusze często utkną)
Trav

7
„Kod ma krótki czas życia. Na przykład przekształcasz wiele danych w standardowy format za pomocą programu ad-hoc”. Co się stanie, jeśli transformacja nie zostanie wykonana poprawnie, ale rozbieżności w danych zostaną zauważone dopiero znacznie później?
Joey Adams,

3
@Trav Tak więc, aby potwierdzić, że faktyczna konsekwencja awarii jest ogromna, ale moja postrzegana konsekwencja awarii wynosi zero, nie ma żadnego ryzyka?
Christian Stewart

3
@ChristianStewart Z czysto matematycznego punktu widzenia twoje twierdzenie byłoby poprawne. Jednak w praktyce postrzeganie konsekwencji jako zero nie neguje wagi prawdopodobieństwa x rzeczywistej konsekwencji. Postrzeganie jest umieszczane w formule, aby uwzględnić obawy organizacyjne, które często wpływają na decyzje dotyczące łagodzenia. Brak takiego strachu nie zmniejsza faktycznego prawdopodobieństwa ani konsekwencji. Dlatego należy założyć, że postrzeganie jest zawsze co najmniej równe 1 (ponieważ może powiększać, ale w żaden sposób nie negować faktycznego ryzyka)
Trav

1
@Trav Alternatywnie zmień nazwę na jeden. Mianowicie, ryzyko należy zamienić na postrzegane ryzyko , ponieważ jeśli uważamy, że nie ma żadnych konsekwencji awarii, prawdopodobnie również uważamy, że nie ma ryzyka.
Delioth,

237

Oni nie. Obecnie pracuję nad bazą kodu stworzoną przez „szybkich i brudnych” programistów, którzy „wyczyściliby ją później”. Dawno minęły, a kod żyje dalej, trzeszcząc w stronę zapomnienia. Kowbojscy koderzy po prostu nie rozumieją wszystkich potencjalnych trybów awarii, jakie może mieć ich oprogramowanie i nie rozumieją ryzyka, na jakie narażają firmę (i klientów).


31
Ilekroć słyszę „później to posprzątaj” lub „zrobimy to, gdy sytuacja trochę zwolni”. Zawsze kusi mnie, aby zacząć śpiewać „Jutro, jutro, pokocham cię jutro. Ale to może być tylko ja.
JohnFx,

8
Wielu z nas było w dość niefortunnej sytuacji. To dość niepokojące, że zapisał dług techniczny innych ludzi .
Mark Booth,

34
Rzeczywistym problemem jest klasyfikowanie innych programistów na kowbojskie lub szybkie i brudne lub inne tytuły. Każdy programista ma kilka trybów awarii, a odczytanie kodu jest bardzo trudne, a znalezienie własnych błędów jest bardzo trudne. Wszystko to razem oznacza, że ludzie zbyt łatwo oznaczyć innych programistów, jak źli, myśląc własnego kodu jest idealne
TP1

3
@ tp1: Dobrzy programiści potrafią pisać kod, który jest łatwy do odczytania. Robią to, prosząc kogoś innego o przeczytanie i wyjaśnienie wszystkiego, co jest niejasne. Z praktyką część niejasna przy pierwszym czytaniu będzie się kurczyć.
kevin cline

9
@JimThio, czy naprawdę uważasz, że którykolwiek z wyżej wymienionych programistów celowo napisał zły kod? Czy czytałeś kiedyś kod napisany kilka lat temu? Czy uważasz to za dobre? Możliwe, że dawałeś z siebie wszystko i nadal widzisz wiele rzeczy, które można poprawić w tym kodzie.
Péter Török,

103

Okej, ryzykując całkowitą przynętą, zamierzam „diabłów popierać” pogląd przeciwny.

Proponuję, abyśmy jako programiści nadmiernie martwili się takimi rzeczami, jak właściwa praktyka i czystość kodu. Sugeruję, że chociaż te rzeczy są ważne, nic nie ma znaczenia, jeśli nigdy nie wyślesz .

Każdy, kto był w tym biznesie przez pewien czas, prawdopodobnie zgodziłby się, że można będzie bawić się oprogramowaniem w nieskończoność. Duke Nukem Forever, moi przyjaciele. Nadchodzi czas, kiedy ta przyjemna w obsłudze funkcja lub tak pilna praca refaktoryzacyjna powinny zostać odłożone na bok, a rzecz powinna się nazywać GOTOWA.

Wiele razy o to walczyłem. ZAWSZE jest jeszcze jedna poprawka, coś innego, co „należy” zrobić, aby było „właściwe”. ZAWSZE możesz to znaleźć. W pewnym momencie, w prawdziwym świecie, wystarczająco dobry musi być wystarczająco dobry. Żadne rzeczywiste oprogramowanie wysyłkowe nie jest idealne. Żaden. W najlepszym razie jest wystarczająco dobry.


9
A może, jeśli jest używany, ciężko, przez dziesięciolecia, prawdopodobnie będzie wyglądał jak bałagan. Jeśli nie będzie używany (w ogóle lub przez długi czas), nie będzie miał szans na nagromadzenie żadnego cruftu.
Bezużyteczne

7
„Każdy, kto zajmuje się tym biznesem, prawdopodobnie zgodziłby się, że będzie można bawić się oprogramowaniem w nieskończoność”. Byłoby to możliwe, ale dlaczego to robisz? Po ustaleniu standardu jakości projektujesz go, wdrażasz, testujesz, naprawiasz błędy, testujesz ponownie, a następnie go nie dotykasz. Zajmuje więcej czasu niż zwykłe włamanie się do niego, ale gdy osiągniesz swój cel (wymagana funkcjonalność zostanie zaimplementowana i przetestowana), jest całkiem jasne, że nie powinieneś już więcej majstrować przy kodzie. Tylko moje 2 centy.
Giorgio

7
+1 - w prawdziwym świecie zawsze będzie kompromis między jakością kodu a dotrzymywaniem terminów. Wolałbym mieć programistę, który potrafi szybko opracować rozsądny kod, niż perfekcjonistę, który spędza miesiące bolesne nad tym, czy powinien nazwać metodę „serializować” czy „writeToFile”.
James Anderson,

3
to powiedziałaś. Pracowałem w organizacji, w której w następnym pokoju był zespół, który pracował nad wymaganiami funkcjonalnymi dla nowego systemu przez ostatnie 5 lat, nigdy nie napisano dla niego linii kodu. Wielu programistów jest takich samych (szczególnie juniorzy, świeżo po studiach z dużymi pomysłami na kod musi być piękny i spełniać określone „standardy”, inaczej jest źle) i będzie, o ile nie zostanie zatrzymany, bez końca bawi się czymś, co było doskonale funkcjonalne kilka miesięcy temu (ja czasami nadal mam tę tendencję, myślę, że wszyscy tak). Ale w końcu najważniejsze jest wyciągnięcie go za drzwi.
jwenting

6
@Giorgio: Nie zgadzam się z twoim „przesądem”, że praca wysokiej jakości trwa dłużej niż zwykłe hakowanie. Może tak być, jeśli utożsamiasz programowanie z pisaniem. Biorąc pod uwagę cały cykl życia oprogramowania, sprawy przebiegają znacznie płynniej, a zatem szybciej, jeśli zależy Ci na jakości.
ThomasX

85

Tacy programiści prawie nigdy nie wiedzą, że dobrze to zrobili, tylko w to wierzą . Różnica może nie być łatwa do zauważenia.

Pamiętam, jak programowałem, zanim dowiedziałem się o testach jednostkowych. I pamiętam to poczucie pewności siebie na zupełnie innym poziomie po przeprowadzeniu pierwszego przyzwoitego zestawu testów jednostkowych. Nie wiedziałem, że taki poziom zaufania do mojego kodu istnieje wcześniej.

Dla kogoś, kto nie ma tego doświadczenia, nie można wyjaśnić różnicy. Dlatego mogą nawet rozwijać się w trybie kodowania i modlitwy przez całe życie, życzliwie (i nieświadomie) wierząc, że robią, co w ich mocy, biorąc pod uwagę okoliczności.

To powiedziawszy, naprawdę mogą istnieć wspaniali programiści i wyjątkowe przypadki, kiedy naprawdę uda się utrzymać całą przestrzeń problemową w jego umyśle, w stanie pełnego przepływu. Doświadczyłem takich rzadkich chwil, kiedy doskonale wiedziałem, co napisać, kod po prostu wyleciał ze mnie bez wysiłku, mogłem przewidzieć wszystkie specjalne przypadki i warunki brzegowe, a wynikowy kod po prostu działał . Nie mam wątpliwości, że istnieją geniusze programowania, którzy mogą pozostać w takim stanie przepływu przez dłuższy czas lub nawet przez większość swojego czasu, a to, co tworzą, to piękny kod, pozornie bez wysiłku. Sądzę, że takie osoby mogą nie mieć potrzeby pisania drobnych testów jednostkowych, aby zweryfikować to, co już wiedzą. A jeśli naprawdę jesteś geniuszem, może być OK (chociaż nawet wtedy nie będziesz w pobliżu tego projektu na zawsze i powinieneś pomyśleć o swoich następcach ...). Ale jeśli nie ...

I spójrzmy prawdzie w oczy, prawdopodobnie nie jesteś. Ja sam wiem, że nie jestem. Miałem rzadkie chwile spływu - i niezliczone godziny żalu i smutku, zwykle spowodowane własnymi błędami. Lepiej bądź szczery i realistyczny. W rzeczywistości uważam, że najwięksi programiści są w pełni świadomi własnej omyłki i błędów z przeszłości, więc świadomie rozwinęli nawyk podwójnego sprawdzania swoich założeń i pisania tych małych testów jednostkowych, aby zachować bezpieczeństwo. ( „Nie jestem świetnym programistą - po prostu dobrym programistą o wielkich nawykach.” - Kent Beck.)


8
„życzliwie (i nieświadomie) wierząc, że robią co w ich mocy, biorąc pod uwagę okoliczności”. Idealne podsumowanie problemu. # 1 rzucił się z powodu ograniczeń i zrobił wszystko, co mógł. Nadchodzi # 2, który odziedziczył chaos i nowe terminy, a także daje z siebie wszystko. Aż do dwudziestej biednej duszy, która nie mogłaby dać z siebie wszystkiego, gdyby miał lata, by naprawić szkody. Właśnie dlatego praktykuję zasadę skautów: „zostaw to czystsze niż znalazłeś”. Daj temu następnemu sokowi szansę na walkę - to możesz być ty.
Steve Jackson

1
Zabawne, czuję się odwrotnie, odkąd zacząłem testować jednostki w kodzie (w pracy). To jak lenistwo; nie ma powodu, aby naprawdę rozumieć twój kod, ponieważ inny kod będzie
wychwytywał

8
Częściowo piszesz testy jednostkowe, aby udowodnić, że Twój kod działa. Co ważniejsze, piszesz testy jednostkowe, aby inni programiści mogli bez obaw zmieniać Twój kod.
Stephen Gross

4
Donald Knuth: „Strzeż się błędów w powyższym kodzie; udowodniłem tylko, że jest poprawny, a nie wypróbowałem”. haacked.com/archive/2007/11/29/…
MarkJ

1
@Izkata - jeśli nie rozumiesz, co robisz, testy jednostkowe są prawdopodobnie zepsute i sprawdzanie, czy kod zawiera te same błędy, co w testach. Ponadto, nawet przy 100% pokryciu decyzji i dokładnych testach jednostkowych, możliwe (choć nietypowe) jest wystąpienie błędu, którego testowanie nie ujawnia.
Steve314,

33

Testy jednostkowe . To jedyny sposób, aby mieć zaufanie do dowolnego kodu (brudnego lub nie).

Na marginesie;

skróty powodują duże opóźnienia (Pippin)


6
Dobry cytat, ale to nie był Gandalf. To był Pippin, argumentujący, dlaczego on, Frodo i Sam nie powinni przepłynąć kraju do promu Buckleberry, w pierwszej podróży z Hobbiton.
Daniel Roseman,

22
Korekta: „Testy jednostkowe. Jest to jedyny sposób na fałszywe poczucie bezpieczeństwa w kodzie (brudny lub nie)”. Testy jednostkowe są dobre, ale nie gwarantują niczego.
Koder,

8
Kiedy chcę odkryć ukryte błędy, pokazuję aplikację mojemu szefowi. Nazywam to testem szefa, należy go wykonać po testach jednostkowych. Ma aurę magnetyzmu, który przyciąga wszelkiego rodzaju dziwne błędy, a także promienie kosmiczne prosto do rejestrów procesora.
Mister Smith,

8
Podczas gdy cytujemy, może ci się spodobać „Testowanie pokazuje obecność, a nie brak błędów” - Edsger Dijkstra
Timothy Jones

2
Testy -1 nie sprawdzą poprawności kodu - testy jednostkowe niczego NIE POTWIERDZAJĄ, dają pewną dozę pewności, ale nie są nic warte więcej. Są dobrą miarą, po prostu nie zakładaj, że oznaczają one więcej niż to, że mała podsekcja kodu działa dokładnie tak, jak go napisałeś, nie oznacza to, że napisałeś go poprawnie lub że będzie poprawnie współdziałał z czymkolwiek innym. Chociaż są one ogólnie dobrą miarą, ale nie pomagają w kiepskim kodzie i faktycznie pogorszą go, dając ci więcej kodu do zmiany przy każdym refaktorze.
Bill K

15

Dobrze jest nauczyć się akceptować fakt, że żaden system oprogramowania o rozsądnej złożoności nie będzie idealny bez względu na to, ile testów jednostkowych i poprawek kodu jest wykonywanych. Pewien stopień chaosu i wrażliwość na nieoczekiwane zawsze czają się w kodzie. Nie oznacza to, że nie należy próbować tworzyć dobrego kodu ani przeprowadzać testów jednostkowych. Są to oczywiście ważne. Należy znaleźć równowagę, która będzie się różnić w zależności od projektu.

Umiejętność, którą należy rozwinąć, to zrozumienie, jaki poziom „doskonałości” należy zastosować w przypadku konkretnego projektu. Na przykład, jeśli piszesz aplikację do elektronicznej dokumentacji medycznej z 12-miesięczną osią czasu projektu, będziesz chciał poświęcić znacznie więcej czasu na testowanie i upewnienie się, że twój kod jest łatwy do utrzymania, niż w przypadku jednorazowej aplikacji internetowej do rejestracji konferencji które należy wdrożyć do piątku. Problemy pojawiają się, gdy ktoś robiący aplikację EMR staje się niechlujny lub aplikacja rejestracyjna nie jest wdrażana na czas, ponieważ programista jest zbyt zajęty poprawianiem kodu.


1
+1 za wskazanie, że decyzje dotyczące miar jakości muszą być uzasadnione potrzebami biznesowymi.
Stephen Gross

+1 za * „Umiejętność, którą należy rozwinąć, to zrozumienie, jaki poziom„ doskonałości ”należy zastosować w konkretnym projekcie.” ... Ustal minimalny standard określający, w jakim stopniu „poprawianie” Twojej firmy będzie akceptowalne ryzyko pod względem jakości, a następnie trzymaj się tego.
S.Robins,

11

Szybkie i brudne jest idealnie w obrębie podsystemu . Jeśli masz dobrze zdefiniowany interfejs między badziewiem a resztą systemu oraz dobry zestaw testów jednostkowych, które sprawdzają, czy brzydki szybki i brudny kod działa prawidłowo, może być zupełnie w porządku.

Na przykład może masz ohydny hack wyrażeń regularnych i przesunięcia bajtów, aby przeanalizować niektóre pliki pochodzące od strony trzeciej. Załóżmy, że masz test potwierdzający, że wynik analizowania przykładowych plików jest tym, czego oczekujesz. Możesz to wyczyścić, abyś mógł ... Nie wiem, reagować szybciej, gdy strona trzecia zmieni format pliku? To po prostu nie zdarza się dość często. Bardziej prawdopodobne jest, że zmienią się one na zupełnie nowy interfejs API, a ty wyrzucisz stary parser i podłączysz nowy, który jest zgodny z tym samym interfejsem API, i voila, gotowe.

Problemem jest szybkie i brudne rozwiązanie, gdy architektura jest szybka i brudna. Twój główny obiekt domeny musi być dobrze przemyślany, a interfejsy, ale krawędzie twojego systemu mogą zwykle być nieuporządkowane bez konieczności płacenia za piper.


1
Innymi słowy - moduły mogą być Q&D, ale architektura powinna być odpowiednio czysta.
Kromster

9

Oto historia szybkiego i brudnego programisty, którego znam.

Znam osobę, która uważa testy jednostkowe za stratę czasu. Po wielu kłótniach w końcu napisał jeden. Składał się z jednej długiej metody posypanej && i || i zwrócił wartość logiczną do assertTrue. Instrukcja obejmuje 20 wierszy. Z drugiej strony napisał klasę, w której każda metoda miała jedną linię, a główna ponad 1000 linii bez białych spacji. To była ściana tekstu. Kiedy przejrzałem jego kod i wstawiłem kilka nowych wierszy, zapytał „dlaczego”. Powiedziałem „Ze względu na czytelność”. Westchnął i usunął je. Na górze umieścił komentarz: „Nie dotykaj, to działa!”

Ostatnim razem, gdy z nim rozmawiałem, napisał kod dla strony internetowej dla firmy. Próbował znaleźć błąd. Ostatnie 3 dni spędził robiąc to przez 8 godzin dziennie. Nieco później rozmawiałem z nim ponownie i okazało się, że jego kolega z zespołu zmienił wartość literału i nie zaktualizował go gdzie indziej. To nie było stałe. Więc zmienił też inne literały, aby naprawić błąd. Skarżył się na kod spaghetti kolegi z drużyny. Powiedział mi: „Haha, czy nie wszyscy wiemy, jak to jest spędzać całą noc z debuggerem, nie przespać jednego paskudnego robaka”. Uważa, że ​​jest to coś, co robią naprawdę dobrzy programiści i naprawdę się z tym czuje.

Uważa też, że czytanie książek o programowaniu i blogów jest bezużyteczne. Mówi: „po prostu zacznij programować”. Robi to od 12 lat i uważa, że ​​jest doskonałym programistą. / facepalm


Oto trochę więcej.

Innym razem pisaliśmy klasę DatabaseManager dla naszej aplikacji internetowej. Umieścił w niej wszystkie wywołania bazy danych. To była klasa Boga z ponad 50 metodami dla każdej możliwej rzeczy. Zasugerowałem podzielenie go na podklasy, ponieważ nie każdy kontroler musi wiedzieć o każdej metodzie bazy danych. Nie zgodził się, ponieważ „łatwo było” mieć tylko jedną klasę dla całej bazy danych, a dodanie nowej metody było „szybkie”, gdy tylko jej potrzebowaliśmy. W końcu DatabaseManager miał ponad 100 publicznych metod od uwierzytelnienia użytkownika do sortowania lokalizacji stanowisk archeologicznych.


1
+1. Z jakiegoś powodu uwielbiam czytać te historie. Nawet już mnie nie smucą ani nie gniewają.
sam hocevar,

-1 do pisania dowolnej klasy _______Manager.
Brian Driscoll,

@SamHocevar Run, nie idź, do
thedailywtf.com

7

Moją lekcją unikania szybkich i brudnych rzeczy było to, że miałem sześć miesięcy na dostarczenie tego, co zostało oszacowane (niedoszacowane) na rok pracy. Przed rozpoczęciem pracy postanowiłem zbadać metodologię. W końcu zainwestowałem trzy miesiące badań i byłem w stanie dostarczyć wyniki w pozostałych trzech miesiącach.

Osiągnęliśmy duże korzyści, identyfikując wspólną funkcjonalność i budując biblioteki wymagane do obsługi tych wymagań. Nadal widzę programistów piszących własny kod, gdy są dostępne procedury biblioteczne. Ci koderzy często przepisują lub co najwyżej wycinają i wklejają ten sam kod, gdy muszą później rozwiązać ten sam problem. Poprawki błędów niezmiennie wychwytują tylko niektóre kopie kodu.

Jeden programista udzielił wymownej odpowiedzi, gdy poprosiłem go o użycie kodu bibliotecznego: „Czy to nie oszustwo? Musiałem napisać cały swój własny kod w szkole”.


1
Dosyć etyczny programista, którego tam masz!
Stephen Gross

6

W niektórych przypadkach wydaje mi się, że może istnieć duży zestaw testów regresji, które znajdą „wszystkie” błędy i zweryfikują zachowanie, umożliwiając w ten sposób szybką i brudną technikę kodowania. Ale przede wszystkim jest to kwestia złego planowania projektu i menedżera, który uważa, że ​​ważniejsze jest, aby to zrobić, niż zrobić to dobrze.

I zapomnij o „posprzątaj później”, to się nigdy nie zdarza. W rzadkich przypadkach zdarza się, że programista zapomina większość kodu, dzięki czemu zadanie jest znacznie droższe, niż gdyby zrobił to dobrze za pierwszym razem.


6

Produkt jest wysyłany.

Kod nie istnieje w próżni. Cierpiałem nieopisany żal gaszący ogień w następstwie szybkiego i brudnego i kowbojskiego kodowania. Ale czasami ukończenie produktu jest priorytetem, nie zastanawianie się, jak napisać najlepszy kod. Ostatecznie, jeśli produkt zostanie dostarczony i będzie działał wystarczająco dobrze, użytkownicy i klienci nie będą wiedzieli ani obchodzić się z tym, jak „zły” jest kod w środku, i przyznam, że były chwile, kiedy w ogóle mnie to nie obchodziło tak długo, jak wyszedłem przez drzwi.

Tak, dotyczy to kwestii organizacyjnych i „nigdy nie powinno się zdarzyć”. Ale jeśli zdarzy ci się pisać kod w organizacji, która jest źle zarządzana i ściśle związana z terminami, na poziomie indywidualnego programisty masz ograniczone możliwości.


5

Nie sądzę, że mogą szczerze powiedzieć, że dobrze to zrobili, jeśli nie jest to łatwe do utrzymania. Jeśli przyznają, że muszą „później to posprzątać”, prawdopodobnie istnieje coś, czego nie przemyśleli wystarczająco. Dokładne przetestowanie pozwoli naprawdę odkryć wszelkie problemy z brudnym kodem.

Ja osobiście nie chciałbym rozwijać umiejętności „pisania brudnego kodu” i być pewnym jego poprawności. Wolę napisać poprawny kod za pierwszym razem.


5

Skąd oni wiedzą, że dobrze to zrobili? Testowanie to prosta odpowiedź.

Jeśli ich kod został dokładnie przetestowany przez dobry zespół ds. Kontroli jakości i przejdzie pomyślnie, powiedziałbym, że dobrze go zrozumieli.

Pisanie szybkiego i brudnego kodu nie jest czymś, co powinno być nawykiem, ale jednocześnie zdarzają się sytuacje, w których możesz spędzić 20 minut na pisaniu kodu, który może być sklasyfikowany jako brudny lub 4 godziny refaktoryzacji dużej ilości kodu, aby zrobić to dobrze. W świecie biznesu czasami wystarczy 20 minut na wykonanie zadania, a gdy dotrzymasz terminów, szybka i brudna może być jedyną opcją.

Sam byłem po obu stronach tego, musiałem naprawić brudny kod i musiałem napisać własny, aby obejść ograniczenia systemu, w którym się rozwijałem. Powiedziałbym, że mam zaufanie do kodu, który ja napisałem, ponieważ chociaż był brudny i trochę włamany, czasami upewniłem się, że został dokładnie przetestowany i miał dużo wbudowanej obsługi błędów, więc jeśli coś pójdzie nie tak, nie zniszczy to reszty systemu.

Kiedy patrzymy z góry na tych szybkich i brudnych programistów, musimy pamiętać o jednej rzeczy, klient zasadniczo nie płaci, dopóki nie ma produktu, jeśli zostanie wysłany i przejdzie testy UAT i znajdzie błędy z szybkiego i brudnego kodu, to jest o wiele mniej prawdopodobne, że wycofają się, gdy będą mieli prawie działający produkt przed nimi, ale jeśli nie mają nic, a ty im mówisz: „wkrótce to zrobimy, my tylko naprawiamy x” lub „to było opóźnione, ponieważ musieliśmy dostać y działa idealnie ”, są bardziej skłonni do poddania się i pójścia z konkurentem.

Oczywiście, ponieważ ten obraz pokazuje, że nikt nie powinien lekceważyć niebezpieczeństwa szybkiego i brudnego kodu! wprowadź opis zdjęcia tutaj


4

Nie sądzę, że powinieneś zacząć iść tą drogą. Szybki i brudny może dać czasową korzyść szybszego ukończenia, ale zawsze płacisz dziesięciokrotnie za zrobienie tego w końcu.


5
Czasami nie będziesz mieć żadnych pieniędzy, jeśli nie wyślesz teraz ... ale wysyłka teraz pozwala zapłacić „dziesięciokrotnie”, aby go posprzątać, a potem trochę, ponieważ pokonałeś konkurencję na rynku i dostałeś rozpoznanie marki w pierwszej kolejności.
CaffGeek,

2
Pozwolę sobie być innego zdania. Jeśli pieniądze są już napięte, wydajesz dochód na następny produkt i będziesz to robić, dopóki Twoja firma nie umrze lub nie osiągnie wystarczającej wielkości. W drugim przypadku i najprawdopodobniej pierwotni programiści nie będą już tam, aby naprawić stary kod.
Raku

Pokonywanie innych na rynku nie gwarantuje, że społeczeństwo zaakceptuje Twój produkt. Jeśli produkt zawiera zbyt wiele wad, lepiej mieć nadzieję, że masz dodatkową gotówkę, aby zastosować dobry marketing dymu i luster, a także mieć świetną i wybaczającą relację z bazą klientów. To nie jest ani pozycja / ani. Kluczem do sukcesu jest zbilansowanie ryzyka i nagrody oraz terminowe wypuszczenie produktu najwyższej jakości, który możesz dostarczyć. Twoje umiejętności zostaną ocenione na podstawie jakości wydanego produktu, a szkody, jakie wadliwe oprogramowanie może wyrządzić Twojemu obrazowi, mogą być nieodwracalne.
S.Robins,

1
Zacznij się różnić od tego, co lubisz, ale historia jest pełna przykładów, w których obecność we właściwym czasie, dostępna dla każdego, kto tego chciał, była ważniejsza niż bycie najlepszym możliwym produktem. Zawsze jest to koszt alternatywny, zawsze.
Warren P,

1
Warren, to w zasadzie to, co mówiłem. Moim zdaniem koszt alternatywny przywracania kodu do utrzymania rośnie wykładniczo, im dłużej zwlekasz. Jeśli Twoja firma jest w stanie przetrwać katastrofę niemożliwą do utrzymania, ponieważ sprzedaż poszła dobrze, a kod nie był zbyt brudny, dobrze, ale co jeśli nie?
Raku,

4

Moim zdaniem nauka oceniania poprawności kodu Q&D nie jest umiejętnością wartą rozwijania, ponieważ jest to po prostu zła praktyka. Dlatego:

Nie sądzę, by „szybkie i brudne” i „najlepsze praktyki” były w ogóle zgodne. Wielu programistów (łącznie ze mną) wypaliło szybki i brudny kod w wyniku przekrzywienia potrójnych ograniczeń . Kiedy musiałem to zrobić, był to zwykle efekt pełzania zakresu i zbliżającego się terminu. Wiedziałem, że kod, który sprawdzam, jest zasysany, ale wypluł właściwe dane wyjściowe, biorąc pod uwagę zestaw danych wejściowych. Bardzo ważne dla naszych interesariuszy, wysyłamy na czas.

Spojrzenie na oryginalny raport CHAOS wyraźnie pokazuje, że Q&D nie jest dobrym pomysłem i zabije budżet później (w trakcie konserwacji lub w trakcie rozbudowy). Nauczenie się, jak oceniać poprawność kodu Q&D, to strata czasu. Jak powiedział Peter Drucker: „Nie ma nic tak bezużytecznego, jak robienie skutecznie tego, czego w ogóle nie należy robić”.


3

Nie wiem, czy mój nowy kod jest poprawny, jeśli jest zbyt brudny.

„Brudny” oznacza różne rzeczy dla różnych ludzi. Dla mnie oznacza to przede wszystkim poleganie na rzeczach, o których wiesz, że prawdopodobnie nie powinieneś polegać, ale o których wiesz, że możesz spodziewać się pracy w najbliższym czasie. Przykłady: zakładając, że przycisk ma wysokość 20 pikseli zamiast obliczać wysokość; twarde kodowanie adresu IP zamiast rozpoznawania nazwy; liczenie na tablicę do posortowania, ponieważ wiesz, że tak jest, mimo że metoda, która zapewnia tablicę, nie gwarantuje jej.

Brudny kod jest delikatny - możesz go przetestować i wiedzieć, że teraz działa , ale całkiem niezły zakład, że w pewnym momencie w przyszłości się złamie (albo zmusi wszystkich do chodzenia po skorupkach jaj w obawie przed jego złamaniem).


3

Ryzykując, że zabrzmi to trochę kontrowersyjnie, twierdzę, że nikt tak naprawdę NIE WIE, że ich kod jest w 100% poprawny i w 100% bez błędów. Nawet jeśli masz naprawdę dobry zasięg testu i rygorystycznie stosujesz dobre praktyki BDD / TDD, nadal możesz opracować kod zawierający błędy i tak, który może nawet zawierać skutki uboczne!

Samo pisanie kodu i zakładanie, że działa, oznacza nadmierną pewność ze strony programisty, że wyczuwa on własne umiejętności tego programisty, a gdy pojawią się problemy (które nieuchronnie będą), wysiłek debugowania i utrzymania kodu będzie kosztowny, szczególnie jeśli inny programista potrzebuje aby zachować kod później. Prawdziwa różnica polega na zastosowaniu dobrych praktyk inżynierii oprogramowania, które zapewniają prawdziwą pewność, że Twój kod prawdopodobnie będzie działał przez większość czasu, a jeśli wystąpi błąd, łatwiej jest debugować i znacznie mniej kosztowne w zmianie i utrzymaniu, niezależnie od osoby, która później pracuje nad tym kodem.

Istotną kwestią jest to, że dobrze przemyślany i dobrze przetestowany kod pozwoli INNYM na zaufanie do twojego kodu, co w większości przypadków jest ważniejsze niż twoje zaufanie.


2

Jeśli brudny kod jest dobrze przetestowany, można mu zaufać. Problem polega na tym, że testowanie brudnego kodu przez jednostkę jest zwykle bardzo trudne i kłopotliwe. Właśnie dlatego TDD jest tak dobry; odsłania i usuwa brud i zapachy. Ponadto testy jednostkowe są często pierwszą rzeczą, która cierpi na utratę czasu. Więc jeśli najczystszy facet stworzył najczystszy kod, jaki kiedykolwiek napisał, nadal nie ufałbym mu ani trochę, gdyby pominął testy jednostkowe ze względu na pewność czasu.


2

Dobrzy programiści (Quick & Dirty i inni) nie mają pychy, by założyć, że mają rację. Zakładają, że wszystkie duże systemy mają błędy i wady, ale w pewnym momencie mogą być wystarczająco przetestowane i sprawdzone, aby mieć wystarczająco niskie ryzyko lub wystarczająco niskie koszty awarii, które kod może wysłać.

Dlaczego więc istnieją tak zwani programiści Quick & Dirty? Moja hipoteza dotyczy selekcji darwinowskiej. Programiści, którzy wysyłają sprawny kod szybko, czasami wysyłają przed wysyłką konkurencji, budżet się kończy lub firma bankrutuje. Dlatego ich firmy wciąż działają, zatrudniając nowych programistów, aby narzekać na bałagan, który należy usunąć. Dostarczane są również tak zwane czyste kody, ale niezbyt zróżnicowane, aby doprowadzić do wyginięcia koderów Quick & Dirty.


To prawda. Widziałem co najmniej jeden produkt, który był w stanie wysłać ze względu na kod Quick & Dirty, brodawki i inne. Tak się złożyło, że kilka dni w porównaniu z miesiącem z góry oznaczało dwumiesięczny skok na konkurencję. Produkt odniósł sukces, a kod Quick & Dirty został ostatecznie zastąpiony lepszym kodem. Odkąd widzę, że staram się lepiej sprawdzać jakość mojego kodu nie tylko z punktu widzenia inżynierii, ale także z perspektywy biznesowej / konkurencyjnej. Uwaga: interfejs tego kodu był w porządku, to była szkicowa implementacja.
J Trana,

0

Prawdopodobnie można by pomyśleć, że nieoptymalna część kodu może nie mieć znaczenia, ze względu na krótki czas życia, niewielki wpływ na biznes lub mało czasu na wykonanie. Prawidłowa odpowiedź jest taka, że ​​tak naprawdę nie wiesz. Za każdym razem, gdy słyszę, jak ktoś mówi, że „jest to niewielka cecha” lub „sprawmy, by było to tak szybkie i tak proste, jak to tylko możliwe” i poświęcamy mało czasu na zastanawianie się nad właściwym projektem, jedynymi dwiema rzeczami, które faktycznie występują są:

1-) Projekt staje się większy, a motywacja zespołu mniejsza, pracując na kodzie pełnym „szwów”. W takim przypadku projekt prawdopodobnie przejdzie do szybkiego pasa w kierunku chaosu.

2-) Projekt staje się znany jako rozwiązanie nieoptymalne, a jego stosowanie zaczyna być zniechęcane na korzyść nowego rozwiązania lub refaktoryzacji, która jest tak droga jak nowe rozwiązanie.

Staraj się zawsze robić najlepszy możliwy kod. Jeśli nie masz wystarczająco dużo czasu, wyjaśnij, dlaczego potrzebujesz więcej. Nie narażaj się na źle wykonaną pracę. Bądź zawsze lepszym profesjonalistą. Nikt nie może cię za to ukarać, jeśli jesteś rozsądny. Jeśli tak, to nie jest miejsce, w którym powinieneś pracować.


0

Porozmawiaj z seniorem i oceń wpływ ewentualnych awarii. Na przykład sytuacja, w której można naprawić zabrudzenie, zajmuje 1 dzień, a solidny kod wymaga zmiany projektu i architektury, co może zająć 4-6 miesięcy + dodatkowy czas sprawdzania poprawności, aby całkowicie zweryfikować wszystkie przepływy pracy, które zostały zmienione w wyniku zmiany projektu.

Musimy również podjąć decyzję na podstawie czasu + pojemności + priorytetów na liście. Dobra dyskusja w zespole z seniorami lub osobami z większym doświadczeniem może pomóc w podjęciu decyzji, która najlepiej pasuje do zespołu i jego rezultatów.

Czysty kod jest pierwszym i najważniejszym podejściem, w którym jako brudny kod zapisuje się eskalacje, decyzje klientów go / no go, pokazuje stopery, reputację organizacji na stawce i wiele innych, gdy brudny kod przechodzi do czystego kodu.


4
wydaje się, że nie oferuje to nic istotnego w porównaniu z punktami przedstawionymi i wyjaśnionymi w poprzednich 23 odpowiedziach
gnat
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.