Potrafię pisać kod… ale nie potrafię dobrze zaprojektować. Jakieś sugestie? [Zamknięte]

83

Czuję, że jestem dobry w pisaniu kodu fragmentami, ale moje projekty są naprawdę do kitu. Pytanie brzmi: jak mogę ulepszyć swoje projekty - a co za tym idzie zostać lepszym projektantem?

Myślę, że szkoły i uczelnie wykonują dobrą robotę, ucząc ludzi, jak stać się dobrym w rozwiązywaniu problemów matematycznych, ale przyznajmy, że większość aplikacji tworzonych w szkole ma na ogół około 1000 - 2000 linii, co oznacza, że ​​jest to w większości ćwiczenie akademickie co nie odzwierciedla złożoności rzeczywistego oprogramowania - rzędu kilkuset tysięcy do milionów wierszy kodu.

Uważam, że nawet projekty takie jak topcoder / euler projektów również nie będą zbyt pomocne, mogą wyostrzyć twoje matematyczne umiejętności rozwiązywania problemów - ale możesz zostać programistą akademickim; ktoś, kto bardziej interesuje się ładnymi, czystymi rzeczami, który jest całkowicie niezainteresowany codziennymi przyziemnymi i owłosionymi rzeczami, z którymi ma do czynienia większość programistów aplikacji.

Więc moje pytanie brzmi: jak mogę poprawić swoje umiejętności projektowania? Czyli umiejętność projektowania aplikacji na małą / średnią skalę, które przejdą do kilku tysięcy wierszy kodu? Jak mogę nauczyć się umiejętności projektowania, które pomogą mi zbudować lepszy zestaw edytora HTML lub jakiś program graficzny, taki jak Gimp?

użytkownik396089
źródło
1
„Przyznajmy, że większość aplikacji tworzonych w szkole ma na ogół około 1000 - 2000 linii, co oznacza, że ​​jest to w większości ćwiczenie akademickie, które nie odzwierciedla złożoności rzeczywistego oprogramowania”: Kiedy uczyłem, mieliśmy dwa semestralny projekt oprogramowania, w którym zespół dziesięciu studentów opracował dość złożoną aplikację w okresie od 6 do 8 miesięcy. Ponadto wiele firm (przynajmniej w Niemczech) oferuje krótkie umowy dla studentów, którzy chcą poćwiczyć przed ukończeniem studiów.
Giorgio

Odpowiedzi:

87

Jedynym sposobem, aby stać się naprawdę dobrym w czymś, jest próba, spektakularne niepowodzenie, ponowna próba, ponowna porażka nieco mniej niż wcześniej, a wraz z upływem czasu rozwijanie doświadczenia w rozpoznawaniu przyczyn awarii, aby móc później poradzić sobie z potencjalnymi awariami. Dotyczy to zarówno nauki gry na instrumencie muzycznym, prowadzenia samochodu, jak i zdobycia poważnego wieku PWN w ulubionej strzelance FPS, podobnie jak uczenia się dowolnego aspektu tworzenia oprogramowania.

Nie ma prawdziwych skrótów, ale są rzeczy, które możesz zrobić, aby uniknąć problemów z wymykaniem się z rąk podczas zdobywania doświadczenia.

  • Znajdź dobrego mentora . Nie ma nic lepszego niż możliwość rozmowy o twoich problemach z kimś, kto już zapłacił swoje składki. Wskazówki to świetny sposób na przyspieszenie nauki.
  • Czytaj , czytaj więcej, ćwicz to, co czytałeś i powtarzaj przez cały okres swojej kariery. Robię te rzeczy od ponad 20 lat i wciąż mam ochotę uczyć się czegoś nowego każdego dnia. Dowiedz się nie tylko o projektowaniu z góry, ale także o projektowaniu, testowaniu, najlepszych praktykach, procesach i metodach. Wszystkie mają różny wpływ na to, jak Twoje projekty będą się pojawiać, kształtować, a co ważniejsze, jak będą trwać w czasie.
  • Znajdź czas na majsterkowanie . Weź udział w projekcie skunkwork w swoim miejscu pracy lub ćwicz we własnym czasie. Idzie to w parze z czytaniem, wprowadzaniem nowej wiedzy w życie i sprawdzaniem, jak takie rzeczy będą działać. To także sprawia, że ​​dyskusja z mentorem jest dobra.
  • Zaangażuj się w coś technicznego poza miejscem pracy. Może to być projekt lub forum. Coś, co pozwoli ci przetestować swoje teorie i pomysły poza bezpośrednim kręgiem rówieśników, aby zachować świeże spojrzenie na rzeczy.
  • Bądź cierpliwy . Uznaj, że zdobywanie doświadczenia wymaga czasu i naucz się akceptować konieczność wycofania się na chwilę, aby dowiedzieć się, dlaczego i gdzie poniosłeś porażkę.
  • Prowadź dziennik lub blog swoich zadań, myśli, porażek i sukcesów. Nie jest to absolutnie konieczne, jednak odkryłem, że może być dla ciebie bardzo korzystne, aby zobaczyć, jak rozwijałeś się w czasie, jak rozwijały się twoje umiejętności i zmieniały się twoje myśli. Co kilka miesięcy wracam do własnych czasopism i przeglądam rzeczy, które napisałem 4-5 lat temu. To prawdziwy otwieracz do oczu, który odkrywa, jak wiele nauczyłem się w tym czasie. To także przypomnienie, że od czasu do czasu coś mi się nie udaje. To zdrowe przypomnienie, które pomaga mi się poprawić.
