Sposoby przełamania „Syndromu idealnego programisty” [zamknięte]

16

Prawdopodobnie nie jestem jedynym, który tak się czuje. Ale mam coś, co nazywam „syndromem idealnego programisty”, co wielu mogłoby powiedzieć, że jest perfekcjonistą, ale w tym przypadku jest to dziedzina programowania. Jednak dziedzina programowania jest nieco problematyczna w przypadku takiego syndromu.

Czy kiedykolwiek czułeś, że kiedy programujesz, nie masz pewności lub nigdy nie jesteś wystarczająco pewny, że Twój kod jest czysty i dobry, zgodny z większością najlepszych praktyk? Jest tak wiele zasad, których należy przestrzegać, że czuję się jakoś przytłoczony. Nie dlatego, że nie lubię przestrzegać zasad, oczywiście Jestem programistą i uwielbiam programować, widzę to jako sztukę i muszę przestrzegać zasad. Ale ja też to uwielbiam, to znaczy chcę i uwielbiam przestrzegać zasad, aby mieć dobre przeczucie, że to, co robię, idzie właściwą drogą .. ale chciałabym tylko mieć więcej kontroli. dotyczące najlepszych praktyk i dobrego kodu.

Może to brak organizacji? Może to brak doświadczenia? Może brak praktyki? Może to brak czegoś, na co ktoś mógłby zwrócić uwagę? Czy jest jakiś sposób na pozbycie się tego syndromu?

Rushino
źródło
1
Na to pytanie można odpowiedzieć, wiedząc nieco więcej o swoim osobistym pochodzeniu, chociaż może to szybko sprawić, że będzie zbyt zlokalizowane. Tao programowania może być dobrym miejscem do rozpoczęcia.
back2dos
Nie zgadzam się z tym .. wierzę, że każdy, niezależnie od tła, może się tak czuć, może w różnych stopniach, ale nadal.
Rushino
2
Chociaż każdy może doświadczyć tych samych objawów, przyczyna jest bardzo różna, a zatem „leczy”.
back2dos
Nie ma idealnego programisty. Możesz znaleźć doświadczonego i zorientowanego na szczegóły, który ma pęd i chęć do doskonalenia swoich umiejętności. - możesz nazwać ich „go gettersami” ...
Yusubov
„Muszę przestrzegać zasad” ... i jest twój problem. „Najlepsze praktyki” nie są regułami, są sugestiami opartymi na zbiorowym doświadczeniu. Jeśli traktujesz je jako niezłomne zasady, widzę źródło stresu.
GrandmasterB

Odpowiedzi:

21

Priorytetyzuj . Najpierw pierwsze. Skoncentruj się na tym, co ważne.

Twoje priorytety mogą się różnić, ale ogólnie powinieneś dbać o:

  • Poprawny kod
  • Kod możliwy do utrzymania
  • Wyczyść kod
  • Prosty, elegancki kod
  • Wydajny kod

Może w tej kolejności. Najważniejszy jest jednak pierwszy punkt. Bez niego kod jest bezużyteczny. Co robisz z programem, który nie działa poprawnie?

Spraw, by działało, wszystko inne jest prawie nieistotne dla rozwiązania problemów, które musisz rozwiązać. Oczywiście ja też cierpię z tego powodu. Nauczyłem się, że pomaga to skupić się na rozwiązaniach, które działają . Wystarczy. To 99% pracy.

Możesz pomyśleć o dobrym kodzie . Co to jest? Jakiego rodzaju ludzie to piszą? Jak napisać dobry kod ? To jest bardzo proste. Napisz kod, który działa . Kod roboczy to dobry kod. Wszystko inne przychodzi później.

Oczywiście, gdy piszemy kod w środowisku profesjonalnym, zespołowym, oczywisty, czytelny kod i możliwy do utrzymania kod stają się coraz ważniejsze. Jednak nadal pierwszym zadaniem jest sprawienie, aby działało i skupienie się na tym. Tylko wtedy możesz rozpocząć rafinację i refaktoryzację dla lepszego - w razie potrzeby.

Często dość oczywiste jest, że poprawność kodu jest bardzo ważna - ale wszyscy nie uwzględniamy jego znaczenia podczas pisania kodu. Skracamy rogi, stosujemy przedwczesną optymalizację, staramy się pisać elegancki kod, jeszcze zanim mamy napisany działający kod. Ludzką naturą jest dążenie do doskonałości od samego początku, ale programowanie i tworzenie oprogramowania to procesy iteracyjne, a priorytety istnieją. Ponownie więc spraw, aby działało , martw się o wszystko później. Rozumiesz znaczenie ważnego kodu i staraj się go.

