Ciągle przytłaczają mnie duże projekty, kiedy osiągają pewien poziom złożoności. Gdy osiągnę pewien punkt w projekcie, moje postępy zwalniają do pełzania i nieustannie śledzę moje kroki i rozwiązuję wszelkie zamieszanie.

Naprawdę dobrze sobie radzę z refaktoryzacją z powodu mojej słabości. I zawsze staram się rozkładać moje obiekty na mniejsze, łatwiejsze do zarządzania. Ta słabość prawdopodobnie spowodowała, że ​​zbyt wiele uwagi poświęciłem projektowaniu.

Wiem, że jeśli uda mi się rozdzielić moje problemy na mniejsze, będę w stanie bez problemu rozwiązać. Jedną ze strategii, która przychodzi na myśl, jest rozwój oparty na testach. Co jeszcze mogę zrobić?

przestań myśleć o kodzie

zacznij myśleć o warstwach, funkcjach, modułach, usługach i innych abstrakcjach wyższego poziomu

jesteś przytłoczony, ponieważ myślisz na zbyt niskim poziomie

Uproszczenie kompleksu jest łatwe ; poczekaj, pomyśl, że jest na odwrót.

Każdy ma z tym problem, nie ma prostego rozwiązania, które byłoby tak skuteczne.

Ponieważ nie wymieniłeś tego w swoich pytaniach, proponuję:

Skoncentruj się na spójności funkcjonalnej poprzez:

Zasada pojedynczej odpowiedzialności stanowi, że każdy przedmiot powinien mieć jedną odpowiedzialność i że odpowiedzialność powinna być całkowicie zamknięta w klasie. Wszystkie jego usługi powinny być ściśle dostosowane do tej odpowiedzialności.

Jeśli umieścisz go w Google wśród wyników na pierwszej stronie, znajdziesz dwa świetne zasoby:

• „ Zasada pojedynczej odpowiedzialności ” Roberta C. Martina (luty 2002): Zasada ta omawia potrzebę umieszczania rzeczy, które zmieniają się z różnych powodów w różnych klasach.
• „ Curly's Law: Do One Thing ” Jeffa Atwooda (marzec 2007): Zasada pojedynczej odpowiedzialności mówi, że klasa powinna mieć jeden i jedyny powód do zmiany.

Czym jest spójność w informatyce?

Spójność jest miarą tego, jak ściśle powiązane lub skoncentrowane są obowiązki jednego modułu. W przypadku programowania obiektowego, jeśli metody, które służą danej klasie, są podobne pod wieloma względami, mówi się, że klasa ma wysoką spójność. W bardzo spójnym systemie zwiększa się czytelność kodu i prawdopodobieństwo ponownego użycia, a złożoność jest utrzymywalna.

Spójność jest zmniejszana, jeśli : - Funkcje wbudowane w klasę, do których można uzyskać dostęp za pomocą jej metod, mają niewiele wspólnego. - Metody przeprowadzają wiele różnorodnych czynności, często wykorzystując gruboziarniste lub niepowiązane zestawy danych.

Wadami niskiej spójności (lub „słabej spójności”) są: - Zwiększone trudności w zrozumieniu modułów. - Zwiększona trudność w utrzymaniu systemu, ponieważ zmiany logiczne w domenie wpływają na wiele modułów i ponieważ zmiany w jednym module wymagają zmian w powiązanych modułach. - Zwiększona trudność w ponownym użyciu modułu, ponieważ większość aplikacji nie potrzebuje losowego zestawu operacji zapewnianych przez moduł.

Jeśli masz jakieś pytania, daj mi znać.

Rozłóż elementy na najmniejszy możliwy element. Na przykład pojedyncze pole w formularzu. Wybierz najbardziej ryzykowny lub o najwyższym priorytecie i idź naprzód, jakby to była prosta poprawka, a nie duży projekt. To prawda, że ​​później dokonasz refaktoryzacji, ale przynajmniej będziesz iść do przodu.

Z mojego doświadczenia odpowiedziałeś na swoje pytanie komentarzem na temat TDD. Dla mnie często czułem to samo co Ty, szybki sukces szybko przerodził się w drobne szczegóły, gdy system osiągnął określony rozmiar. Zauważyłem, że z TDD pomogło, ponieważ możesz poradzić sobie z każdą częścią systemu jako małe porcje, wiedząc, że reszta systemu będzie lub powinna nadal działać, tak jak ją opuściłeś. Myślę też, że dzięki TDD pomaga upewnić się, że twój system jest wyraźnie podzielony na mniejsze części, które można niezależnie przetestować.

