begrijpen als u in softwareontwikkeling bent, verschijnen er voortdurend nieuwe technieken, talen en concepten. We voelen allemaal af en toe die zeurende twijfels: “kan ik de veranderingen bijhouden en concurrerend blijven?”Neem een moment, en Som een regel uit Mijn favoriete film, Casablanca:” de fundamentele dingen zijn van toepassing, naarmate de tijd verstrijkt.”
om de paar weken bezoeken we enkele van de favoriete berichten van onze lezer uit de geschiedenis van de site. Deze tutorial werd voor het eerst gepubliceerd in April, 2012.
Wat Waar is voor Liefde, is waar voor code.
Wat Waar is voor Liefde, is waar voor code. De fundamentele dingen zullen altijd van toepassing zijn. Als je inzicht hebt in de onderliggende ideeën van softwareontwikkeling, zul je je snel aanpassen aan nieuwe technieken. In deze zelfstudie bespreken we drie basisprincipes en mengen we ze met nog veel meer. Ze bieden een krachtige manier om de complexiteit van software te beheren. Ik zal delen een aantal van mijn persoonlijke meningen en gedachten, die hopelijk nuttig zal blijken als het gaat om het toepassen van hen om code en real-world projecten.
Principe-herhaal uzelf niet
een basisstrategie voor het reduceren van complexiteit tot beheersbare eenheden is om een systeem in stukken te verdelen.
dit principe is zo belangrijk om te begrijpen, dat ik het niet twee keer zal schrijven! Het wordt vaak aangeduid door de acroniem, DRY, en kwam naar voren in het boek The Pragmatic Programmer, door Andy Hunt en Dave Thomas, maar het concept, zelf, is bekend voor een lange tijd. Het verwijst naar de kleinste onderdelen van uw software.
wanneer u een groot softwareproject bouwt, zult u meestal overweldigd worden door de algehele complexiteit. Mensen zijn niet goed in het beheren van complexiteit; ze zijn goed in het vinden van creatieve oplossingen voor problemen van een specifieke omvang. Een basisstrategie voor het reduceren van complexiteit tot beheersbare eenheden is om een systeem te verdelen in onderdelen die handiger zijn. In het begin wilt u misschien uw systeem opdelen in componenten, waarbij elk onderdeel zijn eigen subsysteem vertegenwoordigt dat alles bevat wat nodig is om een specifieke functionaliteit te bereiken.
bijvoorbeeld, als u een content management systeem bouwt, zal het deel dat verantwoordelijk is voor gebruikersbeheer een component zijn. Dit onderdeel kan worden onderverdeeld in andere subcomponenten, zoals rolbeheer, en het kan communiceren met andere componenten, zoals de beveiligingscomponent.
Als u systemen opgesplitst in componenten ,en verder componenten in subcomponenten, komt u op een niveau, waar de complexiteit wordt gereduceerd tot een enkele verantwoordelijkheid. Deze verantwoordelijkheden kunnen worden geïmplementeerd in een klasse (We gaan ervan uit dat we een object-georiënteerde applicatie bouwen). Klassen
bevatten methoden en eigenschappen. Methoden implementeren algoritmen. Algoritmen en – afhankelijk van hoe obsessief we willen worden-subdelen van
algoritmen berekenen of bevatten de kleinste stukjes die uw bedrijfslogica bouwen.
het droge principe stelt dat deze kleine stukjes kennis slechts één keer in uw hele systeem kunnen voorkomen.
ze moeten één enkele representatie hebben.
elk stukje kennis moet een enkele, ondubbelzinnige, gezaghebbende representatie binnen een systeem hebben.
merk Het Verschil Op tussen het stukje kennis en de representatie ervan. Als we de databaseverbinding implementeren in ons CMS, zullen we een codefragment hebben dat het databasestuurprogramma initaliseert, de referenties doorgeeft en een verwijzing naar de verbinding in een variabele opslaat. Het codefragment maakt deel uit van de kennis, het gaat over hoe iets wordt bereikt. De variabele met de verwijzing naar de verbinding is de representatie van die kennis – en dit kan door andere partijen worden gebruikt. Als de database referenties veranderen, zullen we het fragment moeten veranderen – niet de representatie.
in een perfecte toepassing, elk klein stukje van de business logica vat zijn kennis in een representatie, namelijk een variabele of een klasse-eigenschap.
deze variabele zelf is ingekapseld in een klasse die kan worden beschreven als een representatie van een verantwoordelijkheid. De klasse is ingekapseld in een component die kan worden beschreven als een representatie van functionaliteit.
Dit kan worden voortgezet totdat we het hoogste niveau van ons softwareproject bereiken – dat wil zeggen, een stapel representaties met toenemende complexiteit. Deze manier van kijken naar de complexiteit van software heet modulaire architectuur, en droog is een belangrijk onderdeel ervan.
het bereiken van droogheid
DRY is een filosofie die logica in representaties verpakt.
Er zijn vele manieren om droogheid te bereiken. Hunt en Thomas stelden (onder andere) code generators en data transforming voor. Maar in wezen is droog een filosofie die logica verpakt in representaties.
elk deel van uw toepassing kan worden gezien als representatie, elk deel bloot specifieke fragmenten van uw onderliggende logica: het gebruikersbeheer blootstelt toegang tot geregistreerde gebruikers van het CMS, de user class vertegenwoordigt een enkele gebruiker en bloot zijn eigenschappen (zoals de gebruikersnaam). Het haalt de eigenschappen op, via de representatie van de database.
droge en modulaire architectuur vereisen een goede planning. Om een representationele hierachy van onderop te bereiken, verdeel uw toepassing in een hiërarchie van logisch gescheiden kleinere delen en laat ze met elkaar communiceren. Als je grotere projecten te beheren, organiseren ze in componenten en het gebruik van droog binnen de componenten is een goed idee. Probeer de volgende regels toe te passen:
- Maak een visuele hiërarchie van uw toepassing en wijs de belangrijkste componenten ervan toe. Voor complexe projecten kan een speciale kaart voor elk onderdeel nodig zijn.
- Als u op een niveau van verbonden verantwoordelijkheden aankomt, kunt u overschakelen naar UML-diagrammen (of vergelijkbaar).
- voordat u een stuk code schrijft, geeft u de hiërarchie een naam in uw softwareproject. Definieer wat het vertegenwoordigt, en zorg ervoor dat je zijn rol kent in de omringende component.
- definieer wat de representatie moet blootstellen aan andere partijen (zoals functies om SQL uit te voeren in een database driver) en wat het moet verbergen (zoals de database referenties).
- zorg ervoor dat representaties niet afhankelijk zijn van representaties van een ander complexiteitsniveau (zoals een component die afhankelijk is van een klasse in een ander component).
het databasestuurprogramma is een vereenvoudigd voorbeeld, omdat er veel meer lagen betrokken zijn in de echte wereld (zoals een specifieke database – abstractielaag), en er is veel meer dat u kunt doen om logica in te kapselen-vooral door in ontwerppatronen te duiken. Maar zelfs als je net begonnen bent met coderen, is er één ding om in gedachten te houden:
als je merkt dat je code schrijft die vergelijkbaar is met of gelijk is aan iets dat je eerder hebt geschreven, neem dan een moment om na te denken over wat je doet en herhaal jezelf niet.
in de echte wereld zijn toepassingen die 100% droog zijn moeilijk, zo niet onmogelijk te bereiken. Toepassingen die onaanvaardbaar zijn – en daarom moeilijk te handhaven zijn-komen echter vrij vaak voor. Vandaar, het is niet verwonderlijk om te leren dat meer dan 50% van alle software projecten mislukken – als je het nemen van een kijkje op de code.
veel mensen hebben de neiging om te denken dat slechte code wordt geproduceerd door slechte programmeurs. In mijn ervaring is dit een uitzondering. Vaker wel dan niet, slechte code wordt geproduceerd door slechte accountmanagers en een algemene misconfiguratie van procesbeheer in bedrijven.
slechte code wordt zelden geproduceerd door slechte programmeurs.
een voorbeeld
droogheid wordt bereikt door goede planning.
als voorbeeld, stel dat u bent ingehuurd als technisch adviseur door een bedrijf dat problemen heeft met de kwaliteit en het onderhoud van de code. Je bekijkt de bron en je ziet hacks en code duplicatie – de code is niet droog. Dit is een symptoom van slechte code kwaliteit, Het is niet de reden. Als u een kijkje nemen op de version control system – aka de geschiedenis van de code – de kans groot dat u hacks die werden geïntroduceerd soms in de buurt van deadlines en mijlpalen te vinden. Neem de tijd om te bekijken welke wijzigingen zijn aangebracht, en u zult waarschijnlijk worden geconfronteerd met een verandering in de eisen.
zoals hierboven vermeld, wordt droogheid bereikt door een goede planning. Gedwongen veranderingen op een moeilijke deadline dwingen ontwikkelaars om vuile oplossingen te implementeren. Zodra de code is gecompromitteerd, zal het principe van droog waarschijnlijk volledig worden opgeofferd bij verdere wijzigingen.er is een reden waarom de meest succesvolle bedrijven in de IT-business werden opgericht door mensen met een zeer goede technische kennis – of zelfs programmeurs zelf: Bill Gates, Mark Zuckerberg, Steve Wozniak, Steve Jobs, Larry Page, Sergey Brin en Larry Ellison weten (of wisten) welke inspanningen nodig zijn om iets te implementeren. Integendeel, veel bedrijven hebben de neiging om de eisen voor engineering in de handen van accountmanagers, en het conceptuele deel in de handen van business consultants…mensen die nooit iets hebben geïmplementeerd.
daarom werken veel technische concepten alleen in Powerpoint, Photoshop en op 27″ breedbeeldschermen. Dit kan een succesvolle aanpak zijn geweest in de dagen van, min of meer, statische websites, maar het is niet tegenwoordig – met interactieve toepassingen op meerdere apparaten. Omdat programmeurs de laatste in de regel zijn, zijn zij degenen die snelle oplossingen moeten toepassen op fouten in het concept. Als dit wordt begeleid door een accountmanager, die niet kan weerstaan aan een klant die graag last-minute wijzigingen aan te brengen, plannen worden gegooid in de vuilnisbak, en iets snel en vies wordt uitgevoerd. De code wordt unDRY.
dit voorbeeld is een beetje extreem (toch heb ik dergelijke scenario ‘ s gezien), maar het toont aan dat droog een theoretisch concept is, dat door verschillende partijen in de echte wereld wordt uitgedaagd. Als je werkt in een bedrijf dat je dwingt om te werken op deze manier, kunt u een aantal wijzigingen in het proces voorstellen (zoals de invoering van technische expertise in een eerdere fase van technische projecten).
als je een hands-off aanpak hebt, lees dan verder! Het principe dat je het niet nodig hebt komt je te hulp.
Principe – houd het simpel dom
De eenvoudigste verklaring is meestal de juiste.aan het eind van de 19e eeuw hadden natuurkundigen moeite om uit te leggen hoe zwaartekracht, magnetisme en optica interageren als het gaat om grote afstanden – zoals de afstanden in ons zonnestelsel. Daarom werd een medium genaamd aether gepostuleerd. Er werd gezegd dat licht door dit medium reist en dat het verantwoordelijk is voor effecten die niet anders konden worden verklaard. Door de jaren heen werd de theorie uitgebreid met veronderstellingen die het aether-postulaat aanpasten aan de resultaten van experimenten. Sommige veronderstellingen waren willekeurig, sommige introduceerden andere problemen, en de hele theorie was vrij complex.een medewerker van het Zwitserse Octrooibureau, Albert Einstein, stelde voor om van de hele ethertheorie af te komen toen hij een eenvoudig, maar revolutionair idee introduceerde: alle eigenaardigheid in berekenen met grote afstanden zou verdwijnen als we zouden accepteren dat tijd geen constante is; het is relatief. Dit ongelooflijk van out-of-the-box denken om te komen tot de eenvoudigste verklaring met de minste veronderstellingen om te kiezen tussen concurrerende scenario ’s wordt aangeduid als Ockhams’ s Razor.
Er zijn vergelijkbare concepten op veel gebieden. In software ontwikkeling (en anderen), we verwijzen naar het als KISS. Er zijn vele varianten voor dit acroniem, maar ze betekenen allemaal dat je moet streven naar de eenvoudigste manier om iets te doen.
aanzienlijke vooruitgang in de geschiedenis van de mensheid werd bereikt door laterale denkers.HTTP
Het Hypertext Transfer Protocol wordt algemeen beschouwd als een perfect voorbeeld voor een eenvoudige oplossing: ontworpen om hypertext gebaseerde documenten over te dragen, het is de ruggengraat van zeer interactieve en desktop-achtige toepassingen tegenwoordig. Misschien moeten we oplossingen vinden voor beperkingen in het protocol, en misschien moeten we het ooit vervangen. Echter, status quo is: gebaseerd op een paar request methoden (zoals GET en POST), statuscodes en platte tekst argumenten, HTTP heeft bewezen flexibel en robuust te zijn. Daarom is HTTP herhaaldelijk tot het uiterste gedreven door webontwikkelaars – en staat nog steeds overeind.
We nemen deze aanpak als vanzelfsprekend aan, maar de geschiedenis van softwareontwikkeling en standaardisatie zit vol te complexe en halfbakken oplossingen. Er is zelfs een speciaal verzonnen woord voor: bloatware. Software zoals deze wordt ook beschreven als DOD, dood bij aankomst. Ik heb een theorie die erg lijkt op mijn theorie van unDRY code, als het gaat om bloatware … Het succes van het internet kan echter worden omschreven als een succes van eenvoudige, maar efficiënte oplossingen.
Wat is er nodig om tot de eenvoudigste oplossing te komen? Het komt allemaal neer op onderhoudbaarheid en begrijpelijkheid in softwareontwikkeling. Vandaar, KISS kicks in tijdens de fase van requirements engineering. Wanneer u nadenkt over hoe u de vereisten van een client kunt omzetten in implementeerbare componenten, probeert u de volgende onderdelen te identificeren:
- functionaliteit die een ongepaste verhouding heeft tussen voordeel en inspanningen.
- functionaliteit die sterk afhankelijk is van andere functionaliteit.
- functionaliteit die waarschijnlijk zal toenemen in complexiteit.
Er zijn veel mensen betrokken bij het conceptuele proces, die niet over de technische expertise beschikken om een betrouwbare kosten-batenanalyse te maken
Ik werkte ooit aan een project, waarbij de klant Excel-spreadsheets wilde importeren in zijn crew management software. Dit was een duidelijke match. Excel is een propriëtaire software met een complex document formaat. Het formaat is complex, omdat het feature-rijke: u kunt grafieken en andere dingen toe te voegen aan het – functies die niet nodig waren door de client. Hij was gewoon geïnteresseerd in de cijfers. Dus, het implementeren van de Excel import zou de implementatie van een heleboel onnodige functionaliteit vereisen. Op de top van dat, er zijn meerdere versies van Excel-versies, en Microsoft vuurt uit een andere release elk jaar. Dit zou moeilijk te handhaven zijn geweest, en het komt met extra kosten in de toekomst.
uiteindelijk implementeerden we een komma-gescheiden-waarde import. Dit werd gedaan met een paar regels code. De overhead van de gegevens was erg klein (vergelijk een Excel-blad met het CSV-equivalent) en de oplossing was onderhoudbaar en toekomstbestendig. Excel was klaar om CSV toch te exporteren (evenals andere programma ‘ s die de client zou willen gebruiken in de toekomst). Omdat de oplossing ook goedkoop was, was het een goede toepassing van het KISS-principe.
om samen te vatten: probeer out-of-the box te denken als een taak er ingewikkeld uitziet. Als iemand je zijn eisen uitlegt, en je denkt dat het moeilijk en complex zal zijn om te implementeren, heb je gelijk onder bijna alle omstandigheden. Terwijl sommige dingen zijn gewoon dat – moeilijk te implementeren-overcomplicated oplossingen zijn heel gebruikelijk. Dit is het geval omdat er veel mensen bij het conceptuele proces betrokken zijn, die niet over de technische expertise beschikken om een betrouwbare kosten-batenanalyse te maken. Daarom zien ze het probleem niet. Controleer de eisen of ze echt zijn gestript tot de essentie die de klant nodig heeft. Neem de tijd om kritische punten te bespreken en uit te leggen waarom andere oplossingen geschikter zouden kunnen zijn.
Principe-You “Ain’ T Gonna Need It
codering gaat over het bouwen van dingen.toen Google + werd gelanceerd, was Mark Zuckerberg – oprichter van Facebook – een van de eersten die een account aanmaakte in het sociale netwerk dat zijn eigen account wilde uitschakelen. Hij voegde slechts één regel toe aan de Over mij sectie: “ik ben dingen aan het bouwen.”. Ik denk eerlijk gezegd dat dit een briljante zin is, omdat het de pure essentie van coderen in een paar eenvoudige woorden beschrijft. Waarom besloot je codeerder te worden? Enthousiasme voor technische oplossingen? De schoonheid van efficiëntie? Wat je antwoord ook is, het is misschien niet “het bouwen van de 1.000.001th corporate website met standaard functionaliteit”. Maar de meesten van ons verdienen op die manier geld. Waar u ook werkt, u zult waarschijnlijk worden geconfronteerd met saaie en repetitieve taken zo nu en dan.
80% van de tijd besteed aan een softwareproject wordt geïnvesteerd in 20% van de functionaliteit.
Het You ain ‘ t gonna need it Principe (YAGNI) behandelt deze taken. Het vertaalt zich in feite naar: als het niet in het concept zit, zit het niet in de code. Het is bijvoorbeeld gebruikelijk om de toegang tot de database te abstraheren in een laag die de verschillen tussen verschillende stuurprogramma ‘ s aanpakt, zoals MySQL, PostgreSQL en Oracle. Als je werkt aan een bedrijfswebsite die wordt gehost op een LAMP stack, op een gedeelde host, hoe waarschijnlijk is het dan dat ze de database zullen veranderen? Vergeet niet dat het concept is geschreven met budget in het achterhoofd.
als er geen budget is voor database-abstractie, is er geen database-abstractie. Als de onwaarschijnlijke gebeurtenis van een database verandering toch optreedt, is het een natuurlijke zaak om kosten voor de verandering aanvraag.
u hebt misschien het verschil gemerkt tussen U zult het niet nodig hebben en DROOGGESTUURDE modulaire architecturen: de laatste vermindert de complexiteit door een project op te delen in beheersbare componenten, terwijl de eerste de complexiteit vermindert door het aantal componenten te verminderen. YAGNI is vergelijkbaar met het KISS-principe, omdat het streeft naar een eenvoudige oplossing. KISS streeft echter naar een eenvoudige oplossing door iets zo gemakkelijk mogelijk te implementeren; YAGNI streeft naar eenvoud door het helemaal niet te implementeren! Theodore Sturgeon, een Amerikaanse sci-fi auteur, verklaarde de wet: “negentig procent van alles is onzin”. Dit is een zeer radicale aanpak, en niet al te nuttig in real-world projecten. Maar houd in gedachten dat” onzin ” kan zeer tijdrovend zijn. Een goede vuistregel is: ongeveer 80% van de tijd besteed aan een softwareproject wordt geïnvesteerd in 20% van de functionaliteit. Denk na over je eigen projecten! Telkens als ik dat doe, ben ik verrast door de nauwkeurigheid van de 80:20 regel.
80% van de tijd besteed aan een softwareproject wordt geïnvesteerd in 20% van de functionaliteit.Als u in een bedrijf zit dat berucht is om strakke deadlines en onnauwkeurige Concepten, is dit een krachtige strategie. U wordt niet beloond voor het implementeren van een database abstractie laag. De kans is groot dat je baas niet eens weet wat een database abstractielaag is.
hoewel dit concept eenvoudig klinkt, kan het moeilijk zijn om het noodzakelijke te onderscheiden van de onnodige delen. Als u bijvoorbeeld vertrouwd bent met een bibliotheek of een framework dat databaseabstractie gebruikt, bespaart u niet veel tijd bij het dumpen ervan. Het belangrijkste concept is een andere manier van kijken naar software: we zijn getraind om toekomstbestendige en onderhoudbare software te schrijven. Dit betekent dat we getraind zijn om vooruit te denken. Welke veranderingen kunnen zich in de toekomst voordoen? Dit is van cruciaal belang voor grotere projecten, maar overhead voor kleinere. Denk niet in de toekomst! Als een kleine corporate website doet fundamentele veranderingen, ze kunnen hebben om te beginnen vanaf nul. Dit is geen groot probleem in vergelijking met de totale begroting.
een Project plannen
wanneer u uw takenlijst voor een project voorbereidt, overweeg dan de volgende gedachten:
- bereik een lagere complexiteit door het abstractieniveau te verlagen.
- scheid functionaliteit van functies.
- ga uit van matige niet-functionele eisen.
- Identificeer tijdrovende taken en verwijder ze.
laten we een beetje in detail gaan! Ik heb al een voorbeeld gegeven voor het eerste item in de lijst: wikkel een database driver niet rond een database abstractielaag. Wees verdacht van alles wat complexiteit toevoegt aan uw software stack. Merk op dat abstractie vaak wordt geleverd door bibliotheken van derden. Bijvoorbeeld-afhankelijk van uw programmeertaal -, een persistence layer, zoals Hibernate (Java), Doctrine (PHP) of Active Record (Ruby) wordt geleverd met database abstraction en object-relationele mapping. Elke bibliotheek voegt complexiteit toe. Het moet worden gehandhaafd. Updates, patches en beveiligingsoplossingen moeten worden toegepast.
We implementeren functies dagelijks, omdat we verwachten dat ze nuttig zijn. Daarom denken we vooruit en implementeren we te veel. Veel klanten willen bijvoorbeeld een mobiele website hebben. Mobiel is een term van breed begrip; het is geen ontwerpbeslissing. Het is een use case! Mensen die gebruik maken van een mobiele website zijn, nou ja, mobiel. Dat betekent dat ze mogelijk toegang willen tot andere informatie of functionaliteit dan een gebruiker die de site laid back bezoekt op zijn bureaublad. Denk aan een bioscoop site: gebruikers op de bus zal waarschijnlijk willen toegang tot de starttijd van de komende films, niet de 50 MB trailer.
slechte Concepten kunnen vaak worden geïdentificeerd door het ontbreken van niet-functionele vereisten.
met een passend budget voert u een specifieke analyse uit van de vereisten voor mobiel. Zonder deze analyse, zult u gewoon dezelfde informatie als op de desktop site. Dit zal prima zijn voor vele omstandigheden! Omdat mobiele browsers zijn erg slim in het aanpassen van desktop sites aan hun display, een radicale yagni aanpak zou kunnen zijn om niet te schrijven van een mobiele site op alle!
niet-functionele vereisten beschrijven niet het gedrag van een software, ze beschrijven aanvullende eigenschappen die kunnen worden gebruikt om de kwaliteit van software te beoordelen. Omdat het beschrijven van softwarekwaliteit kennis over software veronderstelt, kunnen slechte concepten vaak worden geïdentificeerd door het ontbreken van niet-functionele vereisten. Onderhoudbaarheid, documentatieniveau en integratiegemak zijn voorbeelden van niet-functionele vereisten. Niet-functionele eisen moeten meetbaar zijn. Vandaar, ” de pagina moet snel te laden.”is te onnauwkeurig,” de pagina moet worden geladen in twee seconden max tijdens een gemiddelde prestatietest.”is zeer concreet en meetbaar. Als u het YAGNI-Principe wilt toepassen, neem dan gematigde niet-functionele eisen aan als ze niet in het concept worden genoemd (of als ze wel worden genoemd, maar niet nauwkeurig zijn). Als u het schrijven van de niet-functionele eisen zelf, wees realistisch: een klein bedrijf met 20-50 pagina bezoeken per dag vereist geen drie dagen van de prestaties tweaken – als de pagina snel genoeg moet laden omdat de server is niet druk. Als het bedrijf het aantal dagelijkse bezoeken kan verhogen, moet een betere server of hostingpakket niet te duur zijn.
last, but not least, remember the 80:20 rule-of-thumb!
last but not least, onthoud de 80:20 vuistregels! We moeten de tijdrovende onderdelen identificeren. Als een onderdeel absoluut noodzakelijk is, moet je het implementeren. De vraag zou moeten zijn: hoe gaat u het uitvoeren? Moet dit het laatste kader zijn met een kleine gemeenschap? Moet u overschakelen naar de zojuist uitgebrachte versie van een bibliotheek als de documentatie niet up-to-date is? Moet u het nieuwe CMS gebruiken als niet alle extensies beschikbaar zijn? Hoeveel onderzoek is daarvoor nodig? “Zo hebben we het altijd gedaan.”is geen spannende aanpak, maar het zal de klus te klaren zonder verrassingen.
Het is belangrijk om te begrijpen dat dit alles niet betekent dat je onderweg kunt beginnen met het schrijven van vuile code met hacks! Je schrijft een lichtgewicht applicatie, geen rommelige! Echter, je gaat niet nodig het is een praktische aanpak. Als het zou leiden tot veel regels code om een paar regels code duplicaten te verminderen, ik persoonlijk denk dat je inspanningen kan betrekking hebben op de begroting en sommige unDRYness is ok. Het is een kleine toepassing. Daarom is de toegevoegde complexiteit van het onderhoud aanvaardbaar. We zijn in de echte wereld.
laten we terugkeren naar de inital gedachte: we houden van dingen bouwen. Toen Beethoven de Diabelli Variations schreef, was het contractwerk. Ik denk niet dat hij compromissen heeft gemaakt over het budget. Hij liep de extra mijl, omdat hij niet wilde om gemiddelde muziek te schrijven; hij wilde een perfecte compositie te schrijven.
Ik beweer zeker niet dat we allemaal genieën zijn, en dat onze genialiteit door elke regel code heen zou moeten schijnen, maar ik zie softwarearchitectuur graag als composities. Ik ben een gepassioneerde Ontwikkelaar, omdat ik perfecte composities wil bouwen, en Ik wil trots zijn op de dingen die ik Bouw.
als je een ervaren en business-proofed Ontwikkelaar wilt zijn, moet je het principe dat je het niet nodig hebt onder de knie hebben. Als je je passie wilt behouden, moet je er af en toe tegen vechten.
samenvatting
Softwareprincipes zijn een manier om naar software te kijken. Voor mij zou een goed principe gebaseerd moeten zijn op een eenvoudig concept, maar het zou moeten evolueren naar een complexe constructie van ideeën wanneer het geconfronteerd wordt met andere technieken en filosofieën. Wat zijn uw favoriete software principes?