Co roku ssać mniej? [Zamknięte]

10

Ssanie mniej każdego roku - Jeff Atwood

Natrafiłem na ten wnikliwy artykuł: cytowanie bezpośrednio z postu

Często myślałem, że ssanie mniej każdego roku jest sposobem na poprawę pokornych programistów. Powinieneś być niezadowolony z kodu napisanego rok temu. Jeśli tak nie jest, oznacza to, że albo A) nie nauczyłeś się niczego przez rok, B) twój kod nie może zostać ulepszony, lub C) nigdy nie wracasz do starego kodu. Wszystko to jest pocałunkiem śmierci dla twórców oprogramowania.

  1. Jak często to się zdarza, czy nie?
  2. Ile czasu minie, zanim zobaczysz faktyczną poprawę swojego kodowania? miesiąc, rok?
  3. Czy kiedykolwiek ponownie odwiedzasz swój stary kod?
  4. Jak często męczy cię stary kod? lub jak często masz do czynienia z długiem technicznym.

Naprawdę bardzo bolesne jest usuwanie starych błędów i brudnego kodu, które mogliśmy zrobić, aby szybko dotrzymać terminu i te szybkie poprawki, w niektórych przypadkach może być konieczne przepisanie większości aplikacji / kodu. Żadnych argumentów na ten temat.

Niektórzy z programistów, z którymi się spotkałem, twierdzili, że byli już na etapie ewolucji, w którym ich kodowanie nie wymaga poprawy lub nie można go już ulepszyć.

  • Czy to się dzieje?
  • Jeśli tak, ile lat trzeba napisać w danym języku?

Związane z:

Czy pamiętasz kiedyś swój stary kod i krzywił się z bólu?

Moment Gwiezdnych wojen w kodzie „Luke! Jestem twoim kodem!” „Nie! Niemożliwe! Nie może być!”

Aditya P.
źródło
3
Ludzie IMHO, którzy uważają, że są idealni i myślą, że nie muszą się poprawiać, mają rację. Nie mogą się poprawić. Każda rozsądna osoba wie, że nigdy nie będzie idealna, zawsze jest miejsce na ulepszenia / naukę nowych rzeczy. Byłbym przerażony, gdybym dowiedział się, że nie jestem w stanie się poprawić - nie chcę myśleć, że mam pułap.
MAK
Uwielbiam wracać do projektów, które stworzyłem, gdy byłem bardzo nowy, i patrzeć na kod, który tak trudno było mi napisać. Wiele razy kod jest tak prosty. To sprawia, że ​​się śmieję.
The Muffin Man,

Odpowiedzi:

6
  > Sucking Less Every Year ?

No ale Ssanie inny Każdy rok :-)

Po moich pierwszych recenzjach wiele lat temu cierpiałem z powodu braku konwencji nazewnictwa.

Potem cierpiałem, że mój kod został (niepotrzebnie) zaimplementowany, aby był jak najbardziej ogólny, ale to sprawiło, że kod był trudny do zrozumienia i utrzymania.

Potem zacząłem programowanie oparte na testach, InversionOfControl, co to generics kropka gdzie i wiele innych.

wniosek

cierpienie starych złych nawyków zmniejszyło się, ale zrekompensowały mnie nowe cierpienia, ponieważ nauczyłem się więcej.

k3b
źródło
19

Co ciekawe, wszyscy programiści „rockstar”, z którymi kiedykolwiek pracowałem, byli wyjątkowo pokorni, chętni do nauki i gotowi przyznać, że nie wiedzą wszystkiego. Do licha, wielu z nich było wręcz deprecjonujących, przynajmniej w lekkich chwilach.

Nie sądzę, że kiedykolwiek spotkałem programistę, który uważa, że ​​ich kodowania „nie można poprawić”, ale coś mi mówi, że ci faceci byliby tak daleko od rockstar, jak to tylko możliwe - delikatnie mówiąc.

Stoły Bobby'ego
źródło
2
Zgadzam się w 100%. Są cichymi zabójcami! No i świetna nazwa użytkownika, xkcd? :)
jamiebarrow 18.03.11
@jamiebarrow: Oczywiście. :)
Tabele Bobby
innym przypadkiem niepowodzenia jest osoba, która mówi: „całe oprogramowanie jest złe, wszystkie włamania, twoje pomysły na ulepszenia nie mają znaczenia”. Rodzaj przygnębienia do pracy z tymi typami.
Doug T.
13

