3 Viktige Programvareprinsipper Du Må Forstå

hvis du er i programvareutvikling, dukker nye teknikker, språk og konsepter opp hele tiden. Vi alle føler de griner tvil nå og da: «kan jeg holde tritt med endringene og være konkurransedyktig?»Ta et øyeblikk, og sum en linje fra Min favorittfilm, Casablanca:» de grunnleggende tingene gjelder, ettersom tiden går.»

det som er sant for kjærlighet, er sant for kode.

det som er sant for kjærlighet, er sant for kode. De grunnleggende tingene vil alltid gjelde. Hvis du har en forståelse av de underliggende ideene om programvareutvikling, vil du raskt tilpasse seg nye teknikker. I denne opplæringen vil vi diskutere tre grunnleggende prinsipper og blande dem med mange flere. De gir en effektiv måte å håndtere kompleksiteten av programvare. Jeg vil dele noen av mine personlige meninger og tanker, som forhåpentligvis vil være nyttige når det gjelder å bruke dem til kode og virkelige prosjekter.

Prinsipp-Ikke Gjenta deg selv

en grunnleggende strategi for å redusere kompleksitet til administrerbare enheter er å dele et system i stykker.

dette prinsippet er så viktig å forstå, at jeg ikke vil skrive det to ganger! DET er ofte referert til av akronymet, DRY, og kom opp i boken The Pragmatic Programmerer, Av Andy Hunt Og Dave Thomas, men konseptet selv har vært kjent i lang tid. Det refererer til de minste delene av programvaren.

når du bygger et stort programvareprosjekt, vil du vanligvis bli overveldet av den generelle kompleksiteten. Mennesker er ikke gode til å håndtere kompleksitet; de er gode til å finne kreative løsninger på problemer med et bestemt omfang. En grunnleggende strategi for å redusere kompleksiteten til administrerbare enheter er å dele et system i deler som er mer praktiske. Først vil du kanskje dele systemet i komponenter, hvor hver komponent representerer sitt eget delsystem som inneholder alt som trengs for å oppnå en bestemt funksjonalitet.

hvis du for eksempel bygger et innholdsstyringssystem, vil delen som er ansvarlig for brukeradministrasjonen være en komponent. Denne komponenten kan deles inn i flere delkomponenter, som rollestyring, og den kan kommunisere med andre komponenter, for eksempel sikkerhetskomponenten.

når du deler systemer i komponenter, og videre komponenter i delkomponenter, kommer du til et nivå hvor kompleksiteten reduseres til et enkelt ansvar. Dette ansvaret kan implementeres i en klasse (vi antar at vi bygger et objektorientert program). Klasser
inneholder metoder og egenskaper. Metoder implementere algoritmer. Algoritmer og – avhengig av hvor obsessive vi ønsker å få-deler av
algoritmer beregner eller inneholder de minste brikkene som bygger forretningslogikken din.

DET TØRRE prinsippet sier at disse små kunnskapsstykkene bare kan forekomme nøyaktig en gang i hele systemet.

De må ha en enkelt representasjon i den.

hvert stykke kunnskap må ha en enkelt, entydig, autoritativ representasjon i et system.

Merk forskjellen mellom kunnskapsstykket og dets representasjon. Hvis vi implementerer databasetilkoblingen i VÅRT CMS, vil vi ha en kodebit som vil initalisere databasedriveren, passere legitimasjonene og lagre en referanse til tilkoblingen i en variabel. Kodebiten er en del av kunnskapen, det handler om hvordan noe oppnås. Variabelen med henvisning til forbindelsen er representasjonen av den kunnskapen – og dette kan brukes av andre parter. Hvis databasens legitimasjon endres, må vi endre kodebiten-ikke dens representasjon.I en perfekt applikasjon innkapsler hver liten forretningslogikk sin kunnskap i en representasjon, nemlig en variabel eller en klasseegenskap.
denne variabelen i seg selv er innkapslet i en klasse som kan beskrives som en representasjon av et ansvar. Klassen er innkapslet i en komponent som kan beskrives som en representasjon av funksjonalitet.

Dette kan fortsette til vi når toppnivået i vårt programvareprosjekt – det vil si en stabel med representasjoner med økende kompleksitet. Denne måten å se på programvarens kompleksitet kalles modulær arkitektur, OG TØRR er en viktig del av den.