S.Robins
źródło
45
+1 za próbę niepowodzenia. Ponieważ gdy nie rozumiesz, dlaczego istnieje wzorzec projektowy, nie możesz go skutecznie wykorzystać.
Mert Akcakaya
2
+1 świetna odpowiedź, ale uważam, że jest nieco niekompletna. Uważam, że zdecydowanie najważniejszym wkładem byłby bardzo dobry apetyt na refaktoryzację. Pisz, spójrz na to, co mówi teoria (artykuły, książki lub mentor), refaktoryzuj / przepisz, wróć do teorii, refaktoryzuj / przepisz - da ci to czas na skupienie się na strukturze podczas pracy ze znanym kodem. Bądź swoim własnym najgorszym krytykiem. Powiedziałbym również, że bardzo ważne jest, aby nigdy nie stracić apetytu na ciągłe odwiedzanie własnej pracy.
vski
1
@vski Istnieje wiele koncepcji, które mogłem uwzględnić, ale pytanie brzmi, czy same te koncepcje byłyby rozsądną drogą do zdobycia doświadczenia potrzebnego OP do uznania go za ulepszonego projektanta. W zakresie mojej odpowiedzi refaktoryzację postrzegam jako praktykę (jak na mój drugi punkt). Podobnie praktykuje się Clean Code, Test First, BDD i wiele innych pojęć. Przyjąłem podejście, że istnieje wiele umiejętności i doświadczeń potrzebnych do rozwoju do tego stopnia, że ​​umiejętności projektowe pojawią się i będą rosły wraz z zdobytym doświadczeniem i wiedzą. :)
S.Robins
2
+1 za zdobycie mentora. Najlepiej, poproś swojego mentora o zrobienie z Tobą recenzji kodu. Poproszenie kogoś o przeczytanie i krytykę kodu może naprawdę pomóc, jeśli chodzi o lepszy i czystszy projekt.
Leo
2
„Kiedykolwiek próbowałem. Zawsze się nie udawało. Nieważne. Spróbuj ponownie. Ponów porażkę. Lepiej nie.” --- Samuel Beckett.
Peter K.,
16

Cóż, nie ma złotego jabłka na takie pytanie i wydaje mi się, że każdy koder może znaleźć to, co jest dla niego odpowiednie. W każdym razie oto moje zdanie.

Państwo mogli czytać książki na ten temat. Świetne książki. Fantastyczne książki. Ale uważam, że te książki pomogą ci tylko wtedy, gdy spróbujesz zbudować i zaprojektować aplikację - i to się nie powiedzie.

Dla mnie najważniejsze jest doświadczenie. Kiedy zaczynałem jako debiutant, czytałem książki o projektowaniu. Wtedy nie rozumiałem zbyt wiele treści. Kiedy zacząłem pracować i sam musiałem projektować aplikacje, zrobiłem bardzo niechlujne aplikacje. Pracowali, ale ich utrzymanie było uciążliwe. Potem ponownie przeczytałem te książki - i tym razem lepiej je zrozumiałem.

Teraz nadal popełniam nowe błędy i uczę się na starych.

Amadeus Hein
źródło
10
Warto tu przywołać świetny punkt: ciągle popełniaj nowe błędy; nie popełniaj tych samych starych błędów - ucz się na nich i rób coś nowego.
Bevan
11

