Tīras koda koncepcijas, kas pielāgotas JavaScript
Clean Code JavaScript
Programmatūras inženierijas principi no Roberta C. Mārtina grāmatas Tīrs kods , pielāgots JavaScript. Šī nav stila rokasgrāmata. Tas ir ceļvedis lasāmas, atkārtoti lietojamas un atkārtoti lietojamas programmatūras izveidei JavaScript.
Satura rādītājs
- Ievads
- Mainīgie lielumi
- Funkcijas
- Objekti un datu struktūras
- Klases
- CIETS
- Testēšana
- Vienlaicīgums
- Kļūdu apstrāde
- Formatēšana
- komentāri
- Tulkošana
Ievads
Programmatūras inženierijas principi no Roberta C. Mārtina grāmatas Tīrs kods , pielāgots JavaScript . Šī nav stila rokasgrāmata. Tas ir ceļvedis lasāmas, atkārtoti lietojamas un atkārtoti lietojamas programmatūras izveidei JavaScript.
Ne visi šeit minētie principi ir stingri jāievēro, un vēl mazāk būs vispārpieņemti. Šīs ir vadlīnijas un nekas vairāk, taču tās ir kodificētas daudzu gadu kolektīvās pieredzes laikā, ko autori ir apkopojuši Tīrs kods .
Mūsu programmatūras inženierijas amats ir tikai nedaudz vairāk par 50 gadiem, un mēs joprojām daudz mācāmies. Kad programmatūras arhitektūra būs tikpat veca kā pati arhitektūra, iespējams, mums būs grūtāk ievērot noteikumus. Pagaidām ļaujiet šīm vadlīnijām kalpot par atskaites punktu, lai novērtētu jūsu un jūsu komandas izstrādātā JavaScript koda kvalitāti.
Vēl viena lieta: zinot tos, jūs uzreiz nepadarīsit labāku programmatūras izstrādātāju, un, strādājot ar tiem daudzus gadus, tas nenozīmē, ka nepieļausit kļūdas. Katrs koda fragments sākas kā pirmais melnraksts, piemēram, slapjš māls iegūst galīgo formu. Visbeidzot, pārskatot to kopā ar kolēģiem, mēs novēršam nepilnības. Nepārbaudiet sevi par pirmajiem melnrakstiem, kas jāuzlabo. Tā vietā sasit kodu!
terraform importa moduļa piemērs
Mainīgie lielumi
Izmantojiet jēgpilnus un izrunājamus mainīgo nosaukumus
Slikti:
|_+_|Labi:
|_+_|Tāda paša veida mainīgajam izmantojiet to pašu vārdu krājumu
Slikti:
|_+_|Labi:
|_+_|Izmantojiet meklējamus vārdus
Mēs lasīsim vairāk kodu, nekā mēs jebkad rakstīsim. Ir svarīgi, lai mūsu rakstītais kods būtu lasāms un meklējams. Autors nē Nosaucot mainīgos, kas galu galā ir nozīmīgi mūsu programmas izpratnei, mēs kaitējam saviem lasītājiem. Padariet savus vārdus meklējamus. Tādi rīki kā draugs.js un ESLint var palīdzēt identificēt nenosauktas konstantes.
Slikti:
|_+_|Labi:
|_+_|Izmantojiet skaidrojošos mainīgos
Slikti:
|_+_|Labi:
|_+_|Izvairieties no garīgās kartēšanas
Skaidrs ir labāks nekā netiešs.
Slikti:
|_+_|Labi:
|_+_|Nepievienojiet nevajadzīgu kontekstu
Ja klases/objekta nosaukums jums kaut ko stāsta, neatkārtojiet to mainīgā nosaukumā.
Slikti:
|_+_|Labi:
|_+_|Īssavienojumu vai nosacījumu vietā izmantojiet noklusējuma argumentus
Noklusējuma argumenti bieži ir tīrāki nekā īssavienojums. Ņemiet vērā, ka, ja tos izmantosit, funkcija nodrošinās tikai noklusējuma vērtības |_+_| argumenti. Citas “viltus” vērtības, piemēram, |_+_|, |_+_|, |_+_|, |_+_|, |_+_| un |_+_|, netiks aizstātas ar noklusējuma vērtība.
Slikti:
|_+_|Labi:
|_+_|Funkcijas
Funkciju argumenti (ideālā gadījumā 2 vai mazāk)
Funkciju parametru skaita ierobežošana ir neticami svarīga, jo tas atvieglo funkcijas pārbaudi. Ja ir vairāk nekā trīs, tas noved pie kombinatoriskā sprādziena, kurā jums ir jāpārbauda daudz dažādu gadījumu ar katru atsevišķu argumentu.
Viens vai divi argumenti ir ideāls gadījums, un, ja iespējams, jāizvairās no trim. Jebkas vairāk nekā tas ir jākonsolidē. Parasti, ja jums ir vairāk nekā divi argumenti, jūsu funkcija mēģina izdarīt pārāk daudz. Gadījumos, kad tā nav, lielāko daļu laika kā argumentu pietiks ar augstāka līmeņa objektu.
Tā kā JavaScript ļauj izveidot objektus lidojuma laikā, bez daudzām klasēm, varat izmantot objektu, ja jums ir nepieciešams daudz argumentu.
Lai būtu skaidrs, kādas īpašības funkcija sagaida, varat izmantot ES2015/ES6 destrukturēšanas sintaksi. Tam ir dažas priekšrocības:
- Kad kāds aplūko funkcijas parakstu, uzreiz ir skaidrs, kādi rekvizīti tiek izmantoti.
- To var izmantot, lai modelētu nosauktos parametrus.
- Destrukturēšana arī klonē funkcijai nodotā argumenta objekta norādītās primitīvās vērtības. Tas var palīdzēt novērst blakusparādības. Piezīme: objekti un masīvi, kas ir destrukturēti no argumenta objekta, NETIEK klonēti.
- Linters var brīdināt par neizmantotiem īpašumiem, kas būtu neiespējami bez destrukturizācijas.
Slikti:
|_+_|Labi:
|_+_|Funkcijām vajadzētu darīt vienu
Šis ir vissvarīgākais programmatūras inženierijas noteikums. Ja funkcijas veic vairāk nekā vienu darbību, tās ir grūtāk izveidot, pārbaudīt un pamatot. Ja funkciju varat izolēt tikai vienai darbībai, to var viegli pārveidot, un jūsu kods tiks nolasīts daudz tīrāk. Ja no šīs rokasgrāmatas atņemsiet neko citu, kā tikai šo, jūs apsteigsiet daudzus izstrādātājus.
Slikti:
|_+_|Labi:
|_+_|Funkciju nosaukumos ir jānorāda, ko tās dara
Slikti:
|_+_|Labi:
|_+_|Funkcijām jābūt tikai vienam abstrakcijas līmenim
Ja jums ir vairāk nekā viens abstrakcijas līmenis, jūsu funkcija parasti dara pārāk daudz. Funkciju sadalīšana nodrošina atkārtotu izmantošanu un vienkāršāku testēšanu.
Slikti:
|_+_|Labi:
|_+_|Noņemiet dublikātu kodu
Dariet visu iespējamo, lai izvairītos no koda dublikātiem. Dublēts kods ir slikts, jo tas nozīmē, ka ir vairāk nekā viena vieta, kur kaut ko mainīt, ja jums ir jāmaina kāda loģika.
Iedomājieties, ja jūs vadāt restorānu un sekojat līdzi saviem krājumiem: visiem saviem tomātiem, sīpoliem, ķiplokiem, garšvielām utt. Ja jums ir vairāki saraksti, kuros to paturat, tad, pasniedzot ēdienu ar tomātiem, tie visi ir jāatjaunina. viņos. Ja jums ir tikai viens saraksts, ir tikai viena vieta, ko atjaunināt!
Bieži vien jums ir dublēts kods, jo jums ir divas vai vairākas nedaudz atšķirīgas lietas, kurām ir daudz kopīga, taču to atšķirības liek jums izmantot divas vai vairākas atsevišķas funkcijas, kas veic gandrīz vienu un to pašu. Dublēta koda noņemšana nozīmē abstrakcijas izveidi, kas var apstrādāt šo dažādu lietu kopu tikai ar vienu funkciju/moduli/klasi.
Pareiza abstrakcija ir ļoti svarīga, tāpēc jums jāievēro SOLID principi, kas izklāstīti Klases sadaļā. Sliktas abstrakcijas var būt sliktākas par dublikātu kodu, tāpēc esiet piesardzīgs! To sakot, ja varat izdarīt labu abstrakciju, dariet to! Neatkārtojiet sevi, pretējā gadījumā jūs atjaunināsit vairākas vietas jebkurā laikā, kad vēlaties mainīt vienu lietu.
Slikti:
|_+_|Labi:
|_+_|Iestatiet noklusējuma objektus ar Object.assign
Slikti:
|_+_|Labi:
|_+_|Neizmantojiet karogus kā funkciju parametrus
Karogi norāda lietotājam, ka šī funkcija veic vairāk nekā vienu darbību. Funkcijām vajadzētu darīt vienu. Sadaliet savas funkcijas, ja tās izmanto dažādus koda ceļus, pamatojoties uz Būla vērtību.
Slikti:
|_+_|Labi:
|_+_|Izvairieties no blakusparādībām (1. daļa)
Funkcija rada blakus efektu, ja tā dara kaut ko citu, nevis uzņem vērtību un atgriež citu vērtību vai vērtības. Blakusparādība var būt rakstīšana failā, globāla mainīgā modificēšana vai nejauša visas naudas pārsūtīšana svešiniekam.
Tagad dažkārt programmā ir jābūt blakusparādībām. Tāpat kā iepriekšējā piemērā, iespējams, jums būs jāraksta failā. Ko jūs vēlaties darīt, ir centralizēt to, kur jūs to darāt. Nav vairāku funkciju un klašu, kas raksta noteiktā failā. Ir viens pakalpojums, kas to dara. Viens un vienīgais.
Galvenais ir izvairīties no izplatītām kļūmēm, piemēram, stāvokļa koplietošanas starp objektiem bez jebkādas struktūras, izmantojot mainīgus datu tipus, uz kuriem var ierakstīt jebko, un necentralizēt, kur rodas jūsu blakusparādības. Ja jūs to varat izdarīt, jūs būsiet laimīgāks nekā lielākā daļa citu programmētāju.
Slikti:
|_+_|Labi:
|_+_|Izvairieties no blakusparādībām (2. daļa)
Programmā JavaScript dažas vērtības ir nemaināmas (nemainīgas), bet dažas ir maināmas (mainīgas). Objekti un masīvi ir divu veidu mainīgas vērtības, tāpēc ir svarīgi ar tiem rīkoties uzmanīgi, kad tie tiek nodoti funkcijai kā parametri. JavaScript funkcija var mainīt objekta īpašības vai masīva saturu, kas var viegli izraisīt kļūdas citur.
Pieņemsim, ka ir funkcija, kas pieņem masīva parametru, kas attēlo iepirkumu grozu. Ja funkcija veic izmaiņas šajā iepirkumu groza masīvā — piemēram, pievienojot pirkumam preci —, tad jebkura cita funkcija, kas izmanto to pašu |_+_| masīvu ietekmēs šis papildinājums. Tas var būt lieliski, taču tas var būt arī slikti. Iedomāsimies sliktu situāciju:
Lietotājs noklikšķina uz pogas Pirkt, kas izsauc |_+_| funkcija, kas rada tīkla pieprasījumu un nosūta |_+_| masīvs uz serveri. Slikta tīkla savienojuma dēļ |_+_| funkcijai ir jāturpina atkārtot pieprasījumu. Ko darīt, ja tikmēr lietotājs pirms tīkla pieprasījuma sākšanas nejauši noklikšķina uz pogas Pievienot grozam uz preces, kuru viņš patiesībā nevēlas? Ja tas notiek un sākas tīkla pieprasījums, šī pirkšanas funkcija nosūtīs nejauši pievienoto vienumu, jo |_+_| masīvs tika modificēts.
Lielisks risinājums būtu |_+_| funkcija, lai vienmēr klonētu |_+_|, rediģētu to un atgrieztu klonu. Tas nodrošinātu, ka izmaiņas neietekmēs funkcijas, kas joprojām izmanto veco iepirkumu grozu.
Šai pieejai jāpiemin divi brīdinājumi:
Var būt gadījumi, kad jūs patiešām vēlaties modificēt ievades objektu, taču, pieņemot šo programmēšanas praksi, jūs atklāsit, ka šādi gadījumi ir diezgan reti. Lielāko daļu lietu var pārveidot, lai tām nebūtu blakusparādību!
Lielu objektu klonēšana var būt ļoti dārga veiktspējas ziņā. Par laimi, praksē tā nav liela problēma, jo tādas ir lieliskas bibliotēkas kas ļauj šāda veida programmēšanas pieejai būt ātrai un ne tik intensīvai atmiņai, kā tas būtu, ja jūs manuāli klonētu objektus un masīvus.
Slikti:
|_+_|Labi:
|_+_|Nerakstiet globālajām funkcijām
Globālo datu piesārņošana ir slikta JavaScript prakse, jo jūs varētu saskarties ar citu bibliotēku, un jūsu API lietotājs nebūtu gudrāks, kamēr ražošanā neiegūs izņēmumu. Padomāsim par piemēru: kā būtu, ja vēlaties paplašināt JavaScript vietējo masīva metodi, lai tai būtu |_+_| metode, kas varētu parādīt atšķirību starp diviem masīviem? Jūs varētu rakstīt savu jauno funkciju uz |_+_|, taču tā varētu būt pretrunā ar citu bibliotēku, kas mēģināja darīt to pašu. Ko darīt, ja šī cita bibliotēka tikai izmantoja |_+_| lai atrastu atšķirību starp masīva pirmo un pēdējo elementu? Tāpēc daudz labāk būtu vienkārši izmantot ES2015/ES6 klases un vienkārši paplašināt |_+_| globāli.
Slikti:
|_+_|Labi:
|_+_|Dodiet priekšroku funkcionālai programmēšanai, nevis obligātajai programmēšanai
JavaScript nav funkcionāla valoda tādā veidā kā Haskell, taču tai ir funkcionāls aromāts. Funkcionālās valodas var būt tīrākas un vieglāk pārbaudāmas. Kad vien iespējams, dodiet priekšroku šim programmēšanas stilam.
Slikti:
|_+_|Labi:
apis, ko izmantot projektiem|_+_|
Iekapsulēt nosacījumus
Slikti:
|_+_|Labi:
|_+_|Izvairieties no negatīviem nosacījumiem
Slikti:
|_+_|Labi:
|_+_|Izvairieties no nosacījumiem
Tas šķiet neiespējams uzdevums. Pirmo reizi to dzirdot, vairums cilvēku saka: 'Kā es varu kaut ko darīt bez |_+_| paziņojums, apgalvojums?' Atbilde ir tāda, ka daudzos gadījumos varat izmantot polimorfismu, lai sasniegtu vienu un to pašu uzdevumu. Otrais jautājums parasti ir: 'Tas ir lieliski, bet kāpēc es gribētu to darīt?' Atbilde ir iepriekšējā tīrā koda koncepcija, ko mēs uzzinājām: funkcijai vajadzētu veikt tikai vienu darbību. Ja jums ir klases un funkcijas, kurām ir |_+_| paziņojumus, jūs sakāt savam lietotājam, ka jūsu funkcija veic vairāk nekā vienu darbību. Atcerieties, dariet tikai vienu lietu.
Slikti:
|_+_|Labi:
|_+_|Izvairieties no tipa pārbaudes (1. daļa)
JavaScript nav ierakstīts, kas nozīmē, ka jūsu funkcijas var pieņemt jebkāda veida argumentus. Reizēm šī brīvība tevi sagrauj, un kļūst vilinoši veikt tipa pārbaudi savās funkcijās. Ir daudz veidu, kā izvairīties no tā. Pirmā lieta, kas jāņem vērā, ir konsekventas API.
Slikti:
|_+_|Labi:
|_+_|Izvairieties no tipa pārbaudes (2. daļa)
Ja strādājat ar primitīvām pamatvērtībām, piemēram, virknēm un veseliem skaitļiem, un nevarat izmantot polimorfismu, taču joprojām jūtat nepieciešamību veikt tipa pārbaudi, apsveriet iespēju izmantot TypeScript. Tā ir lieliska alternatīva parastajam JavaScript, jo tā nodrošina statisku rakstīšanu papildus standarta JavaScript sintaksei. Problēma ar parastu JavaScript manuālu tipa pārbaudi ir tāda, ka, lai to izdarītu labi, ir nepieciešams tik daudz papildu vārdu, ka iegūtā mākslīgā “tipa drošība” nekompensē zaudēto lasāmību. Saglabājiet savu JavaScript tīru, uzrakstiet labus testus un sniedziet labus kodu pārskatus. Pretējā gadījumā dariet to visu, izņemot ar TypeScript (kas, kā jau teicu, ir lieliska alternatīva!).
Slikti:
|_+_|Labi:
|_+_|Nepārmērīgi optimizējiet
Mūsdienu pārlūkprogrammas izpildes laikā veic daudz optimizācijas. Daudzas reizes, ja jūs optimizējat, tad jūs vienkārši tērējat savu laiku. Ir labi resursi lai redzētu, kur trūkst optimizācijas. Tikmēr atlasiet tos, līdz tie ir novērsti, ja iespējams.
Slikti:
|_+_|Labi:
|_+_|Noņemiet mirušo kodu
Mirušais kods ir tikpat slikts kā dublēts kods. Nav iemesla to paturēt savā kodu bāzē. Ja to nesauc, atbrīvojieties no tā! Ja jums tas joprojām būs nepieciešams, tas joprojām būs drošībā jūsu versiju vēsturē.
Slikti:
|_+_|Labi:
|_+_|Objekti un datu struktūras
Izmantojiet getters un seters
Getteru un iestatītāju izmantošana, lai piekļūtu datiem par objektiem, varētu būt labāka nekā vienkārša objekta rekvizīta meklēšana. 'Kāpēc?' jūs varētu jautāt. Šeit ir nesakārtots iemeslu saraksts, kāpēc:
- Ja vēlaties darīt vairāk, ne tikai iegūt objekta rekvizītu, jums nav jāmeklē un jāmaina katrs piekļuves līdzeklis savā kodu bāzē.
- Padara vienkāršāku apstiprināšanas pievienošanu, veicot |_+_|.
- Iekapsulē iekšējo attēlojumu.
- Iegūstot un iestatot, viegli pievienot reģistrēšanu un kļūdu apstrādi.
- Varat slinki ielādēt sava objekta rekvizītus, teiksim, iegūstot to no servera.
Slikti:
|_+_|Labi:
|_+_|Padarīt objektiem privātus dalībniekus
To var paveikt, izmantojot slēgšanu (ES5 un zemākām versijām).
Slikti:
|_+_|Labi:
|_+_|Klases
Dodiet priekšroku ES2015/ES6 klasēm, nevis ES5 vienkāršajām funkcijām
Klasiskajām ES5 klasēm ir ļoti grūti iegūt lasāmas klases mantojuma, konstrukcijas un metožu definīcijas. Ja jums ir nepieciešams mantojums (un ņemiet vērā, ka jums tas var nebūt nepieciešams), dodiet priekšroku ES2015/ES6 klasēm. Tomēr dodiet priekšroku mazām funkcijām, nevis klasēm, līdz jums ir nepieciešami lielāki un sarežģītāki objekti.
Slikti:
|_+_|Labi:
|_+_|Izmantojiet ķēdes metodi
Šis modelis ir ļoti noderīgs JavaScript, un tas ir redzams daudzās bibliotēkās, piemēram, jQuery un Lodash. Tas ļauj jūsu kodam būt izteiksmīgam un mazāk izteiktam. Šī iemesla dēļ es saku, izmantojiet metodes ķēdi un apskatiet, cik tīrs būs jūsu kods. Klases funkcijās vienkārši atgrieziet |_+_| katras funkcijas beigās, un tajā var pievienot papildu klases metodes.
Slikti:
|_+_|Labi:
|_+_|Dodiet priekšroku kompozīcijai, nevis mantojumam
Kā slaveni teikts Dizaina modeļi Četru banda, kur vien iespējams, jums vajadzētu dot priekšroku kompozīcijai, nevis mantošanai. Ir daudz labu iemeslu, lai izmantotu mantojumu, un daudz labu iemeslu, lai izmantotu kompozīciju. Šīs maksimas galvenais mērķis ir tāds, ka, ja jūsu prāts instinktīvi tiecas pēc mantojuma, mēģiniet domāt, vai kompozīcija varētu labāk modelēt jūsu problēmu. Dažos gadījumos var.
Jums varētu rasties jautājums, kad man vajadzētu izmantot mantojumu? Tas ir atkarīgs no jūsu problēmas, taču šis ir pienācīgs saraksts ar gadījumiem, kad mantojumam ir lielāka nozīme nekā sastāvam:
- Jūsu mantojums ir “ir-a” attiecības, nevis “ir-a” attiecības (cilvēks->Dzīvnieks pret lietotāju->Lietotāja informācija).
- Varat atkārtoti izmantot kodu no bāzes klasēm (cilvēki var pārvietoties tāpat kā visi dzīvnieki).
- Jūs vēlaties veikt globālas izmaiņas atvasinātajās klasēs, mainot bāzes klasi. (Mainiet visu dzīvnieku kaloriju patēriņu, kad tie pārvietojas).
Slikti:
|_+_|Labi:
|_+_|CIETS
Vienas atbildības princips (SRP)
Kā teikts Clean Code, “klases maiņai nekad nedrīkst būt vairāk par vienu iemeslu”. Ir vilinoši piebāzt klasi ar daudzām funkcionalitātēm, piemēram, kad lidojumā varat paņemt tikai vienu koferi. Problēma ir tāda, ka jūsu klase nebūs konceptuāli vienota, un tas dos daudz iemeslu mainīties. Ir svarīgi samazināt klases maiņas reižu skaitu. Tas ir svarīgi, jo, ja vienā klasē ir pārāk daudz funkcionalitātes un jūs modificējat tās daļu, var būt grūti saprast, kā tas ietekmēs citus atkarīgos moduļus jūsu kodu bāzē.
Slikti:
|_+_|Labi:
|_+_|Atvērtais/slēgtais princips (OCP)
Kā norādīja Bertrāns Meijers, “programmatūras entītijām (klasēm, moduļiem, funkcijām utt.) jābūt atvērtām paplašināšanai, bet slēgtām modifikācijai”. Tomēr ko tas nozīmē? Šis princips būtībā nosaka, ka jums jāļauj lietotājiem pievienot jaunas funkcijas, nemainot esošo kodu.
Slikti:
|_+_|Labi:
|_+_|Liskova aizstāšanas princips (LSP)
Tas ir biedējošs termins ļoti vienkāršai koncepcijai. Tas ir formāli definēts kā “Ja S ir T apakštips, tad T tipa objektus var aizstāt ar S tipa objektiem (t.i., S tipa objekti var aizstāt T tipa objektus), nemainot nevienu no šīs programmas vēlamajām īpašībām. (pareizība, veikts uzdevums utt.).' Tā ir vēl biedējošāka definīcija.
Labākais izskaidrojums tam ir, ja jums ir vecāku klase un bērnu klase, tad pamata klasi un bērnu klasi var izmantot savstarpēji aizstājot, nesaņemot nepareizus rezultātus. Tas joprojām var būt mulsinoši, tāpēc apskatīsim klasisko kvadrātveida taisnstūra piemēru. Matemātiski kvadrāts ir taisnstūris, taču, ja to modelējat, izmantojot mantojuma attiecību “is-a”, jūs ātri nonākat nepatikšanās.
Slikti:
|_+_|Labi:
|_+_|Interfeisa segregācijas princips (ISP)
JavaScript nav saskarņu, tāpēc šis princips netiek piemērots tik stingri kā citi. Tomēr tas ir svarīgi un aktuāli pat tad, ja JavaScript trūkst tipa sistēmas.
ISP norāda, ka 'klientus nedrīkst piespiest būt atkarīgiem no saskarnēm, kuras viņi neizmanto.' Saskarnes ir netieši līgumi JavaScript pīles rakstīšanas dēļ.
Labs piemērs, kas parāda šo JavaScript principu, ir paredzēts klasēm, kurām nepieciešami lieli iestatījumu objekti. Tas, ka klientiem nav jāiestata milzīgs daudzums iespēju, ir izdevīgi, jo lielākoties viņiem nebūs nepieciešami visi iestatījumi. Padarot tos pēc izvēles, tiek novērsta “treknā saskarne”.
Slikti:
|_+_|Labi:
|_+_|Atkarības inversijas princips (DIP)
Šis princips nosaka divas būtiskas lietas:
- Augsta līmeņa moduļiem nevajadzētu būt atkarīgiem no zema līmeņa moduļiem. Abiem jābūt atkarīgiem no abstrakcijām.
- Abstrakcijām nevajadzētu būt atkarīgām no detaļām. Detaļai jābūt atkarīgai no abstrakcijām.
Sākumā to var būt grūti saprast, taču, ja esat strādājis ar AngularJS, esat redzējis šī principa ieviešanu atkarības ievadīšanas (DI) formā. Lai gan tie nav identiski jēdzieni, DIP neļauj augsta līmeņa moduļiem uzzināt sīkāku informāciju par saviem zemā līmeņa moduļiem un tos iestatīt. To var paveikt, izmantojot DI. Milzīgs ieguvums no tā ir tas, ka tas samazina savienojumu starp moduļiem. Savienojums ir ļoti slikts izstrādes modelis, jo tas padara jūsu kodu grūti pārstrukturējamu.
Kā minēts iepriekš, JavaScript nav saskarņu, tāpēc abstrakcijas, no kurām ir atkarīgas, ir netieši līgumi. Tas ir, metodes un īpašības, ko objekts/klase pakļauj citam objektam/klasei. Tālāk esošajā piemērā netiešais līgums ir tāds, ka jebkurš Pieprasījuma modulis |_+_| būs |_+_| metodi.
Slikti:
|_+_|Labi:
nākamā js firebase mitināšana|_+_|
Testēšana
Pārbaude ir svarīgāka par piegādi. Ja jums nav testu vai nepietiekams daudzums, tad katru reizi, nosūtot kodu, jūs nebūsit pārliecināts, ka neko neesat sabojājis. Jūsu komandas ziņā ir izlemt, kas veido adekvātu summu, taču 100% pārklājums (visi paziņojumi un atzari) ir veids, kā sasniegt ļoti augstu pārliecību un izstrādātāja sirdsmieru. Tas nozīmē, ka papildus lieliskai testēšanas sistēmai jums ir jāizmanto arī a labs pārklājuma rīks .
Nav attaisnojuma nerakstīt testus. Tur ir daudz labu JS testa ietvaru , tāpēc atrodiet tādu, kam jūsu komanda dod priekšroku. Kad atrodat tādu, kas noder jūsu komandai, mēģiniet vienmēr rakstīt testus katrai jaunajai funkcijai/modulim, ko ieviešat. Ja jūsu izvēlētā metode ir Test Driven Development (TDD), tas ir lieliski, taču galvenais ir tikai pārliecināties, vai sasniedzat pārklājuma mērķus, pirms sākat kādu funkciju vai pārveidot esošu.
Viena koncepcija katrā testā
Slikti:
|_+_|Labi:
|_+_|Vienlaicīgums
Izmantojiet solījumus, nevis atzvanīšanu
Atzvani nav tīri, un tie izraisa pārmērīgu ligzdošanu. Izmantojot ES2015/ES6, Promises ir iebūvēts globāls veids. Izmantojiet tos!
Slikti:
|_+_|Labi:
|_+_|Async/Await ir pat tīrāki par Promises
Promises ir ļoti tīra alternatīva atzvanīšanai, taču ES2017/ES8 nodrošina asinhronizāciju un gaidīšanu, kas piedāvā vēl tīrāku risinājumu. Viss, kas jums nepieciešams, ir funkcija, kuras prefikss ir |_+_| atslēgvārdu, un tad jūs varat rakstīt savu loģiku obligāti bez |_+_| funkciju ķēde. Izmantojiet to, ja šodien varat izmantot ES2017/ES8 funkcijas!
Slikti:
|_+_|Labi:
|_+_|Kļūdu apstrāde
Izmestās kļūdas ir laba lieta! Tas nozīmē, ka izpildlaiks ir veiksmīgi identificējis, kad kaut kas jūsu programmā ir nogājis greizi, un tas informē jūs, apturot funkcijas izpildi pašreizējā stekā, iznīcinot procesu (Node) un paziņojot jums konsolē ar steka izsekošanu.
Neignorējiet pieķertās kļūdas
Neko nedarot ar pieķerto kļūdu, nedodat iespēju kādreiz labot minēto kļūdu vai reaģēt uz to. Kļūdas reģistrēšana konsolē (|_+_|) nav daudz labāka, jo bieži tā var pazust konsolei izdrukāto lietu jūrā. Ja iesaiņojat jebkuru koda bitu |_+_| tas nozīmē, ka jūs domājat, ka tur var rasties kļūda, un tāpēc jums ir jābūt plānam vai jāizveido koda ceļš, kad tā notiek.
Slikti:
|_+_|Labi:
|_+_|Neignorējiet noraidītos solījumus
Tā paša iemesla dēļ nevajadzētu ignorēt pieķertās kļūdas no |_+_|.
Slikti:
|_+_|Labi:
|_+_|Formatēšana
Formatēšana ir subjektīva. Tāpat kā daudzi šeit minētie noteikumi, nav stingru noteikumu, kas jums jāievēro. Galvenais ir NESTRĪDĀTIES par formatējumu. Tur ir tonnas instrumentu lai to automatizētu. Izmantojiet vienu! Tā ir laika un naudas izšķiešana, ja inženieri strīdas par formatējumu.
Par lietām, kas neietilpst automātiskā formatēšanas kompetencē (atkāpe, tabulēšanas zīmes un atstarpes, dubultpēdiņas vai vienpēdiņas utt.), skatiet šeit dažus norādījumus.
Izmantojiet konsekventu lielo burtu lietojumu
JavaScript netiek ievadīts, tāpēc lielo burtu lietojums daudz pastāsta par jūsu mainīgajiem lielumiem, funkcijām utt. Šie noteikumi ir subjektīvi, tāpēc jūsu komanda var izvēlēties, ko vien vēlas. Lieta ir tāda, ka neatkarīgi no tā, ko jūs visi izvēlaties, vienkārši esiet konsekventi.
Slikti:
|_+_|Labi:
|_+_|Funkcionālie zvanītāji un zvanītāji ir jāslēdz
Ja funkcija izsauc citu, turiet šīs funkcijas vertikāli tuvu avota failā. Ideālā gadījumā zvanītāju turiet tieši virs zvanītāja. Mēs mēdzam lasīt kodu no augšas uz leju, piemēram, avīzi. Šī iemesla dēļ lieciet kodu nolasīt šādā veidā.
Slikti:
|_+_|Labi:
|_+_|komentāri
Komentējiet tikai lietas, kurām ir biznesa loģikas sarežģītība.
Komentāri ir atvainošanās, nevis prasība. Labs kods pārsvarā pašus dokumentus.
Slikti:
|_+_|Labi:
|_+_|Neatstājiet komentētu kodu savā kodu bāzē
Versijas kontrole pastāv kāda iemesla dēļ. Atstājiet veco kodu savā vēsturē.
Slikti:
|_+_|Labi:
|_+_|Nav žurnāla komentāru
Atcerieties, izmantojiet versiju kontroli! Nav nepieciešams nedzīvs kods, komentēts kods un jo īpaši žurnāla komentāri. Izmantojiet |_+_| lai iegūtu vēsturi!
Slikti:
|_+_|Labi:
|_+_|Izvairieties no pozīcijas marķieriem
Parasti tie tikai rada troksni. Ļaujiet funkcijām un mainīgo nosaukumiem kopā ar pareizu atkāpi un formatējumu piešķirt jūsu kodam vizuālo struktūru.
Slikti:
|_+_|Labi:
|_+_|Tulkošana
Tas ir pieejams arī citās valodās:
Lejupielādes informācija:
Autors: ryanmcdermott
Avota kods: https://github.com/ryanmcdermott/clean-code-javascript
Licence: MIT