Oppnå Tørrhet

TØRR ER en filosofi som pakker logikk inn i representasjoner.

Det er mange måter Å oppnå Tørrhet på. Hunt og Thomas foreslo (blant annet) kodegeneratorer og datatransformering. MEN I hovedsak ER TØRR en filosofi som pakker logikk inn i representasjoner.

som hver del av søknaden din kan ses som representasjon, avslører hver del spesifikke fragmenter av din underliggende logikk: brukeradministrasjonen avslører tilgang til registrerte brukere AV CMS, brukerklassen representerer en enkelt bruker og avslører hans egenskaper (som brukernavnet). Den henter egenskapene, via representasjon av databasen.

TØRR og modulær arkitektur krever god planlegging. For å oppnå en representativ hierachy fra bunnen opp, del opp søknaden din i et hierarki av logisk adskilte mindre deler og la dem kommunisere med hverandre. Hvis du må håndtere større prosjekter, er det en god ide å organisere dem i komponenter og bruke TØRR i komponentene. Prøv å bruke følgende regler:

• Lag et visuelt hierarki av programvaren din og kartlegg hovedkomponentene til den. Komplekse prosjekter kan kreve et dedikert kart for hver komponent.
• hvis du kommer til et nivå av tilkoblede ansvar, kan det være lurt å bytte TIL UML-diagrammer (eller lignende).
• før du skriver en del av koden, navngi hierarkiet i programvareprosjektet. Definer hva den representerer, og vær sikker på at du kjenner sin rolle i den omkringliggende komponenten.Definer Hva representasjonen skal eksponere for andre parter (som funksjoner for å utføre SQL i en databasedriver) og hva den skal skjule (som databasens legitimasjon).
• Sørg for at representasjoner ikke stole på representasjoner av et annet kompleksitetsnivå (som en komponent som er avhengig av en klasse i en annen komponent).

databasedriveren er et forenklet eksempel, da det er mange flere lag involvert i den virkelige verden( for eksempel et bestemt databaseabstraksjonslag), og det er mye mer du kan gjøre for å kapsle logikk – spesielt dykking i designmønstre. Men selv om du nettopp har startet med koding, er det en ting å huske på:

når du finner deg selv å skrive kode som er lik eller lik noe du har skrevet før, ta et øyeblikk å tenke på hva du gjør og ikke gjenta deg selv.

i den virkelige verden, programmer som er EN 100% TØRR er vanskelig, om ikke umulig, å oppnå. Men programmer som er unDRY i uakseptabel grad – og derfor vanskelig å vedlikeholde – er ganske vanlig. Derfor er det ikke overraskende å lære at mer enn 50% av alle programvareprosjekter mislykkes-hvis du tar en titt på koden.

Mange mennesker har en tendens til å tro at dårlig kode er produsert av dårlige kodere. I min erfaring er dette veldig mye et unntak. Oftere enn ikke, dårlig kode er produsert av dårlige kontoadministratorer og en generell feilkonfigurasjon av prosessledelse i selskaper.

Dårlig kode produseres sjelden av dårlige kodere.

Et Eksempel

Tørrhet oppnås ved god planlegging.

for eksempel, si at du er ansatt som teknisk konsulent av et selskap som har problemer med kodekvalitet og vedlikehold. Du ser gjennom kilden og du ser hacks og kode duplisering-koden ER IKKE TØRR. Dette er et symptom på dårlig kodekvalitet, det er ikke grunnen. Hvis du tar en titt på versjonskontrollsystemet-aka kodenes historie-er sjansene at du kan finne hack som ble introdusert til tider nær tidsfrister og milepæler. Ta deg tid til å vurdere hvilke endringer som er gjort, og du vil sannsynligvis bli konfrontert med en endring i krav.