Następujące punkty nie są poradami, ale dziennikiem osobistym:

  • używając mniej zmiennych globalnych
  • nie używaj skrótu dla zmiennych lub nazw funkcji
  • napisz [niektóre] kody testowe
  • nie oceniaj kodu jako wolnego (lub szybkiego) bez testowania
  • dowiedz się, jak załadować test aplikacji
  • nie naprawiaj tego, jeśli nie jest zepsute
  • użyj narzędzia do zarządzania kodem źródłowym (git / hg)
  • refaktoryzacja jest fajna, nie niedoszacuj kosztu testów, które ona przynosi
  • bezpieczeństwo jest trudne, więc strzeż się tego jak najwcześniej
  • załataj kilka błędów projektu open source
  • bloguj coś nowego
  • użyteczność może nie być żądaniem funkcji, ale jest ważna

Nie nauczyłem się wszystkiego w ciągu roku, wszystko wymaga czasu ...

ohho
źródło
Podoba mi się to, jak wspominasz „napisz [niektóre] kody testowe”. Wierzę, że nikt nigdy nie osiągnie doskonałości, gdzie nigdy nie popełni błędu jako programista - wszyscy jesteśmy ludźmi i od czasu do czasu popełniamy błędy. Testy jednostkowe i integracyjne mogą zmniejszyć liczbę naszych błędów. I zauważam, że mówisz „niektóre” testy, co jest ważne, ponieważ czasami dałem się ponieść pisaniu testów, które nie były tak naprawdę przydatne.
jamiebarrow 18.03.11
Właściwie myślę, że pod spodem „nie naprawiaj, jeśli się nie zepsuło” dodałbym „Jeśli się zepsuło i jest skomplikowane,
odtwórz
2
Czy mogę dodać kilka? Jeśli jest to interfejs API, nie ujawniaj więcej wewnętrznych szczegółów niż musisz, jeśli go ukryjesz, możesz go później zmienić. Zawsze używaj stałych zamiast magicznych liczb, ponieważ łatwiej je dokumentować i zmieniać. Niezmienność jest niezwykle użyteczna, szczególnie w przypadku współbieżności. Pracuj nad bazą kodową innego użytkownika, to nieskończenie cenny proces oceniania własnego stylu kodowania, gdy musisz uzasadnić to komuś innemu. Zatrzymaj specyfikację (jeśli to możliwe), ponieważ trudniej trafić w ruchomy cel.
Evan Plaice,
Jeśli pracujesz na miejscu lub w pobliżu klientów, spakuj swoje karty bez uprawnień i karty o większej mocy. Jeśli poprosą cię o zmianę czegoś poza specyfikacją, wyciągnij kartę (Mam) bez uprawnień, a następnie (skierowanie do) karty o większej mocy (najlepiej PM poza siedzibą, który może przyjąć prośby). Najlepszy przypadek, pozwoli ci skupić się na rozwoju; w najgorszym przypadku zmniejszy to liczbę żądań funkcji drive-by. (kontrowersyjny) Zwróć wcześnie i zwróć często, jeśli zwrot miał nastąpić na końcu bloku kodu, nie byłoby dla niego słowa kluczowego. Mam nadzieję, że nadal co roku ssę mniej.
Evan Plaice,
4

Często ludzie myślą, że dobry kod nagle się zdarza, ale dla większości z nas zwykli śmiertelnicy rozwijają się w naszym bazie kodów. Mam na myśli, że bardzo trudno jest napisać idealne oprogramowanie od samego początku, ponieważ wymagania ciągle się zmieniają i nie jesteśmy doskonałymi programistami, więc głupie decyzje podejmowane są nieustannie przez menedżerów i programistów. Potem widzę, że każde wymaganie zmienia dobrą okazję do przeformułowania starego kodu na lepszy (i zapłacimy za to!) I spłacę trochę długu technicznego. Jak mówią: „opuszczaj repozytorium kodu nieco lepiej za każdym razem, gdy zatwierdzasz kod”. Wtedy twój system ewoluuje w system zbliżony do idealnego.

Nie znam absolutnie żadnego programisty, który byłby dumny ze swojego oprogramowania, ale to dobrze. Niż oznacza, że ​​programista nauczył się w tym procesie.

Również, jeśli przeczytasz książkę „Wyczyść kod”, kilkakrotnie zwiększysz swój własny „współczynnik ssania”. :RE

Rafa de Castro
źródło
1
Nie zgadzam się z tobą w jednym punkcie, uważam, że kod, z którego możesz być dumny. Ironią losu jest to, że jeden projekt może się powieść wyjątkowo dobrze i być z niego dumnym, może z pewnymi drobnymi niedogodnościami. W następnym projekcie twoje WTF na godzinę są wysokie ... dla twojego własnego kodu! : D
jamiebarrow 18.03.11
1
Może zależy od kroku, w którym jesteś teraz. Teraz znajduję kod, który napisałem rok temu i nawet trudno mi zrozumieć niektóre nazwy lub cel niektórych metod. Również znajduję kod odkryty przez testy i tego typu rzeczy. W miarę ciągłego doskonalenia takie rzeczy są raczej wyjątkami niż normami i zaczynam się wstydzić z powodu problemów, które wcześniej wydawały się nieistotne ...
Rafa de Castro
+1 za czysty kod, chociaż jego porównanie jest zawsze z tobą.
Aditya P
4

