Jak faktycznie dowiedzieć się, co należy zrobić w projektowaniu obiektowym?

Najpierw zastrzeżenie: Naprawdę nie wiem, czy to pytanie pasuje do tej witryny, ale nadal uważam to za istotne pytanie nie tylko dla mnie, ale dla innych osób, które są początkujące. Jeśli pytanie można poprawić, aby pasowało tutaj, proszę zaznaczyć int komentarze. Jeśli to nie pasuje, daj mi również znać, a jeśli to możliwe, daj mi znać, gdzie można to omówić, ponieważ nie znalazłem żadnych dobrych forów na ten temat.

Nauczyłem się programować w 2009 roku, kiedy studiowałem PHP. Później w 2012 roku przeniosłem się do C # i .NET. W każdym razie kodowanie nie jest problemem, zapisywanie algorytmów nie jest moim problemem. Mój rzeczywisty problem polega na tym, aby wiedzieć, co należy zakodować, aby osiągnąć wymaganie, i gdzie należy go zakodować.

Większość kursów dostępnych w Internecie dotyczy tego, jak - jak pisać kod w określonym języku, jak korzystać z niektórych zestawów interfejsów API itp. Nie o to mi chodzi.

Przez te lata dużo czytałem o wielu rzeczach: analiza i projektowanie obiektowe, wzorce projektowe, projektowanie oparte na domenie i tak dalej. Rozumiem na przykład zasady SOLID, niektóre z głównych idei DDD, takie jak konieczność zaangażowania ekspertów w dziedzinie, rozwój wszechobecnego języka i tak dalej. Odważyłbym się powiedzieć, że mam przynajmniej teoretyczne podstawy.

Ale jeśli chodzi o praktykę, czuję się jak katastrofa. Jakiś czas temu musiałem kontynuować rozwój systemu finansowego, który był już opracowywany przez kogoś innego. Jest to rodzaj „starego systemu” opracowanego przy użyciu C # i WinForms. Po raz pierwszy wybrałem projekt o prawdziwej złożoności domen, z wieloma regułami biznesowymi i tak dalej.

Przyznaję, że kiedy otrzymuję wymagania przez większość czasu, myślę „jak, u licha, można to zrobić?” - Nie mam pojęcia, jak zacząć pracę nad wymaganiami, aby dowiedzieć się, co należy zrobić. Uważam, że moje główne nieporozumienia dotyczą tego, co muszę kodować, jakie klasy, interfejsy i gdzie idzie każda logika, na której klasie musi być każda rzecz. Problem polega na tym, że nie wiem od czego zacząć.

Przez większość czasu, z dość dużą ilością przemyśleń, kończę na kilku pomysłach, ale nigdy nie wiem, jak ocenić, czy mój pomysł jest poprawny, czy nie.

Mam na myśli, że nie sądzę, że to brak teorii, ponieważ powiedziałem, że przeczytałem o wielu rzeczach na temat architektury oprogramowania i orientacji obiektu, które mi zalecono, ale nie pomogło to w określeniu, co należy zrobić w praktyce .

W jaki sposób można nauczyć się naprawdę zrobić obiektowego projektowania? Chcę się nauczyć: podane wymagania wiedzą, jak rozpocząć pracę nad nimi w procesie, który prowadzi do ustalenia, co należy zrobić i gdzie należy każdy fragment kodu. Jak mogę nauczyć się oceniać, czy mój pomysł jest poprawny, czy nie?

Uważam, że pełne wyjaśnienie tego jako odpowiedzi tutaj nie byłoby możliwe. To, czego szukam, może być zgodne ze stylem strony, to odpowiedzi, które dają przegląd i wskazanie pewnych referencji (książek, kursów online itp.), Które można wykorzystać do rozwinięcia pomysłów i prawdziwej nauki tych rzeczy.

Jak mogę się nauczyć projektowania obiektowego? Chcę się nauczyć: podane wymagania wiedzą, jak rozpocząć pracę nad nimi w procesie, który prowadzi do ustalenia, co należy zrobić i gdzie należy każdy fragment kodu. Jak mogę nauczyć się oceniać, czy mój pomysł jest poprawny, czy nie?

Po pierwsze, przestań myśleć o projektowaniu obiektowym jako poprawnym. To tak, jakby myśleć o angielskim jako poprawnym.

Zorientowany obiektowo paradygmat jest nieprawidłowy. Ma pewne zalety i wady. To jest ideał. To nie jest nasz jedyny. To lepsze niż nic, ale na pewno nie wszystko.

Koduję od dziesięcioleci. Studiowałem te rzeczy prawie tak długo, jak istniały pomysły. Wciąż uczę się, co to znaczy. Eksperci wciąż uczą się, co to znaczy. Całe nasze pole ma mniej niż 100 lat.

Więc kiedy weźmiesz stos wymagań i okaże się, że kod je spełnia, a mimo to czujesz, że napisany kod to tragiczny bałagan, nie jesteś sam. Działający kod jest po prostu pierwszym krokiem do doskonałego kodu. Kod, który nie tylko działa, ale który inni mogą łatwo odczytać i zrozumieć. Kod, który można szybko dostosować, gdy zmieniają się wymagania. Kod, który sprawia, że ​​chcesz usiąść i powiedzieć „Wow, to takie proste”.

