Jestem programistą z rocznym doświadczeniem, ostatnio zdałem sobie sprawę, że rzadko rozpoczynam projekt poprawnie (większość mojego pobocznego projektu), zwykle cykl projektu przebiega jak

1. Zacznij od kilku przypadków użycia
2. Zacznij kodować
3. Uświadom sobie kilka rzeczy, z którymi nie radziłem sobie dobrze i nie pasują dobrze do obecnej bazy kodu.
4. Przepisz większą część kodu

i to może potrwać kilka razy

Więc moje pytania są

1. Czy taka praktyka jest powszechna, czy sugeruje, że nie jestem kompetentna?
2. Jak mogę się poprawić w tym aspekcie?

Cykl, który opisujesz, jest normalny. Sposobem na poprawę rzeczy nie jest unikanie tego cyklu, ale usprawnienie go. Pierwszym krokiem jest zaakceptowanie, że:

1. Prawie niemożliwe jest wiedzieć wszystko pierwszego dnia projektu.
2. Nawet jeśli w jakiś sposób wiesz wszystko, do czasu ukończenia projektu coś (wymagania klienta, rynek, na którym działa, technologia, z którą pracujesz, życzenia klientów) ulegnie zmianie i nastąpi w przynajmniej część tego, co wiesz, że jest nieprawidłowe lub nieprawidłowe.

Dlatego niemożliwe jest zaplanowanie wszystkiego z góry, a nawet gdybyś mógł, przestrzeganie tego planu doprowadziłoby cię do zbudowania czegoś niedoskonałego lub przestarzałego. Wiedząc o tym, wprowadzamy zmiany do naszego planowania. Spójrzmy na twoje kroki:

1. Zacznij od kilku przypadków użycia
2. Zacznij kodować
3. Uświadom sobie kilka rzeczy, z którymi nie radziłem sobie dobrze i nie pasują dobrze do obecnej bazy kodu.
4. Przepisz większą część kodu

To właściwie świetny punkt wyjścia. Oto jak do tego podejdę:

1. Zacznij od kilku przypadków użycia

Dobry. Mówiąc „przypadki użycia”, jesteś koncentrując się na tym, co program jest dla . Mówiąc „kilka”, nie próbujesz wszystkiego odkryć; trzymasz się rozsądnej ilości pracy. Chciałbym tylko dodać im priorytety. Z klientem lub użytkownikiem końcowym opracuj odpowiedź na to pytanie:

Jakie jest najmniejsze, najprostsze oprogramowanie, które mogę ci dać, które poprawiłoby twoją sytuację?

To jest twój minimalny opłacalny produkt - cokolwiek mniejszego nie jest pomocne dla użytkownika, ale cokolwiek większego ryzykuje zbyt wczesne planowanie. Uzyskaj wystarczającą ilość informacji, aby to zbudować, a następnie przejdź dalej. Pamiętaj, że w tym momencie nie będziesz wiedział wszystkiego.

2. Rozpocznij kodowanie.

Wspaniały. Pracujesz jak najszybciej. Dopóki nie napiszesz kodu, Twoi klienci nie uzyskali żadnej korzyści. Im więcej czasu spędzasz na planowaniu, tym dłużej klient spędza na oczekiwaniu bez zwrotu.

Tutaj dodam przypomnienie, aby napisać dobry kod. Zapamiętaj i postępuj zgodnie z ZASADAMI SOLIDNYMI , pisz przyzwoite testy jednostkowe wokół wszystkiego, co kruche lub złożone, rób notatki na temat wszystkiego, o czym prawdopodobnie zapomnisz lub które mogą powodować problemy później. Chcesz uporządkować swój kod, aby zmiana nie powodowała problemów. Aby to zrobić, za każdym razem, gdy podejmujesz decyzję o budowaniu czegoś w ten sposób, zamiast w ten sposób, tak ustrukturyzuj swój kod, aby decyzja miała wpływ na jak najmniej kodu. Ogólnie dobrym sposobem na to jest oddzielenie kodu:

• używaj prostych, dyskretnych komponentów (w zależności od języka i sytuacji, ten komponent może być funkcją, klasą, zespołem, modułem, usługą itp. Możesz także mieć duży komponent zbudowany z mniejszych, takich jak klasa z dużą ilością funkcji lub zestaw z dużą ilością klas).
• każdy element wykonuje jedno zadanie lub zadania związane z jedną rzeczą
• zmiany w sposobie działania jednego komponentu nie powinny powodować zmiany innych komponentów
• Składniki powinny być podane rzeczy, które korzystają lub zależą zamiast pobierania lub tworząc je
• komponenty powinny przekazywać informacje innym komponentom i prosić je o wykonanie pracy, zamiast pobierania informacji i samodzielnego wykonywania pracy
• komponenty nie powinny uzyskiwać dostępu, używać ani zależeć od wewnętrznego działania innych komponentów - należy korzystać wyłącznie z ich publicznie dostępnych funkcji

