Share
Vi har alla våra dåliga vanor. I den här artikeln går vi över en lista över dåliga rutiner som är värda att granska, omvärdera och korrigera omedelbart.
Publicerad handledningVarje par veckor besöker vi några av våra läsares favoritinlägg från hela webbplatsens historia. Denna handledning publicerades först i februari 2011.
Varje gång jag öppnar ett projekt som inte är mitt, åtföljs det av en rädsla för att jag går in i något slags Temple of Doom-scenario, fylld av fälleldörrar, hemliga koder och den enda raden av kod som på förändring, hämtar hela appen (och möjligen skickar en jättestor sten som snubblar mot mig ner i en smal hall).
När vi har fel, och allt är bra bortsett från några mindre skillnader i "hur jag skulle ha gjort det", andas vi lättnadslugan, rulla upp ärmarna och dyka in i projektet.
Men när vi har rätt ... Jo, det är en helt annan historia.
Vår första tanken på att se den här olyckliga röra är vanligtvis i linje med "Vem fan tycker den här killen att han är?" Och med rätta vilken typ av programmerare skulle villigt skapa en sådan ohålig röra ut ur ett projekt?
Fruktansvärda koden är ackumuleringen av flera små genvägar eller medgivanden.
Din första instinkt kan vara att anta att den kille som byggde projektet är en nybörjare, eller kanske är han bara en idiot. Men det är inte alltid fallet.
Min teori är att hemsk kod är ackumuleringen av flera små genvägar eller medgivanden - lika ofta som det är en produkt av oerfarenhet eller dumhet. Detta gör Appel-templet mycket skrämmande, för den som byggt det kan vara lika smart, kunnig och välläsad som du är. De blev bara lata eller sätta saker ihop ihop, och var och en av de små genvägarna lade upp i den svängande mardrömmen som bara föll i knäet.
Ännu skrämmare, det kan innebära att någon gång ärft någon din kod och strax brista i tårar.
Det gör aldrig ont om att ompröva din nuvarande praxis och se till att du inte tar några genvägar som kan bidra till någon annans förlorad sömn.
Låt oss ta några minuter och gå över några vanliga genvägar, medgivanden och andra dåliga rutiner för att se till att våra projekt inte slår rädsla i bybornas hjärtan.
Innan du skriver en enda kod, borde du ha en solid plan för attack.
Innan du skriver en enda kod, borde du ha en solid plan för attack. Detta hjälper till att hålla dig på rätt spår och undviker vandrande kod som kommer att förvirra dig senare, för att inte tala om någon annan dålig själ.
Ett tillvägagångssätt som har sparat mig tid - både i utveckling och kommentar - är att skriva en skiss i kommentarer först:
Som du kan se, utan att skriva en enda kod, vet jag nästan exakt vad filen kommer att se ut. Bäst av allt kan du planera en hel applikation på det här sättet, och om du kommer till en punkt där en funktion kräver en funktionalitet, tweak till en annan, allt du behöver göra är att ändra kommentaren.
Det kräver en förändring i hur du närmar dig utveckling, men det kommer att göra dina projektorganisationskunskaper gå genom taket.
NOTERA: Några av dessa kommentarer är inte nödvändiga. några av dem kommer att förändras andra kommer att behöva läggas till - det är förväntat. Det här är typiskt som att skriva en skiss för ett papper eller skriva en livsmedelsbutik: det håller dig bara på rätt spår när du går för att avsluta jobbet.
Du kommenterar inte något
Men det enda värsta problemet med de flesta kod som jag stöter på är att det är dåligt kommenterat, eller inte kommenterat alls.
Det gör mig ledsen att jag måste skriva ner det här. När något är så enkelt som att kommentera, borde det inte vara något vi måste påminna varandra om att göra.
Men det enda värsta problemet med de flesta kod som jag stöter på är att det är dåligt kommenterat, eller inte kommenterat alls. Detta lägger inte bara en bra del av tiden till min första förtrogenhet med projektet, men det garanterar ganska mycket att en fix som görs med hjälp av en okonventionell metod ur nödvändighet kommer att förvirra mig. Därefter, om jag slutar göra någon refactoring, kommer jag oavsiktligt att bryta appen eftersom jag inte har stött på de förmildrande omständigheterna som krävde åtgärden.
Denna process kan ta var som helst från 10 minuter till 6 timmar. (Och du har gjort det här för mig, jag vet var du bor. Jag kommer till dig.)
Så säg detta högt:
jag, [ange ditt namn], Härmed svär att kommentera i alla situationer där syftet med koden jag har skrivit inte är omedelbart uppenbart.
"Omedelbart uppenbart" hänvisar till kod som inte kan vara självdokumentande (eftersom det inte skulle vara rimligt att göra det) och / eller inte fullbordar en dödlig uppgift. Tänk på det här sättet: om du var tvungen att sluta och tänka på din lösning i mer än några sekunder, förtjänar det förmodligen en snabb förklaring.
För att illustrera min punkt kommer jag att använda ett exempel från en artikel som jag skrev nyligen för nybörjare. Tänk på följande:
$ pieces = explodera ('.', $ image_name); $ extension = array_pop ($ bitar);Vad gör det? Måste du sluta och tänka på det? Vet du fortfarande inte säkert vad som lagras i $ förlängning?
Titta på det stycket igen, men med en snabb kommentar:
// Hämta förlängningen av bildfilnamnet $ pieces = explodera ('.', $ Image_name); $ extension = array_pop ($ bitar);Fem sekunder i taget kommer att lägga upp på ett stort sätt.
Nu kollar den här koden inte kräver någon extra hjärnkraft: du ser kommentaren, ser koden och behöver aldrig ifrågasätta sin avsikt.
Det kan bara spara dig fem sekunder av kontemplation, men om du har en komplex app kommer fem sekunder åt gången att lägga upp på ett stort sätt.
Så sluta göra ursäkter. Skriv den jävla kommentaren.
Du uppoffrar klarhet för bräcklighet
Goda exempel på att offra tydlighet för korthet inkluderar oklara variabla namn och släppa de lockiga axlarna.
Det är en universell frestelse att få något gjort i så få tecken som möjligt, men den frestelsen är typ av som frestelsen att bara ha ett par underkläder: Visst, tvätten görs snabbt, men de problem som uppstår ur ditt val enormt uppväger fördelarna.
Goda exempel på att offra tydlighet för korthet inkluderar korta, oklara variabla namn (t.ex.
$ a- vad gör$ abutik?) och släppa de lockiga axlarna.Att lossa lockiga hängslen från kontrollstrukturerna är en speciell mina älskling. Om du inte gillar lockiga axlar, byt till Python. I PHP är det bara för lätt att förlora meningen utan dem.
Titta till exempel på den här uppsättningen nestade if-else-utlåtanden utan lockiga hängslen:
5) eko "Större än 5!"; annars eko "Mindre än 5!"; annars eko "Större än 10!"; eko "
En annan anteckning. ";I ett ögonblick ser det ut som att den sista raden bara skulle kunna avfyra om värdet av
$ fooär större än 10. Men vad som faktiskt händer är ett fall av felaktig indragning; Det sista eko-uttalandet kommer att skjuta oavsett vilket$ foobutiker.Kan du räkna ut om du tittar på det i några sekunder och vet att om-annat uttalanden utan lockiga hängslen bara påverkar den närmaste nästa raden? Självklart.
Ska du slösa bort den energi som räknar ut det? Absolut inte.
Att lägga till lockiga hängslen lägger till några rader, men det klargör uttalandet oerhört, även med den udda indragningen:
5) echo "Större än 5!"; annars echo "Mindre än 5!"; annars echo "Större än 10!"; eko "
En annan anteckning. ";Ja, det är bra att hålla koden noggrann, men inte på bekostnad av tydligheten. Det är värt de extra linjerna för att säkerställa att ingen måste slå huvudet mot ett tangentbord som försöker sikta genom din kod.
Du följer inte en kodningsstandard
Välj en standard och hålla fast vid den.
Att bli söt med din formatering kan tillfredsställa dina konstnärliga uppmaningar, men det gör inget bra för någon. Välj en standard (jag rekommenderar PEAR-kodningsstandarden) och hålla fast vid den. Alla kommer att tacka dig. (Inklusive dig själv, en dag.)
Lita på mig. Jag var den där killen en gång - jag ville ha en "signaturstil" - och jag slösat bort många timmar med att fixa min fruktansvärda formatering senare. Det är dags att vara annorlunda och en tid att göra det som alla andra.
När det gäller programmering, tänk på det som ett talat språk. Grammatik och skiljetecken finns av en anledning: så vi kan tydligt förstå varandra när vi skriver ner sakerna. Tänk på kodningsstandarder som en geeky version av Strunk & Whites Style Elements - enligt riktlinjerna betyder det att människor förstår vad du försöker säga, inte att du är en tråkig person.
Du kopiera kod
Du gör fel.
Försök att titta på varje enskild del av din app som något som behöver ändras vid någon tidpunkt. Om det gör, måste du uppdatera mer än en fil? Om du svarade ja, är det dags att omvärdera hur du skriver kod.
Om du har kod som gör samma sak på mer än ett ställe i din app gör du det fel.
Du följer inte ett utvecklingsmönster
Du borde alltid ha en struktur när du kodar.
Du borde alltid ha en struktur när du kodar. Jag menar inte att du måste följa MVC-mönstret eller något lika styvt, men jag menar att du borde veta hur man klassificerar komponenter och var de ska gå.
Genom att följa ett logiskt utvecklingsmönster blir många beslut automatiska, och någon som kommer in i din kod behöver inte gissa mycket när man letar efter en viss funktionalitet i din codebase.
Det tar inte lång tid, och det kommer verkligen att klargöra dina appar på ett stort sätt.
Du är för smart för ditt eget gott
Den enklaste lösningen är vanligtvis den mest lämpliga
Det finns en bra linje mellan en smidig lösning och en överkomplicerad.
Det är alltid frestande att prova lite sött nytt trick du har lärt dig, men vi måste motstå strävan att tvinga en komplex lösning till ett utrymme där en enkel är tillräcklig.
På en grundläggande nivå är den enklaste lösningen vanligtvis den mest lämpliga. Du försöker komma ifrån punkt A till punkt B - tar en omväg genom punkt Awesome är kul, men lägger verkligen inte till några fördelar.
Din super söta lösning utgör emellertid ett problem där någon annan kanske inte har sett den speciella lösningen och kommer att gå vilse. Det är inte för att de inte är lika smarta som du heller; det är troligt för att de inte såg den artikeln eller försökte inte tvinga ett kvadratkonsept till ett runt problem.
Stöt inte dig själv, men kom ihåg att undvika överkomplicerade saker "bara".
Du är en Wang
Undvik att aktivt göra din kod svår att förstå till varje pris.
När jag först började utveckla, arbetade jag med en kille som var en självutnämnd "expert" programmerare. När jag hade en fråga om ett koncept gav han mig aldrig ett rakt svar; För att få svaret på min ursprungliga fråga, var jag tvungen att svara på ett par preliminära frågor för att "bevisa att du kan hantera svaret."
Den här killen var också riktigt bra på att skriva kod som var kryptisk, obfuscated och bara vanligtvis förvirrad.
Filer som hans är resultatet av programmerare som tycker att de behöver göra deras kod svårt att läsa för att "hålla idioterna ute".
Den allmänna filosofin bakom detta tenderar att vara "Om du inte är tillräckligt smart för att förstå den här koden, borde du inte vara i den i första hand."
Det här är en djupt missvisad och antisocial inställning till programmering. Det är ett mycket elitistiskt sätt att titta på saker, och det visar att programmeraren har förlorat kontakten med sina nybörjarerötter när han själv behövde hjälp.
Undvik att aktivt göra din kod svår att förstå till varje pris. Det gör dig inte något kallare eller smartare, och det stärker inte respekten. Det gör dig bara en wang.
Dude, vad pratar du om?
Om du slutar lära sig, är de projekt du arbetar på fast i vilken tid du bestämde dig för att bosätta dig.
Förutom genvägarna och generell latskap ovan är en annan sak som kan hålla dig tillbaka en brist på fortsatt lärande och framåtskridande framsteg.
Tekniken förändras inte eftersom samhället som helhet är uttråkad och vi bestämde oss för att renovera; De flesta nya tekniker framstår som effektivare och lättare att lösa existerande problem. Att välja att ignorera framsteg är att välja att starta den långsamma processen att marginalisera din kompetens.
Här är några saker vi alla kan sluta göra för att se till att våra kompetenser är aktuella, allt utan att ge upp våra helger.
Du försöker göra allt själv
Ta reda på vilka av dessa programmerare har en liknande inställning och låta dem fylla dig på de stora nyheterna.
Du kan inte hålla koll på hela samhället. Som någon som någonsin försökt att hålla sig med en prenumeration på 200 + tech bloggar kommer att berätta att det helt enkelt inte kan ske inom en rimlig tidsram.
Lyckligtvis finns det inom samhället som ägnar sig åt att titta på teknikens utveckling och rapportera sina resultat. Om du tar dig tid att ta reda på vilken av dessa programmerare som har liknande inställning och stil, kan du låta dem fylla dig på de stora nyheterna.
Att titta på 2-5 av dessa "tidiga adopter" -typbloggar kan vara mer fördelaktigt än att prenumerera på varje techblogg du stöter på av flera anledningar:
Bland de PHP bloggare jag litar på är David Walsh och Chris Shiflett.
Jag menar helt enkelt att du kommer att känna dig mer uppfylld som programmerare och se dina talanger utvecklas mer och mer om du väljer att alltid titta på nästa nivå av programmering.
Om du inte gör något som utmanar dig, är något fel. Att hitta nya utmaningar inom projekt är det mesta som gör programmering givande (eller åtminstone det borde vara).
Försök fråga dig själv följande frågor när du börjar titta på nya projekt:
Tänk på: Jag pratar inte om att göra något grovt komplicerat, här.
Det kan vara så enkelt som att komma ihåg att lägga till Docblocks till dina objekt eller så komplicerat som att göra din app kompatibel med XMLRPC så det är lättare för användarna att lägga upp uppdateringar.
Försök bara att inte bosätta dig och övertyga dig själv, du har lärt dig allt du ska lära dig. Då börjar det bli ful för dig.
Diskutera alltid din kod med dina medprogrammerare.
Det bästa sättet att förbättra är att diskutera din kod med dina medprogrammerare. Detta kan göras genom flera möjligheter: om du känner dig särskilt utåtriktad skriver du en handledning eller släpper ett open source-projekt; om du inte känner till någonting av den omfattningen, kanske du kan hänga på ett community forum och erbjuda hjälp till nykomlingarna.
"Hur hjälper hjälpmedlemmarna mig att göra framsteg?" du frågar. Vanligtvis, om du lägger upp en lösning som kan optimeras, kommer andra erfarna programmerare att hoppa in och erbjuda tweaks. Så detta tillvägagångssätt är en dubbel-whammy av awesomeness: du hjälper inte bara till att utveckla samhället genom att erbjuda din kunskap till nybörjare, men du skärper din egen kompetens genom att hänga dina kakor ut för alla att se och hjälpa dig att utvecklas.
Om du vill komma in i något nytt och coolt, det är lite för inblandat att sätta i ett verkligt projekt är det bästa sättet att lära sig att starta ett sidoprojekt som använder tekniken.
På så sätt kan du utvecklas i din egen takt, på fritiden, och riskerar aldrig att missa en deadline eller "göra fel".
Om vi gör det rätt borde vi alltid förbättra. Och logiken säger att om vi är bättre nu då var vi sämre förut. Och om vi följer den här resonemanget tillräckligt långt, var det en punkt där vi var hemska.
Jag vet att när jag tittar tillbaka på någon av de koden jag skrev tidigare, är jag förskräckt.
Vi kommer aldrig att bli perfekta. Men vi kan göra allt som står i vår makt för att se till att vi kommer så nära som möjligt.
Vad håller du på med ditt husdjur när du hanterar andra utvecklarers kod? Låt mig veta i kommentarerna!
Accentsconagua