Mój proponowany projekt jest zwykle gorszy niż projekt mojego kolegi - jak mogę się poprawić? [Zamknięte]

Programuję od kilku lat i ogólnie jestem dobry, jeśli chodzi o rozwiązywanie problemów i tworzenie małych i średnich skryptów, jednak ogólnie nie jestem dobry w projektowaniu dużych programów w sposób obiektowy. Kilka pytań

1. Ostatnio kolega z taką samą liczbą lat doświadczenia jak ja i ja pracowaliśmy nad problemem. Pracowałem nad problemem dłużej niż on, jednak wymyślił lepsze rozwiązanie i ostatecznie wykorzystamy jego projekt. To naprawdę na mnie wpłynęło. Przyznaję, że jego projekt jest lepszy, ale chciałem wymyślić równie dobry projekt. Zastanawiam się nawet nad odejściem z pracy. Nie jestem pewien, dlaczego, ale nagle odczuwam presję, np. Co myślą o mnie juniorzy itp.? Jest to normalne? Czy myślę o tym trochę za dużo?

2. Moja praca polega na programowaniu w języku Python. Próbuję czytać kod źródłowy, ale jak myślisz, jak mogę poprawić swoje umiejętności projektowania? Czy są jakieś dobre książki lub oprogramowanie, które powinienem studiować?

Proszę, oświeć mnie. Naprawdę docenię twoją pomoc.

Myślę, że to bardzo pozytywny znak twoich umiejętności. O wiele bardziej powszechne jest, że ludzie, którzy mają trudności z wymyśleniem „lepszego” projektu w zespole, zupełnie nie są w stanie rozpoznać, dlaczego inny projekt jest lepszy.

Masz dwie naprawdę wielkie (i zaskakująco rzadkie) mocne strony:

• Jesteś w stanie obiektywnie ocenić swoje projekty na tle innych
• Masz pragnienie i wysiłek, aby Twoje projekty były optymalne

Masz dopiero kilka lat i masz przed sobą długą drogę, ale dzięki temu podejściu na pewno się tam dostaniesz, po prostu nie poddawaj się; wszyscy mamy do czynienia z takimi mentalnymi niepowodzeniami. Tak często, jak mam szansę, lubię podłączać Zasady Projektowania (NIE takie same jak wzorce projektowe) i myślę, że jest to doskonały przykład tego, gdzie się przydają. Przestudiuj je i przećwicz ich stosowanie w swoich projektach, zanim się zorientujesz, zrobił kolejny krok w tym zakresie.

Na koniec pamiętaj, że projektowanie jest trudne. Codziennie mamy do czynienia ze złożonymi abstrakcjami na wysokim poziomie, aby tworzyć je z cienkiego powietrza, aby działały dobrze, a łatwość w użyciu dla kolegów jest niezwykle trudnym zadaniem. To wymaga praktyki, na lata .

Więc odpręż się i pamiętaj: istnieje grupa ludzi, którzy nie potrafią ocenić dwóch projektów i faktycznie uznają jeden za lepszy od drugiego, jak myślisz, jak dobrze sobie radzą w tworzeniu dobrych projektów?

Edycja:
„inna wskazówka, po zapoznaniu się z zasadami i poćwiczeniu ich zastosowania, myślę, że jest inny klejnot z innego pytania, który mówi o wartości studiowania różnych języków, które mają różne cele i zasady:

Idealnie każdy programista powinien znać język z każdej klasy. Czego możesz się nauczyć:

1. Język głównego nurtu OOP o typie statycznym: Java, C # (używany głównie w oprogramowaniu dla przedsiębiorstw) i C ++ (programowanie systemu i złożone aplikacje komputerowe)
2. Protokółowy język OOP: JavaScript (programowanie po stronie klienta)
3. Język proceduralny: C (oprogramowanie wbudowane i programowanie systemu)
4. Język funkcjonalny: Haskell, ML lub Lisp (języki funkcjonalne są dobre dla wysoce zrównoleglonego oprogramowania).

Logiczny język programowania (Prolog) prawdopodobnie nie jest tak przydatny w przemyśle, ponieważ jest wykorzystywany głównie w badaniach nad AI.

Pomoże to poszerzyć różnorodność pomysłów, które przychodzą na myśl podczas próby zaprojektowania rozwiązania.