W ten sposób izolujesz skutki zmiany, aby w większości przypadków naprawić problem w jednym miejscu, a reszta kodu nie zauważy.

3. Napotkać problemy lub niedociągnięcia w projekcie.

To się stanie. Jest to nieuniknione. Zaakceptuj to. Kiedy napotkasz jeden z tych problemów, zdecyduj, jaki to problem.

Niektóre problemy to problemy w kodzie lub projekcie, które utrudniają robienie tego, co oprogramowanie powinno robić. W przypadku tych problemów musisz cofnąć się i zmienić projekt, aby rozwiązać problem.

Niektóre problemy są spowodowane brakiem wystarczającej ilości informacji lub posiadaniem czegoś, o czym wcześniej nie pomyślałeś. W przypadku tych problemów musisz wrócić do użytkownika lub klienta i zapytać, w jaki sposób chcieliby rozwiązać problem. Po uzyskaniu odpowiedzi przejdź do projektu i zaktualizuj go, aby go obsłużyć.

W obu przypadkach powinieneś zwracać uwagę na to, które części kodu musiały się zmienić, a pisząc więcej kodu, powinieneś zastanowić się, które części mogą ulec zmianie w przyszłości. Ułatwia to ustalenie, które części mogą być zbyt powiązane, a które mogą wymagać większej izolacji.

4. Przepisz część kodu

Po ustaleniu, jak należy zmienić kod, możesz przejść i dokonać zmiany. Jeśli dobrze ustrukturyzowałeś swój kod, zwykle będzie to wymagało zmiany tylko jednego komponentu, ale w niektórych przypadkach może również wymagać dodania niektórych komponentów. Jeśli okaże się, że musisz zmienić wiele rzeczy w wielu miejscach, zastanów się, dlaczego tak jest. Czy możesz dodać komponent, który zachowuje cały ten kod w sobie, a następnie pozwolić, aby wszystkie te miejsca po prostu korzystały z tego komponentu? Jeśli możesz, zrób to, a następnym razem, gdy będziesz musiał zmienić tę funkcję, będziesz mógł to zrobić w jednym miejscu.

5. Test

Częstą przyczyną problemów w oprogramowaniu jest niewystarczająca znajomość wymagań. Często nie jest to wina programistów - często też użytkownik nie jest pewien, czego potrzebuje. Najłatwiejszym sposobem rozwiązania tego jest odwrócenie pytania. Zamiast pytać „do czego potrzebujesz oprogramowania?”, Za każdym razem, gdy wykonasz te kroki, daj użytkownikowi to, co zbudowałeś do tej pory i zapytaj: „Zbudowałem to - czy robi to, czego potrzebujesz?”. Jeśli powiedzą tak, zbudowałeś coś, co rozwiązuje ich problem i możesz przestać działać! Jeśli powiedzą „nie”, będą mogli powiedzieć bardziej konkretnie, co jest nie tak z twoim oprogramowaniem, i możesz udoskonalić tę konkretną rzecz i wrócić po więcej informacji.

6. Dowiedz się

Przechodząc przez ten cykl, zwróć uwagę na znalezione problemy i wprowadzane zmiany. Czy są jakieś wzory? Czy możesz poprawić?

Kilka przykładów:

• Jeśli nadal zauważasz, że przeoczyłeś punkt widzenia określonego użytkownika, czy możesz sprawić, by ten użytkownik był bardziej zaangażowany w fazę projektowania?
• Jeśli nadal musisz zmieniać rzeczy, aby były kompatybilne z technologią, czy możesz zbudować coś do interfejsu między twoim kodem a tą technologią, więc wystarczy zmienić interfejs?
• Jeśli użytkownik ciągle zmienia zdanie na temat słów, kolorów, zdjęć lub innych elementów interfejsu użytkownika, czy mógłbyś zbudować komponent, który zapewnia pozostałym aplikacjom je tak, aby wszystkie były w jednym miejscu?
• Jeśli okaże się, że wiele zmian dotyczy tego samego komponentu, czy jesteś pewien, że ten komponent trzyma się tylko jednego zadania? Czy mógłbyś podzielić go na kilka mniejszych kawałków? Czy możesz zmienić ten komponent bez dotykania innych?