Chociaż istnieje mnóstwo tak zwanych dobrych praktyk , myślę, że zdrowy rozsądek jest najważniejszy, zastanów się, dlaczego praktyki te są uważane za dobre, kiedy i gdzie je stosować. Nie staraj się jednak spełniać wszystkich dobrych praktyk. Nie ma możliwości zastąpienia lub zastąpienia osobistego doświadczenia. Nie można uniknąć typowych pułapek - bez względu na to, ile książek czytasz, seminariów, do których uczęszczasz, i tak dalej. Liczy się nauka, robienie rzeczy, poprawne działanie i dobra zabawa - gdy tylko jest to możliwe.

zxcdw
źródło
9
Najlepsza optymalizacja to taka, która przenosi Twój program ze stanu niedziałającego do stanu roboczego.
deadalnix
1
@deadalnix Doskonała rada! To takie proste, takie oczywiste, a jednocześnie tak prawdziwe w całym kodzie.
zxcdw
7
+1. Zastanowiłbym się nad tym, by utrzymywalność była powyżej prawidłowej . W końcu jedną cechą
łatwego
1
EFficient powinien być ponad wszystko, ale poprawny, jeśli mówimy o kodzie bazy danych i znacznie powyżej elegancji. Dobry kod SQL (dobry dla bazy danych, która nie jest deweloperem) rzadko jest elegancki. Znane są nieefektywne sposoby robienia rzeczy i nie są one mniej łatwe w utrzymaniu lub trudniejsze do zrozumienia, gdy zaczniesz ich regularnie używać.
HLGEM
2
@HLGEM Rzeczywiście, w niektórych dziedzinach priorytety mogą zostać całkowicie odwrócone. Na przykład czasami piszę i modyfikuję kod asemblera, który został napisany pod ekstremalnymi ograniczeniami dotyczącymi wielkości i prędkości (produkty demonstracyjne). W takich sytuacjach nawet poprawność programu może zostać zakwestionowana - okazało się, że wiele nieprawidłowo działających fragmentów kodu działa wyjątkowo dobrze (na przykład piękne artefakty wizualne i dźwiękowe oparte na niepoprawnym kodzie).
zxcdw
6

Najprostszym sposobem uniknięcia tego problemu jest zmiana tylko tego, co boli. Nie szlifuj kodu, który jest poprawny, czytelny i łatwy w utrzymaniu, nawet jeśli uważasz, że niektóre zmiany mogą go jeszcze poprawić. Ale kiedy np. Próbujesz coś zmienić i zmienić na zmienną, której cel jest niejasny, lub funkcję, która jest zbyt długa, aby ją zrozumieć, napraw to. Nie wcześniej

Nie oznacza to, że nie powinieneś dążyć do dobrego, czystego kodu, oczywiście powinieneś, ale powinieneś rozważyć swoją pierwszą próbę jako „wystarczająco dobrą”, chyba że udowodniono inaczej.

użytkownik 281377
źródło
+1 lubię tę część. „Twoja pierwsza próba” jest wystarczająco dobra, chyba że udowodniono inaczej.
Rushino
Oddany i upomniany. Zdecydowanie złota rada!
zxcdw
4

Myślę, że najlepszym antidotum na to jest przypomnienie sobie, że wszystkie te najlepsze praktyki i reguły czystości kodu nie istnieją dla nich samych, podobnie jak sam kod.

Ostatecznie najważniejsze jest to, że oprogramowanie działa i można z niego korzystać. I tak się nie stanie, jeśli go nie skończysz.

Nie podoba mi się porównanie kodowania ze sztuką, ale pod tym względem działa: artyści ( zwłaszcza autorzy ) również często chcą pracować nad dziełem, ponieważ zawsze jest coś, co nie jest idealne. Ale jaką wartość ma w doskonałości, gdy opóźnia publikację na czas nieokreślony, a tym samym uniemożliwia docenienie dzieła?

Michael Borgwardt
źródło
2

Najważniejszą rzeczą do zrozumienia jest to, że Twój kod zawsze będzie się zmieniał i zawsze jest miejsce na ulepszenia. Żaden kod nigdy nie jest idealny. Najczęściej biblioteka klas, nad którą dziś pracujesz, będzie zupełnie inna za sześć miesięcy. Uczysz się nowych technik lub znajdujesz wzór, który naprawdę Ci odpowiada. Tak długo, jak kod jest łatwy do utrzymania i odczytu, powinieneś być dobry. Idealnie byłoby mieć testy jednostkowe, aby ułatwić refaktoryzację później w dół drogi.

Łatwo jest przyłapać się na tym, że kod wygląda idealnie i przestrzega każdego standardu, jaki możesz wymyślić. To się zdarza nam wszystkim. Patrząc na kod, który napisałem kilka tygodni temu, myślę o wprowadzeniu zmian. Dodaj właściwość tutaj, zmodyfikuj tam metodę. I wydaje się, że dzieje się to pod koniec projektu. Ale jeśli zostaniesz zbyt pochłonięty tym, że możesz popsuć błąd. Robiłem to kilka razy na początku mojej kariery. Kilka sesji naprawy błędów 3 rano wyleczyło mnie z tego problemu.