1. Jest to całkowicie normalne, że wiele osób wymyśla projekty o różnej jakości. W przeszłości byłem zapraszany do oceniania konkursów w zakresie projektowania oprogramowania, więc byłem świadkiem tego z pierwszej ręki: nawet najprostsze projekty dały rozwiązania drastycznie różnej jakości, wszystkie pochodzące od inteligentnych i doświadczonych ludzi.
2. Czytanie kodu źródłowego jest zbyt niskie, aby pomóc Ci poprawić swoje umiejętności projektowania: kod rozwiązuje złożoność na niższym poziomie niż ogólny projekt.

Najlepszym sposobem na ulepszenie oprogramowania do projektowania jest projektowanie oprogramowania ^* . Jednym ze sposobów jest obejrzenie konkursów projektowych: TopCoder posiada archiwum ponad 100 projektów komponentów, wraz z dokumentacją projektową UML i implementacjami w Javie i / lub C #. Wybierz gotowy element, który Ci się podoba, przeczytaj specyfikację wymagań i spróbuj wymyślić oryginalny projekt, który spełni wymagania. Poświęć godzinę lub dwie na przemyślenie problemu i naszkicowanie schematu zajęć, a następnie otwórz zwycięski projekt i przeczytaj, co zrobił autor. Porównaj jego projekt z twoim, dostrzeż różnice i sprawdź, czy twój projekt jest lepszy. Sprawdź kartę wyników konkursu, aby zobaczyć, jak sędziowie ocenili projekt. Dzięki temu uzyskasz informacje zwrotne, które musisz podjąć, aby poprawić swoje umiejętności projektowania.

Nie rezygnuj z pracy. Lepiej jest pracować z kimś, kto ma lepsze umiejętności niż ty, abyś mógł uczyć się od niego.

Spójrz na lepszy projekt i ustal, dlaczego jest lepszy. WYJDŹ od przyjętego projektu i pomyśl o sposobach zastosowania podobnego projektu w innych sytuacjach. Kiedy już wiesz, dlaczego jest to lepsze niż twój projekt, wiesz, co to za mistatke, aby nie zrobić następnym razem. Porozmawiaj z drugim deweloperem i zapytaj, jak wymyślił projekt.

Aby poprawić umiejętności projektowania, najlepiej jest tworzyć projekty, a następnie bądź brutalny w ocenie ich i określaniu, jak można je ulepszyć. Zadaj sobie następujące pytania: czy to zadziała i czy spełnia wymagania pod każdym względem, czy jest to możliwe do utrzymania, jak będę w stanie to przetestować, czy spowoduje problemy z wydajnością, jak prawdopodobne jest wymaganie zmiany i jak dobrze projekt być w stanie poradzić sobie ze zmianą. Przeczytaj o wzorach projektowych, a następnie spróbuj zastosować je do swoich projektów. Refaktoryzuj bezlitośnie po wymyśleniu wstępnego projektu. Jeśli projektujesz bazę danych wraz z aplikacją, czytasz obszernie informacje o normalizacji i dostrajaniu wydajności bazy danych, dowiesz się wiele o projektowaniu bazy danych, jeśli nauczysz się, jak sprawić, by baza danych działała najbardziej efektywnie i wydajnie. W przypadku aplikacji podczas projektowania należy pomyśleć o zasadach SUCHEJ i SOLIDNEJ. Przeczytaj o antypatternach, aby dowiedzieć się, jakich rzeczy unikać.

Ważną umiejętnością jest rozpoznanie lepszego projektu. Powinieneś to wspierać, postępując zgodnie z niektórymi wcześniejszymi sugestiami dotyczącymi patrzenia na projekty.

Na podstawie jakich kryteriów oceniłeś drugi projekt lepiej? Czy było to prostsze i łatwiejsze do zrozumienia? Czy zapewniło to przewagę wydajności? Czy było bardziej rozszerzalne? Istnieje wiele zasad projektowania, takich jak rozkład, abstrakcja, ukrywanie informacji i modułowość komponentów, których można użyć do oceny projektów i które można już rozpoznać.

• Spróbuj wymienić swoje kryteria, zrozumieć je, rozwinąć i ponownie użyć, gdy spojrzysz na inne projekty. Kiedy projektujesz rzeczy samodzielnie, weź udział w procesie, aby stosować te kryteria i świadomie mierz swoje projekty względem nich. Następnie przygotuj się na całkowitą modyfikację lub odrzucenie projektu, jeśli nie spełnia on twoich kryteriów.

Otrzymasz pomysły na różne zasady dotyczące projektów z niektórych następujących źródeł: http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf Projektowanie oprogramowania na wikipedii Google „Zasady projektowania oprogramowania”