Przestań projektować i naucz się refaktoryzować kod. Stopniowy rozwój z ciągłym i agresywnym refaktoryzowaniem zapewni znacznie czystszy produkt końcowy niż jakikolwiek projekt z góry.

Kevin Cline
źródło
2
Wyłaniające się wzornictwo to piękna rzecz IMHO, ale bez dyscypliny ryzykujesz tworzenie „wschodzącego spaghetti”. Problem z projektowaniem z góry polega na tym, że ludzie postrzegają to jako propozycję „wszystko albo nic”, co daje złą reputację, gdy coś idzie nie tak. Przypomina mi to jeden z artykułów Joela, w którym wspomina, że ​​projekt jest ważny. To, czego potrzeba, wystarczy z góry, aby projekt mógł coś zmienić, nie pozbawiając cię czasu, zasobów i szansy na zobaczenie pięknych projektów wspierających, które powstają organicznie poprzez czysty kod.
S.Robins
@ S.Robins: Czułem, że OP wciąż atakuje projekty na tyle małe, że można je bardzo dobrze ukończyć dzięki TDD i ciągłemu refaktoryzacji. Dzięki temu może nauczyć się dyscypliny potrzebnej do zrozumienia, ile projektowania jest potrzebne w przypadku bardziej złożonych projektów.
kevin cline
Pomyślałem, że może tak być, ale czułem, że warto dodać przeciwwskazanie do wniosku, że „jakikolwiek projekt z góry” będzie potencjalnie gorszy niż coś, co powstaje całkowicie. Zgadzam się jednak, że sposobem na zbudowanie niezbędnego doświadczenia, którego poszukuje OP, jest mniej martwienie się na początku projektowaniem i skupienie się na pisaniu dobrze przemyślanego i czystego kodu. :-)
S.Robins
Nie zgadzam się, że refaktoryzacja zawsze prowadzi do najlepszego projektu. Oczywiście refaktoryzacja często pozwala odkryć i zrozumieć problem, ale dobry projekt nie zawsze pojawia się stopniowo poprzez refaktoryzację. Czasami widzisz o wiele lepsze rozwiązanie i zdajesz sobie sprawę, że twój obecny kod jest tak daleko od niego, że przepisywanie jest znacznie szybsze niż refaktoryzacja.
Giorgio
Niedawno miałem takie doświadczenie: ciągle refaktoryzowałem i refaktoryzowałem i ciągle chodziłem w kółko, mając te same problemy: używałem iteratorów do kodowania czegoś, a kod wciąż był skomplikowany. Potem postanowiłem zapomnieć o iteratorach i musiałem przepisać większą część kodu, ale logika stała się znacznie bardziej przejrzysta i zwięzła niż wcześniej. Nie wiem, czy nazwałbyś to „agresywnym refaktoryzacją”: ogólna struktura aplikacji nie uległa zmianie, ale niektóre podstawowe części zostały po prostu wyrzucone i przepisane od nowa.
Giorgio
7

Poczytaj o wzorach, jasne, ale przede wszystkim o anty-wzorach. Rozpoznawanie anty-wzorów jest ważne i łatwiej jest zrozumieć, dlaczego czegoś nie należy robić w taki sposób, niż dlaczego.

Zobacz na przykład http://sourcemaking.com/antipatterns/software-development-antipatterns .

Napisz kod, aby można go było szybko dostosować w przypadku zmiany wymagań (co jest bardzo powszechne w środowisku produkcyjnym).

Bądź sceptycznie nastawiony do dodawania „jeszcze jednego małego hacka”. Jeszcze jeden tutaj, jeszcze jeden, a kod staje się nieczytelny.

Cenią sobie otwarte / zamknięte zasadę .

Napisz testy (jak w TDD). Zmuszają cię do przemyślenia swojego projektu, nawet zanim go faktycznie wdrożysz.

Przejrzyj kod projektów open source (czyli rozsądnych rozmiarów). Byłem zaskoczony - zazwyczaj - widząc tak wiele poziomów abstrakcji. Teraz rozumiem, że to nie sztuka ze względu na sztukę, jest powód, dla którego tak się dzieje.

Konrad Morawski
źródło
4

Jedną z zasad, które uważam za bardzo ważne dla dobrego projektowania, jest rozkład: jeśli klasa jest zbyt duża (więcej niż, powiedzmy, 300-400 linii kodu), podziel ją na mniejsze klasy; jeśli metoda jest zbyt duża (powiedzmy, ponad 50 wierszy kodu) ją rozkłada; jeśli projekt zawiera więcej niż 50 klas, rozłóż go.

