Jestem obecnie jedynym programistą / architektem dość dużej aplikacji internetowej (stos ASP.NET MVC, około 150 000 + linii kodu) i koniec rozwoju jest na horyzoncie. W związku z tym zaczynam myśleć o tym, co należy zrobić, aby przekazać projekt i chcę upewnić się, że robię to, co należy, dla każdego, kto będzie musiał utrzymać projekt w przyszłości.
O czym należy pamiętać, przygotowując się do przekazania projektu innemu deweloperowi lub zespołowi programistów konserwacji?
Odpowiedzi:
IMHO, jeśli mógłbyś zrobić tylko jedną rzecz przed przekazaniem swojego projektu (bezpośrednio lub pośrednio), zaleciłbym podwójne i potrójne sprawdzenie, czy kompiluje się od momentu kontroli źródła.
Nie śmieję się, ale nie mogę powiedzieć, ile razy otrzymałem „najnowszą” kontrolę źródła i nie udało się jej skompilować, ale później dowiedziałem się, że nie byłem „na starej skrzynce Freda”, ponieważ najwyraźniej kod „tylko kompiluje na starym pudełku Freda ". Miałem nawet byłego pracodawcę, który natychmiast usunął mój pulpit z mojej kostki i zastąpił go „starym pudełkiem Freda”, abym mógł pracować nad projektem, który miał być.
Jako rozszerzenie powyższej rekomendacji, ponieważ czasami uzyskanie najnowszych informacji nie jest konieczne do skompilowania aplikacji, zalecam utworzenie pliku README.txt i umieszczenie go w katalogu głównym aplikacji i przekazanie go kontroli źródła. Ten dokument README powinien zawierać listę zewnętrznych zależności, których nie można było wpisać do kontroli źródła (jeśli istnieją), jak skonfigurować bazę danych oraz wszelkie inne nieścisłości związane z cyklami kompilacji, wykonywania lub wdrażania aplikacji.
Cokolwiek powyżej i powyżej powyższych dwóch sugestii byłoby po prostu sos, ale IMHO powyższe dwa są prawie wymagane w każdym projekcie większym niż „Hello World”.
EDYTOWAĆ:
Na temat dokumentacji ...
Przez lata zarówno pisałem, jak i czytałem swoją uczciwą część dokumentacji oprogramowania w celu ułatwienia przejścia dewelopera. Powiedziałbym, że takie dokumenty rzadko są warte papieru, na którym są drukowane. Programiści (w tym ja) rzadko kiedy myślą o ważnych częściach aplikacji, pisząc takie dokumenty, zwykle myślimy tylko o najnowszych pożarach, z którymi walczyliśmy. Oprócz tego, że dokumenty te zwykle nie obejmują wszystkich ważnych aspektów oprogramowania, stają się również bardzo NIEaktualne bardzo szybko. Kiedy dokument jest nieaktualny, przyszły programista z dużym prawdopodobieństwem całkowicie go zignoruje, zamiast przywracać go do rzeczywistości (myśl zmieniające się wymagania).
Zamiast dokumentacji jako takiej, zalecam testy jednostkowe. Wiem, że w tym momencie prawdopodobnie wydaje się stary, ale pozwól, aby kod wykonał dokumentację za Ciebie. Testy uszkodzonych jednostek są trudne do zignorowania (i łatwiejsze do wykrycia) niż dokument Word. Ponadto język angielski jest okropnie nieprecyzyjny w wyrażaniu drobniejszych punktów projektowania oprogramowania. Jest po prostu zbyt wiele sposobów interpretacji znaczenia nawet najprostszych angielskich zdań, a to tylko prowadzi do zamieszania i / lub błędów.
readmepliku. Jeśli kod się skompiluje i uruchomi, wszystko jest ustawione.
Właśnie dlatego komentarze nie mają zapachu kodu. Dlatego też powinniśmy udokumentować nasz kod.
Powinieneś upewnić się, że masz solidną dokumentację. Istnieją programy, które mogą generować dokumentację na podstawie komentarzy w zależności od formatu komentarzy i języka programowania.
Zastanów się, jakie informacje chciałbyś uzyskać o bibliotece lub bazie kodu podczas przejęcia. Poproś znajomego, który jest programistą, o szybkie spojrzenie i sprawdzenie, czy zauważy jakieś oczywiste pytania.
Powodzenia!
Upewnij się, że kod jest kompilowany i pakowany w ostatecznej formie za pomocą jednego polecenia / kliknięcia.
Nie mogę głosować za odpowiedzą Na co należy zwrócić uwagę przygotowując się do oddania projektu? wystarczy, więc muszę to jeszcze raz zapisać.
Jestem bardzo wybredny w tej kompilacji za pomocą jednego kliknięcia , ponieważ poświęciłem już tyle czasu na zastanowienie się, jak właściwie skompilować lub spakować projekt, że musiałem naprawić tylko jeden mały błąd. Zacząłem umieszczać małe skrypty wsadowe / wsadowe w moich projektach, aby spakować końcowe ZIP, JAR lub EAR.
Oprócz tego dodaję plik README.txt do katalogu głównego, który opisuje ogólny projekt , złożone części i środowisko projektu (w zakresie komunikacji z innymi działami lub osobami).
Staram się, aby plik README.txt był mały , ponieważ nikt nie czyta ponad 200 stron dokumentów specyfikacji, jeśli wszystko, co chcesz zrobić, to naprawić błąd, skompilować go i spakować. Szczegóły implementacji są udokumentowane w testach jednostkowych , więc nie ma potrzeby zapisywania tego wszystkiego w książce ...
Moja domyślna lista kontrolna przekazania:
Jeśli coś jest zepsute, naprawię to przed przekazaniem. Nic nie powoduje, że ktoś zaczyna działać od momentu sprawdzenia projektu, zbudowania go i uruchomienia w dniu otrzymania projektu.