• Zapoznaj się z różnymi modelami do projektowania oprogramowania, takimi jak Object Objected Design lub Functional Design lub Structured Analysis Design. Mogą to być zupełnie inne sposoby myślenia, od których można podejść do zadania projektowego, i każdy z nich ma obszary, w których się wyróżniają. Naucz się ich jako narzędzi do swojego zestawu narzędzi. http://userpages.umbc.edu/~khoo/survey2.html

• Upewnij się, że oddzielasz projekt od implementacji, spróbuj narysować schematy rzeczy, które postrzegasz jako dobre projekty, aby oddzielić specyfikę języka i implementacji od zasad projektowania wyższego poziomu. I rozwinąć swoje „oko projektowe” i umiejętności komunikacyjne.

• Wreszcie, ale być może najważniejsze, szerokie czytanie jest bardzo dobrym narzędziem - istnieje wiele interesujących rzeczy, od fraktali przez analizę bayesowską, logikę rozmytą po przetwarzanie języka naturalnego, które mogą dostarczyć pożywienia dla pomysłów, które pojawią się później i nieoczekiwanie. Dzięki sieci możesz przeglądać tematy na wiele sposobów, tylko dla rozrywki i podbudowania, a to przyniesie korzyści. Nie musisz stać się ekspertem, wystarczy zapoznać się z terminami i pomysłami.

Baw się dobrze - nie rób tego, jeśli choć trochę ci się nie podoba!

Cóż, zrobiłeś już pierwszy krok. Przyznajesz, że musisz się czegoś nauczyć, że praca twojego kolegi jest lepsza niż twoja i chcesz się uczyć i doskonalić.

Drugim krokiem jest analiza. Spójrz na jego pracę i nie mów tylko, że jest lepsza; dowiedz się, dlaczego tak jest lepiej. Poszukaj konkretnych szczegółów i punktów, które zrobił lepiej.

Kiedy to zrozumiesz, wyodrębnij za nim zasady. Zadaj pytania takie jak te:

• Co z tym projektem jest lepsze niż mój projekt?
• Czy ten punkt jest czymś specyficznym dla tego projektu, czy jest to ogólna zasada, którą można zastosować w innych projektach w przyszłości?
• Jeśli jest to ogólna zasada, jakie są jej ograniczenia? Kiedy warto nie robić tego w ten sposób? (Ten jest bardzo ważny. Nie pozwala ci traktować jakiegoś użytecznego pomysłu jak złotego młota , nawet w nieodpowiednich przypadkach.)

Postaraj się to rozwiązać na własną rękę, ponieważ lepiej przyswoisz sobie pomysły, jeśli sam wymyślisz łańcuch rozumowania, który doprowadził cię do wniosku, ale porozmawiaj również ze współpracownikiem, aby upewnić się, że otrzymujesz rzeczy dobrze. (W końcu nie chcesz popełniać błędów w swoim rozumowaniu i internalizować złą zasadę.) I nie wahaj się poprosić współpracownika o pomoc, jeśli nie możesz tego zrozumieć. Programowanie to dyscyplina, w której szanuje się pokorę, a wielu programistów skorzysta z okazji, aby nauczyć kogoś czegoś nowego, co jest prawdopodobnie dużą częścią tego, dlaczego StackOverflow stał się tak duży.

Chciałbym również dodać (oprócz świetnych odpowiedzi), że jest w tym coś więcej niż „Potrafi stworzyć lepszy projekt niż ja”. Pozostałe odpowiedzi koncentrują się na tym, w jaki sposób można poprawić projektowanie, co jest dobre i dobre ... ale ...

Założę się, że TY możesz zrobić coś lepszego niż współpracownik. Nie po to, żeby stworzyć dopasowanie do sikania lub cokolwiek innego (możesz zrobić Y lepiej? Chrzanić, mogę zrobić X lepiej!), Ale wskazać prawdę, że każdy ma mocne i słabe strony.

W mojej pracy jest 4 programistów. Czasami dwaj główni „programiści” mogą tworzyć rzeczy, które po prostu zostawiają mnie w prochu. Kręci mi się w głowie, próbując owinąć głowę wokół ich dzieł.

Ale jestem znacznie lepszy w SQL i skryptach wiersza poleceń niż one, i mogę zautomatyzować rzeczy, które pozostawiają je w pyle.

Czy są lepsi ode mnie? W niektórych obszarach jest zdecydowanie. Do diabła, są na wielu obszarach - zdecydowanie jestem młodszym programistą w moim sklepie i indywidualnie mam na nich wieloletnie doświadczenie. Pomimo tych wieloletnich doświadczeń jestem lepszy w niektórych obszarach niż oni.