Som nevnt ovenfor oppnås Tørrhet ved god planlegging. Tvunget endringer på en tøff frist tvinger utviklere til å implementere skitne løsninger. Når koden er kompromittert, vil PRINSIPPET OM TØRR sannsynligvis bli ofret helt ved ytterligere endringer.det er en grunn til at DE mest vellykkede selskapene I IT-virksomheten ble grunnlagt av folk med veldig god teknisk forståelse-Eller til og med kodere selv: Bill Gates, Mark Zuckerberg, Steve Wozniak, Steve Jobs, Larry Page, Sergey Brin og Larry Ellison vet (eller visste) hvilke anstrengelser som trengs for å implementere noe. I motsetning har mange selskaper en tendens til å legge kravene til engineering i hendene på kontoadministratorer, og den konseptuelle delen i hendene på forretningskonsulenter…folk som aldri har implementert noe.

derfor fungerer mange tekniske konsepter bare I Powerpoint, Photoshop og på 27 » widescreen-skjermer. Dette kan ha vært en vellykket tilnærming i dagene til mer eller mindre statiske nettsteder , men det er ikke i dag-med interaktive applikasjoner på flere enheter. Fordi kodere er de siste i linjen, er de de som må bruke hurtige løsninger på feil i konseptet. Hvis dette er ledsaget av en kontoadministrator, som ikke kan stå opp til en klient som liker å gjøre endringer i siste øyeblikk, blir planer kastet i søppel, og noe raskt og skittent blir implementert. Koden blir unDRY.

dette eksemplet er litt ekstremt (likevel har jeg sett slike scenarier), men det viser AT TØRR er et teoretisk konsept, som utfordres av ulike parter i den virkelige verden. Hvis du jobber i et selskap som tvinger deg til å jobbe på denne måten, kan du foreslå noen endringer i prosessen (som å introdusere teknisk kompetanse på et tidligere stadium av tekniske prosjekter).

hvis du har en hands-off tilnærming, fortsett å lese! Du trenger ikke det prinsippet vil komme til unnsetning.

Prinsipp-Hold Det Enkelt Dumt

den enkleste forklaringen har en tendens til å være den rette.

på slutten av det 19.århundre slet fysikere med å forklare hvordan gravitasjon, magnetisme og optikk interagerer når det gjelder store avstander – som avstandene i vårt solsystem. Derfor ble et medium kalt aether postulert. Det ble sagt at lyset reiser gjennom dette mediet, og at det er ansvarlig for effekter som ikke kunne forklares ellers. Gjennom årene ble teorien utvidet med forutsetninger som justerte aether-postulatet til resultatene av eksperimenter. Noen forutsetninger var vilkårlig, noen introduserte andre problemer, og hele teorien var ganske kompleks.En ansatt I det sveitsiske patentkontoret, Albert Einstein, foreslo å kvitte seg med hele aether-teorien da han introduserte en enkel, men revolusjonerende ide: All oddness i beregning med store avstander ville visne bort hvis vi ville akseptere at tiden ikke er en konstant; den er relativ. Dette utrolig av out-of-the-box tenkning å komme til den enkleste forklaringen med færrest forutsetninger for å velge mellom konkurrerende scenarier er referert til Som Ockhams Razor.

det finnes lignende begreper på mange områder. I programvareutvikling (og andre) refererer vi til DET SOM KISS. Det er mange varianter for dette akronymet, men de betyr alle at du bør streve for den enkleste måten å gjøre noe på.

HTTP

Hypertext Transfer Protocol er allment ansett for å være et perfekt eksempel på en enkel løsning: designet for å overføre hypertekstbaserte dokumenter, er det ryggraden i svært interaktive og desktop-esque applikasjoner i dag. Kanskje vi må finne løsninger for begrensninger i protokollen, og kanskje må vi erstatte den en dag. Men status quo er: BASERT på noen få forespørselsmetoder (SOM GET og POST), statuskoder og rene tekstargumenter, HAR HTTP vist seg å være fleksibel og robust. DERFOR HAR HTTP gjentatte ganger blitt presset til grensene av webutviklere-og står fortsatt.Vi tar denne tilnærmingen for gitt, men historien om programvareutvikling og standardisering er full av altfor komplekse og halvbakte løsninger. Det er enda en dedikert gjort opp ord for det: bloatware. Programvare som dette er også beskrevet Å VÆRE DOD, død ved ankomst. Jeg har en teori som er veldig lik min teori om unDRY kode, når det gjelder bloatware … Suksessen til internett kan imidlertid beskrives som en suksess med enkle, men effektive løsninger.