Mam do tego obie strony medalu.

Z jednej strony patrzysz na stary kod i widzisz, że jest pełen błędów i skomplikowanych sposobów robienia rzeczy, które są po prostu osiągane dzięki wykorzystaniu technik i funkcji językowych, o których wtedy nie wiedziałeś.

Z drugiej strony widzisz szczególnie eleganckie rozwiązanie problemu i nie możesz powstrzymać się od uśmiechu zadowolonego z tego, jak sprytny byłeś wtedy.

A potem przewijasz kilka linii i grymasuje z przerażeniem na fakt, że użyłeś GOTO w C.

Chris Browne
źródło
3

Hmm ... Często jestem dość mile zaskoczony, jak dobry jest mój starszy kod.

Gdybym to robił dzisiaj, często pisałbym to inaczej, ale gdybym musiał żyć z ograniczeniami czasu, nie jestem pewien, czy tak zrobię. Kiedy możesz liczyć na typową maszynę z co najmniej kilkoma gigabajtami pamięci RAM, możesz (i często powinieneś) pisać swój kod nieco inaczej niż wtedy, gdy duży dysk twardy miał 100 megabajtów.

Jerry Coffin
źródło
3
  1. Jak często to się zdarza, czy nie?

  2. Ile czasu minie, zanim zobaczysz faktyczną poprawę swojego kodowania? miesiąc, rok?

  3. Czy kiedykolwiek ponownie odwiedzasz swój stary kod?

  4. Jak często męczy cię stary kod? lub jak często masz do czynienia z długiem technicznym.

  1. Za każdym razem, gdy uczę się czegoś nowego, mam nadzieję, że to codziennie.

  2. Jeśli uda mi się wdrożyć to, czego się nauczyłem, to jest to natychmiastowe, od kiedy to wdrażam.

  3. Tak, tylko dla (1) nowych funkcji, (2) poprawek błędów, (3) nostalgii, (4) Zobacz, jak coś rozwiązałem, może być przydatny.

  4. Powiązane z 1., kiedy uczę się, jak robić coś lepiej, mam świadomość, że niektóre starsze projekty „mogły” zostać wykonane lepiej. Zostawiam ich. Tylko upewnij się, że następny projekt zostanie wykonany lepiej. Nie martwię się, chyba że jest to prawdziwy błąd.

Ciemna noc
źródło
3

W innym pytaniu temat dotyczył sposobów oceny jakości własnego kodu. Jedną z moich sugestii było przejrzenie go za kilka lat, kiedy twoje doświadczenie jest znacznie wyższe niż w momencie pisania kodu. Jeden cytat mojej odpowiedzi na to drugie pytanie jest bezpośrednio związany z twoim pytaniem:

„w moim przypadku żywotność wynosi jeden rok: oznacza to, że mogę zmodyfikować kod, który napisałem sześć miesięcy temu, ale jeśli kod został napisany dwa lata temu, istnieje duże prawdopodobieństwo, że zostanie wyrzucony, a następnie całkowicie przepisany, ponieważ po prostu jest do kitu. ”

Tak, w praktyce każdy fragment kodu , który napisałem, staje się nie do zniesienia z mojego punktu widzenia w ciągu roku. I nie mówię o kodzie wyrzucającym, ale także o kodzie, który napisałem z myślą o jakości, łatwości konserwacji i czytelności. W tej chwili nie było wyjątków.

Odpowiedź na drugie pytanie dotyczące długości życia jest bardzo zróżnicowana. Wyrzucony fragment kodu ma zero sekund : jest do bani zaraz po napisaniu, ale to nie ma znaczenia. Niektóre fragmenty kodu, które napisałem, były znośne po dwóch latach , ale wymagały pewnych kosmetycznych zmian: trochę refaktoryzacji, egzekwowania reguł StyleCop itp. Średnio, w moim konkretnym przypadku, żywotność waha się od ośmiu miesięcy do jednego roku dla C # i od dwóch sześciu miesięcy dla PHP.

Czy ponownie odwiedzam mój stary kod? Tak, oczywiście, jak każdy programista, chyba że nie dbasz o DRY i ciągle wymyślasz własne koło. Istnieją również szanse na częste przeglądanie i ulepszanie kodu, jeśli masz wspólną bazę kodów, której używasz w wielu projektach . Inną kwestią jest to, że jeśli pracujesz nad dużymi projektami, niektóre mogą zająć ci lata , więc będziesz musiał ponownie odwiedzić stary kod.