Problem polega na tym, że nie otrzymujemy zapłaty za to wszystko. Robimy to wszystko, ponieważ jesteśmy profesjonalistami. Musimy zrobić to wszystko, gdy szef nie patrzy, ponieważ zawsze jest termin. Ale chcemy wrócić za 5 lat i powiedzieć początkującym: „O tak, napisałem to. Nadal działa, prawda? Fajnie”.

Jak się tam dostałeś? Ćwiczyć. Nie akceptuj ŻADNEGO pomysłu na wiarę. Ktoś nie chce się zamykać na temat tego, jak projektowanie sterowane zdarzeniami uprości ten projekt? Nie jesteś pewien, czy mają rację? Zbuduj własny projekt zabawki w domu, który wykorzystuje wzorzec obserwatora. Bałagan z tym. Spróbuj znaleźć rzeczy, w których NIE pomaga.

Czytać. Pytanie. Test. Powtarzać.

Kiedy dojdziesz do tego, że robisz to przez 80% swojego życia, będziesz tak samo zdezorientowany jak ja.

Przyznaję, że kiedy otrzymuję wymagania przez większość czasu, myślę „jak, u licha, można to zrobić?” - Nie mam pojęcia, jak zacząć pracę nad wymaganiami, aby dowiedzieć się, co należy zrobić. Uważam, że moje główne nieporozumienia dotyczą tego, co muszę kodować, jakie klasy, interfejsy i gdzie idzie każda logika, na której klasie musi być każda rzecz. Problem polega na tym, że nie wiem od czego zacząć.

Czułam to samo. Potem odkryłem radość z refaktoryzacji. Chętnie dostosowuj projekty podczas pisania kodu. Trudnym sposobem jest wypracowanie wszystkiego na papierze. Napisz kod, który można udowodnić, że jest błędny, udowodnij, że jest błędny i napraw go.

Rozwój oprogramowania sprowadza się do dostarczenia działającego oprogramowania na czas, zgodnie z budżetem, przy jednoczesnym spełnieniu wszystkich kryteriów akceptacji. Zakładając, że udało ci się to zrobić, postrzegana jakość kodu lub jego struktury jest kwestią drugorzędną.

Problem polega oczywiście na tym, że pisanie nowego kodu Greenfield jest zwykle znacznie tańsze i łatwiejsze niż utrzymywanie starszego kodu, więc zamiast być zbytnio rozłączonym z jakością kodu lub architekturą, pamiętaj, że twoim prawdziwym problemem jest łatwość konserwacji.

Zazwyczaj kod uważa się za możliwy do utrzymania, gdy koszty, czas i ryzyko związane ze zmianą tego kodu są wystarczająco niskie, aby naprawianie błędów lub wprowadzanie zmian w wymaganiach było nadal opłacalne, a przez wdrożenie tych zmian nie utrwala się „spirali śmierci” „entropii kodu.

I odwrotnie, kod jest uważany za niemożliwy do utrzymania, gdy nie można z ufnością zmienić lub zrefaktoryzować bez poważnego ryzyka uszkodzenia lub poświęcenia nadmiernej ilości czasu / pieniędzy, aby upewnić się, że nic nie jest zepsute - tj. Gdy czas, koszty i ryzyko związane z pracą z tym kodem wynosi nieproporcjonalnie wysoki w porównaniu z korzyściami wynikającymi ze zmian (tj. pracodawca lub klient nie traci pieniędzy dodając nowe funkcje, naprawiając błędy itp.)

Pamiętaj, że nawet najbardziej diaboliczny bałagan spaghetti może być potencjalnie możliwy do utrzymania, jeśli masz wystarczająco dużo zapasów wokół bałaganu, aby uchronić się przed przełamywaniem zmian (chociaż takie przypadki są rzadkie). Problem z bałaganem spaghetti polega na tym, że ochrona przed przełamywaniem zmian jest zwykle dość droga i nieefektywna - zwłaszcza jeśli robisz to z mocą wsteczną.

Być może najbardziej niezawodnym sposobem na upewnienie się, że napisałeś możliwy do utrzymania kod, jest napisanie (tam, gdzie jest to racjonalnie możliwe) odpowiedniego zestawu automatycznych testów jednocześnie (przy jednoczesnym pełnym wykorzystaniu wszelkich innych dostępnych narzędzi analizy statycznej).

Nie musisz szczególnie przestrzegać ścisłej metodologii programistycznej, takiej jak TDD / BDD, aby uzyskać wystarczającą liczbę zautomatyzowanych testów umożliwiających dokonanie refaktoryzacji; potrzebujesz tylko tyle, aby zabezpieczyć kod przed przypadkowymi zmianami w przyszłości.

Jeśli Twój kod jest objęty automatycznymi testami, możesz zrelaksować się przy jego projektowaniu i strukturze, wiedząc, że jesteś objęty tymi testami; w późniejszym terminie możesz agresywnie zrefaktoryzować lub nawet wyrzucić go i zacząć od nowa.

To nasuwa pytanie, jak napisać łatwo testowalny kod; jest to zazwyczaj główny argument przemawiający za przestrzeganiem zasad SOLID; w rzeczywistości cechą kodową, która jest zgodna z zasadami SOLID, jest to, że pisanie testów jednostkowych jest łatwe i oszczędne czasowo / kosztowo.

Oczywiście czasami nie masz czasu na pisanie testów jednostkowych; jeśli jednak napisałeś cały kod, pamiętając o pytaniu „Jak napisać w tym celu automatyczne testy?” (nawet jeśli nie wdrożyłeś tych testów), prawdopodobnie udało ci się również znaleźć projekt, który można w rozsądny sposób utrzymać.