så hva kreves for å komme til den enkleste løsningen mulig? Alt kommer ned til vedlikehold og forståelighet i programvareutvikling. Derav, KISS spark i løpet av fasen av krav engineering. Når du tenker på hvordan du forvandler kundens krav til implementerbare komponenter, kan du prøve å identifisere følgende deler:

• Funksjonalitet som har et upassende forhold mellom fordel og innsats.
• Funksjonalitet som er svært avhengig av annen funksjonalitet.
• Funksjonalitet som sannsynligvis vil vokse i kompleksitet.

det er mange som er involvert i den konseptuelle prosessen, som ikke har den tekniske ekspertisen til å lage en pålitelig kost-nytte-analyse

jeg jobbet en gang på et prosjekt, der klienten ønsket å importere Excel-regneark til sin crew management software. Dette var en klar kamp. Excel er en proprietær programvare med et komplekst dokumentformat. Formatet er komplekst, fordi det er funksjonsrikt: Du kan legge til grafer og andre ting til det – funksjoner som ikke var nødvendig av klienten. Han var bare interessert i tallene. Dermed vil implementering Av Excel-importen kreve implementering av mye unødvendig funksjonalitet. På toppen av det er det flere versjoner Av Excel-versjoner, Og Microsoft brenner av en annen utgivelse hvert år. Dette ville ha vært vanskelig å vedlikeholde, og det kommer med ekstra kostnader i fremtiden.

vi endte opp med å implementere en kommaseparert verdi import. Dette ble gjort med noen få linjer med kode. Overhead av dataene var veldig liten (sammenlign Et Excel-ark til DET CSV-ekvivalent) og løsningen var vedlikeholdbar og fremtidssikker. Excel var klar til å eksportere CSV uansett (samt andre programmer som klienten kanskje vil bruke i fremtiden). Siden løsningen var rimelig også, det var en god anvendelse AV KISS prinsippet.

for å oppsummere: prøv å tenke ut av boksen hvis en oppgave ser komplisert ut for deg. Hvis noen forklarer deg hans krav, og du tenker at det vil være tøft og komplekst å implementere, har du rett under nesten alle omstendigheter. Mens noen ting er nettopp det-vanskelig å implementere-overkompliserte løsninger er ganske vanlig. Dette er tilfellet fordi det er mange som er involvert i den konseptuelle prosessen, som ikke har den tekniske ekspertisen til å lage en pålitelig kost-nytte-analyse. Derfor ser de ikke problemet. Dobbeltsjekk kravene om de virkelig er strippet ned til essensen som klienten trenger. Ta deg tid til å diskutere kritiske punkter og forklare hvorfor andre løsninger kan være mer egnet.

Prinsipp-Du «Kommer ikke Til å Trenge det

Koding handler om å bygge ting.

Da Google+ ble lansert, Var Mark Zuckerberg – grunnlegger Av Facebook – en av de første som opprettet en konto i det sosiale nettverket som hadde som mål å ta sin egen ned. Han la bare en linje Til Om meg-delen: «jeg bygger ting.». Jeg tror ærlig at dette er en strålende setning, fordi den beskriver den rene essensen av koding i noen få enkle ord. Hvorfor bestemte du deg for å bli en koder? Entusiasme for tekniske løsninger? Skjønnheten i effektivitet? Uansett hva svaret ditt er, kan det ikke være » å bygge 1.000.001th bedriftens nettside med standard funksjonalitet». Men de fleste av oss tjener penger på den måten. Uansett hvor du jobber, vil du sannsynligvis bli konfrontert med kjedelige og repeterende oppgaver nå og da.

80% av tiden brukt på et programvareprosjekt er investert i 20% av funksjonaliteten.

Du trenger ikke det prinsippet (YAGNI) omhandler disse oppgavene. Det betyr i utgangspunktet: hvis det ikke er i konseptet, er det ikke i koden. For eksempel er det en vanlig praksis å abstrahere databasetilgangen i et lag som håndterer forskjellene mellom ulike drivere, som MySQL, PostgreSQL og Oracle. Hvis du jobber på et bedriftsnettsted som er vert på EN LAMP-stabel, på en delt vert, hvor sannsynlig er det at de vil endre databasen? Husk at konseptet ble skrevet med budsjett i tankene.