Kluczem jest oszacowanie rozmiaru twojego systemu i zbudowanie kilku warstw abstrakcji (np. Podsystemu, aplikacji, projektu, modułu, klasy, metody), które pozwalają ci rozłożyć kod na zrozumiałe jednostki z wyraźnymi zależnościami między nimi i kilkoma zależnościami.

Giorgio
źródło
1
Chociaż w twojej sugestii są pewne zalety, wiersze kodu nie mają tak naprawdę znaczenia, zachowanie ma znaczenie. Jeśli twoja metoda robi więcej niż jedną rzecz, prawdopodobnie nadszedł czas na jej refaktoryzację. Jeśli ta jedna rzecz to tylko wywoływanie metod, które same wykonują jedną czynność, i łączenie ich ze sobą, to w porządku.
jer
1
@jer: Oczywiście jest to ogólna zasada. Metoda wywołująca 100 innych metod to, jak mówisz, po prostu zszywanie rzeczy razem (nazywa się listą podfunkcji). Bardziej myślę o metodach zawierających pewną prawdziwą logikę: zwykle jest to zły znak, jeśli trzeba przewijać wiele razy w przód i w tył, aby zrozumieć, co robi metoda. To samo, jeśli spojrzysz na definicję klasy z dużą liczbą elementów (a klasa nie jest tylko dużym płaskim zbiorem właściwości).
Giorgio
„Projekt zawiera ponad 50 klas, rozłóż go” nie jest poważny
dynamiczny
@ yes123: Miał dać pomysł. To naprawdę zależy od tego, co rozwijasz, w jakim języku itp.
Giorgio
Myślę, że rozsądnie byłoby zauważyć, że nie pomoże to w projektowaniu z góry (ponieważ refaktoryzujesz), ale pomoże w nauce wzorców i najlepszych praktyk, które poprawią twoje przyszłe projekty.
Craig Bovis
0

To trudne, to, o czym tak naprawdę mówimy, to zdolność do abstrakcji zamiast tworzenia lepszego kodu, ale dwie rzeczy sprawią, że będziesz lepszy, a jedna sprawi, że będziesz szczęśliwszy:

"Lepszy"

A) Znajdź najlepszego projektanta, który możesz i sparuj program / zrób projekt razem. Poproś ich, aby wyjaśnili, co myślą, gdy rozwiązują problem, nie zadowalaj się „to po prostu właściwe” i kontynuuj kopanie. Ten proces pomoże również partii „mentoringowej”

B) Wyobraź sobie wszystko jako poszczególnych aktorów i rozmowy między nimi. Każdy z aktorów powinien mieć jedną rolę / odpowiedzialność, a grupy z nich obsługują różne systemy. Jeśli ta rozmowa się powiedzie, a każdy aktor poczuje się spójny, to jesteś na dobrej drodze.

I „szczęśliwszy”

C) Jeśli dołożyłeś wszelkich starań, aby nadal tak się nie działo, nie ma nic złego w zaakceptowaniu faktu, że niektórzy ludzie nie mogą nic zrobić. Możesz pisać ciasny, genialny kod, ale nigdy nie będziesz w stanie zaprojektować ani architektować. Więc co? Nie mogę uprawiać sportów fizycznych dla toffi, nie wyglądam dobrze, a moja jazda samochodem nigdy nie będzie lepsza niż średnia. Rozkoszuj się i wykorzystaj to, w czym jesteś dobry.

Stuart Muckley
źródło
-1

Z mojego osobistego doświadczenia wynika, że ​​kod jest dobrym źródłem „inspiracji”. Mam na myśli próbę zrozumienia projektów innych osób i zadaj sobie pytanie, dlaczego on / ona robi rzeczy w ten sposób?

możesz znaleźć wiele projektów typu open source do badań.

w każdym razie potrzebujesz praktyki.

PCJ
źródło
-1

Nie żyj w strachu

Dąż do prostoty

Słuchaj swoich użytkowników

Wypróbuj wiele pomysłów

Stwórz coś, a następnie ulepsz

Pracuj nad rzeczami, które dodają wartości, porzuć rzeczy, które nie

erturne
źródło
-1

Naucz się zadawać właściwe pytania. Najczęściej poprawisz swój projekt, patrząc na problem z innej perspektywy. W szczególności pomoże ci to odejść od koncentrowania się na rozwiązywaniu problemu i przyjrzeć się rozwiązaniom, które rozwiązują wiele powiązanych problemów.

Craig Bovis
źródło