Jak uniknąć przepisywania części aplikacji

Pracuję w firmie nad projektem dla ich działu sprzedaży. To moja pierwsza profesjonalna praca programistyczna, ale pisałam sama i uczę się od lat. Część projektu obejmuje pobranie niektórych danych i połączenie ich z danymi wejściowymi do produkcji i tworzenia wykresów. Następnie zapisz dane ... i tak dalej. Więc napisałem kod do tego w niecały dzień. Następnego dnia pokazałem mojemu opiekunowi projektu, który mu się spodobał, ale „co, gdybyśmy to mieli” i chciał, żebym dodał coś do wykresu. Nie była to ogromna zmiana w wyglądzie lub funkcji programu, ale drastycznie zmieniła to, jak musiałem przechowywać dane, przetwarzać je itp.

Ponownie zajęło mi około dnia przebudowanie tabeli bazy danych i przepisanie kodu w zasadzie od zera w celu obsługi tego nowego żądania. Ponownie mu to oddałem i stało się dokładnie to samo. Poprosił o coś innego, co drastycznie zmieniło sposób, w jaki potrzebowałem przetwarzać dane. Musiałem więc przepisać to jeszcze raz. W końcu się na to podpisał i mam nadzieję, że nie będę musiał go ponownie pisać.

Wyraźnie, nie wstydzę się swojego kierownika ani nic takiego. To świetny facet, a rzeczy, o które prosił, nie były nie z tego świata, były po prostu niezgodne z tym, co wcześniej zrobiłem.

Zastanawiam się tylko, czy mogę coś zrobić w przyszłości, aby uniknąć kompletnego przepisywania. Rozumiem tworzenie elastycznego kodu i starałem się to zrobić, ale chciałbym tylko wiedzieć o wszelkich praktykach lub rzeczach, które mogłem zrobić inaczej, aby było to łatwiejsze, więc w przyszłości nie spędzam 3 dni na czymś, co powinienem wziąć 1.

Jak skomentowałem, mam silne przeczucie, że wymagania nie były jasne za pierwszym razem lub prawdopodobnie przegapiłeś kilka ważnych szczegółów.

Nie wszystko można rozwiązać za pomocą lepszego kodu, najlepszych praktyk, wzorców projektowych lub zasad OOP. Żadna z nich nie uniemożliwi ponownego wykonania całej aplikacji, jeśli implementacja jest oparta na fałszywych założeniach lub błędnych przesłankach.

Nie spiesz się do kodowania rozwiązania. Przed wpisaniem pojedynczego LOC poświęć trochę czasu na wyjaśnienie wymagań. Im głębiej zagłębisz się w wymagania, tym bardziej, jeśli pojawią się pytania. Nie czekaj, aż Menedżer zaskoczy Cię kolejnym „ co-jeśli” . Przewiduj rzeczy sam. To małe ćwiczenie może znacznie zmniejszyć czynnik zaskoczenia .

Nie bój się pytać tyle razy, ile potrzebujesz. Czasami drzewa (szczegóły) nie pozwalają nam zobaczyć lasu (ogólny obraz). I to las, który musimy zobaczyć najpierw.

Gdy wymagania są jasne, łatwiej jest podejmować lepsze decyzje na etapie projektowania.

Na koniec pamiętaj, że ogólny obraz jest celem. Droga do tego celu nie jest ani prosta, ani prosta. Zmiany będą się nadal pojawiać, więc bądź zwinny.

Nie można tego wiedzieć na podstawie tego, co dałeś. Jest bardziej szybki i brudny, a tego właśnie potrzebujesz. Ale potem komuś się to spodobało i robi się coraz bardziej skomplikowane, więc teraz zaczynasz widzieć, że wiele problemów nie ujawnia się, dopóki nie pojawi się złożoność. Jest tak wiele różnych rzeczy, które można zrobić, to po prostu przytłaczające.

Jest stary „No Silver Bullet” i to prawda. Ponownie, nie ma sposobu, aby wiedzieć, co zrobić z pełnymi specyfikacjami (lub lepszymi bieżącymi specyfikacjami dla Agile) oraz umiejętnością korzystania z dobrych zasad programowania i dobrych projektów. Programiści uwielbiają przepisywać, w kółko . Nie twierdzę, że wpadasz w to koniecznie z tego powodu, że w tym momencie jest mały.

Skorzystaj z okazji, aby zastosować podstawowe zasady. Przekonasz się, że one działają, ale wtedy ktoś powie: „O nie, to źle” lub zrobisz coś innego, co lubisz. Nie możesz zrobić tego wszystkiego z pieniędzy firmy, ale jeśli dadzą ci czas na eksplorację, wykorzystaj to jako okazję. Zawsze jest ktoś, jakaś podstawa, ktoś, kto ma „najlepszy” sposób lub jakiś „nowy” sposób robienia rzeczy.

Twój menedżer najprawdopodobniej miał rację na każdym etapie, przez który przechodziłeś. Nie dlatego, że jest menedżerem, ale dlatego, że bierze pod uwagę wyniki i użyteczność oraz prawdopodobnie liczbę wcześniejszych kontaktów z klientami lub prośbami klientów.

