Jak powinienem zaplanować i rozpocząć projekt?

Za każdym razem, gdy rozpoczynam projekt, w kluczowych momentach decyduję się całkowicie zmienić podstawowe klasy i dać się wciągnąć w niejasne błędy. Staram się planować z wyprzedzeniem i zwykle zaczynam na dobrej stopie, ale potem idę do niego następnego dnia i postanawiam, że chcę to zrobić „w inny sposób”.

Czy istnieje jakiś standard podczas rozpoczynania projektu, na przykład mapowania klas i rozpoczynania od testów jednostkowych? Jaka jest dobra konwencja podczas planowania i rozpoczynania średniego projektu.

Ostatnim rozpoczętym projektem był symulator ruchu pocisków - wiem, przewidywalny.

Podczas planowania nie planuj z wyprzedzeniem wszystkich możliwych elementów aplikacji. Planuj kroki dziecka. Jaka jest absolutna minimalna funkcjonalność, której potrzebujesz, aby zacząć korzystać z aplikacji? Zacznij tam.

Kiedy zaczynasz swój projekt, koduj tylko absolutną minimalną funkcjonalność. Kiedy go kodujesz, upewnij się, że piszesz dobry, czysty kod z inteligentną enkapsulacją . Pozwoli to zminimalizować błędy wynikające z późniejszych zmian.

Powtarzaj tę minimalną funkcjonalność, aż będziesz z niej zadowolony. Następnie zacznij dodawać nowe funkcje i rozszerzenia, pojedynczo. Ponownie skup się na pisaniu dobrego, czystego kodu z inteligentnym enkapsulacją.

Jeśli planujesz krok po kroku i piszesz czysty kod, zminimalizuje to liczbę zmian, których faktycznie potrzebujesz. Do czasu ukończenia pisania tej pierwszej funkcji powinieneś przyjąć wzorce, na których będzie opierać się podstawa aplikacji. Jeśli występują problemy z tą podstawą, kolejne funkcje powinny szybko ujawnić problem. Łatwiej będzie zobaczyć, jak integrują się elementy. Wprowadzane zmiany powinny w tym momencie powodować minimalne zakłócenia.

Wygląda na to, że twoje planowanie nie pomaga. Nie jest to niespodzianką, ponieważ nie masz wystarczającego doświadczenia, aby stworzyć realny plan. Rozwiązanie jest proste. Przestań tyle planować. Po prostu zaakceptuj, że będziesz pisać i przepisywać kod w trakcie pracy. W porządku, ponieważ kod jest darmowy, z wyjątkiem twojego czasu. Jeśli piszesz aplikację interfejsu użytkownika, po prostu zacznij od pustego okna i dodawaj po trochu, aż skończysz. Gdy masz więcej doświadczenia, Twoje projekty będą przebiegać szybciej. Martwienie się, ponieważ zmieniasz kod, jest jak student muzyki martwiący się wszystkimi notatkami zmarnowanymi w praktyce.

Nikt tak naprawdę nie wie, jaki będzie najlepszy projekt, dopóki nie zakoduje pewnej jego liczby. Dlatego sekretem dobrego projektu jest rozpoznanie, że twój pierwszy szkic jest nieuchronnie nieoptymalny, i planujesz przepisywać mniejsze fragmenty wcześniej i częściej . Zamiast usuwać prawie kompletny program, przepisuj wiersze, funkcje lub klasy, gdy tylko zauważysz ich braki.

Dobrzy doświadczeni programiści zwykle nie potrafią tego zrobić przy pierwszym szkicu. Z doświadczeniem wiąże się możliwość wcześniejszego rozpoznania złego projektu i szybsze przepisywanie.

Z mojego doświadczenia wynika, że ​​problem ten ustępuje, gdy masz więcej doświadczenia - czujesz, co działa, a co nie. Ponadto dobre kapsułkowanie może obniżyć koszty zmiany projektu. Im ściślej zamknięte są moduły, tym taniej będzie je później zmienić. Uznaj to za doskonałą motywację do oddzielenia zajęć.

http://nathanmarz.com/blog/suffering-oriented-programming.html

To rozwiązuje twój problem. Zaczął od upewnienia się, że oprogramowanie jest możliwe, prototypowania i tworzenia go. Następnie zaczyna brać kod i go rozbijać. Następnie optymalizuje to.

