Awgrymiadau ar gyfer Ysgrifennu Cod Cynaliadwy
Nid yw ysgrifennu cod yn ymwneud â chael rhaglen i "redeg" yn unig. Yn ymarferol, mae cyfran sylweddol o amser datblygu meddalwedd yn cael ei dreulio yn darllen, mireinio a datblygu cod presennol—boed yn eich cod eich hun neu god rhywun arall. Felly, mae'r gallu i ysgrifennu cod y gellir ei gynnal yn sgil hanfodol i unrhyw raglennydd. Mae cod y gellir ei gynnal yn lleihau costau cynnal a chadw, yn cyflymu ychwanegiadau nodweddion, yn lleihau bygiau, ac yn gwneud cydweithio tîm yn llawer mwy effeithiol. Dyma rai awgrymiadau ymarferol ar gyfer ysgrifennu cod glân, clir a gwydn.
1. Blaenoriaethu darllenadwyedd dros “glyfrwch”
Mae cod sy'n rhy "glyfar" yn aml yn anodd ei ddeall. Er enghraifft, gall ysgrifennu llinell gryno iawn o god edrych yn gain, ond gall fod yn ddryslyd wrth ei ail-ddarllen. Dewiswch ateb clir, hyd yn oed os yw ychydig yn hirach. Mae darllenadwyedd yn fuddsoddiad: efallai mai dim ond unwaith y byddwch chi'n ysgrifennu'r cod, ond byddwch chi'n ei ddarllen sawl gwaith.
Er enghraifft, yn lle nythu gweithrediadau lluosog i mewn i un mynegiant, gwahanwch nhw'n gamau gydag enwau newidynnau ystyrlon. Mae hyn yn helpu'r darllenydd i ddeall bwriad y rhaglen heb orfod dyfalu.
2. Defnyddiwch enwi clir a chyson
Enwau newidynnau, ffwythiannau a dosbarthiadau yw "llinell gyntaf y ddogfennaeth" ar gyfer eich cod. Dylai enwau da ddisgrifio eu rôl neu eu pwrpas, nid dim ond fformat eu data. Er enghraifft, mae `userList` yn fwy addysgiadol na `ul`, ac mae `calculateTotalPrice()` yn gliriach na `ctp()`.
Yn ogystal ag eglurder, dylai enwi fod yn gyson hefyd. Os ydych chi'n defnyddio camelCase ar gyfer newidynnau, glynu wrtho drwy gydol eich prosiect. Ar gyfer dosbarthiadau, defnyddiwch PascalCase os mai dyna'ch confensiwn iaith dewisol. Mae cysondeb yn gwneud i god deimlo'n unffurf ac yn lleihau'r llwyth meddyliol wrth ddarllen.
3. Cymhwyso egwyddor “Cyfrifoldeb Sengl”
Un o brif achosion cod sy'n anodd ei gynnal yw ffwythiannau neu ddosbarthiadau sy'n gwneud gormod o bethau. Mae'r Egwyddor Cyfrifoldeb Sengl yn awgrymu mai dim ond un prif gyfrifoldeb ddylai fod gan uned o god. Fel arfer, mae ffwythiant rhy hir yn arwydd bod angen ei ddadansoddi.
Er enghraifft, byddai swyddogaeth "proses dalu" sy'n dilysu mewnbwn, yn cyfrifo prisiau, yn cysylltu â phorth talu, ac yn anfon negeseuon e-bost ar yr un pryd yn anodd ei phrofi ac yn anodd ei newid. Drwy ei rhannu'n swyddogaethau ar wahân (dilysu, cyfrifo, taliad, hysbysu), gallwch wneud newidiadau i un rhan heb dorri'r lleill.
4. Osgowch ddyblygu (SYCH), ond peidiwch â gorwneud pethau.
Mae DRY (Peidiwch ag Ailadrodd Eich Hun) yn egwyddor bwysig: os ydych chi'n copïo'r un bloc o god sawl gwaith, bydd newid bach yn gofyn i chi olygu popeth. Mae hyn yn dueddol o wneud gwallau. Yr ateb yw echdynnu'r rhesymeg ailadroddus i mewn i swyddogaeth neu fodiwl.
Fodd bynnag, mae'n bwysig cofio y gall osgoi dyblygu gormodol hefyd niweidio darllenadwyedd. Os yw dau ddarn o god yn ymddangos yn debyg ond mewn gwirionedd mae ganddynt gyd-destunau gwahanol, gall gorfodi "haniaethu" wneud y cod yn fwy cymhleth. Dewch o hyd i gydbwysedd: ailffactorio pan fydd dyblygu yn wirioneddol ystyrlon a bod ganddo'r potensial i newid gyda'i gilydd.
5. Creu strwythur prosiect taclus
Mae strwythur ffolderi clir yn effeithio ar hwylustod cynnal a chadw. Grwpiwch ffeiliau yn ôl nodwedd neu fodiwl, nid yn ôl math o ffeil yn unig, yn enwedig ar gyfer prosiectau mawr. Mae strwythur da yn ei gwneud hi'n haws i newydd-ddyfodiaid ddeall pensaernïaeth y prosiect.
Er enghraifft, yn lle rhoi eich holl gydrannau UI mewn un ffolder fawr, gallech eu rhannu yn ôl nodwedd: `auth/`, `profile/`, `checkout/`, ac yn y blaen. Mae'r dull hwn yn helpu eich prosiect i raddio wrth iddo dyfu.
6. Cyfyngu ar gymhlethdod a gwneud y llif rhesymegol yn hawdd i'w ddilyn.
Mae cod sy'n llawn datganiadau os-fel arall wedi'u nythu, nifer o amodau, ac eithriadau arbennig yn aml yn anodd ei gynnal. Ceisiwch symleiddio'ch rhesymeg. Gallwch ddefnyddio technegau fel dychwelyd cynnar i leihau nythu, neu symud rhesymeg gymhleth i swyddogaethau bach y gellir eu henwi'n briodol.
Os oes gan ffwythiant ormod o baramedrau, mae hefyd yn arwydd o gymhlethdod. Ystyriwch ddefnyddio gwrthrych ffurfweddu (neu strwythur data) i drefnu paramedrau'n well a'u gwneud yn haws i'w hymestyn.
7. Ysgrifennwch sylwadau sy'n taro'r targed
Nid yw sylwadau yn lle cod clir. Os oes angen i chi esbonio "beth mae'r cod yn ei wneud," mae'n debyg bod angen ei wneud yn fwy darllenadwy. Fodd bynnag, mae sylwadau'n dal yn ddefnyddiol ar gyfer esbonio "pam" mae rhywbeth yn cael ei wneud, yn enwedig os oes penderfyniadau dylunio, cyfyngiadau system, neu resymau busnes penodol.
Mae enghreifftiau o sylwadau da yn cynnwys egluro pam mae algorithm penodol yn cael ei ddefnyddio oherwydd cyfyngiadau perfformiad, neu pam mae rheol ddilysu yn ymddangos yn rhyfedd oherwydd ei bod yn dilyn rheoliad. Fel hyn, ni fydd eraill yn "tacluso" y cod ac yn torri rhesymeg bwysig.
8. Defnyddiwch fformatio cod a chanllawiau arddull
Mae fformatio cyson yn gwneud i god edrych yn broffesiynol ac yn hawdd i'w ddarllen. Defnyddiwch linters a fformatwyr awtomataidd os ydynt ar gael (e.e., ESLint + Prettier ar gyfer JavaScript, Black ar gyfer Python, neu gofmt ar gyfer Go). Gyda'r offer hyn, nid oes rhaid i dimau boeni am fylchau a mewnoliad, gan fod popeth yn cael ei drin yn awtomatig.
Mae canllawiau arddull hefyd yn helpu: a ddylid defnyddio dyfynodau sengl neu ddwbl, sut i enwi ffeiliau, pryd i dorri llinellau hir, ac yn y blaen. Gall safonau bach fel y rhain wneud gwahaniaeth mawr yn y tymor hir.
9. Ysgrifennwch brofion i gynnal hyder wrth ailffactorio.
Mae cod cynaliadwy nid yn unig yn lân ond hefyd yn ddiogel i'w newid. Mae profion awtomataidd (profion uned, profion integreiddio) yn gwarantu nad yw eich newidiadau'n torri ymddygiad sefydledig. Heb brofion, mae pobl yn tueddu i fod ofn gwella cod oherwydd y risg o fygiau heb eu canfod.
Dechreuwch gyda'r adrannau hanfodol: ffwythiannau cyfrifo prisiau, rheolau disgownt, dilysu, neu fodiwlau sy'n cael eu newid yn aml. Dros amser, bydd cwmpas y prawf yn tyfu ac yn darparu amddiffyniad cryf yn erbyn atchweliadau.
10. Perfformiwch ailffactorio yn rheolaidd ac yn fesuradwy
Mae cynnal a chadw yn broses barhaus. Nid yw ailffactorio yn golygu "ailysgrifennu popeth," ond yn hytrach gwelliannau bach sy'n gwella ansawdd y cod heb newid ei ymddygiad. Trefnwch ailffactorio pan fyddwch chi'n cyffwrdd ag adran o god: tacluso ychydig, cywiro enwi, torri swyddogaeth rhy hir, neu gael gwared ar god marw.
Mae ailwampio bach, rheolaidd yn fwy diogel na ailwampio mawr, anaml. A sicrhewch bob amser eich bod yn profi digonol, neu o leiaf yn gwirio, cyn ac ar ôl newidiadau.
11. Dogfennu penderfyniadau pwysig
Yn ogystal â sylwadau cod, mae gan brosiectau da ddogfennaeth gryno fel arfer: sut i redeg y rhaglen, sut i'w hadeiladu, sut i ffurfweddu'r amgylchedd, ac esboniad pensaernïol lefel uchel. Nid oes rhaid i'r ddogfennaeth hon fod yn helaeth, ond dylai fod yn gywir ac yn hawdd dod o hyd iddi. Gall ffeil sydd wedi'i chynnal a'i chadw'n dda fel `README.md` arbed llawer o amser wrth gyflwyno aelodau newydd.
Os oes penderfyniad technegol allweddol (e.e., dewis cronfa ddata benodol, patrwm pensaernïol, neu gyfyngiad integreiddio), dogfennwch y rhesymeg. Mae hyn yn helpu'r tîm i ddeall y cyd-destun ac yn osgoi ailadrodd yr un drafodaeth.
Cau
Mae cod cynaliadwy yn ganlyniad arferion da: ysgrifennu'n glir, dadansoddi cyfrifoldebau, cynnal cysondeb, lleihau cymhlethdod, a diogelu newidiadau gyda phrofion. Nid oes cod yn berffaith, ond gall pob prosiect wella'n barhaus os yw'r tîm wedi ymrwymo i ansawdd. Drwy weithredu'r awgrymiadau uchod, byddwch mewn gwell sefyllfa i ffynnu—nid yn unig heddiw, ond hefyd yn y misoedd a'r blynyddoedd i ddod.