Interfejs użytkownika jest trudny, zwykle 5 osób ma 15 różnych poglądów. A struktura danych i ich analiza oraz analiza danych mają tendencję do zmieniania tego mnożnika przez współczynnik 10 :). Interfejs użytkownika jest jak moda, niektóre kombinacje są fajne, niektóre są okropne lub brakuje im zdrowego rozsądku.

Nie wspominając, że na przykład podczas procesu LEAN nic nie jest osadzone w kamieniu. Doświadczasz czegoś w rodzaju oceny iteracyjnej i na każdym etapie jest trochę lepiej lub unika się złej ścieżki.

Tak prosta odpowiedź jest taka, że ​​nie ma w ogóle czegoś takiego jak przepisywanie.

Rozwój iteracyjny (który w zasadzie zrobiłeś, choć jednodniowe iteracje) jest często taki. Wczesne próby rozwiązania są często nie na miejscu, a dzięki zbieraniu informacji zwrotnych system staje się rozwiązaniem. Pożyczę rysunek 2.2 z materiału instruktorskiego Craiga Larmana do jego książki o stosowaniu UML i wzorach projektowych .

Na początku projektu uczysz się żyć z pozornie niestabilnymi wersjami. Nie zgadzam się z odpowiedziami, które mówią „musisz wcześniej uzyskać więcej wymagań”, ponieważ takie jest myślenie na podstawie Wodospadu. To prawda, że ​​powinieneś starać się uzyskać jak najwięcej pod względem wymagań, ale z wielu powodów nie można mieć pełnych i dokładnych wymagań.

Nie oznacza to, że nie możesz zmniejszyć ilości przepisywania po otrzymaniu opinii. Jedną z rzeczy, która często była prawdą, jest to, że interakcja oprogramowania człowiek-komputer prawdopodobnie bardzo się zmieni, ponieważ trudno jest to naprawić za pierwszym razem.

Pomyśl o Microsoft Word i tym, jak jego format danych (.doc) tak naprawdę nie ewoluował przez lata. Wynika to z faktu, że dokument tekstowy jako domena problemowa tak naprawdę nie ewoluował zbyt wiele (strona wciąż jest stroną, akapit nadal jest akapitem itp.). Jednak interfejs użytkownika programu Word ewoluował wiele (i nadal się rozwija). Kod prezentacji lub danych wejściowych bywa niestabilny między wersjami, więc najlepiej nie podłączać bezpośrednio innych części systemu (aby odizolować je przed przepisaniem).

Architektury oprogramowania, które mogą oddzielić prezentację od podstawowej logiki i danych o problemie, pozwalają na mniejszą liczbę ponownych zapisów. Wiele wzorców oprogramowania, takich jak separacja Model-View, powstało z powodu ludzi takich jak ty, którzy cierpieli z powodu wielokrotnych zapisów i szukali lepszego sposobu.

Może to zabrzmieć bardzo buddyjsko, ale masz szczęście, że poniósłeś te przeróbki! Tak wiele osób uczy się o wzorach MVC lub innych wzorach projektowych bez „cierpienia” koszmarów z ponownym pisaniem, których wzorce powinny unikać.

Nie mam odpowiedzi, a raczej ćwiczenia - takiego, które prawdopodobnie będziesz musiał zrobić we własnym czasie, chociaż w zależności od organizacji możesz uzyskać pozwolenie na zrobienie tego w godzinach pracy.

Przeprojektuj swoje pierwsze rozwiązanie, aby robić dokładnie to, co zrobiło, ale ułatw sobie dodawanie drugiego lub drugiego i trzeciego kroku. Nie dodawaj tych kroków, nie usuwaj ich. Po prostu stwórz rozwiązanie, które spełnia wszystkie pierwotne wymagania, ale można je łatwo zaktualizować o nową funkcję. Zrób to samo dla drugiego rozwiązania.

Wymagania się zmieniają, to fakt. Z perspektywy czasu: czy pierwsze rozwiązanie mogło być inne, więc całkowity czas programowania byłby krótszy? Właśnie tego uczysz się z doświadczeniem.

To pierwsza stroma krzywa uczenia się. Kiedy sobie z tym poradzisz, pojawi się drugie wyzwanie: Jak poradzić sobie ze zmienionymi wymaganiami, gdy użytkownicy przechowują dane z roku, których nie chcą wyrzucać?

Z twojej historii jasno wynika, że ​​wymagania i preferowane decyzje architektoniczne nie zostały wystarczająco dobrze przedstawione. Dlatego jeden z was, a może obaj, są złymi komunikatorami.

Może to być również architekt, ponieważ niektórzy architekci zdobywają wysoki status za dobre osiągnięcia podczas samodzielnego programowania lub świetną edukację (to też najczęściej chodzi o samodzielne studia) lub bycie pierwszym programistą w firmie (oczywiście sam) i są niekoniecznie dobry w komunikacji z zespołem. Często zdarza się, że skupiają się bardziej na programowaniu niż na dokumentowaniu projektów i wspieraniu zespołu.

Jednak również w tym przypadku możesz spróbować zrekompensować to, mówiąc dłużej, zadając pytania i robiąc notatki. Możesz nawet napisać małą specyfikację i poprosić architekta o jej zatwierdzenie.