Istnieją dwa aspekty projektowania aplikacji. Pierwszym jest podjęcie decyzji, co może zrobić Twoja aplikacja. Drugi to projektowanie, jak to zrobić. Zmiany w tym, co robi, są dość znaczące i zależą od dojrzałości aplikacji (i zmiany kierunku aplikacji) najlepiej traktować ją jako przepisywanie, a nie przerabianie.

Drugi aspekt to jak. Korzystając z testów jednostkowych i zwinnych metod programowania, można zminimalizować wpływ zmiany sposobu wykonywania określonej funkcji przez refaktoryzację. Częścią uczenia się, jak wykorzystać te techniki, jest praktyka.

Daję radę, której udzielałem raz po raz. Wybierz projekt zwierzaka. Napisz to najlepiej, jak potrafisz. Naucz się czegoś nowego i zastosuj to, czego się nauczyłeś, aby poprawić podejście do rozwoju tego projektu.

Na przykład zacznij od listy rzeczy do zrobienia. Uprość to ... na początku nawet nie martw się o przechowywanie bazy danych. Po prostu uruchom to. Teraz zacznij budować na tym fundamencie. Może chcesz nauczyć się MVVM i WPF ... już wiesz, jak zaimplementować listę zadań do wykonania w pamięci, więc masz jeden problem do rozwiązania. Teraz chcesz, aby wielu użytkowników mogło załadować swoje listy rzeczy do zrobienia z bazy danych. Rozwiązałeś problem z pamięcią i oddzielną prezentacją, dzięki czemu możesz skupić się na dostępie do danych. Stamtąd możesz rozwinąć aplikację, aby uzyskać bardziej złożony model domeny (na przykład przejście z listy zadań do wykonania do rozwiązania do zarządzania projektami), interfejs internetowy, a nawet uruchomienie go na urządzeniu mobilnym. Kluczem do wykonania tej pracy jest wybranie czegoś, co możesz osiągnąć, z którym możesz oznaczyć postęp i z czasem możesz rosnąć.

Z mojego doświadczenia wynika, że ​​projektowanie systemu często trwa tak długo lub dłużej niż faktyczne kodowanie. Co powiesz na „planowanie z wyprzedzeniem”? Może idź do starej szkoły i zastosuj jedną ze sprawdzonych metod projektowania. Lub idź do starej szkoły i napisz pseudo kod przed napisaniem rzeczywistego kodu.

Myślę, że musisz zadać sobie pytanie, dlaczego zmieniasz rzeczy w kluczowych momentach, zamiast trzymać się pierwotnego planu. Czy pierwotny plan był wadliwy? A może miałeś wnikliwy moment, który pokazał lepszy sposób robienia rzeczy. Czy to rzeczywiście było lepsze czy po prostu inne?

Gdy zdobędziesz exp, będziesz musiał przepisywać / rysować i zacząć od nowa, rzadziej. Zapisz problem, który próbujesz rozwiązać. Zapisz niejasne opisy klas, które Twoim zdaniem będą Ci potrzebne, i opisz, jak będą musieli wchodzić w interakcje. Dowiedz się, jak wszystko będzie działać, a następnie kod. Nie trać czasu na zapisywanie każdej właściwości, metody zajęć. Na tym etapie próbujesz uzyskać widok 50 stóp stóp na to, co powinieneś zrobić. Gdy zaczniesz kodować, jeśli chcesz zapisać więcej szczegółów, idź do niego. Jeśli nie, po prostu zacznij kodować.

Powód, dla którego uważasz to za tak trudne, jest taki, że masz pomysł, ale tak naprawdę nie masz pełnego pojęcia, co chcesz zrobić. Jeśli wykonujesz własny projekt i nie masz klienta, który powiedziałby ci, czego chce, to od ciebie zależy, czy będziesz własnym klientem. Postaw się w sytuacji klienta i zacznij budować niemożliwą listę życzeń.

Innymi słowy, kiedy zaczynasz Nie projektuj NIC !!! .

Gdy będziesz mieć dużą listę rzeczy, które chcesz, aby system robił, ustal priorytetyzację wszystkiego i zdecyduj, jaka będzie minimalna funkcjonalność, aby uruchomić podstawowy system. Może to być pojedyncza podstawowa funkcja lub cały ekran, ale musi to być coś, co czujesz - jako klient - będzie wystarczająco przydatne do przetestowania.

Zatem lista życzeń funkcji + podstawowe priorytety = wymagania .

