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

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?

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.

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.

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?

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.

Zrób to na odwrót.

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

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

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

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.