Niektóre osoby są dobre w projektowaniu modułowych, łatwo zrozumiałych programów, ale większości programistów brakuje tej możliwości, w mniejszym lub większym stopniu. Wiem, że nie znam żadnej książki, procedury ani praktyki, które mogłyby zmienić jednego z pierwszych programistów w drugi, z wyjątkiem być może dużego doświadczenia. Ale nawet nie jestem tego pewien.

Najważniejsze jest to, że większość programistów będzie miała trudności z wzniesieniem się ponad przeciętną, niektórym uda się być w porządku (to miejsce, w którym umieściłbym siebie i być może 50% profesjonalnych programistów z (powiedzmy) branży IB) i bardzo mała mniejszość będzie doskonała. Powinienem powiedzieć, że nigdy w mojej długiej karierze nie spotkałem jednego z tych doskonałych :-)

Myślę, że wiele osób próbuje nad-inżynierować rozwiązania. Przyjmują podejście „Adam i Ewa”, gdy tylko nieco bardziej praktyczne uprościłoby sprawy o wiele.

Specjalistyczne klasy nie są złe, są naturalną konsekwencją dźwiękowego projektowania oprogramowania.

Moim zdaniem wielu programistów nie rozumie tego i nie znam żadnej książki, która by to wyjaśniała.

Inną rzeczą, która z pewnością pomaga, jest TDD, która pozwala zrozumieć „w jaki sposób” będziesz korzystać z zajęć w praktyce i może w wielu przypadkach uratować dzień, ponieważ pokazuje ewentualne problemy / ograniczenia na początku dnia.

Na koniec, kolejną BARDZO ważną rzeczą, której bym szukał, gdybym był tobą, są wzory. Wzorce projektowe to sposób, w jaki ludzie mądrzejsi od ciebie lub mnie rozwiązują problemy programistyczne. Pomysł na wzorce, zgadnij co ?, polega na tym, że nie można ich używać jako książek kucharskich, przepisów, które po prostu uderzasz tam, ale w zamyśleniu i przede wszystkim rozumiejąc domenę aplikacji.

Mądre użycie wzoru znacznie zmniejszy ilość szczegółów, którymi musisz zarządzać.

Dobra biblioteka wzorców projektowych zaprojektowana z myślą o twoich potrzebach okaże się bezcenna. Zobaczmy bardzo prosty przykład, aby umieścić rzeczy w kontekście:

wyobraź sobie, że masz formularz, w którym po naciśnięciu przycisku inne formularze muszą się zaktualizować. Jest to typowy wzorzec „obserwatora”. Masz podmiot i kilku obserwatorów, którzy rejestrują się w temacie. Dlaczego musisz wdrożyć interfejs? Możesz po prostu dodać metody, lub jeszcze lepiej, użyć interfejsu dla obserwatorów i ogólnej listy dla tematu. Teraz masz to, co najlepsze z obu światów: niezależność dla obserwatorów i brak bzdurnych rzeczy na ten temat.

Mam nadzieję, że ma to dla ciebie sens!

Andrea

Problem szybkości i czytelności deweloperów może pojawić się, gdy przeoczymy potrzebę abstrakcji. W niektórych dużych bazach kodu, nad którymi pracowałem, najczęstszym wrogiem była ogromna liczba wyspecjalizowanych klas, które mają bardzo podobne funkcje, które powodują wzdęcie kodu. Jeśli cofniemy się o krok i zrozumiemy wymagania jako całość, a nie części aplikacji, wówczas przyjdzie nam na myśl wiele abstrakcji.

Kilka prostych kroków, które mi pomogły

• Użyj analizatora podobieństwa (takiego jak Simian), aby znaleźć duplikaty bloków kodu w bazie kodu. Dużo zduplikowanego kodu oznacza mniej abstrakcji.
• Monitoruj rozmiar klas i metod, duże klasy i metody oznaczają, że niewielu usług lub kontrolerów staje się bogami.
• Obowiązkowe testy jednostkowe / integracyjne, dają pewność refaktoryzacji, a także działają jako specyfikacja.
• Co dwa tygodnie retrospektywa z firmą, aby dowiedzieć się, czy stosowane przez nią warunki techniczne / biznesowe / domeny znajdują odzwierciedlenie w nazwach klas. Pomaga to w zrozumieniu i uzyskaniu nazw dla kolekcji pierwszej klasy zamiast reprezentowania ich jako proste zestawy i listy. Niektóre abstrakcje, o których nigdy nie myśleliśmy, pojawią się również, gdy usiądziemy z ludźmi biznesu.