Co roku ssać mniej? [Zamknięte]

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ć!”

  > 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.

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.

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 ...

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

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.

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.

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.

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ę.

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.

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.