Nyligen stötte jag på flera artiklar som diskuterade trenden att gå från en mikrotjänstarkitektur tillbaka till en monolitisk arkitektur, ofta av olika praktiska skäl. I de flesta av dessa fall presenteras en modulär monolit som ett genomförbart alternativ till mikrotjänster. Intressant nog har vissa stora företag gått ifrån mikrotjänster till förmån för en monolitisk arkitektur, medan andra har använt en monolit från början och aldrig infört mikrotjänster överhuvudtaget.
Detta stämmer överens med min egen uppfattning att mikrotjänster i många fall inte införs av en verklig nödvändighet, utan snarare för att vissa tekniska intressenter (utvecklare, ingenjörer) känner sig tvungna att visa att de kan arbeta med dem - ungefär som en övermodig drinkare som försöker bevisa att de kan dricka mer än alla andra.
Som sagt, jag är inte här för att dyka in i arkitektoniska debatter. Istället vill jag fokusera på en viss aspekt av kodorganisation - en som kan påminna dig om ett modulärt tillvägagångssätt, även om det inte är strikt arkitektoniskt.
Bra kod handlar inte bara om att skriva nya funktioner - det handlar om att göra förändringar enkla. Oavsett om det handlar om att lägga till en ny funktion, ändra befintlig funktionalitet eller ta bort något helt och hållet, bör en välstrukturerad kodbas göra dessa uppgifter enkla. Men hur utvärderar du om din kod är välorganiserad?
I den här artikeln presenteras Rule of Delete, en enkel heuristisk metod för att bedöma kodstruktur. Idén är okomplicerad:
När du har implementerat en ny funktion eller en modul kan du tänka dig att du behöver ta bort all relaterad kod. Om du kan göra detta med tre eller färre delete-åtgärder är din kod sannolikt välstrukturerad. Om det krävs betydligt mer kan din kod vara alltför kopplad, utspridd eller svår att underhålla.
Denna regel ger ett snabbt och intuitivt sätt att bedöma kodorganisationen. Värdet av den här regeln ligger i dess enkelhet och praktiska användbarhet. Det handlar inte om att upprätthålla strikta raderingsgränser utan om att lyfta fram modularitet, separation av problem och underhållbarhet.
Tanken bakom Rule of Delete är enkel: en välstrukturerad funktion ska vara fristående och lätt att ta bort. Om det krävs ändringar i flera orelaterade filer för att ta bort en funktion tyder det på att koden är alltför sammanflätad med resten av systemet.
Så här tillämpar du Rule of Delete i praktiken:
En delete-åtgärd är en enda logisk borttagning av en funktionsrelaterad enhet. Ett exempel:
✅ En raderingsåtgärd: Ta bort en särskild modul eller katalog som innehåller all funktionens kod.
✅ En raderingsåtgärd: Ta bort en väl inkapslad klass, komponent eller API-slutpunkt.
✅ En raderingsåtgärd: Radering av en enda databastabell eller ett schema som är relaterat till funktionen.
🚫 F lera raderingsåtgärder krävs: Om borttagning innebär att ändra orelaterade filer över flera lager av applikationen, behöver strukturen förbättras.
Rule of Delete är inte ett nytt koncept - det överensstämmer med flera välkända principer för programvarudesign. Skillnaden? Den förenklar dem till ett praktiskt test som är lätt att komma ihåg och som är särskilt användbart för nybörjare. Här är några välkända principer:
Du kan enkelt koppla Rule of Delete till flera andra designprinciper också - här är några som är värda att utforska:
Rule of Delete är en användbar heuristik, men den ska inte ses som en absolut regel. Sammanhanget spelar alltid roll. Vissa funktioner kräver naturligtvis integration mellan flera komponenter, och att tvinga fram en strikt gräns på tre raderingar kanske inte alltid är praktiskt.
Det verkliga värdet av denna regel ligger inte i en strikt tillämpning utan i att den fungerar som en indikator - omdet känns alltför komplicerat att ta bort en funktion är det ett tecken på att din kodorganisation kan behöva förbättras.
Styrkan ligger i att det är praktiskt - detger utvecklarna ett omedelbart och konkret sätt att utvärdera kodorganisationen. Det hjälper till att belysa potentiella problem, men det krävs fortfarande ett gott ingenjörsmässigt omdöme för att avgöra om omstrukturering verkligen är nödvändig.
Fråga dig själv nästa gång du implementerar en ny funktion:
Om jag var tvungen att ta bort det här, hur svårt skulle det vara?
Om svaret innebär mer än tre raderingsåtgärder kan det vara dags för en omarbetning.
