Översättarens förord: Efter att ha läst den här artikeln kan du bli förvånad eller till och med arg. Ja, vi blev också förvånade: författaren lär aldrig ha hört talas om hierarkin i teamet, om att sätta uppgifter med statusen "gör det snabbt och utan resonemang." Ja just det, det här är en lite konstig text. Faktum är att författaren föreslår att programmeraren tar rollen som systemarkitekt - varför behöver man då en arkitekt? Men alla dessa invändningar bör inte göra dig blind för det huvudsakliga - varför vi ändå tog och översatte den här texten. Han pratar inte om roller. Den här texten handlar om ett professionellt förhållningssätt och medvetenhet. Sanningen är att så länge du bara "gör vad du blir tillsagd" utan att tänka på innebörden av dina handlingar, kommer du aldrig att bli en bra programmerare.
Säg nej till onödig kod. Allt du behöver göra är att sätta ihop tre bokstäver och säga ordet. Låt oss försöka göra det här tillsammans: "Neeej!"
Men vänta. Varför gör vi det här? Trots allt är huvuduppgiften för en programmerare att skriva kod. Men behöver du skriva någon kod som efterfrågas av dig? Nej! "Att förstå när man inte ska skriva kod är förmodligen den viktigaste färdigheten för en programmerare." .
Påminnelse: för alla läsare av "Habr" - en rabatt på 10 000 rubel när du anmäler dig till någon Skillbox-kurs med hjälp av "Habr"-kampanjkoden.
Skillbox rekommenderar: Praktisk kurs .
Programmering är konsten att lösa problem. Och ni är mästare i denna konst.
Ibland, i ett försök att börja arbeta så snabbt som möjligt, tänker vi inte på något annat än att slutföra uppgiften. Och detta kan orsaka ännu allvarligare problem.
Vad blundar programmerare för?
All kod du skriver måste vara begriplig för andra utvecklare och måste testas och felsökas.
Men det finns ett problem: vad du än skriver kommer det att komplicera din programvara och förmodligen introducera buggar i framtiden.
Enligt Rich Skrent, . Så här skriver han:
”Koden är dålig eftersom den börjar ruttna och kräver konstant underhåll. Att lägga till nya funktioner kräver ofta att man ändrar gammal kod. Ju större den är, desto större är sannolikheten för att ett fel inträffar och desto längre tid tar det att kompilera. Det tar en annan utvecklare längre tid att ta reda på det. Och om det behövs omfaktorering kommer det definitivt att finnas fragment som är värda att förändra. Stor kod innebär ofta minskad flexibilitet och funktionalitet i projektet. En enkel och elegant lösning är snabbare än komplex kod.”
Hur vet man när man inte ska skriva kod?
Problemet är att programmerare ofta överdriver antalet funktioner som deras applikation behöver. Som ett resultat förblir många avsnitt av koden oavslutade eller ingen använder dem, men de komplicerar applikationen.
Du måste tydligt förstå vad ditt projekt behöver och vad det inte behöver.
Ett exempel är en applikation som bara löser en uppgift - att hantera e-post. För detta ändamål har två funktioner införts - att skicka och ta emot brev. Du bör inte förvänta dig att e-posthanteraren ska bli en uppgiftshanterare samtidigt.
Du måste bestämt säga "nej" till förslag om att lägga till funktioner som inte är relaterade till applikationens huvuduppgift. Detta är exakt det ögonblick då det står klart att ytterligare kod inte behövs.
Tappa aldrig fokus på din ansökan.
Fråga dig själv alltid:
— Vilken funktion ska implementeras nu?
— Vilken kod ska jag skriva?
Ifrågasätt de idéer som kommer att tänka på och utvärdera förslag som kommer utifrån. Annars kan extra kod helt enkelt döda projektet.
Att veta när du inte ska lägga till onödiga saker hjälper dig att hålla din kodbas under fast kontroll.
I början av sökvägen har programmeraren bara två eller tre källfiler. Det är enkelt. Att kompilera och starta programmet kräver ett minimum av tid; Det är alltid tydligt var och vad man ska leta efter.
När applikationen expanderar dyker det upp fler och fler kodfiler. De fyller katalogen, var och en med hundratals rader. För att organisera allt detta korrekt måste du skapa ytterligare kataloger. Samtidigt blir det allt svårare att komma ihåg vilka funktioner som är ansvariga för vad och vilka handlingar som orsakar dem; att fånga buggar tar också längre tid. Projektledning blir också mer komplex, inte en utan flera utvecklare krävs för att hålla reda på allt. Följaktligen ökar kostnaderna, både pengar och tid, och utvecklingsprocessen saktar ner.
Projektet blir så småningom enormt, och att lägga till varje ny funktion kräver mer och mer ansträngning. Även för något mycket obetydligt måste du spendera flera timmar. Att korrigera befintliga fel leder till att det dyker upp nya och deadlines för applikationssläpp missas.
Nu måste vi kämpa för projektets liv. Varför?
Faktum är att du helt enkelt inte förstod när du inte skulle lägga till extra kod, och svarade "ja" på varje förslag och idé. Du var blind, lusten att skapa nya saker fick dig att strunta i viktiga fakta.
Låter som ett skräckfilmsmanus, eller hur?
Det är precis vad som kommer att hända om du fortsätter att säga ja. Försök att förstå när kod inte ska läggas till. Ta bort onödiga saker från projektet - detta kommer att göra ditt liv mycket enklare och förlänga applikationens livslängd.
"En av mina mest produktiva dagar var när jag raderade 1000 XNUMX rader kod."
– Ken Thompson.
Att lära sig när man inte ska skriva kod är svårt. Men det är nödvändigt.
Ja, jag vet att du precis har slagit in på en utvecklares väg och vill skriva kod. Det är bra, tappa inte det första intrycket, men tappa inte bort viktiga faktorer ur sikte på grund av entusiasm. Vi insåg allt genom försök och misstag. Du kommer också att göra misstag och lära dig av dem. Men om du kan lära dig av ovanstående kommer ditt arbete att bli mer medvetet.
Fortsätt skapa, men vet när du ska säga nej.
Skillbox rekommenderar:
- Tillämpad onlinekurs .
- Onlinekurs .
- Praktisk årskurs .
Källa: will.com