bwalk2895
źródło
1

Zrób to na odwrót.

Zamiast „co można zrobić lepiej?” szukaj „co mnie wkurza?” dopóki nic nie robi.

Arnis Lapsa
źródło
4
„Książka jest skończona nie wtedy, gdy nic więcej nie można dodać, ale kiedy nic nie można z niej usunąć”. - Kod ukończony
Jonathan
To właściwie parafraza z Saint-Exupéry, zabawne, że może on być mniej wiarygodny niż Code Complete tutaj.
scrwtp
1

Jako programista Twoim zadaniem jest tworzenie kodu. Celem najlepszych praktyk jest zwiększenie tempa produkcji poprzez ułatwienie zrozumienia / zrobienia / zapamiętania. Jeśli przestrzeganie tych praktyk przeszkadza w wykonywaniu zadań, robisz coś złego. Po prostu spróbuj stworzyć kod tak szybko, jak to możliwe, a twoje praktyki powinny ewoluować, abyś mógł to zrobić.

suszterpatt
źródło
Nie zgadzam się. Jako programista Twoim zadaniem jest rozwiązywanie problemów. Zbyt wielu programistów patrzy na problem i mówi „Mogę kodować rozwiązanie tego problemu” i nie rozglądam się za rozwiązaniami, które już istnieją . Najlepszym rozwiązaniem jest to, czego nie musisz pisać. To powiedziawszy, jako programista, który musi kodować rozwiązanie, Twoim zadaniem jest spełnienie wymagań. Istnieją najlepsze praktyki, aby upewnić się, że kod spełniający wymagania może być łatwo zmieniony, gdy zmienią się wymagania (nie jeśli , ale kiedy ).
KeithS,
1

Spraw, by działał, uczyń go czystym, spraw, aby był SOLIDNY, spraw, aby był wydajny.

Pierwsze trzy to powiedzenie, które wypowiadam się, gdy tylko ktoś zastanawia się, jak napisać kod SOLID na osi czasu. Kiedy po raz pierwszy piszesz wiersz kodu, musi on po prostu działać, więc rób to, co musisz, i nie bądź fantazyjny. Za pierwszym razem, gdy ponownie odwiedzasz wiersz kodu, nie jest on już jednorazowy i powinieneś go wyczyścić, aby był czytelny, a przez to łatwiejszy w utrzymaniu. Za trzecim razem, gdy kursor znajdzie się w tym wierszu, jest to prawdopodobnie wielka sprawa i powinieneś to zmienić, aby zastosować się do metodologii SOLID, wyodrębnić zależności, implementować wzorce i ogólnie ułatwić kodowi podłączenie lub podłączenie do przyszłego rozszerzenia.

Elegancję w kodzie należy osiągnąć tam, gdzie programiści zauważą taką możliwość, i na ogół jest to funkcja upraszczająca, czyszcząca i ogólnie poprawiająca czytelność i łatwość konserwacji kodu podczas wykonywania poprzednich kroków. To nie jest coś, co można zmaksymalizować .

Kod wykonawczy jest prawie zawsze najmniejszy w językach zarządzanych pamięcią (Java, rodzina .NET, najbardziej funkcjonalne języki itp.). W tych środowiskach celem jest napisanie poprawnego kodu („poprawny” tutaj zdefiniowany jako generujący oczekiwany wynik we wszystkich oczekiwanych przypadkach, orazbyć zrozumiałym i dobrze skonstruowanym, a tym samym możliwym do utrzymania), a wydajność ma drugorzędne znaczenie (zwykle będzie przebiegać do pewnego stopnia od poprawnego kodu). We wszystkich przypadkach algorytm działa, gdy jest „wystarczająco dobry”. Pamiętajcie: „przedwczesna optymalizacja jest źródłem wszelkiego zła”; optymalizacje, których nie potrzebujesz, to niewiele więcej niż marnowanie czasu, zaciemnianie kodu i ogólnie zapobieganie postępom. Najpierw musi zadziałać, a potem, gdy już działa, uruchom go i sprawdź, jak szybko działa. Jeśli nie jest wystarczająco szybki (jak zdefiniowano w jakimś teście porównawczym, który jest opublikowanym wymaganiem), popraw go, aż będzie, a następnie przestań .

KeithS
źródło
0

Naprawdę musisz być pragmatyczny w programowaniu. Tak, wszyscy lubimy robić wszystko dobrze, ale zarabiasz za dostarczanie działającego oprogramowania, a nie za dopracowywanie go do końca życia.

Podejście, które należy podjąć, to „załatwić sprawę” w życiu zawodowym. Dostarcz i ruszaj dalej. Zachowaj swój perfekcjonizm dla osobistych projektów.

James McLeod
źródło
Rozumiem, ale nie możemy uznać tego za „czarny lub biały”.
Rushino