Jakie uwagi należy wziąć za i przeciw „super” stronom?

Moja firma rozważa konsolidację wszystkich aplikacji i witryn poziomu 1 (tj. Produkcji na najwyższym poziomie) w jedną kompleksową bazę kodu.

Teoria polega na tym, że ich uprawnienia, wygląd i ogólna funkcjonalność mogą być homogenizowane i centralnie zarządzane.

Nie mam końca obaw związanych z tym podejściem, ponieważ struktury danych leżące u podstaw każdej aplikacji są bardzo różne, reguły biznesowe są złożone i unikalne dla każdej aplikacji, a ogólne podstawy kodu dla istniejących aplikacji są bardzo zróżnicowane i bardzo zaniedbane.

EDYCJA :

Obecne środowisko składa się z trzech witryn ASP.Net 1.1, które ledwo dostrzegły prawdziwej miłości od momentu napisania (głównie z powodu braku doświadczonych programistów w firmie) oraz jednej aplikacji MVC2, która była również witryną ASP.Net 1.1, zanim została zaktualizowany w zeszłym roku. Piszemy wyłącznie w języku C #.

Firma jest dość mała, zatrudnia około 50 pracowników; z których trzech to prawdziwi programiści. Zarządzanie (nawet zarządzanie IT) nie ma żadnego zaplecza informatycznego ani doświadczenia innego niż zarządzanie projektami projektów IT (a zatem pewna wiedza na temat terminologii i wpływu na biznes).

Aplikacje są głównie usługami online do obsługi produktów sprzedawanych przez firmę. Firma nie sprzedaje bezpośrednio żadnego oprogramowania.

Sformułujmy więc całą tę sytuację za pomocą dość konkretnego i możliwego do odpowiedzi pytania: jakie są niektóre istotne powody przemawiające za i przeciw próbowaniu połączenia wszystkich systemów w jedno nadrzędne rozwiązanie, biorąc pod uwagę obecne warunki (tj. Stara baza kodu, złożone systemy biznesowe i reguły )?

Kiepski pomysł

Ta reakcja opiera się na następujących założeniach:

1. Istnieje wiele dość różnych aplikacji, które są homogenizowane
2. Istnieje wiele zespołów pracujących nad różnymi aplikacjami
3. Nie ma szanowanego i autorytatywnego architekta oprogramowania, który aktywnie zarządzałby aplikacjami

Co się stanie, jeśli pójdziesz dalej

Najprawdopodobniej zostanie podjęta początkowa skonsolidowana próba zebrania wszystkiego w jednym podejściu projektowym. To pokaże ogromny wysiłek potrzebny do tego, aby wszystko działało tak samo i może stać się niemożliwe w praktyce.

Jeśli będzie naciskać, wówczas będzie wymagane jakieś scentralizowane repozytorium zawierające dane konfiguracyjne (np. Dostęp bezpieczeństwa, poziomy rejestrowania itp.), W którym to momencie ktoś wskaże oczywiste i powie

„Hej, dlaczego po prostu nie zmodernizujemy tego zewnętrznego podejścia do konfiguracji starych aplikacji, będzie to znacznie szybsze?”

a chwilę później ktoś inny się z nimi potoczy

„A ponieważ i tak dokonujemy refaktoryzacji, dlaczego po prostu nie zastosujemy standardu projektowania dla każdej domeny aplikacji - przetwarzanie w sieci wygląda tak, przetwarzanie reguł biznesowych w ten sposób i dostęp do bazy danych w ten sposób”.

aż w końcu

„Och, a tutaj jest wiele wspólnego kodu, dlaczego nie połączyć kilku łatwo udostępnianych bibliotek. Prawdopodobnie będziemy potrzebować jakiegoś rodzaju kompilacji integracyjnej uruchamianej w regularnych odstępach czasu, powiedzmy, każdej nocy.”

W tym momencie wszyscy odetchną z ulgą, że nie zbudowano ogromnego monolitu.

Pracowaliśmy nad tym w mojej firmie. Myślę, że jest to możliwe i istnieją oczywiste korzyści (wspomniałeś o nich), jednak prawdopodobnie będzie to projekt trwający od 5 do 7 lat przy absolutnym minimum i wymaga zasadniczo napisania wszystkiego od nowa. Jeśli możesz się wypisać na czymś takim, powiedziałbym, że idź. Jeśli nie, przygotuj się na koszmarny marsz śmierci.

Google to robi, więc na pewno jest to możliwe .

Ten link BTW to ciekawa prezentacja Googlera na temat zarządzania bazą kodu, ciągłej integracji, testowania itp.

Jednak bez podobnego zaangażowania w narzędzia, tak jak zrobiło to Google, prawdopodobnie znajdziesz się w świecie bólu.

Kluczowe pytanie tutaj brzmi: dlaczego ? Dlaczego kierownictwo wyższego szczebla chce to zrobić? Jakie oszczędności, dźwignię lub inną korzyść mają nadzieję uzyskać?

