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

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?

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

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.

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.

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.

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.

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.

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.

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

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.