Bądź zwinny

To, do czego zmierzasz, to styl pracy zwany zwinnym. Agile nie jest metodologią, to rodzina metodologii obejmująca cały ładunek rzeczy (Scrum, XP, Kanban, by wymienić tylko kilka), ale ich wspólną cechą jest pomysł, że rzeczy się zmieniają, a jako twórcy oprogramowania powinien planować dostosowanie się do zmian zamiast ich unikać lub ignorować. Niektóre z jego podstawowych zasad - w szczególności te, które odnoszą się do Twojej sytuacji - są następujące:

• Nie planuj dalej, niż możesz z pewnością przewidzieć
• Uwzględnij rzeczy, które mogą ulec zmianie w miarę upływu czasu
• Zamiast budować coś dużego za jednym razem, zbuduj coś małego, a następnie stopniowo go ulepszaj
• Zaangażuj użytkownika końcowego w proces i otrzymuj szybką, regularną informację zwrotną
• Sprawdź swoją pracę i postępy i ucz się na własnych błędach

To normalne.

Możesz zastosować jedno z dwóch podejść:

1. Witamy Zmień

Jeśli zakładasz, że się pomylisz, musisz zbudować bazę kodu, która jest otwarta na zmiany. Przeważnie wymaga to pobrania kodu na końcu książki o refaktoryzacji i zbudowania kodu w ten sposób od samego początku (rozkład, dobry zasięg testu, ...).

2. Unikaj zmian

W takim przypadku musisz wykonać BDUF (duży projekt z przodu). Musisz wykonać wiele papierowych prototypów, dyskutować pomysły z potencjalnymi użytkownikami lub sobą przez gumowe kaczątko, wypróbowywać różne rzeczy w prototypach lub makietach, spisywać pełną specyfikację, i dopiero gdy poczujesz, że wpadłeś na rozwiązanie, to w końcu może zacząć kodować. Robiąc wszystko, co tak naprawdę nie pozbywa się nieoczekiwanych zmian, po prostu trochę je zmniejsza, mniej więcej w pierwszym roku. Tak więc nadal musisz zbudować swój kod, aby łatwo go zmienić.

Zasadniczo zmiana jest dana. Załóż, że tak się stanie. Zbuduj odpowiednio swój kod. W praktyce można znaleźć środek między podejściami do projektowania i kodowania od samego początku, co pozwala uniknąć nieuzasadnionych zmian bez utknięcia w paraliżu analizy. To wymaga trochę doświadczenia.

Rozwój oprogramowania został opisany jako szereg z natury „nikczemnych” problemów .

Horst Rittel i Melvin Webber zdefiniowali „niegodziwy” problem jako taki, który można jednoznacznie zdefiniować jedynie poprzez jego rozwiązanie lub rozwiązanie jego części *. Ten paradoks implikuje, że trzeba „raz” rozwiązać problem, aby go jasno zdefiniować, a następnie rozwiązać ponownie, aby stworzyć rozwiązanie, które działa. Proces ten był macierzyństwem i szarlotką w rozwoju oprogramowania od dziesięcioleci

To doskonale opisuje problem, przed którym stoisz. Zasadniczo to , co robimy, jest trudne . Jeśli jest jakaś część, którą można opisać jako „rutynową”, z czasem ją izolujemy i automatyzujemy. Pozostało więc nowe albo trudne.

Istnieją inne sposoby rozwiązania takich problemów; niektórzy ludzie spędzają dużo czasu rozważając problemy z wyprzedzeniem i nie pisząc kodu, dopóki nie poczują się dobrze z projektem. Inni szukają wskazówek od osób, które już miały do ​​czynienia z takimi problemami, albo poprzez programowanie parami, albo po prostu takie strony.

Ale z pewnością twoje podejście nie sugeruje niekompetencji. Jedynym problemem może być to, że kiedy wracasz, nie zastanawiasz się, dlaczego na początku postanowiłeś robić rzeczy w ten sposób i czy byłbyś w stanie zobaczyć „lepszą” drogę bez przepisać.

W wielu przypadkach miało to miejsce i można je włączyć do procesu projektowania następnym razem. W niektórych przypadkach nie było (lub koszt byłby tak wysoki lub wyższy niż koszt twojego drugiego podejścia) i możesz po prostu odpuścić.

