Od wielu lat pracuję jako programista. Z mojego doświadczenia wynika, że projekty stają się bardziej złożone i niemożliwe do utrzymania, ponieważ coraz więcej programistów angażuje się w rozwój produktu.
Wydaje się, że oprogramowanie na pewnym etapie rozwoju ma tendencję do „hackier” i „hackier”, zwłaszcza gdy żaden z członków zespołu, który zdefiniował architekturę, nie pracuje już w firmie.
To frustrujące, że deweloper, który musi coś zmienić, ma trudności z uzyskaniem pełnego obrazu architektury. Dlatego istnieje tendencja do rozwiązywania problemów lub wprowadzania zmian w sposób, który działa w stosunku do oryginalnej architektury. Rezultatem jest kod, który staje się coraz bardziej złożony i jeszcze trudniejszy do zrozumienia.
Czy jest jakaś pomocna rada na temat tego, jak utrzymać kod źródłowy w sposób umożliwiający jego utrzymanie przez lata?
Odpowiedzi:
Jedynym prawdziwym rozwiązaniem pozwalającym uniknąć zgnilizny kodu jest prawidłowe kodowanie!
Jak dobrze kodować to kolejne pytanie. Jest to wystarczająco trudne, nawet jeśli jesteś doskonałym programistą pracującym sam. W heterogenicznym zespole jest jeszcze trudniej. W projektach (pod) zlecanych na zewnątrz ... po prostu módlcie się.
Zwykłe dobre praktyki mogą pomóc:
źródło
Testy jednostkowe są twoim przyjacielem . Ich wdrożenie wymusza niskie sprzężenie. Oznacza to również, że „hacky” części programu można łatwo zidentyfikować i zreorganizować. Oznacza to również, że wszelkie zmiany można szybko przetestować, aby upewnić się, że nie psują istniejącej funkcjonalności. Powinno to zachęcić programistów do modyfikowania istniejących metod, a nie do powielania kodu z obawy przed uszkodzeniem.
Testy jednostkowe działają również jako dodatkowa dokumentacja twojego kodu, określając, co każda część powinna zrobić. Dzięki obszernym testom jednostkowym programiści nie powinni znać całej architektury programu, aby wprowadzać zmiany i korzystać z wychodzących klas / metod.
Jako miły efekt uboczny, testy jednostkowe również mają nadzieję zmniejszyć liczbę błędów.
źródło
Wszyscy tutaj szybko wspominają o zgniliznie kodu i całkowicie to rozumiem i zgadzam się z tym, ale nadal brakuje większego obrazu i większego problemu tutaj. Zgnilizna kodu nie tylko się zdarza. Ponadto wymieniono testy jednostkowe, które są dobre, ale tak naprawdę nie rozwiązują problemu. Można mieć dobry zasięg testu jednostkowego i stosunkowo wolny od błędów kod, jednak nadal ma on zepsuty kod i wygląd.
Wspomniałeś, że deweloper pracujący nad projektem ma trudności z wdrożeniem funkcji i brakuje szerszego obrazu ogólnej architektury, a tym samym wprowadza hack do systemu. Gdzie jest przywództwo techniczne w zakresie egzekwowania i wpływania na projekt? Gdzie są recenzje kodu w tym procesie?
W rzeczywistości nie cierpisz na zgniliznę kodu, ale cierpisz na zgniliznę drużyny . Faktem jest, że nie powinno mieć znaczenia, czy oryginalni twórcy oprogramowania nie należą już do zespołu. Jeśli kierownik techniczny istniejącego zespołu w pełni i naprawdę rozumie projekt i jest dobry w roli lidera technicznego, nie byłoby to problemem.
źródło
Jest kilka rzeczy, które możemy zrobić:
Prześlij jedną osobę ogólną odpowiedzialność za architekturę. Wybierając tę osobę, upewnij się, że ma wizję i umiejętności do opracowania i utrzymania architektury oraz że ma wpływ i autorytet, aby pomóc innym deweloperom podążać za architekturą. Ta osoba powinna być doświadczonym programistą, któremu ufa zarządzanie i któremu szanują rówieśnicy.
Utwórz kulturę, w której wszyscy programiści przejmą własność architektury. Wszyscy programiści muszą być zaangażowani w proces opracowywania i utrzymywania integralności architektonicznej.
Rozwiń środowisko, w którym decyzje architektoniczne są łatwo przekazywane. Zachęć ludzi do rozmowy na temat projektowania i architektury - nie tylko w kontekście bieżącego projektu, ale także ogólnie.
Najlepsze praktyki kodowania sprawiają, że architektura jest lepiej widoczna z kodu - poświęć trochę czasu na refaktoryzację, komentowanie kodu, opracowanie testów jednostkowych itp. Rzeczy takie jak konwencje nazewnictwa i czyste praktyki kodowania mogą bardzo pomóc w komunikacji architektury, więc jako zespół, którego potrzebujesz poświęcić czas na opracowanie i przestrzeganie własnych standardów.
Upewnij się, że cała niezbędna dokumentacja jest jasna, zwięzła, aktualna i dostępna. Upublicznij zarówno schematy architektury wysokiego, jak i niskiego poziomu (przypinanie ich do ściany może pomóc) i utrzymywać je publicznie.
Wreszcie (jako naturalny perfekcjonista) muszę uznać, że integralność architektoniczna jest godnym dążeniem, ale mogą istnieć ważniejsze rzeczy - na przykład zbudowanie zespołu, który może dobrze współpracować i faktycznie wysłać działający produkt.
źródło
Sposób, w jaki podchodzę do tego problemu, to wycinanie go w katalogu głównym:
Moje wyjaśnienie będzie używać terminów z Microsoft / .NET , ale będzie miało zastosowanie do dowolnej platformy / zestawu narzędzi:
źródło
Wyczyść zgniły kod poprzez refaktoryzację podczas pisania testów jednostkowych. Spłacaj (to) zadłużenie projektowe na całym dotkniętym kodzie, ilekroć:
Znacznie przyspiesz swój pierwszy cykl testowy poprzez:
Kod refaktoryzujący do zastosowania niskiego sprzężenia (jednostek o dużej spójności wewnętrznej) przez:
Wzrost organiczny jest dobry; duży projekt z przodu jest zły.
Miej lidera, który ma wiedzę na temat obecnego projektu. Jeśli nie, czytaj kod projektu, dopóki nie zdobędziesz wiedzy.
Przeczytaj książki o refaktoryzacji.
źródło
Prosta odpowiedź: nie możesz .
Dlatego powinieneś dążyć do pisania małego i prostego oprogramowania. To nie jest łatwe.
Jest to możliwe tylko wtedy, gdy myślisz wystarczająco długo o swoim pozornie złożonym problemie, aby zdefiniować go w możliwie najprostszy i zwięzły sposób.
Rozwiązanie naprawdę dużych i złożonych problemów można często rozwiązać, bazując na małych i prostych modułach.
Innymi słowy, jak zauważyli inni, kluczem są prostota i luźne połączenie.
Jeśli nie jest to możliwe lub wykonalne, prawdopodobnie prowadzisz badania (złożone problemy bez znanych prostych rozwiązań lub w ogóle nieznanych). Nie oczekuj, że dzięki badaniom bezpośrednio powstają produkty, które można utrzymać, nie po to są.
źródło
Pracuję na bazie kodu dla produktu, który jest w ciągłym rozwoju od 1999 roku, więc jak można sobie wyobrazić, jest on teraz dość złożony. Największym źródłem włamań w naszej bazie kodu jest to, że wiele razy musieliśmy przenosić go z ASP Classic na ASP.NET , z ADO na ADO.NET, z postbacków na Ajax , przełączania bibliotek UI, standardów kodowania itp.
Podsumowując, zrobiliśmy rozsądną robotę, utrzymując bazę kodu w utrzymaniu. Główne rzeczy, które zrobiliśmy, które się do tego przyczyniły:
1) Stałe refaktoryzacja - jeśli musisz dotknąć fragmentu kodu, który jest hackerski lub trudny do zrozumienia, oczekuje się, że poświęcisz dodatkowy czas na jego wyczyszczenie i będziesz mieć swobodę w tym zakresie. Testy jednostkowe sprawiają, że jest to o wiele mniej przerażające, ponieważ łatwiej można przetestować pod kątem regresji.
2) Utrzymuj porządek w środowisku programistycznym - bądź czujny, usuwając nieużywany kod i nie pozostawiaj kopii zapasowych / kopii roboczych / kodu eksperymentalnego w katalogu projektu.
3) Spójne standardy kodowania przez cały czas trwania projektu - Spójrzmy prawdzie w oczy, nasze poglądy na standardy kodowania ewoluują z czasem. Sugeruję trzymanie się standardu kodowania, który zacząłeś przez całe życie projektu, chyba że masz czas, aby cofnąć się i zmodernizować cały kod, aby był zgodny z nowym standardem. To wspaniale, że masz już notację węgierską , ale zastosuj tę lekcję do nowych projektów i nie przełączaj się tylko w połowie nowego projektu.
źródło
Ponieważ otagowałeś pytanie zarządzaniem projektami, próbowałem dodać punkty inne niż kodowe :)
Planuj obroty - zakładaj, że cały zespół programistów zniknie, zanim osiągnie fazę konserwacji - żaden programista warty swojej soli nie chce utknąć na utrzymaniu swojego systemu na zawsze. Zacznij przygotowywać materiały do przekazania, gdy tylko będziesz mieć czas.
Nie można wystarczająco podkreślić spójności / jednolitości. To zniechęci kulturę „idź sam” i zachęci nowych programistów, by zapytali, czy mają wątpliwości.
Pozostań w głównym nurcie - zastosowane technologie, wzorce projektowe i standardy - ponieważ nowy programista w zespole (na dowolnym poziomie) będzie miał większe szanse na szybkie uruchomienie i działanie.
Dokumentacja - zwłaszcza architektura - dlaczego podjęto decyzje i standardy kodowania. Zachowaj także referencje / notatki / mapy drogowe w dokumentacji domeny biznesowej - zdziwisz się, jak trudno firmom biznesowym wytłumaczyć, co robią deweloperowi bez doświadczenia w domenie.
Jasno określ zasady - nie tylko dla obecnego zespołu programistów, ale pomyśl o przyszłych programistach konserwacji. Jeśli oznacza to umieszczenie hiperłącza do odpowiedniego projektu i standardowej dokumentacji na każdej stronie, niech tak będzie.
Upewnij się, że architektura, a zwłaszcza warstwy kodu, są wyraźnie rozgraniczone i oddzielone - potencjalnie pozwoli to na zastąpienie warstw kodu w miarę pojawiania się nowych technologii, na przykład zastąpienie interfejsu Web Forms interfejsem jQuery HTML5 itp., Co może kup około roku na dłuższą żywotność.
źródło
Jedną z właściwości wysoce możliwego do utrzymania kodu jest czystość funkcji .
Czystość oznacza, że funkcje powinny zwracać ten sam wynik dla tych samych argumentów. Oznacza to, że nie powinny zależeć od skutków ubocznych innych funkcji. Ponadto przydaje się, jeśli same nie wywołują skutków ubocznych.
Ta właściwość jest łatwiejsza do zaobserwowania niż właściwości sprzęgania / kohezji. Nie musisz się starać, aby to osiągnąć, a ja osobiście uważam to za bardziej wartościowe.
Gdy twoja funkcja jest czysta, jej typ sam w sobie jest bardzo dobrą dokumentacją. Ponadto pisanie i czytanie dokumentacji pod względem argumentów / zwracanych wartości jest znacznie łatwiejsze niż wspominanie o jakimś stanie globalnym (możliwe, że są dostępne inne wątki O_O).
Jako przykład szerokiego używania czystości w celu ułatwienia konserwacji, możesz zobaczyć GHC . Jest to duży projekt mający około 20 lat, w którym dokonuje się dużych refaktoryzacji i wciąż wprowadzane są nowe ważne funkcje.
Wreszcie, nie podoba mi się punkt „Uprość to”. Nie możesz uprościć programu podczas modelowania skomplikowanych rzeczy. Spróbuj stworzyć prosty kompilator, a wygenerowany kod prawdopodobnie skończy się powolnym działaniem. Oczywiście, możesz (i powinieneś) uprościć poszczególne funkcje, ale w rezultacie cały program nie będzie prosty.
źródło
Oprócz innych odpowiedzi polecam warstwy. Nie za dużo, ale wystarczająco, aby oddzielić różne typy kodu.
Używamy wewnętrznego modelu API dla większości aplikacji. Istnieje wewnętrzny interfejs API, który łączy się z bazą danych. Następnie warstwa interfejsu użytkownika . Różne osoby mogą pracować na każdym poziomie bez zakłócania działania innych aplikacji.
Innym podejściem jest zachęcenie wszystkich do czytania ryzyk comp.risks i The Daily WTF, aby mogli dowiedzieć się o konsekwencjach złego projektu i złego programowania, i będą się bać, widząc swój własny kod opublikowany na The Daily WTF .
źródło
Ponieważ wiele z tych odpowiedzi wydaje się koncentrować na dużych zespołach, nawet od samego początku, zamierzam przedstawić swój pogląd jako część dwuosobowego zespołu programistów (trzech, jeśli włączysz projektanta) na starcie.
Oczywiście najlepsze są proste projekty i rozwiązania, ale kiedy masz faceta, który dosłownie wypłaca ci pensję, oddychając ci za szyję, niekoniecznie masz czas, aby pomyśleć o najbardziej eleganckim, prostym i łatwym do utrzymania rozwiązaniu. Mając to na uwadze, moim pierwszym ważnym punktem jest:
Dokumentacja Nie komentarze, kod powinien być w większości samodokumentujący, ale takie rzeczy jak dokumenty projektowe, hierarchie klas i zależności, paradygmaty architektoniczne itp. Wszystko, co pomaga nowemu lub nawet istniejącemu programistowi zrozumieć bazę kodu. Pomocne może być także udokumentowanie tych nieparzystych pseudobibliotek, które w końcu się wyskakują, np. „Dodaj tę klasę do elementu tej funkcji”, ponieważ uniemożliwia to również ponowne zapisywanie funkcji.
Jednak nawet jeśli masz ograniczony termin, uważam, że kolejną dobrą rzeczą do zapamiętania jest:
Unikaj włamań i szybkich poprawek. O ile szybka poprawka nie jest faktyczną poprawką, zawsze lepiej jest znaleźć rozwiązanie problemu, a następnie naprawić. Jeśli nie masz dosłownie scenariusza „zacznij działać w ciągu następnych 2 minut lub zostaniesz zwolniony”, poprawka jest teraz lepszym pomysłem, ponieważ nie zamierzasz naprawiać kodu później, po prostu przejdź do następnego zadania, które masz.
Moja ulubiona wskazówka to raczej cytat, choć nie pamiętam źródła:
„Koduj tak, jakby osoba, która Cię ścigała, była morderczym psychopatą, który wie, gdzie mieszkasz”
źródło
/** Gets the available times of a clinic practitioner on a specific date. **/
lub/** Represents a clinic practitioner. **/
.Jedną z zasad, o której nie wspomniano, ale którą uważam za ważną, jest zasada otwarta / zamknięta .
Nie należy modyfikować kodu, który został opracowany i przetestowany: każdy taki fragment kodu jest zapieczętowany. Zamiast tego rozszerz istniejące klasy za pomocą podklas lub użyj ich do pisania opakowań, klas dekoratorów lub przy użyciu dowolnego wzorca, który uważasz za odpowiedni. Ale nie zmieniaj działającego kodu .
Tylko moje 2 centy.
źródło
Bądź zwiadowcą . Zawsze zostawiaj kod czystszy, niż go znalazłeś.
Napraw uszkodzone okna . Wszystkie te komentarze „zmiana w wersji 2.0”, gdy jesteś w wersji 3.0.
W przypadku poważnych włamań, zaprojektuj lepsze rozwiązanie jako zespół i zrób to. Jeśli nie możesz naprawić włamania jako zespołu, to nie rozumiesz wystarczająco dobrze systemu. „Poproś dorosłego o pomoc”. Najstarsi ludzie w okolicy mogli to wcześniej widzieć. Spróbuj narysować lub wyodrębnić schemat systemu. Spróbuj narysować lub wyodrębnić przypadki użycia, które są szczególnie hackerskie jako diagramy interakcji. To nie naprawia tego, ale przynajmniej możesz to zobaczyć.
Jakie założenia nie są już prawdą, które popchnęły projekt w określonym kierunku? Za tym bałaganem może kryć się małe refaktoryzacja.
Jeśli wyjaśnisz, jak działa system (nawet tylko jeden przypadek użycia) i okaże się, że musisz przepraszać podsystem w kółko, to jest problem. Jakie zachowanie uprościłoby resztę systemu (bez względu na to, jak trudne jest wdrożenie w porównaniu z tym, co tam jest). Klasyczny podsystem do przepisania to taki, który zanieczyszcza każdy inny podsystem swoją semantyką operacyjną i implementacją. „Och, musisz zebrać wartości, zanim podasz je do podsystemu„ froo ”, a następnie ponownie je odszyfrujesz, gdy uzyskasz dane wyjściowe z froo. Może wszystkie wartości powinny zostać odczytane, gdy zostaną odczytane przez użytkownika i pamięć, a reszta systemu jest nieprawidłowa? Staje się to bardziej ekscytujące, gdy istnieją dwa lub więcej różnych problemów.
Spędź tydzień jako zespół usuwając ostrzeżenia, aby widoczne były prawdziwe problemy.
Ponownie sformatuj cały kod do standardu kodowania.
Upewnij się, że system kontroli wersji jest powiązany z twoim modułem do śledzenia błędów. Oznacza to, że przyszłe zmiany są miłe i możliwe do rozliczenia, i możesz wypracować DLACZEGO.
Zrób trochę archeologii. Znajdź oryginalne dokumenty projektowe i przejrzyj je. Mogą znajdować się na starym komputerze w rogu biura, w opuszczonej przestrzeni biurowej lub w szafce na dokumenty, której nikt nigdy nie otwiera.
Opublikuj ponownie dokumenty projektowe na wiki. Pomaga to zinstytucjonalizować wiedzę.
Napisz procedury podobne do list kontrolnych dla wydań i kompilacji. To powstrzymuje ludzi od myślenia, dzięki czemu mogą skoncentrować się na rozwiązywaniu problemów. Automatyzuj kompilacje tam, gdzie to możliwe.
Spróbuj ciągłej integracji . Im szybciej kompilacja się nie powiedzie, tym mniej czasu projekt może poświęcić na szyny.
Jeśli lider zespołu nie robi tych rzeczy, to źle dla firmy.
Postaraj się, aby cały nowy kod uzyskał prawidłowe testy jednostkowe ze zmierzonym zasięgiem. Tak więc problem nie może się znacznie pogorszyć.
Spróbuj przeprowadzić test jednostkowy niektórych starych bitów, które nie są testowane jednostkowo. Pomaga to zmniejszyć strach przed zmianą.
Zautomatyzuj test integracji i regresji, jeśli możesz. Przynajmniej mieć listę kontrolną. Piloci są sprytni i zarabiają dużo, korzystają z list kontrolnych. Spieprzają też dość rzadko.
źródło
Przeczytaj, a następnie ponownie przeczytaj Kod ukończony przez Steve'a McConnella. To jest jak biblia dobrego pisania oprogramowania, od wstępnego projektu do pojedynczej linii kodu i wszystkiego pomiędzy. Najbardziej podoba mi się to, że jest on poparty dziesięcioleciami solidnych danych; to nie tylko kolejny najlepszy styl kodowania.
źródło
Nazywam to „efektem tajemniczego domu Winchester”. Podobnie jak dom, zaczął się dość prosto, ale z biegiem lat wielu różnych pracowników dodało tak wiele dziwnych funkcji bez ogólnego planu, że nikt tak naprawdę go nie rozumie. Dlaczego te schody prowadzą donikąd i dlaczego te drzwi otwierają się tylko w jedną stronę? Kto wie?
Sposobem ograniczenia tego efektu jest rozpoczęcie od dobrego projektu, który jest wykonany tam, gdzie jest wystarczająco elastyczny, aby poradzić sobie z rozszerzeniem. Zaproponowano już kilka sugestii na ten temat.
Ale często podejmujesz pracę, w której szkody już zostały wyrządzone, a jest już za późno na dobry projekt bez wykonywania kosztownej i potencjalnie ryzykownej przeprojektowania i przepisania. W takich sytuacjach najlepiej jest znaleźć sposób na ograniczenie chaosu, jednocześnie do pewnego stopnia go obejmując. Może to drażnić twoją wrażliwość projektową, że wszystko musi przejść przez ogromną, brzydką, singletonową klasę „manager” lub warstwa dostępu do danych jest ściśle związana z interfejsem użytkownika, ale naucz się sobie z tym radzić. Koduj defensywnie w tych ramach i staraj się spodziewać nieoczekiwanego pojawienia się „duchów” programistów z przeszłości.
źródło
Refaktoryzacja kodu i testy jednostkowe są całkowicie w porządku. Ale ponieważ ten długo działający projekt wkracza do hacków, oznacza to, że kierownictwo nie kładzie nóg, aby oczyścić zgniliznę. Zespół jest zobowiązany do wprowadzenia hacków, ponieważ ktoś nie przeznacza wystarczających zasobów na szkolenie ludzi i analizowanie problemu / żądania.
Utrzymanie długoterminowego projektu jest tak samo obowiązkiem kierownika projektu, jak indywidualnego programisty.
Ludzie nie wprowadzają hacków, ponieważ im się podoba; są zmuszeni przez okoliczności.
źródło
Chcę tylko postawić kwestię nietechniczną i (być może) pragmatyczne podejście.
Jeśli menedżerowi nie zależy na jakości technicznej (zarządzalny kod, prosta architektura, niezawodna infrastruktura itp.), Trudno jest ulepszyć projekt. W takim przypadku konieczne jest wykształcenie wspomnianego menedżera i przekonanie do „zainwestowania” wysiłków w utrzymanie i rozwiązywanie problemów technicznych .
Jeśli marzysz o jakości kodu znalezionej w tych książkach, potrzebujesz również szefa, który się tym martwi.
A jeśli chcesz oswoić „projekt Frankensteina”, oto moje wskazówki:
Z mojego doświadczenia wynika, że programowanie jest raczej entropijne niż wschodzące (przynajmniej w popularnym paradygmacie o strukturze imperatywnej). Kiedy ludzie piszą kod „po prostu działają”, ma tendencję do utraty organizacji. Teraz porządkowanie kodu wymaga czasu, czasem znacznie więcej niż sprawienie, by działało.
Oprócz implementacji funkcji i poprawek błędów, nie spiesz się z czyszczeniem kodu.
źródło
Byłem zaskoczony, gdy stwierdziłem, że żadna z licznych odpowiedzi nie uwypukliła oczywistości: spraw, aby oprogramowanie składało się z wielu małych, niezależnych bibliotek. Dzięki wielu małym bibliotekom możesz zbudować duże i złożone oprogramowanie. Jeśli wymagania się zmienią, nie musisz wyrzucać całej bazy kodu ani badać, jak zmodyfikować dużą bazę kodu honking, aby zrobić coś innego niż to, co obecnie robi. Po prostu decydujesz, które z tych bibliotek są nadal odpowiednie po zmianie wymagań i jak je połączyć, aby uzyskać nową funkcjonalność.
Używaj dowolnych technik programowania w tych bibliotekach, które ułatwiają korzystanie z biblioteki. Zauważ, że np. Jakikolwiek język nie zorientowany obiektowo obsługujący wskaźniki funkcji obsługuje faktycznie programowanie obiektowe (OOP). Tak więc, np. W C, możesz zrobić OOP.
Możesz nawet rozważyć udostępnienie tych małych, niezależnych bibliotek między wieloma projektami (podmoduły git są twoim przyjacielem).
Nie trzeba dodawać, że każda mała, niezależna biblioteka powinna być testowana jednostkowo. Jeśli określonej biblioteki nie można przetestować jednostkowo, robisz coś źle.
Jeśli używasz C lub C ++ i nie podoba ci się pomysł posiadania wielu małych plików .so, możesz połączyć wszystkie biblioteki razem w większy plik .so lub alternatywnie możesz wykonać statyczne łączenie. To samo dotyczy Javy, wystarczy zmienić .so na .jar.
źródło
Prostota: obniż koszty utrzymania większości kodu do zera, aż uzyskasz możliwą do utrzymania liczbę ruchomych części. Kod, którego nigdy nie trzeba zmieniać, nie wiąże się z żadnymi kosztami utrzymania. Polecam dążyć do tego, aby kod naprawdę miał zerowy koszt utrzymania, nie próbując obniżać kosztów w porównaniu z wieloma małymi i wybrednymi iteracjami refaktoryzacji. Spraw, by od razu kosztowało zero .
Okej, wprawdzie to jest o wiele trudniejsze niż się wydaje. Ale nie jest trudno zacząć. Możesz wziąć część bazy kodu, przetestować ją, zbudować ładny interfejs, jeśli projekt interfejsu jest bałaganem, i zacząć rozwijać części bazy kodu, które są niezawodne, stabilne (ponieważ nie ma powodów do zmiany), a jednocześnie kurczenie części, które są zawodne i niestabilne. Podstawy, które wydają się koszmarem do utrzymania, często nie odróżniają ruchomych części, które należy zmienić, od tych, które tego nie robią, ponieważ wszystko jest uważane za zawodne i podatne na zmiany.
Właściwie polecam przejść całą drogę dzielenia organizacji bazy kodu na części „stabilne” i „niestabilne”, przy czym części stabilne to ogromna PITA do przebudowy i zmiany (co jest dobre, ponieważ nie powinny one wymagać zostać zmienione i przebudowane, jeśli naprawdę należą do sekcji „stabilnej”).
To nie jest rozmiar bazy kodu, która utrudnia utrzymanie. To wielkość bazy kodu, którą należy zachować. Jestem zależny od milionów wierszy kodu, ilekroć używam interfejsu API systemu operacyjnego. Ale to nie wpływa na koszty utrzymania mojego produktu, ponieważ nie muszę utrzymywać kodu źródłowego systemu operacyjnego. Po prostu używam kodu i działa. Kod, którego używam i którego nigdy nie muszę utrzymywać, nie wiąże się z żadnymi kosztami utrzymania.
źródło