Mam mały problem psychiczny związany z programowaniem :) Jest nim mania perfekcyjnośći. Uczę się c++ od paru miesiecy i moge powiedzieć ze znam go całkiem dobrze, mimo to, nie jestem w stanie napisać coś wiekszego samemu. Tzn. W większości przypadków znajduje rozwiązanie ale jednocześnie wiem, ze można to zrobić lepiej i to mnie denerwuje i nie mogę kontynuować dalszej pracy. Spojrzałem na pare projektów na github i w tych bardziej amatorskich widać, ze mają gdzieś jakość kodu - są one napisane "byle działalo" - ja tak nie potrafie. Drugim problemem jest mania optymalizacji, zawsze chce aby coś działało najwydajniej. I przez te dwa problemy nie udało mi się jeszcze skodzić coś wiekszego poza prymitywnymi programami. Dodam, ze poza programowaniem brak perfekcji mnie nie rusza. Czy ktoś może poradzić jak się tego oduczyć?
Zawsze wyjdzie, że można zrobić coś lepiej - w programowaniu, jak w wielu innych przypadkach musisz wyznaczyć pułap "nadaje się". I przyjąć, że do ideału należy dążyć, ale nigdy raczej do niego się nie dotrze - ważne, by zawsze się przybliżać.
Mam to samo, po 10 latach przestalem juz walczyc ;) W srodowisku mam juz latke maniaka, ale przynajmniej hajs sie zgadza
Zawieś sobie nad kompem slogan:
"Done is better than perfect"
,,Wyobraź sobie żeś stolarzem/cieślą jest :)"
Zadanie to postawienie komórki na szpadle i grabie na działce. Użyjesz oczywiście dobrych materiałów ale raczej nie będziesz kusił się o ocieplanie i heban na deski :-) Jeśli jednak robisz dom drewniany, będziesz i go ocieplał i cyzelował szczegóły ,,gdzie ludzkie oko widzi".
A poważnie. Masz 2 jakości. Jedna to jakość kodu i to co dookoła (czytelność, dokumentacja, pokrycie testami, modułowość ... itp... ), druga to ta zewnętrzna czyli: program działa, program ładnie wygląda, pomaga rozwiązywać problemy użytkownika. Za dotrzymanie której jakości Ci zapłacą? W przenośni, jakie samochody ludzie kupują? Zgodne z regułą KISS, S.O.L.I.D., GRASP (np. w zależności od potrzeb prawdziwe-terenowe) czy ,,ładne i wygodne" ale które mają tendencję do psucia się po 2 tygodniach od zakończenia gwarancji? :-)
Daleki jestem od rady "nie dbaj o jakość wewnętrzną". O nią należy także dbać. W stopniu jednak proporcjonalnym do całości wymagań projektu i przy ograniczeniach tego co oczekuje klient. Było i będzie zawsze tak, że jakość wewnętrzna jest obniżana bo termin, budżet a klient wymaga.
Abyś jednak mógł "skalibrować" swoje umiejętności, radzę zaimplementować prosty problem (np. przetwarzanie wsadowe złożonych danych z pliku do pliku) w bardzo krótkim czasie poświęconym na kodowanie. Maksymalnie 1 dzień a lepiej godziny. Ma być cel, ma być bardzo szybko zakodowane i ma działać. Jakość wewnętrzna "na glebę" i "oby do przodu". Jak już to zrobisz, to zostaw kod na kilka dni i już go nie poprawiaj. Następnie zrób zadanie od początku ale w trybie "time unlimited & high quality". Ile Ci to zajęło?
Teraz pomyśl. To tylko przetwarzanie plik<->plik a nie sterowanie statkiem kosmicznym. W tym czasie możesz popełnić (przy rozsądnej jakości ale nie absolutnej), o wiele więcej dobrego kodu. Poza tym i tak 2 podejście jest troszkę zakłamane i w rzeczywistości będzie dłuższe bo tu już podchodziłeś do problemu i wiesz jakie niespodzianki Cię czekają :-)
Ja to widzę tak.. sprawdź gdzie masz granice tego co i jak robisz i wybieraj rozsądnie :-)
Świetny Krawiec napisał(a)
Czy ktoś może poradzić jak się tego oduczyć?
A dlaczego chcesz się tego oduczyć? Robotę trzeba robić dobrze i jeśli takie jest Twoje podejście, to jest to Twoja zaleta, a nie wada; Tyle tylko, że Ty jak napisałeś, porządnie lubisz robić soft, a wszystko inne nie; Więc to raczej nie jest Twoja cecha, a jakieś dziwne zboczenie :]
____Sam jak za coś się zabieram, to muszę to zrobić dobrze i dokładnie; Lubię mieć kod napisany dobrze, poza tym sam od siebie wymagam, aby kod działał możliwie jak najszybciej; Często coś optymalizuję, nawet na następny dzień, ale nie mam obsesji na tym punkcie; Trzeba przyjąć do wiadomości to, że zawsze i wszystko można zrobić lepiej; Ja taką granicę potrafię dostrzec - piszę kod, skupiając się nad jego jakością i efektywnością; Jeśli wyjdzie dobrze, działa szybko i przede wszystkim prawidłowo, to nie zastanawiam się nad tym jak napisać go lepiej; Gdybym miał go ciągle poprawiać, to traciłbym kupę czasu i zamiast iść do przodu - projekt stałby w miejscu, a przecież nie o to chodzi;
Po prostu przestań cudować - pisz dobry kod i idź dalej, pchaj wózek do przodu; Po jakimś czasie przestaniesz o tym myśleć, jak będziesz widział ile kodu dzięki temu przybywa.
Mam to samo gdy programuję samemu - czasem kilka dni potrafię poświęcić poprawiając coś co już dawno działa
Gdy ktoś patrzy jak programuję, programuję w parach lub co jakiś czas sprawdza co zrobiłem to nie marnuję czasu w ten sposób i idzie dużo szybciej - może warto wziąć kogoś do zespołu?