Jeśli potrafisz rozwiązać wystarczającą liczbę takich problemów, aby osiągnąć ich cele, możesz uniknąć pojedynczej bazy kodu, która Cię dotyczy, jednocześnie zapewniając im ten sam skuteczny wynik.

Przechodziliśmy podobny proces. Mieliśmy już jakiś produkt. W ubiegłym roku wprowadziliśmy kolejny produkt, który jest w 95% taki sam jak pierwszy, z 5% czasami subtelnych, ale znaczących różnic, przy czym różnice te muszą być opracowane i utrzymywane przez oddzielny zespół.

Kiedy zaczęliśmy pracę nad nowym produktem, stary zespół dokonywał zmian, które negatywnie wpłynęły na nas w tych 5%, ponieważ nie rozumieli nowego produktu. Całkowicie rozwinęliśmy ten 5% kodu, co umożliwiło nam ukończenie pierwszego wydania na czas.

Potem rozpoczęły się dalsze prace konserwacyjne i stwierdziliśmy, że często dokonujemy prawie identycznych zmian w prawie identycznym kodzie. Stary zespół lepiej rozumie teraz nowy produkt, dlatego stopniowo integrujemy to, co rozwinęliśmy, i znajdujemy bardziej efektywne architektoniczne sposoby wyrażania różnic.

Kiedy więc mówisz, że struktury danych są różne, a ogólne podstawy kodu są rozbieżne, zadałbym pytanie, czy muszą być w ten sposób, czy właśnie tak ewoluowały ze względu na odpowiedni moment. Oczywiście musisz wziąć pod uwagę różne reguły biznesowe i wymagania, ale kluczem jest izolowanie tych różnic w tak mały moduł, jak to możliwe. Jeśli często zdarza się, że wdrażasz dokładnie tę samą funkcję dla wielu klientów na nieco inne sposoby dla różnych baz kodu, konsolidacja może naprawdę pomóc i podejrzewam, że tak jest, a zarząd prawdopodobnie nie zaproponowałby tego.

Najprawdopodobniej nie będziesz w stanie skonsolidować wielu aplikacji w tej samej bazie kodu, ponieważ zajmie to sporo wysiłku, a dla starych, zaniedbanych programów może to być znacznie więcej pracy, niż początkowo oczekiwano.

To powiedziawszy, nie ma nic złego w tym, że wszystkie twoje aplikacje znajdują się w tym samym repozytorium kodów , gdzie każda aplikacja ma osobny obszar. Dzięki temu możesz np. Wygenerować dowolną dokumentację online dla całej bazy kodu w jednym spójnym widoku, co jest ogólnie rzeczą dobrą, ponieważ chcesz uzyskać jak największą widoczność.

Ci, którzy o tym decydują, powinni zdecydowanie rozważyć DLACZEGO chcą to zrobić i zastanowić się, ile pracy chcą spędzić na dotarciu na miejsce.

Jeśli jest jedna rzecz, która sprawia, że ​​rozwój przedsiębiorstwa jest tak nieefektywny i kosztowny, to złudzenie, że można stworzyć jeden system, który robi wszystko. Jeśli miałeś jednego właściciela produktu, który rozumie wszystkie szczegóły systemu i może podejmować wszystkie decyzje bez potrzeby tygodniowego spotkania, może to działać, ale nigdy nie widziałem, żeby tak się stało.

Zasadniczo lepiej będzie, jeśli potraktujesz to bardziej jak programowanie w Internecie - po prostu zbuduj własną aplikację, przyznając, że w praktyce nie masz kontroli nad niczym poza własnym kodem. Możesz uzyskać prawie całą spójność, jakiej prawdopodobnie potrzebujesz, dzięki OAuth i prostemu interfejsowi API dla ustawień użytkownika oraz odrobinie wspólnego CSS.

Jest to dość podobne do pierwotnego zamiaru SOA, ale jeśli nazwiesz to, po prostu skończysz z innym rodzajem dużego, ledwo działającego systemu, który próbuje zrobić wszystko.

Moje pierwsze myślenie jest takie, że byłaby to całkowita PITA dla wydawnictw.

Podział na porcje funkcjonalności, którą można zarządzać, jest znacznie bardziej rozsądny, choćby po to, aby uniknąć wszystkich warstw zarządzania i akceptacji.

Podział wspólnych elementów na komponenty / usługi i standaryzowanie w ten sposób byłoby znacznie łatwiejsze.

Możesz podejść do tego inaczej, korzystając z technologii integracji, takiej jak Deliverance, do tworzenia motywów we wszystkich aplikacjach internetowych w podobny sposób. Zasadniczo każda aplikacja jest nadal osobna; Deliverance wykorzystuje reguły XSLT do łączenia swoich wyników w statyczny szablon HTML, który projektujesz. Umożliwia to zastosowanie stosunkowo prostego statycznego motywu HTML / CSS do całego zestawu aplikacji przy minimalnym nieszczęściu.