hvis det ikke er noe budsjett for databaseabstraksjon, er det ingen databaseabstraksjon. Hvis det mot formodning skulle oppstå en databaseendring, er det naturlig å ta betalt for endringsforespørselen.Du har kanskje lagt merke til forskjellen Mellom Du ikke trenger det og TØRRDREVNE modulære arkitekturer: sistnevnte reduserer kompleksiteten ved å dele et prosjekt i håndterbare komponenter, mens den tidligere reduserer kompleksiteten ved å redusere antall komponenter. YAGNI ligner KISS-prinsippet, da det strever etter en enkel løsning. MEN KISS streber etter en enkel løsning ved å prøve å implementere noe så enkelt som mulig; YAGNI strever for enkelhet ved ikke å implementere det i det hele tatt! Theodore Sturgeon, En Amerikansk sci-fi-forfatter, uttalte loven: «nitti prosent av alt er dritt». Dette er en veldig radikal tilnærming, og ikke altfor nyttig i virkelige prosjekter. Men husk at «crap» kan være svært tidkrevende. En god tommelfingerregel er: omtrent 80% av tiden brukt på et programvareprosjekt er investert i 20% av funksjonaliteten. Tenk på dine egne prosjekter! Hver gang jeg gjør det, er jeg overrasket over nøyaktigheten av 80: 20-regelen.

hvis du er i et selskap som er beryktet for stramme tidsfrister og upresise konsepter, er dette en kraftig strategi. Du vil ikke bli belønnet for å implementere en database abstraksjon lag. Sjansen er at sjefen din ikke vet hva et databaseabstraksjonslag selv er.

selv om dette konseptet kan høres enkelt ut, kan det være vanskelig å skille det nødvendige fra de unødvendige delene. Hvis du for eksempel er komfortabel med et bibliotek eller et rammeverk som bruker databaseabstraksjon, sparer du ikke mye tid på å dumpe den. Nøkkelbegrepet er en annen måte å se på programvare: vi er opplært til å skrive fremtidssikker og vedlikeholdbar programvare. Dette betyr at vi er opplært til å tenke fremover. Hvilke endringer kan skje i fremtiden? Dette er viktig for større prosjekter, men overhead for mindre. Ikke tenk inn i fremtiden! Hvis et lite bedriftsnettsted gjør grunnleggende endringer, må de kanskje starte fra bunnen av. Dette er ikke et betydelig problem i forhold til det totale budsjettet.

Planlegge Et Prosjekt

når du forbereder gjøremålslisten for et prosjekt, bør du vurdere følgende tanker:

• Oppnå lavere kompleksitet ved å redusere abstraksjonsnivået.
• Separat funksjonalitet fra funksjoner.
• Anta moderate ikke-funksjonelle krav.
• Identifiser tidkrevende oppgaver og bli kvitt dem.

La oss gå litt i detalj! Jeg har allerede gitt et eksempel på det første elementet i listen: ikke pakk en databasedriver rundt et databaseabstraksjonslag. Vær mistenksom på alt som legger til kompleksitet i programvarestakken din. Legg merke til at abstraksjon ofte leveres av tredjepartsbiblioteker. For eksempel-avhengig av programmeringsspråket ditt-kommer et persistenslag, som Hibernate (Java), Doctrine (PHP) eller Active Record (Ruby) med databaseabstraksjon og objektrelasjonell kartlegging. Hvert bibliotek legger kompleksitet. Det må opprettholdes. Oppdateringer, patcher og sikkerhetsrettelser må brukes.

vi implementerer funksjoner hver dag, fordi vi forventer at de skal være nyttige. Derfor tenker vi fremover og implementerer for mye. For eksempel vil mange kunder ha et mobilt nettsted. Mobil er et begrep med bred forståelse; det er ikke en designbeslutning. Det er et brukstilfelle! Folk som bruker en mobil nettside er, vi vil, mobil. Det betyr at de kanskje vil ha tilgang til annen informasjon eller funksjonalitet enn en bruker som besøker nettstedet, lagt tilbake på skrivebordet. Tenk på en kino nettsted: Brukere på bussen vil trolig ønske å få tilgang til starttidspunktet for kommende filmer, ikke 50 MB trailer.

Dårlige konsepter kan ofte identifiseres ved mangel på ikke-funksjonelle krav.