1. Tak, jest to powszechne, z wyjątkiem może części „przepisz większość kodu”. Nigdy nie spełnisz wszystkich wymagań od samego początku, dlatego ważne jest, aby dobrze radzić sobie ze zmianami. O to właśnie chodzi w koncepcji „utrzymania kodu”. Oczywiście pomaga również poświęcić trochę więcej czasu na dostosowanie wymagań i właściwego projektowania.
2. Najpierw zastanów się, jakie zmiany były wymagane w poprzednich projektach i jak mogłeś je przewidzieć lub lepiej się na nie przygotować. Na początku projektu zastanów się więcej o szczegółach przypadków użycia. Wykonaj jakiś abstrakcyjny projekt (jakie są główne elementy kodu i jak się komunikują, jakie są ich interfejsy API) przed rozpoczęciem implementacji. Co najważniejsze, staraj się, aby kod był tak prosty i łatwy do zmiany, jak to możliwe, przeczytaj o pojęciach takich jak SOLID, DRY, KISS i YAGNI.

Czy taka praktyka jest powszechna, czy sugeruje, że nie jestem kompetentna?

Nie wykluczają się one wzajemnie. Wzór może być powszechny, a ty nadal możesz być niekompetentny. Kompetencje można określić, mierząc wydajność w stosunku do wyznaczonych celów. Czy osiągasz swoje cele?

Czy ten wzór jest powszechny? Niestety tak. Wiele osób nurkuje w projektach, nie mając pojęcia, jaki problem rozwiązują, w jaki sposób opracują prawidłowe rozwiązanie i jakie mierniki będą stanowić sukces.

Jak mogę się poprawić w tym aspekcie?

Jeśli zdecydowałeś się gdzieś pójść i po prostu zacząłeś chodzić, a potem odkryłeś dzień, w którym tak naprawdę trzeba było przetransportować słonia z Kapsztadu do Nowego Jorku, cały czas spędzony na marszu był zmarnowany. Dowiedz się, co robisz, zanim zaczniesz to robić.

Kiedy zaczniesz to robić, zastanów się: jak zawsze wygląda kod, który nie musi być przepisywany ? Ten kod:

• Czy jedna przydatna rzecz.
• Czy to poprawnie
• Czy to z wystarczającą wydajnością.

Zatem: im więcej kodu piszesz, gdy kod ten robi jedną przydatną rzecz dobrze, poprawnie, z dobrą wydajnością, tym mniej kodu będziesz musiał kiedykolwiek przepisać.

Myślę, że można bezpiecznie powiedzieć, że nie jesteś tak daleko od lepszego sposobu pracy i nie jesteś jedyny w tej łodzi.

Myślę, że tęsknisz za tym, że chociaż określasz, czego chcesz, nie przestajesz robić tego samego procesu, w jaki sposób to zrobisz.

Ten krok polegający na zatrzymaniu się i zastanowieniu się, jak ogólnie rozwiązać ten problem, nazywa się projektowaniem. Jest to etap, który sprawia, że ​​spędzasz trochę czasu na rozwijaniu struktury lub architektury systemu, aby wszystko, co robisz z nich, przyczyniało się do ostatecznego rozwiązania, takiego jak dopasowywanie elementów do puzzli po opracowaniu krawędzi.

Wiele osób nie robi tego kroku, ale kiedy zacząłem kodować, było to obowiązkowe. Myślę, że różnica polega na narzędziach programistycznych - podczas gdy zacząłem od edytora tekstu, teraz masz wszystkie funkcje, które pozwalają ci wskoczyć i pisać.

Poświęć trochę czasu, aby dowiedzieć się, jakie są szerokie obszary, komponenty i interoperacyjność między nimi, oraz zdefiniować obiekty, które będą stanowić twoje rozwiązanie, zanim zaczniesz kodować. Nie musi to być zbyt szczegółowe i należy rozumieć, że na początku nie osiągniesz tego idealnie, więc będzie ewoluować z czasem, ale to pomoże ci nie marnować wysiłku na ponowne przeglądanie rzeczy, które nie powinny T trzeba wiele zmienić.

Masz już kilka świetnych odpowiedzi, ale twoje pytanie przywodzi na myśl kilka rzeczy, o których myślałem, że spróbuję się z nimi skontaktować.

1. Jak zauważyłeś, wpadając na zmiany w dalszej części drogi, sugeruję zastanowienie się nad tym, jak rzeczy wpłynęły na twój projekt i jak mogłeś zminimalizować wpływ dzięki wyborowi projektu / kodowania, jednocześnie generując mapę mentalną, w której ludzie często dokonują późnych zmian. Dzięki doświadczeniu możesz przewidywać i kodować z pewną elastycznością dla rzeczy, o których wiesz, że będą ważne - chociaż w branży istnieje rozbieżność co do tego, ponieważ niektórzy będą przeciwstawić się inwestowaniu wysiłku w obszar, który nie jest specjalnie wymagany, per se .

