Jak uniknąć przepisywania części aplikacji

13

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.

SH7890
źródło
2
Jakiego paradygmatu programistycznego używasz? Proceduralne, obiektowe, funkcjonalne, inne?
Tulains Córdova,
2
Aby uniknąć przepisywania - rozłącz bazę danych i warstwę aplikacji. Nie jest to prosta koncepcja zastosowania do pisania kodu. Jest to złożona koncepcja, która sprawia, że ​​kod jest prosty i elastyczny.
StackOverFowl
6
Wygląda na to, że wymagania nie były jasne lub źle je zrozumiałeś. Żadna zasada ani najlepsza praktyka nie uchroni Cię przed ponownym uruchomieniem całej aplikacji, jeśli implementacja została wykonana na podstawie fałszywych założeń. Przed wpisaniem dół jednym LOC dobrze jest poprosić do wymagań „ co jeśli ... ” ... nie czekać na kierownika zaskakując was z nowym Co jeśli ... . Poświęcenie czasu na poszukiwanie luk funkcjonalnych również zmniejszy współczynnik zaskoczenia .
Laiv
3
Dependency Injection jest twoim przyjacielem. Google go i zobacz, jak zastosować go do swojego języka / ramy. Pozwoli ci to napisać o wiele bardziej modułowy kod, co powinno zmniejszyć ilość kodu, który należy przepisać, gdy zmienią się wymagania.
Eternal21
2
Chociaż może się wydawać, że wiele ponownych zapisów jest złą rzeczą, najważniejsze jest to, jak szybko można odpowiedzieć na żądania użytkowników końcowych. Chociaż zależy to od złożoności projektu, powiedziałbym, że 1 dzień to całkiem dobry czas realizacji - musisz robić coś dobrze! W rzeczywistości oprogramowanie, które widzi znaczące zmiany, jest dobrym znakiem - oznacza, że ​​jest użyteczne i ulepsza się. Oprogramowanie, które od lat nie było znacząco zmieniane, jest znacznie trudniejsze w utrzymaniu.
Justin

Odpowiedzi:

22

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.

Laiv
źródło
3
To. Ta odpowiedź jest najlepszym sposobem, w jaki można ją ująć. Spełnij te wymagania, zanim zrobisz absolutnie wszystko.
Rhys Johns
1
To dobra odpowiedź, ale mam dokuczliwe wrażenie, że istnieje lepszy sposób na uporządkowanie aplikacji, aby ułatwić dostosowanie się do tych żądań. Nie sądzę, aby jakakolwiek tak zwana „zasada”, która się pojawi, pomogłaby; rozwiązanie musi być specyficzne dla problemu. Bez dodatkowych informacji Twoja odpowiedź jest jedyna, która ma sens.
Frank Hileman,
Cóż, miałem silne przeczucie, że to właśnie ten problem skomentowałem, ponieważ dokładnie tak się stało z moimi początkowymi programami. Natychmiast przetłumaczyłem frazy na LOC lub moduły, a kiedy musiałem coś zmienić, było to dla mnie dość dramatyczne. Refaktoryzuj refaktor codziennie lub co tydzień. Nawet nie radzę sobie najlepiej z SoC, SPR, polimorfizmem ... Wiele konfliktów, które miałem ze zmianami, było spowodowanych przez mój wyciek z ogólnej wizji.
Laiv
2
Opierając się na tej odpowiedzi: Ważne jest również zwinne podejście do gromadzenia wymagań. Czasami ludzie dostają nowe pomysły lub pamiętają coś, o czym zapomnieli, gdy zobaczyli produkt. Mogą powiedzieć: „Wiem, że prosiłem o zbudowanie tego, ale nie o to mi chodziło” lub „Wiem, że o to prosiłem, ale teraz, kiedy to widzę, chcę czegoś innego”. Możesz zapobiec powodowaniu frustracji i przeróbek, tworząc szybki i brudny „Dowód koncepcji”. Może to być nawet makieta jak fałszywy wykres. Pomaga Twojemu klientowi myśleć.
Akhil
1
Niektórzy mogą argumentować, że wyodrębnienie bazy danych z kodu nie jest koniecznością, ponieważ „dostawcy bazy danych rzadko się zmieniają”. Zgadzam się z tobą, ale sedno mojej odpowiedzi brzmi: zbierając wymagania, zapomnij, że jesteś programistą. Skoncentruj się na zbieraniu wymagań. Myśl jak menedżer, pytaj jak menedżer. Nie spiesz się myśleć jak programista.
Laiv
4

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.

Jasio
źródło
Dobry artykuł, który podlinkowałeś.
SH7890
1
Rzeczywiście dobry artykuł! Myślę, że to nie przypadek OP, ale nie mogłem bardziej zgodzić się z autorem.
Laiv
1
Nie sądziłem, że to jeden na jednego, ale brzmiało to tak, jakby to był jeden dzień. Mam nadzieję, że pomoże to PO.
Johnny
2

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.

ipavlu
źródło
2

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 .

wprowadź opis zdjęcia tutaj

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ć.

Fuhrmanator
źródło
Wolałbym tę odpowiedź niż zaakceptowaną. Iteracja w kierunku rozwiązania jest lepsza niż próba ustawienia wszystkich wymagań z góry. Zwłaszcza jeśli cała aplikacja może zostać przepisana w ciągu jednego dnia.
Euforyczny
Jestem pewien, że szef nie wiedział, czego chcieli w drugiej iteracji, dopóki pierwsza nie została ukończona. „Wcześniejsze zgromadzenie większej ilości wymagań byłoby niemożliwe.
gnasher729,
1

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.

jmoreno
źródło
1

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ć?

gnasher729
źródło
-1

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.

h22
źródło