Key Takeaways
1. Kirjuta puhas kood, mis on loetav ja hooldatav
Ainus kehtiv mõõdik koodi kvaliteedi kohta: WTFs/minuut
Loetavus on ülim. Puhas kood peaks olema teiste arendajate jaoks kergesti mõistetav. See peaks olema lihtne, elegantne ja vaba segadusest. Püüa kirjutada koodi, mis väljendab selgelt oma eesmärki ilma ulatuslike kommentaarideta. Kasuta tähenduslikke muutuja- ja funktsiooni nimesid, hoia funktsioonid väikesed ja keskendunud ning korralda kood loogiliselt.
Hooldatavus võimaldab arengut. Kood, mida on raske muuta, muutub koormaks. Kujunda oma kood paindlikuks ja modulaarseks, et see saaks kohaneda muutuva nõudlusega. Järgige põhimõtteid nagu DRY (Ära Korda Iseennast) ja SOLID, et luua nõrgalt seotud, kuid tugevalt koondatud süsteeme. Refaktoreeri halastamatult, et parandada koodi struktuuri ilma käitumist muutmata.
Puhas kood tasub end ära. Kuigi puhta koodi kirjutamine nõuab alguses rohkem pingutust, säästab see pikas perspektiivis märkimisväärselt aega ja vaeva. Puhas kood on lihtsam tõrgete leidmiseks, laiendamiseks ja hooldamiseks. See võimaldab arendajatel töötada tõhusamalt ja vähendab vigade tekkimise riski muudatuste käigus. Tee puhtast koodist oma arendustava keskne osa.
2. Järgi tähenduslikke nimede konventsioone
Muutuja, funktsiooni või klassi nimi peaks vastama kõigile suurtele küsimustele. See peaks ütlema, miks see eksisteerib, mida see teeb ja kuidas seda kasutatakse.
Kasuta kavatsust paljastavaid nimesid. Vali nimed, mis edastavad selgelt muutuja, funktsiooni ja klassi eesmärgi ja käitumise. Vältige ühekohalisi nimesid või krüptilisi lühendeid. Kasuta hääldatavaid nimesid, mida on lihtne otsida. Näiteks:
- Halb: d (möödunud aeg päevades)
- Hea: elapsedTimeInDays
Ole järjekindel ja täpne. Kasuta kogu oma koodibaasis järjekindlaid nimede konventsioone. Ole täpne, et vältida mitmeti mõistetavust - näiteks kasuta tähenduslikke eristusi nagu getActiveAccounts() ja getActiveAccountInfo(). Vältige kodeeringuid või eesliiteid, mis lisavad müra ilma väärtuseta. Klasside nimed peaksid olema nimisõnad, meetodite nimed peaksid olema tegusõnad.
Nime pikkus peaks vastama ulatusele. Kasuta pikemaid, kirjeldavamaid nimesid muutuja ja funktsioonide jaoks, mille ulatus on suurem. Lühikesed nimed on vastuvõetavad väikeste, kohalike ulatuste jaoks. Nime pikkus peaks olema proportsionaalne selle kasutuse ulatusega. Optimeeri loetavuse ja arusaadavuse nimede kontekstis, kus neid kasutatakse.
3. Hoia funktsioonid väikesed ja keskendunud
Funktsioonid peaksid tegema ühte asja. Nad peaksid tegema seda hästi. Nad peaksid tegema seda ainult.
Väike on ilus. Funktsioonid peaksid olema väikesed - tavaliselt 5-10 rida pikki. Need peaksid mahtuma ühele ekraanile ja olema koheselt arusaadavad. Ekstraheerige kood hästi nimetatud abifunktsioonidesse, mitte kirjutades pikki ja keerulisi funktsioone. Väikesed funktsioonid on lihtsamad mõista, testida ja hooldada.
Tee ühte asja hästi. Igal funktsioonil peaks olema üks selge eesmärk. Kui funktsioon teeb mitut asja, eralda need eraldi funktsioonidesse. Märgid, et funktsioon teeb liiga palju, hõlmavad:
- Mitut abstraktsiooni taset
- Mitut sektsiooni või koodiplokki
- Arvukalt parameetreid
Säilita üks abstraktsiooni tase. Funktsiooni sees olevad väited peaksid olema kõik samal abstraktsiooni tasemel. Ära sega kõrgetasemelist loogikat madala taseme detailidega. Ekstraheerige madalama taseme toimingud eraldi funktsioonidesse. See parandab loetavust, hoides funktsioonid keskendunud ja kontseptuaalselt lihtsad.
4. Harjuta õiget vormindamist ja organiseerimist
Koodi vormindamine on suhtlemise küsimus, ja suhtlemine on professionaalse arendaja esimene prioriteet.
Järjekindel vormindamine on oluline. Kasuta kogu oma koodis järjekindlat sissetoomist, reavahe ja vahemaid. See parandab loetavust ja vähendab kognitiivset koormust. Lepi oma meeskonnaga kokku vormindamisstandardites ja kasuta automatiseeritud tööriistu nende rakendamiseks. Peamised vormindamisjuhised hõlmavad:
- Õiget sissetoomist
- Järjekindlat sulgude paigutust
- Loogilisi reavahe
- Sobivat tühikut
Organiseeri kood loogiliselt. Grupeerige seotud kood koos ja eraldage mitteseotud kood. Kasuta tühje ridu, et luua "paragrahvi" pause loogiliste sektsioonide vahel. Aseta seotud funktsioonid üksteise lähedale. Hoia faile keskendunud ühele kontseptsioonile või komponendile. Jagage suuri faile väiksemateks, keskendunumateks, kui see on asjakohane.
Järgi standardseid konventsioone. Järgige oma keele ja kogukonna standardseid konventsioone. See muudab teie koodi teiste arendajate jaoks tuttavamaks ja kergemini ligipääsetavaks. Näiteks Java-s:
- Klasside nimed kasutavad PascalCase
- Meetodite nimed kasutavad camelCase
- Konstantid kasutavad ALL_CAPS
5. Halda sõltuvusi ja väldi dubleerimist
Dublikaat võib olla kõikide kurjuse juur tarkvaras.
Eemalda dubleerimine. Dubleeritud kood on võimalus abstraktsiooniks. Kui näed dubleerimist, ekstraheeri ühine kood taaskasutatava funktsiooni või klassi. See parandab hooldatavust, keskendades loogika ja vähendades ebajärjekindlate muudatuste riski. Dubleerimise tüübid, millele tähelepanu pöörata:
- Identsed koodiplokid
- Sarnased algoritmid väikeste variatsioonidega
- Korduvalt switch/case või if/else ahelad
Halda sõltuvusi ettevaatlikult. Minimeeri sõltuvusi moodulite vahel, et vähendada sidumist. Kasuta sõltuvuse süstimist ja kontrolli pööramist, et muuta kood modulaarsemaks ja testitavamaks. Järgige sõltuvuse pööramise põhimõtet - sõltuge abstraktsioonidest, mitte konkreetsetest asjadest. See muudab teie koodi paindlikumaks ja kergemini muudetavaks.
Kasuta vähese teadlikkuse põhimõtet. Moodul ei tohiks teada objektide sisust, millega ta manipuleerib. See vähendab moodulite vahelist sidumist. Näiteks, kasuta Demeteri seadust - meetod peaks kutsuma meetodeid ainult:
- Oma objektilt
- Parameetritena edastatud objektidelt
- Loobitud objektidelt
- Otsestelt komponentobjektidelt
6. Käsitle vigu kenasti
Vigade käsitlemine on oluline, kuid kui see varjab loogikat, on see vale.
Kasuta erandeid, mitte veakoodide. Erandid on puhtamad ja ei sega koodi peamist loogikat. Need võimaldavad vigade käsitlemist eraldada õnnelikust teest. Erandeid kasutades:
- Loo informatiivsed veateated
- Anna konteksti eranditega
- Määra erandite klassid vastavalt kutsuja vajadustele
Ära tagasta nulli. Nulli tagastamine viib nulli näitaja eranditeni ja segab koodi nulli kontrollidega. Selle asemel:
- Tagasta tühjad kogud, mitte null loendite jaoks
- Kasuta Null Object mustrit
- Kasuta Java-s Optional või funktsionaalsetes keeltes Maybe
Kirjuta try-catch-finally avaldused esimesena. Alusta try-catch-finally kirjutamisest, kui kirjutad koodi, mis võib visata erandeid. See aitab määratleda ulatuse ja ootused kutsuva koodi jaoks. See tagab, et ressursse hallatakse ja vabastatakse korralikult, isegi vigade korral.
7. Kirjuta põhjalikud üksustestid
Testikood on sama oluline kui tootmiskood.
Järgi TDD kolme seadust. Testipõhine arendus (TDD) parandab koodi kvaliteeti ja disaini:
- Kirjuta ebaõnnestuv test enne tootmiskoodi kirjutamist
- Kirjuta ainult piisavalt testi, et näidata ebaõnnestumist
- Kirjuta ainult piisavalt tootmiskoodi, et test läbida
Hoia testid puhtad ja hooldatavad. Rakenda sama koodi kvaliteedi standardit oma testide jaoks nagu tootmiskoodi puhul. Refaktoreeri ja paranda testikoodi regulaarselt. Hästi struktureeritud testid toimivad dokumentatsioonina ja võimaldavad kartmatut tootmiskoodi refaktoreerimist.
Püüa saavutada põhjalikku testikattvust. Kirjuta teste, mis katavad äärmuslikke juhtumeid, piiriolukordi ja veasenaariume - mitte ainult õnnelikku teed. Kasuta koodi katvuse tööriistu, et tuvastada testikattvuse lünki. Pea meeles, et 100% katvus ei garanteeri vigadeta koodi, kuid see annab kindlust refaktoreerimise ja muudatuste tegemisel.
8. Refaktoreeri koodi pidevalt
Jäta telkimisala puhtamaks, kui leidsid.
Refaktoreeri võimaluste järgi. Paranda koodi struktuuri iga kord, kui töötad koodilõiguga. Järgi Boy Scout reeglit: jäta kood paremaks, kui leidsid. Väikesed, järkjärgulised parandused kogunevad aja jooksul ja takistavad koodi lagunemist. Tavalised refaktoreerimise tehnikad hõlmavad:
- Meetodite või klasside ekstraheerimist
- Selguse nimede muutmist
- Keeruliste tingimuste lihtsustamist
- Dublikaadi eemaldamist
Refaktoreeri ohutult testide abil. Alati peab olema tugev testide komplekt enne refaktoreerimist. Tee väikeseid, järkjärgulisi muudatusi ja jookse teste sageli. See annab sulle kindlustunde, et sinu muudatused ei riku olemasolevat funktsionaalsust. Kasuta automatiseeritud refaktoreerimise tööriistu, kui need on saadaval, et vähendada vigade tekkimise riski.
Tasakaalusta refaktoreerimine ja väärtuse toomine. Kuigi pidev refaktoreerimine on oluline, ära lase sellel edusamme takistada. Püüa saavutada "piisavalt hea" asemel täiuslikkust. Keskenda refaktoreerimise jõupingutused kõige probleemsematele või sagedamini muudetavatele koodialadele. Suhtle refaktoreerimise väärtusest sidusrühmadega, et tagada toetust pidevale koodi parandamisele.
9. Rakenda objektorienteeritud ja funktsionaalsete programmeerimise põhimõtteid
Objektid peidavad oma andmed abstraktsioonide taha ja paljastavad funktsioonid, mis töötavad nende andmete kallal. Andmestruktuurid paljastavad oma andmed ja neil pole tähenduslikke funktsioone.
Kasuta objektorienteeritud põhimõtteid targalt. Rakenda põhimõtteid nagu kapseldamine, pärimine ja polümorfism, et luua paindlikke ja modulaarseid disaine. Järgi SOLID põhimõtteid:
- Ühe vastutuse põhimõte
- Avatud-suletud põhimõte
- Liskovi asendamise põhimõte
- Liidese jagamise põhimõte
- Sõltuvuse pööramise põhimõte
Kasuta funktsionaalsete programmeerimise kontseptsioone. Isegi objektorienteeritud keeltes võivad funktsionaalsed programmeerimise tehnikad viia puhtama koodini:
- Puhtad funktsioonid ilma kõrvalmõjudeta
- Muutumatud andmed
- Kõrgema järgu funktsioonid
- Funktsiooni kompositsioon
Vali õige lähenemine probleemi jaoks. Objektorienteeritud ja funktsionaalsetel paradigmadel on igaühel oma tugevused ja nõrkused. Kasuta objektorienteeritud disaini, kui pead modelleerima keerulisi domeene koos käitumisega. Kasuta funktsionaalseid lähenemisviise andmete transformeerimiseks ja töötlemise torude jaoks. Paljud kaasaegsed keeled toetavad hübriidset lähenemist, võimaldades sul kasutada parimat tööriista iga osa jaoks oma süsteemis.
10. Kaalu konkurentsi hoolikalt
Konkurents on lahtiühendamise strateegia. See aitab meil eraldada, mis tehakse, millal see tehakse.
Mõista konkurentsi väljakutseid. Konkurentsprogrammimine toob kaasa keerukuse ja võimalike peente vigade. Tavalised probleemid hõlmavad:
- Võistlusolukorrad
- Deadlock'id
- Puuduvad signaalid
- Mälu nähtavuse probleemid
Eralda konkurentsi mured. Hoia oma konkurentsiga seotud kood eraldi muust koodist. See muudab selle mõistmise ja testimise lihtsamaks. Kasuta abstraktsioone nagu Executors, Futures ja Actors, et hallata konkurentsi, mitte töötada toorete lõimede kallal.
Eelista muutumatust ja puhtaid funktsioone. Muutumatud objektid ja puhtad funktsioonid on loomulikult lõimede ohutud. Need kõrvaldavad paljusid konkurentsi probleeme, vältides jagatud muudetavat olekut. Kui muudetav olek on vajalik, kasuta õigeid sünkroniseerimistehnikaid ja kaalu atomaarsete muutujate või konkurentsivõimeliste kogude kasutamist.
Last updated:
FAQ
What's "Clean Code: A Handbook of Agile Software Craftsmanship" about?
- Focus on Clean Code: "Clean Code" by Robert C. Martin emphasizes writing code that is easy to read, understand, and maintain.
- Professionalism in Coding: It argues that clean code is a hallmark of professionalism in software development.
- Practical Advice: The book provides guidelines, examples, and case studies to help developers write clean and efficient code.
Why should I read "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Improve Coding Skills: It teaches how to write code that is clean, efficient, and maintainable.
- Learn from Experts: Part of the Robert C. Martin series, known for its technical and pragmatic approach.
- Long-term Benefits: Writing clean code reduces maintenance costs and makes you a more valuable developer.
What are the key takeaways of "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Code Readability: Emphasizes that code should be easy to read and understand.
- Single Responsibility Principle: Advocates for each class or function to have one reason to change.
- Continuous Improvement: Encourages developers to continuously improve their code, following the Boy Scout Rule.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" define clean code?
- Elegance and Efficiency: Clean code is described as elegant and efficient, with minimal dependencies.
- Readable and Maintainable: It should read like well-written prose, making the designer's intent clear.
- Focused and Single-minded: Each function, class, and module should have a single, clear purpose.
What is the Single Responsibility Principle in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- One Reason to Change: A class or module should have one, and only one, reason to change.
- Improves Cohesion: Ensures that classes are cohesive, with closely related methods and variables.
- Facilitates Maintenance: Makes the code easier to maintain and extend, reducing the impact of changes.
What is the "Boy Scout Rule" mentioned in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Continuous Improvement: Suggests leaving the codebase cleaner than you found it.
- Small, Incremental Changes: Encourages making small improvements, like renaming variables or breaking up functions.
- Professional Responsibility: Presented as a professional responsibility to ensure maintainability.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" approach Test-Driven Development (TDD)?
- Fundamental Discipline: TDD is crucial for writing clean, reliable code.
- Three Laws of TDD: Write a failing test first, write code to pass the test, then refactor.
- Benefits: Helps catch bugs early and improves code design.
What are "code smells" according to "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Definition: Indicators of potential problems that hinder readability or maintainability.
- Examples: Long methods, large classes, and duplicated code.
- Addressing Smells: Provides heuristics and refactoring techniques to improve code quality.
How does "Clean Code: A Handbook of Agile Software Craftsmanship" suggest handling exceptions?
- Prefer Exceptions: Use exceptions instead of error codes for better context and management.
- Provide Context: Include meaningful messages and context when throwing exceptions.
- Avoid Checked Exceptions: Suggests using unchecked exceptions for cleaner code.
What role do unit tests play in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Ensure Code Quality: Unit tests ensure code works as intended and remains maintainable.
- Test-Driven Development: Advocates writing tests before production code.
- Clean and Readable Tests: Tests should be as clean and readable as production code.
What is the role of refactoring in "Clean Code: A Handbook of Agile Software Craftsmanship"?
- Continuous Improvement: Refactoring improves code structure and readability without changing functionality.
- Techniques: Provides techniques like Extract Method and Rename Variable to enhance code quality.
- Fearless Refactoring: With comprehensive tests, developers can refactor confidently.
What are the best quotes from "Clean Code: A Handbook of Agile Software Craftsmanship" and what do they mean?
- "Clean code does one thing well." Emphasizes focus and clarity in code.
- "Leave the campground cleaner than you found it." Encourages continuous improvement of the codebase.
- "You know you are working on clean code when each routine you read turns out to be pretty much what you expected." Highlights the importance of readability and predictability.
Review Summary
Puhas Kood saab peamiselt positiivset tagasisidet oma põhimõtete eest loetava ja hooldatava koodi kirjutamisel. Lugejad hindavad praktilisi nõuandeid nimede, funktsioonide ja testimise osas. Raamatu Java keskendumine ja mõned liiga ranged juhised on levinud kriitika allikad. Paljud peavad seda arendajatele hädavajalikuks lugemiseks, kuigi mõned leiavad, et see on kogenud programmeerijatele vähem kasulik. Juhtumiuuringud ja refaktooringu näited saavad osalt kiitust, kuid teised kritiseerivad neid ülepingutatud. Üldiselt on arvustajad ühel meelel, et raamat pakub väärtuslikke teadmisi koodi kvaliteedi kohta, isegi kui mitte kõik soovitused ei ole universaalselt rakendatavad.
Similar Books
