Uruchamianie spójnej architektury w starszej aplikacji

Jestem odpowiedzialny za dużą stronę internetową opartą na Asp.Net. Obecnie jest to strona internetowa (nie aplikacja internetowa), niektóre usługi systemu Windows i wiele bibliotek klas.

Warstwa danych używa mieszanki LLBLGEN i Linq To LLBGen, a także szeregu starszych wersji wbudowanego SQL, które nie zostały ponownie przetworzone.

Istnieje kilka implementacji typu menedżera, ale w wielu przypadkach aplikacja wykazuje anty-wzorzec Smart UI (tj. Zbyt dużo logiki biznesowej w kodzie za klasami)

Witryna ma dość duży ruch, a wydajność jest w porządku, ale zwiększamy nasze możliwości rozwoju do zespołu około 10 osób i coraz bardziej oczywiste jest, że potrzebujemy nadrzędnego warstwowego projektu na bazie istniejącego oprogramowania pośredniego.

Moje pytanie brzmi: od czego zacząć? Mamy 10 lat kodu (niektóre z nich wciąż tak naprawdę migrowały z ASP Classic), wiele różnych podejść i stylów.

Refaktoryzacja całej bazy kodu nie jest realistyczna i prawdopodobnie nie jest pożądana

Wiem, że to nie jest nowa sytuacja, czy są jakieś użyteczne pomysły lub koncepcje, jak podejść do tego problemu?

Pracowałem również w podobnych sytuacjach i mogę udzielić następujących wskazówek.

1. Musisz zmniejszyć dług techniczny . Teraz. Czemu? Ponieważ dług techniczny jest jak dług finansowy. Zapłacisz za to odsetki.
2. Ponieważ refaktoryzacja całej bazy kodu jest niewykonalna, zadaj sobie pytanie: co temu zapobiega? Czy to po prostu za dużo pracy? Czemu?
3. Utwórz plan zmniejszenia zadłużenia technicznego w czasie. Na przykład, ustawiając reguły jako „ każdy fragment kodu, który dotknie zespół, musi zostać naprawiony / ponownie ustawiony na nowy standard ”. Zazwyczaj: testy jednostkowe muszą być napisane, kod musi zostać przeniesiony we właściwych warstwach itp. Pozwala to naprawić wiele kodów bez uciekania się do absurdalnie drogich i mało kosztownych projektów „refaktoryzacji”.
4. Zawiń gówno. Oddzielenie jest kluczem do refaktoryzacji i dobrej architektury. Jeśli potrafisz w jakiś sposób podzielić bazę kodu, możesz refaktoryzować mniejsze bity.
5. Nie zwiększaj dalej zadłużenia technologicznego. Nie zwiększaj dalej zadłużenia technologicznego. Nie zwiększaj dalej zadłużenia technologicznego. Nie rób...

Masz rację, że refaktoryzacja całej bazy kodu nie jest pożądana. Refaktoryzacja to czynność wykonywana przed nowym opracowaniem, aby usprawnić ten proces. Jeśli nie planujesz modyfikować całego kodu w bazie kodu, refaktoryzacja okaże się nieefektywnym wykorzystaniem czasu.

Kilka porad oprócz tego, co mówi Sklivvz:

1. Podziel kod na często modyfikowane sekcje. Tylko często modyfikowane sekcje muszą zostać w pełni wprowadzone do nowej architektury. Zintegruj rzadko modyfikowany kod z nową architekturą, używając jak najmniej zmian (lub żadnych zmian, jeśli możesz to zrobić). Oprzyj się pokusie pełnego przepisania, będzie to kosztować więcej, niż zyskasz na tym. Doceń, że istniejący kod działa, nawet jeśli jest brzydki.

2. Dowiedz się, jaki jest Twój cel refaktoryzacji. Czy chcesz ułatwić dostęp do treści na stronie? Czy masz dużo błędów i chcesz poprawić jakość postrzeganą przez użytkownika? Czy zamiast tego chcesz skrócić czas opracowywania funkcji? A może chcesz przede wszystkim lepszego UX? Twoja architektura powinna ułatwić refaktoryzację kodu, aby osiągnąć wyznaczone cele. Nigdy nie zapominaj, że głównym beneficjentem refaktoryzacji powinien być użytkownik / klient / firma. Czystszy kod sam w sobie nie jest celem, jest metodą do końca, a koniec wymaga użytkownika.

3. Spróbuj znaleźć jak najwięcej architektur referencyjnych i nie bój się ich kopiować. Nie wymyślaj koła ponownie. Jeśli ktoś ma architekturę, która działa dobrze dla witryn takich jak Twoja, ucz się od nich.

4. Pomyśl o stronie zarządzania ludźmi. W moich własnych projektach migracyjnych najtrudniejsze było zmuszenie ludzi do uczenia się nowych sposobów i trzymania się ich. Będziesz potrzebował implementacji referencyjnych i sposobu nauczania architektury dla wszystkich członków zespołu (zarówno starych, jak i nowych). Aby zmniejszyć opór przed zmianami, przed podjęciem decyzji poproś o opinię wszystkich członków zespołu. Upewnij się, że nowy projekt faktycznie poprawia rzeczy z osobistej perspektywy deweloperów i nie jest tak dużym skokiem, że czują się z głębi.

NAJWAŻNIEJSZĄ rzeczą, którą zobaczyłem, gdy próbowałem poradzić sobie ze starą bazą kodu, jest NIE zmienianie tego, do czego strzelasz. To znaczy, wymyśl swoją pożądaną architekturę, a następnie WYTRZYMAJ TEN PLAN! Jednym z dużych problemów, jakie miałem na mojej ostatniej pozycji, było to, że baza kodów miała kilka różnych pomysłów na to, jak powinna ona wyglądać z czasem. Za każdym razem, gdy próbowano nowego pomysłu, część kodu była konwertowana, niektóre nie, a potem ktoś miał „lepszy” pomysł. Z czasem stał się coraz bardziej niespójny i ostatecznie został złomowany.

Jest naprawdę ładna darmowa książka / pdf na temat ponownego projektowania starszego oprogramowania: http://scg.unibe.ch/download/oorp/

W tytule jest napisane OO, ale większość pomysłów dotyczy dowolnego oprogramowania. Omawia od czego zacząć, jak radzić sobie z różnymi częściami systemu podczas restrukturyzacji i wiele więcej z tych tematów.

Jeśli nie ma spójnej architektury, dzieje się tak, ponieważ kierownictwo nie rozumie / nie dba o problem. Po prostu koduj. Powinieneś wprowadzić nową dobrą architekturę podczas pisania nowego kodu.

Powinieneś ponownie zaprojektować rzeczy tylko wtedy, gdy zaczną mieć naprawdę poważne błędy, musisz je rozszerzyć i po prostu nie możesz, lub po prostu nie spełnia on swoich wymagań.

Mówię w zasadzie, że dbają tylko o sprawy, na których tak naprawdę dbają Twoi menedżerowie, a nie o te, na których mogliby się zwracać, gdyby mieli Twoją wiedzę.

Jeśli możesz sprzedać przebudowę do zarządzania, zacznij od testowania. Jeśli nie chcą inwestować w testowanie, twoje wysiłki przyniosą ci tylko kłopoty.