Przestań się skupiać na tym, że ktoś jest lepszy w X niż ty. Ta osoba, nie próbując ani nawet o tym nie myśląc, może być w stanie cię zaprojektować nawet po ćwiczeniu przez następne 10 lat. Nie dlatego, że nie powinieneś pracować nad naprawieniem swoich słabości, ale pamiętaj, że dla każdej siły jest słabość.

Skoncentruj się zarówno na silnych, jak i słabych stronach Ciebie i Twoich współpracowników.

W każdym aspekcie życia znajdziesz ludzi, którzy nie są tak dobrzy jak ty, a także ludzi, którzy są lepsi od ciebie, szczególnie po zaledwie „kilku latach” doświadczenia.

Musisz uczyć się od wszystkich.

Nie czuj się źle Może twój kolega jest naturalny. Powinieneś mu pogratulować i nauczyć się od niego jak najwięcej.

Nie pozwól, aby profesjonalista zazdrośnie stanął między tobą a szansą na naukę.

1. Kilka lat to naprawdę niewiele. I są ludzie z lepszymi lub najgorszymi widokami na wysokim poziomie. Na przykład znałem ludzi zdolnych do pisania skomplikowanych algorytmów dla programów niskopoziomowych w mgnieniu oka, ale niezdolnych do zrozumienia projektu wyższego poziomu i koncepcji takich jak spójność i zależności. Nie jest to jednak stan faktyczny. Oba możesz poprawić na wyższym poziomie projektowania (przeczytaj kilka książek, wypróbuj kilka sztuczek w domu itp.), A także możesz odkryć, że w innych obszarach programowania twój inny programista jest mniej dobry. Ponadto, jeśli uważasz, że jesteś na tym samym poziomie zarówno pod względem doświadczenia, jak i wiedzy technicznej, mogło to mieć przypadkową sytuację. Następnym razem może masz lepsze pomysły na projektowanie. Zamiast rzucić pracę, skorzystaj z okazji i ucz się od kolegi. Następnym razem zrób projekt razem, spróbuj złapać jego sekrety, jego myśli. Programowanie jest jak rzemiosło, uczy się go, robiąc i obserwując, jak inni to robią.

2. Umiejętności projektowe pochodzą głównie z doświadczenia i po przeczytaniu kilku ważnych książek. Poleciłbym następujące:

   • Robert C. Marting - zwinne zasady, wzorce i praktyki (istnieją 2 wersje, jedna w Javie i jedna w języku C #. Nie ma znaczenia, którą wybierzesz, pomysły i zasady można zastosować do dowolnego obiektu zorientowanego - i nie tylko - kod źródłowy)
   • Następnie Robert C. Marting ma 2 inne interesujące książki: Clean Code i The Clean Coder
   • Nawet jeśli Martin omawia wszystkie nowoczesne wzory w swojej pierwszej książce, chcesz poszukać oryginalnej książki z wzorami autorstwa Gang of Four.
   • Wreszcie, istnieją inne książki, które są dziś bardzo cenione: Rosnące oprogramowanie obiektowe oparte na testach lub Refaktoryzacja M. Feathersa (myślę), lub Pisanie przypadków efektywnego użycia A. Cockburn i kilka innych, które odkryjesz po drodze.

Żadna z tych książek nie jest magiczną kulą, ale przeczytanie pierwszych 2 rekomendacji prawdopodobnie zmieni twoje spojrzenie i postrzeganie programowania na zawsze.

Nie pozwól, żeby ci to dotarło. Jeśli masz wieloletnie doświadczenie w naprawianiu błędów i tworzeniu małych programów, to właśnie je osiągniesz. Twój współpracownik prawdopodobnie ma wieloletnie doświadczenie w projektowaniu większych projektów.

Znajomość podstawowych bitów jest niezwykle przydatna, ale jeśli chcesz poprawić projektowanie, musisz zaprojektować kilka projektów. Powtarzaj tę czynność, dopóki umiejętność nie zatonie.

Krótko mówiąc, „lata doświadczenia” nie zawsze są równoważne. Idź, aby twoje lata były coś warte.

„Poprawa” często oznacza lepsze mierzenie projektów lub kodu w stosunku do czegoś / kogoś, staranne porównywanie tego, co się różni, uczenie się na podstawie tych różnic i ciągłe doskonalenie przyszłych projektów w oparciu o to. Zbyt złe przeczucie, że musisz dowiedzieć się więcej, spowolni ten korzystny proces. Jeśli przeprowadzisz się do miejsca, w którym nie ma ludzi (lub innych zasobów), którzy czasami lub zawsze mogą zapewnić ci lepsze porównanie, możesz stracić tę okazję do lepszego uczenia się i spowolnić proces obstawiania.