med et passende budsjett vil du utføre en dedikert analyse av kravene til mobil. Uten denne analysen, vil du bare gi den samme informasjonen som er på skrivebordet nettstedet. Dette vil være helt fint for mange omstendigheter! Fordi mobile nettlesere er veldig flink til å justere stasjonære nettsteder til skjermen, kan en radikal YAGNI-tilnærming være å ikke skrive et mobilnettsted i det hele tatt!Ikke-funksjonelle krav beskriver ikke atferden til en programvare, de beskriver flere egenskaper som kan brukes til å bedømme kvaliteten på programvaren. Siden beskrivelse av programvarekvalitet forutsetter kunnskap om programvare, kan dårlige konsepter ofte identifiseres ved mangel på ikke-funksjonelle krav. Vedlikehold, dokumentasjonsnivå og enkel integrering er eksempler på ikke-funksjonelle krav. Ikke-funksjonelle krav skal være målbare. Derfor, » siden skal lastes raskt.»er for ufattelig, «skal siden lastes om to sekunder maks under en gjennomsnittlig ytelsestest.»det er veldig konkret og målbart. Hvis DU vil bruke yagni-prinsippet, anta moderate ikke-funksjonelle krav hvis de ikke er nevnt i konseptet(eller hvis de er nevnt, men uklare). Hvis du skriver de ikke-funksjonelle kravene selv, vær realistisk: et lite selskap med 20-50 sidebesøk om dagen krever ikke tre dager med ytelsesjustering – siden siden skal lastes raskt nok fordi serveren ikke er opptatt. Hvis selskapet kan øke antall daglige besøk, bør en bedre server eller hosting pakke ikke være for dyrt.

Sist, Men Ikke minst, husk 80: 20 tommelfingerregel!

Sist, men Ikke minst, husk 80: 20 tommelfingerregel! Vi må identifisere de tidkrevende delene. Hvis en del er absolutt nødvendig, må du implementere den. Spørsmålet bør være: hvordan vil du implementere det? Må det være det siste rammeverket med et lite samfunn? Trenger du å bytte til den nettopp utgitte versjonen av et bibliotek hvis dokumentasjonen ikke er oppdatert? Skal du bruke det nye CMS, når ikke alle utvidelser er tilgjengelige? Hvor mye forskning vil være nødvendig for å gjøre det? «Det er slik vi alltid har gjort det.»er ikke en spennende tilnærming, men det vil få jobben gjort uten overraskelser.

Det er viktig å forstå at alt dette ikke betyr at du kan begynne å skrive skitten kode med hack underveis! Du skriver et lett program, ikke en rotete en! Men Du trenger ikke det er en praktisk tilnærming. Hvis det ville føre til mange linjer med kode for å redusere noen få linjer med kodeduplikater, tror jeg personlig at du kan forholde deg til budsjett og litt unDRYness er ok. Det er et lite program. Derfor er den ekstra vedlikeholdskompleksiteten akseptabel. Vi er i den virkelige verden.

La oss komme tilbake til den initale tanken: vi liker å bygge ting. Da Beethoven skrev Diabelli-Variasjonene, var det kontraktsarbeid. Jeg tror ikke han gjorde kompromisser på budsjettet. Han løp den ekstra mile, fordi han ikke ønsket å skrive gjennomsnittlig musikk; han ønsket å skrive en perfekt komposisjon. jeg antyder absolutt ikke at vi alle er genier, og at vår glans skal skinne gjennom hver linje med kode, men jeg liker å tenke på programvarearkitektur som komposisjoner. Jeg er en lidenskapelig utvikler, fordi jeg vil bygge perfekte komposisjoner, og jeg vil være stolt av de tingene jeg bygger.

hvis du vil være en erfaren og forretningssikker utvikler, må du mestre You ain ‘ t gonna need it-prinsippet. Hvis du vil beholde din lidenskap, må du kjempe mot det nå og da.

Sammendrag

programvareprinsipper er en måte å se på programvare. For meg bør et godt prinsipp være basert på et enkelt konsept, men det bør utvikle seg til en kompleks konstruksjon av ideer når de konfronteres med andre teknikker og filosofier. Hva er dine favorittprogramvareprinsipper?