Podczas pracy w językach, w których brakuje wbudowanej struktury i funkcji organizacyjnych (np. Jeśli nie ma przestrzeni nazw, pakietów, zestawów itp.) Lub gdy są one niewystarczające, aby kontrolować bazę kodu o takiej wielkości, naturalną reakcją jest rozwinięcie nasze własne strategie organizowania kodu.
Ta strategia organizacji prawdopodobnie obejmuje standardy dotyczące tego, gdzie należy przechowywać różne pliki, rzeczy, które muszą się zdarzyć przed / po pewnych rodzajach operacji, konwencje nazewnictwa i inne standardy kodowania, a także wiele „w ten sposób jest skonfigurowany - nie zadzieraj z tym! ” wpisz komentarze - które są ważne, o ile wyjaśniają dlaczego!
Ponieważ strategia najprawdopodobniej ostatecznie zostanie dostosowana do konkretnych potrzeb projektu (ludzi, technologii, środowiska itp.), Trudno jest stworzyć jedno uniwersalne rozwiązanie do zarządzania dużymi bazami kodu.
Dlatego uważam, że najlepszą radą jest przyjęcie strategii specyficznej dla projektu i uczynienie z niej zarządzania kluczowym priorytetem: udokumentuj strukturę, dlaczego tak jest, procesy wprowadzania zmian, poddaj ją audytowi, aby upewnić się, że jest przestrzegana, i co najważniejsze: zmień to, kiedy trzeba to zmienić.
Znamy się głównie na lekcjach i metodach refaktoryzacji, ale przy dużej bazie kodu w takim języku sama strategia organizacyjna (wraz z dokumentacją) wymaga refaktoryzacji w razie potrzeby.
Rozumowanie jest takie samo, jak w przypadku refaktoryzacji: rozwiniesz mentalny blok w kierunku pracy nad małymi częściami systemu, jeśli uważasz, że ogólna organizacja tego bałaganu, i ostatecznie pozwoli to się pogorszyć (przynajmniej takie jest moje zdanie to).
Zastrzeżenia są również takie same: użyj testu regresji, upewnij się, że możesz łatwo cofnąć, jeśli refaktoryzacja się nie powiedzie, i zaprojektuj, aby ułatwić refaktoryzację w pierwszej kolejności (lub po prostu tego nie zrobisz!).
Zgadzam się, że jest to o wiele trudniejsze niż refaktoryzacja kodu bezpośredniego i trudniej jest zweryfikować / ukryć czas przed menedżerami / klientami, którzy mogą nie rozumieć, dlaczego należy to zrobić, ale są to również rodzaje projektów najbardziej podatnych na gnicie oprogramowania spowodowane nieelastycznymi konstrukcjami najwyższego poziomu ...