Niektórzy z programistów, z którymi się spotkałem, twierdzili, że byli już na etapie ewolucji, w którym ich kodowanie nie wymaga poprawy lub nie można go już ulepszyć.

Kiedy osoba mówi, że jest tak idealna, że ​​nie musi się niczego uczyć, oznacza to, że nie jest w stanie zrozumieć, jak bardzo jest głupia.

Nawet jeśli masz dwadzieścia lat doświadczenia w komputerach / programowaniu, rzeczy zmieniają się zbyt szybko, więc zawsze są nowe rzeczy do nauczenia się i nowe techniki ulepszania kodu. Na przykład kod C # napisany, gdy nie było .NET Framework 3.0, może być prawdopodobnie bardziej czytelny i lepszy dzięki nowym rzeczom, które mamy dzisiaj (w tym Linq, umowy Code itp.), I to, nawet jeśli stary kod został napisany przez najmądrzejszego programistę.

Arseni Mourzenko
źródło
To bardziej przypomina, że ​​jeśli o to poprosisz, istnieje ryzyko, że będziesz wyglądał jak ktoś, kto nie umie pisać dobrego kodu.
Aditya P
@AdityaGameProgrammer: Istnieje różnica między błędnym, brzydkim kodem a dobrym kodem, który po roku lub mniej może być napisany w bardziej elegancki sposób. (1.) Nikt nie jest w stanie napisać idealnego kodu, który pozostanie doskonały na zawsze, więc musimy przyznać, że nasz kod może ulec poprawie z czasem. (2.) Z biegiem czasu zdobywamy doświadczenie i wiedzę, które są również źródłem udoskonalania starego kodu.
Arseni Mourzenko
1

Zdarza się to dość regularnie, gdy patrzę na kod i zastanawiam się: „Co ja sobie myślałem, kiedy to napisałem?”

Zwykle ciągle pojawiają się ulepszenia, ponieważ czasem przychodzi mi do głowy nowy pomysł na zorganizowanie kodu, stylizację kodu lub coś innego i chociaż może nie być to doskonała poprawa, każda drobna rzecz może pomóc, która jest warta zrobienia.

W zależności od środowiska pracy mogę widzieć kod sprzed kilku lat, ponieważ nadal pracuję w tej samej bazie kodu i dobrze znam to, co tam jest i jest czymś do zarządzania.

Stary kod prawie zawsze mnie dręczy, ponieważ albo zmieniam istniejący system, albo go zastępuję. W obu przypadkach muszę znać dziwactwa istniejącego systemu, aby upewnić się, że są obecne w nowym.

Chociaż jestem pewien, że są tacy jak Jon Skeet, którzy potrafią po prostu wymyślić idealny kod, większość innych ludzi mówi, że ich kodu nie da się poprawić, twierdząc, że z punktu widzenia ego może być nieatrakcyjne. Jednocześnie, jeśli chodzi o znalezienie dużej poprawy za każdym razem, nie zawsze tak będzie.

JB King
źródło
1

1.Jak często to się zdarza lub nie?

Jak często jestem niezadowolony z mojego starego kodu? Prawie zawsze. Są rzadkie wyjątki, w których mam kod, z którego jestem naprawdę dumny ... ale znowu są rzadkie. Powiedziano mi, że kod, który napisałem kilka lat temu, był dobry ... skuliłam się i pomyślałam: „ty biedna biedna osoba, bo widziałeś gorzej niż śmieci, które napisałem”.

2.Jak długo jeszcze widać rzeczywistą poprawę kodowania? miesiąc, rok?

Zazwyczaj jest to etapy ... Naprawdę wchodzę w styl lub metodologię (na przykład bierzę płynne interfejsy ... ponieważ był to ostatni styl, dla którego miałem ogromny mokry) i rzeźnię wszystko, co piszę przez miesiąc lub cztery . Potem zaczyna wyglądać lepiej.

3. Czy kiedykolwiek ponownie odwiedzałeś swój stary kod?

Nie tak często, jak bym chciał. Większość mojego starego kodu jest własnością poprzednich pracodawców. Kod osobisty jest zbyt często myte na biało.

4.Jak często męczy Cię stary kod? lub jak często masz do czynienia z długiem technicznym.

Ponieważ poprzedni pracodawcy mają większość mojego starego kodu, a ja myję większość mojego osobistego kodu ... w ogóle nie bardzo często.

Steven Evers
źródło
białe pranie = zmiana współczynnika? czy odwołujesz się do kodu projektu lub osobistej bazy kodu?
Aditya P,
1
@AdityaGameProgrammer: Białe pranie = wyrzuć to wszystko i napisz od nowa. Mówię o moim osobistym kodzie.
Steven Evers,