Kiedy już to wszystko zrobisz, zrób projekt na bardzo wysokim poziomie. Po prostu usiądź i zastanów się, czego twój system będzie potrzebował, aby uruchomić kilka pierwszych priorytetów. Zmień zdanie, jeśli chcesz, ale tutaj możesz poprawić kod lub konfigurację systemu, aby dowiedzieć się więcej o tym, co jest możliwe. Idź tylko wystarczająco daleko, aby zweryfikować swój podstawowy pomysł na projekt.

Tj .: TERAZ możesz zaspokoić potrzeby projektantów .

Po zakończeniu zaczniesz wdrażać swoje funkcje. Utwórz dla każdej funkcji podstawową specyfikację funkcjonalną. Może to być tak proste, jak zbiór instrukcji funkcji. Karty opowieści, jeśli chcesz. To pozwala ci nieco rozwinąć swój pomysł w głowie i stworzyć zestaw instrukcji, które staną się specyfikacją , na której będziesz testować i budować swoją implementację.

Płacz Havoc, wypuść psy ... Code !!

Następnie zaimplementuj testy zgodne ze specyfikacjami, a następnie dla każdego testu napisz kod. Buduj, „wypuszczaj”, a następnie powtarzaj z następną funkcją, aż zdecydujesz, że projekt jest wystarczająco kompletny.

To naprawdę sprowadza się do doświadczenia, ale to podejście, które znalazłem, jest prostą formułą, która pomaga skoncentrować umysł na tym, co należy zrobić, zamiast uwięzić się w niekończącym się cyklu zwlekania z powodu próby zrobienia zbyt wiele wszystkiego na pewnego razu.

Po zapoznaniu się z podstawami, takimi jak ustalenie celów projektów, uzyskanie listy wymagań i zablokowanie wszelkich interfejsów do systemów zewnętrznych.

Następnie musisz wykonać przypadek użycia lub „historię” dla każdej interakcji użytkownika. Napisano tomy na temat tego, co stanowi „dobry” przypadek użycia lub historię i istnieje wiele odmian. Przypadki użycia to jedno z najbardziej skutecznych narzędzi projektowania, z jakim się zetknąłem. Pomagają w wykryciu brakującej funkcjonalności w tym samym czasie, co eliminują zbędne wymagania i redukują projekt do jego zasadniczych elementów. Jak powiedziałem, metodologie są różne, ale większość praktyków zgadza się co do:

• zwięzły tekst w języku angielskim.
• „Kierowanie na bramkę” działa najlepiej, tzn. „Małpa dostaje winogrona” jest lepsza niż „Małpa naciska czerwony przycisk”.
• zakaz terminologii technicznej. Brak „pulldownów”, „pól tekstowych”. Dobry przypadek użycia powinien być niezależny od jakiejkolwiek technologii interfejsu. Powinieneś być w stanie wziąć przypadek użycia dla systemu opartego na HTML i użyć go dla systemu aktywowanego głosem bez żadnych zmian w samym przypadku użycia. (jest to bardzo trudne, ale warto!).
• Staraj się zmniejszyć liczbę słów w pierwszej wersji roboczej o 50%, pozbyć się niepotrzebnych kroków i słownictwa.

Następnie możesz określić swoje główne klasy:

UML - Universal Modeling Language. Jest standardowym narzędziem do projektowania klas. Określasz członków publicznych i metody każdej klasy i łączysz je ze sobą w przejrzysty, zwięzły model graficzny.

W połączeniu ze schematami sekwencji, modelami danych, możesz zweryfikować i ulepszyć swój projekt przed jakimkolwiek kodowaniem.

Skoncentruj się na wyniku, który chcesz uzyskać, i rozważ potencjalne korzyści wynikające z uczenia się / próbowania nowych wdrożeń, z ryzykiem zejścia drogą, która doprowadzi cię z powrotem do punktu wyjścia.

W przypadku, gdy trafisz z powrotem do kwadratu, wszystko nie zostanie stracone, ponieważ zdobyłeś doświadczenie.

Jeśli masz termin (wydawało się, że programujesz dla zabawy), jest to naprawdę trudne. Jeśli ciągle podążasz w jedną stronę, ryzykujesz używanie przestarzałych metod w miarę upływu czasu. Jeśli nieustannie podążasz w inną stronę, ryzykujesz konsekwencjami produkcji w wolniejszym tempie (zmiennie wolniejszym tempie, w zależności od wyników twoich przygód edukacyjnych).

Kiedyś płonęłam pracą, robiąc wszystko szybko z roku na rok, a potem pewnego dnia zdałam sobie sprawę, że w moim zestawie umiejętności przestałam działać.