2. Jeden z frontów testowych, wypuszczenie prototypu dla interesariusza projektu może być świetnym sposobem na udoskonalenie wymagań. Jednak podczas programowania możesz szukać sposobów, aby „zobaczyć”, co dzieje się w kodzie bez powodowania zbyt dużego bałaganu lub złożoności. Z pewnością są dostępne narzędzia, które mogą pomóc, ale możesz też bez nich wiele zrobić, jeśli chcesz. Tak czy inaczej, wyjście z kodu w celu sprawdzenia, co dzieje się z krytycznym okiem, może zapewnić różne rodzaje wglądu.

3. Szukaj wspólnych działań. Przekonasz się, że ciągle rozwiązujesz te same problemy. Po chwili powinieneś odkryć niedociągnięcia lub kompromisy różnych wyborów i zająć się metodologią, która pomoże ci ich uniknąć. Oczywiście, jeśli pracujesz w środowisku, niektóre z tych problemów mogą być zamknięte w narzędziach, których już używasz.

4. Jeśli pracujesz w ramach, poświęć czas, jeśli możesz go poświęcić, aby zastanowić się, jak robić rzeczy od zera. Na przykład możesz łatwo złożyć komunikat żądania, otworzyć gniazdo i ręcznie wysłać żądanie GET lub POST. Jeśli chcesz, możesz ręcznie parsować wiadomości XML. Cokolwiek zrobisz, wygenerowane pytania i odpowiedzi, które znajdziesz, zwiększą Twoje umiejętności. Oczywiście możesz wybrać, które rodzaje podstawowych problemów są ważne lub interesujące. Rozważałbym ten rozwój osobisty i nie spodziewałbym się, że spędzę tu dużo czasu.

5. Srebrne kule, metodologie i problemy z wysokim współczynnikiem szumu są wszędzie. Zasadniczo rzeczywistość pracy z informacjami nie zmienia się tak szybko. Zwróć uwagę na to, czy obowiązujące ramy, zestaw narzędzi lub metodologia są pomocą czy przeszkodą w różnych sytuacjach. W dużych firmach widziałem wiele prób metodologii, chociaż firma nie była w stanie ich skutecznie wykonać. Podobnie jak ramy, metodologie nie są niezawodnym sposobem działania na wysokim poziomie, nawet jeśli są oparte na praktykach niektórych wysoce funkcjonalnych zespołów.

Trudno jest sprowadzić doświadczenie i mieć je dostępne. Myślę, że jednym ze sposobów, aby to wszystko ująć, jest mieć oczy otwarte, myśleć o tym, co widzisz i nigdy nie przestawać się uczyć.

Chciałbym dodać kilka wskazówek

1) Osobiście uznałem za niewiarygodne zacząć od wizualizacji rzeczy. Rysuj pola, strzałki, linie ... Nieważne, jakiego używasz języka modelowania. Po pierwsze, robisz to dla siebie. Powinno to pomóc w przepływie myśli.

2) Znajdź partnera sparingowego - weź kawę i flipchart / diagram itp. Z góry i dotrzyj do miasta. IMHO jest jeszcze lepiej, jeśli nie masz pasujących umiejętności technicznych. Odbijasz się w jedną i drugą stronę na pomysłach implementacji skrzynki. Znajdziesz ślepy zaułek lub dwa - znajdziesz rozwiązanie. Dzięki zwinnemu umysłowi na tym etapie często spędzasz mniej czasu niż na pisanie kodu, to nie działa i musisz zabijać fragmenty swojej pracy lub je przerabiać

3) Znajdź szefa, który może zrozumieć, że prawdopodobnie nigdy nie skończyłeś ulepszać pisanego oprogramowania. Jeśli zawsze podłączysz nowe funkcje / wymagania, które zostaną zrzucone na biurko i nigdy nie zatroszczysz się o swoje oprogramowanie, zaatakuje cię z błędami, nieprzyjazną konserwacją i dużą ilością włosów ciągnących kilka lat w dół. Zdobądź ten czas / budżet na utrzymanie oprogramowania! Dobra okrągła magiczna liczba to około 20% czasu potrzebnego na opracowanie oprogramowania potrzebnego rocznie, aby utrzymać go w formie przez cały okres jego użytkowania.

4) Ten proces przyrostowego uczenia się nigdy się nie kończy (i nie powinien)! Za 10 lat spojrzysz wstecz i uśmiechniesz się.

Mam nadzieję, że to trochę pomoże i powodzenia!