Perfekcjonizm może być dobry i zły podczas programowania.
Proszę o komentarz, jeśli pytanie jest niejasne.
Odpowiedzi:
KISS i YAGNI , zwłaszcza YAGNI.
Tylko opracuj rozwiązanie dla rzeczy, o których wiesz, że wkrótce będziesz potrzebować. Nie konstruuj go pod kątem rzeczy, które mogą być potrzebne za dwa lata, ponieważ najprawdopodobniej będziesz potrzebować bardzo różnych rzeczy i i tak będziesz musiał je przeprojektować.
Gdy zaczniesz mówić o „tym projekcie w pewnym momencie w przyszłości moglibyśmy zrobić X, a nawet Y”, zamiast „ten projekt pozwala nam spełnić wymagania klienta Z w następnej wersji”, wtedy otrzymujesz w astronomię architektury.
W odpowiedzi na komentarze:
YAGNI.
Użyj iteracyjnego podejścia, a ten problem w większości zniknie. Kod powinien być uruchamiany pierwszego dnia, a następnie prawie każdego dnia. Najpierw spełnij minimalne wymagania i dodaj więcej, gdy masz czas. Nigdy nie zbaczaj z wielkich zmian, gdy nie możesz uruchomić kodu przez długi czas.
Rozwiązanie jest przesadą, gdy dodatkowy czas potrzebny na jego ukończenie jest wart więcej niż potencjalny negatywny wpływ od momentu, gdy łatwiejsze rozwiązanie zostanie ukończone, do momentu, gdy zostanie ono w naturalny sposób ulepszone / zmienione.
Zasadniczo handlujesz czasem teraz, a później. Jeśli spędzasz teraz więcej czasu, a potem zaoszczędzisz, robisz to źle. Jeśli jesteś naprawdę zajęty inżynierią, spędzasz teraz czas, co nie ma wpływu na to, ile czasu (lub nawet go wydłużysz) spędzasz później.
Im więcej masz doświadczenia, tym lepiej. Najlepszym sposobem, aby przejść do rzeczy (z mojego doświadczenia) jest robienie tego, czego potrzebujesz teraz, ale w sposób, który jest najłatwiejszy do zwiększenia, jeśli później wymagają tego wymagania. Wypracowanie, jak to zrobić, jest trudnym zadaniem.
Byłem bardzo perfekcjonistą (spędzałem czas na tworzeniu ram, a nie rozwiązań).
Ale rzeczą, która naprawdę pomogła mi przyspieszyć moją produkcję, było uczenie się i przestrzeganie zasad BDD / TDD, w tym zasady zewnętrznej (co było dla mnie szczególnie trudne do przyjęcia).
To naprawdę nauczyło mnie nie pisać ani jednego wiersza kodu przed testem. Ale testy jednostkowe nie istnieją również przed testem akceptacyjnym. A testy akceptacyjne pochodzą z rzeczywistych potrzeb użytkowników.
Dlatego wszystkie wiersze kodu pochodzą z rzeczywistej potrzeby użytkownika.
Jeśli w zasadzie nie znasz się na zewnątrz, nakazuje to, abyś zaczął pisać testy dla najbardziej zewnętrznej warstwy w swojej aplikacji (tj. GUI w praktycznie wszystkich przypadkach) przy użyciu podwójnych testów, aby symulować zachowanie niższych warstw. Następnie zaimplementuj tylko tyle, aby testy zakończyły się pomyślnie. Ta implementacja górnej warstwy decyduje następnie o testach, które należy napisać dla następnej warstwy itp., Aż dojdziesz do dolnej warstwy aplikacji.
Zauważyłem, że jestem lepszy dzięki doświadczeniu.
Kiedy byłem (bardzo) młody, zawsze szukałem najlepszego rozwiązania, bez kompromisów. Teraz lepiej pamiętam o budżecie i czasie.
Termin określa tę linię dość wyraźnie.
Mój szef tak naprawdę :)
Muszę przyznać, że czuję się coraz lepiej, ale wciąż nie mam zbyt wiele na kompromis. Na szczęście mam mojego szefa, który mnie powstrzymuje;)
Chciałbym jednak poruszyć inny problem niż nadmierna inżynieria, ponieważ nadmierna inżynieria jest dość łatwa do wykrycia.
Moim głównym problemem jest refaktoryzacja. Problem polega na tym, że przez większość czasu, mimo że próbowałem napisać kod tak dobrze, jak mogłem, nie wiedziałem wtedy, co wiem teraz (widziałem więcej kodów, więcej wzorców, nowe idiomy, nowe problemy, nowe rozwiązania). I tak, mimo że działa, teraz znam lepsze sposoby:
Jednak działa tak, jak jest, i dlatego refaktoryzacja nie jest priorytetem, a prawda jest taka, że dokucza mi; Rozumiem przyczyny ekonomiczne i rozumiem oczekiwania klientów (nie widzą kodu i wolą nowe funkcje i poprawki błędów), ale szkoda, że nie miałem czasu nad tym popracować.
Na razie po prostu podążam za rozkazem szefa, ale muszę przyznać, że czuję się nieswojo wiedząc, że kod dostarczony do produkcji nie jest najlepszy, jaki mogłem teraz wymyślić. Perfekcjonizm, tak myślę.
Zarówno zawodowo, jak i osobiście standardem, który staram się zastosować wobec siebie jest:
Bądź zadowolony ze zwycięstwa.
Jeśli mój kod rozwiązuje problem, który ma rozwiązać i nie stwarza nowych problemów *, bardzo prawdopodobne jest, że przejdziemy dalej. Kiedy nauczysz się ustawiać poprzeczkę tak wysoko, jak trzeba ją ustawić, „wystarczająco dobre” staje się, cóż, wystarczająco dobre.
Doskonałość jest jak prędkość światła: nigdy tam nie dotrzesz, ale nie ma ograniczeń co do energii, którą możesz przeznaczyć na próby.
(* - Zauważ, że zarówno „Buggy”, jak i „Trudne w utrzymaniu” oba są zdecydowanie objęte nagłówkiem „Nowe problemy”. Nie nazywam go więc dopóty, dopóki kod nie zostanie przetestowany, bez przycinania zbędnych bitów i zaktualizowane komentarze / dokumentacja API).
Z doświadczeniem zdałem sobie sprawę, że perfekcjonizm nie jest nawet możliwy, dopóki nie będę miał co najmniej kilku lat pod kontrolą w jakimś konkretnym kontekście (język, framework, platforma, standard). Jako nowicjusz pojawią się różnego rodzaju dziwactwa, których nie będziesz świadomy (ucieczka, pierwszeństwo, zastrzeżone słowa, cukier składniowy, limity czasu, wywołania asynchroniczne, nieudokumentowane funkcje i błędy), więc po prostu staram się znaleźć dobre rozwiązanie, wszystkie ucząc się jak najwięcej. Co ważne, zawsze staram się ułatwić refaktoryzację wyniku - modułową architekturę, komentarze w razie potrzeby i brak sprytnych sztuczek .
Podobnie jak wielu innych programistów, mam dużo starszego kodu do utrzymania. Pokusa, by wszystko powtórzyć, zawsze będzie istnieć, ale zasadniczo sprowadziłem to do jednej zasady:
Czy ja (lub ktoś inny) będę musiał to rozgryźć ?
Zwykle zajmuje to dużo kodu spaghetti w nieco łatwiejszym do zarządzania kodzie spaghetti. Wyodrębnij niektóre fragmenty, wrzuć swoje testy, a teraz nie wygląda to na tak wymagające perfekcji.