Ես սիրում եմ վերամշակում: Ոչ, այսպես չէ: Ես սիրում եմ վերամշակում: Ոչ, նույնիսկ դա: Ի ՍատանաԵս սիրում եմ վերամշակում:
Տանել չեմ կարողանում վատ կոդն ու վատ ճարտարապետությունը։ Ես ցնցվում եմ, երբ գրում եմ նոր գործառույթ, և հաջորդ դասը լրիվ խառնաշփոթ է: Ես պարզապես չեմ կարող նայել տխուր անվանված փոփոխականներին: Երբեմն քնելուց առաջ փակում եմ աչքերս և պատկերացնում, թե ինչ կարող է բարելավվել նախագծում: Երբեմն ես արթնանում եմ առավոտյան ժամը երեքին և գնում եմ նոութբուքս՝ ինչ-որ բան շտկելու: Ես ուզում եմ, որ կոդը լինի ոչ միայն կոդ զարգացման ցանկացած փուլում, այլ արվեստի գործ, որը հաճելի է դիտել և հաճելի աշխատել:

Եթե ​​նույնիսկ մի փոքր կիսվեք իմ զգացմունքներով, ապա մենք խոսելու բան ունենք։ Փաստն այն է, որ ժամանակի ընթացքում իմ ներսում ինչ-որ բան սկսեց ինձ ասել, որ ամեն ինչ, ամենուր և անընդհատ վերափոխելը լավագույն գաղափարը չէր: Ինձ սխալ չհասկանաք, կոդը պետք է լավը լինի (և ավելի լավ կլիներ, որ այն կատարյալ լիներ), բայց դաժան իրականության մեջ միշտ չէ, որ խելամիտ է անընդհատ կատարելագործել կոդը: Ես ինքս ինձ համար մի քանի կանոններ եմ մշակել վերամշակման ժամանակին մասին: Եթե ​​ես սկսում եմ քոր առաջանալ ինչ-որ բան բարելավելու համար, ապա ես հետ եմ նայում այս կանոններին և սկսում եմ մտածել. Եկեք մտածենք, թե որ դեպքերում է տեղին ռեֆակտորինգը, իսկ որ դեպքերում՝ ոչ այնքան։

Հրաժարում պատասխանատվությունից:Ամենայն հավանականությամբ, գրառումը կարդալուց հետո շատերը կցանկանան անմիջապես ասել. «Այո, սա արդեն 600 անգամ քննարկվել է»: կամ «Սա այնքան ակնհայտ է, ինչո՞ւ գրել այդ մասին»: Գուցե դուք ճիշտ եք, բայց ահա բանը. մեզ շրջապատող աշխարհում քաոսը դեռ շարունակվում է: Թվում է, թե ամեն ինչ պարզ է բոլորի համար, բայց իրականում պարզվում է, որ այնքան էլ պարզ չէ։ Հետեւաբար, կարծում եմ, որ այս թեմային եւս մեկ անգամ նայելը շատ վնասակար չի լինի։ Բայց եթե կոնկրետ վերամշակման հետ կապված որևէ խնդիր չունեք, ապա կարող եք պարզապես բաց թողնել այս գրառումը, դուք արդեն լավ եք:

Refactor-ը շատ վաղ է

Կարո՞ղ եք հիշել, թե երբ եք վերջին անգամ ունեցել աշխատանքի մշտական ​​հայտարարություն, որը ամիսներ շարունակ չի փոխվել: Ես այնքան էլ լավ չեմ սա հիշելու մեջ: Մենք ապրում ենք իրական աշխարհում, պահանջները անընդհատ փոխվում են։ Ավելին, դրանք անպայմանորեն արտաքին պահանջներ չեն, դրանք կարող են լինել ձեր սեփական պահանջները նախագծի համար: Թույլ տվեք բացատրել գաղափարը օրինակով. ենթադրենք, որ մեկ-երկու օր միջին չափի խնդիր եք վերցրել: Առաջին մի քանի դասերն արդեն գրված են, բայց դեռ մեկնարկելու բան չկա. կոշտ ճարտարապետական ​​հատվածը գրելու գործընթացը շարունակվում է։ Եվ հետո նկատում եք, որ նախագծի մասերից մեկը գրված չէ առանձնապես ունիվերսալ ձևով. «Բայց եթե վեց ամսից պետք է X անես, ապա բոլորը կտուժեն»: Խելամիտ է, որ դուք չէիք ցանկանա ամբարիշտ կոդ ներկայացնել և այլ ծրագրավորողներ ձեզ համար վատ անուն համարեն: Եվ դուք սկսում եք վերամշակել դեռ պատրաստ չէ հատկանիշը. Երբեմն դա արդարացված է, բայց նման ճանապարհին պետք է լինի «ՎՏԱՆԳ» նշանը։ Այսպիսով, դուք ուղղում եք մի բան, հետո մեկ այլ, հետո երրորդը: Անցել է մեկ շաբաթ, գործառույթը դեռ չի գործարկվում, և դուք ասում եք. «Ինչ-որ կերպ ամեն ինչ սխալ է արվել: Բայց հիմա ես Ես ճիշտ հասկացաինչպես դա անել: Հիմա ես արագ կվերագրեմ ամեն ինչ զրոյից»: Հիմնական խնդիրն այն է, որ գործառույթի վերաբերյալ հետադարձ կապ դեռ չի ստացվել, և դուք արդեն սկսել եք աշխատել կոդերի բազայի բարելավման վրա։ Այս մոտեցումը հազվադեպ է հաջողության բերում: Ես չգիտեմ ձեր մասին, բայց ինձ հետ հաճախ է պատահում, որ գործառույթը կիրառելուց հետո ես սկսում եմ հասկանալ, որ ամեն ինչ պետք է մի փոքր այլ կերպ աշխատի: Եվ դա այն պատճառով չէ, որ ես այդքան հիմար եմ և չկարողացա նախօրոք ճիշտ մտածել դրա մասին: Պարզապես պետք է «դիպչել» որոշ ֆունկցիոնալությանը, որպեսզի հասկանաք, թե ինչպես պետք է ամեն ինչ լինի թողարկման մեջ: Երբեմն ձեզ անհրաժեշտ է փոքր նախատիպ (նույնիսկ անպիտան կոդով և սխալներով)՝ գործընկերների հետ որևէ առանձնահատկություն քննարկելու համար: Երբեմն պետք է ինչ-որ բան ցույց տալ հաճախորդին, որպեսզի նա կարողանա ասել. «Ոչ, լավ, դա այն չէ, ինչ ես ուզում էի, ամեն ինչ պետք է հակառակը լինի»: Երբեմն օգտատերերը չեն սիրում նորամուծություններ, նրանք ցանկանում են ամեն ինչ այնպես, ինչպես եղել է. Նոր առանձնահատկությունների խնդիրն այն է, որ դժվար է կանխատեսել դրանց ճակատագիրը։ Հաճախ է պատահում, որ բոլոր զարգացումները նետվում են աղբարկղը, քանի որ առաջին տարբերակը քննարկելուց հետո թիմը որոշել է ամեն ինչ այլ կերպ անել։ Ընդհանուր եզրակացությունն այն է, որ դուք չպետք է վերամշակեք ձեր կոդը շատ վաղ, հատկապես, եթե 100% վստահ չեք, որ այս կոդը կմնա նախագծում:

Ոչ նպատակային վերամշակում

Ամենայն հավանականությամբ, մոտ ապագայի զարգացման ծրագիր ունեք։ Հավանական է, որ դուք ունեք վերջնաժամկետներ (նույնիսկ եթե դրանք ինքներդ եք սահմանել): Թողարկումները պետք է կատարվեն ժամանակին, զարգացումը չպետք է հետաձգվի: Դուք պետք է վերահսկեք ինքներդ ձեզ, դուք պետք է անեք այն բաները, որոնք ձեր անմիջական նպատակների մաս են կազմում: Ենթադրենք, դուք ունեք մի կոդ, որը կարծես ամբողջական է... Դե, վատ տեսք ունի: Բայց, շարունակենք մեր ենթադրությունը, դուք հիմա նրա հետ չեք աշխատում։ Կոդի այս վատ հատվածը կայուն է, հաջողությամբ կատարում է իր աշխատանքը և ոչ մի կապ չունի ձեր ընթացիկ առաջադրանքի հետ: Դե, մի դիպչիր նրան: Այո, դուք կարող եք չափազանց տխրել այն փաստից, որ նախագծի մյուս ծայրում ամեն ինչ շատ վատ է. Բայց ուշադրություն դարձրեք, որ հենց հիմա դա ձեզ ոչ մի կերպ չի անհանգստացնում։ Դուք ընթացիկ խնդիրներ ունեք, զբաղվեք դրանցով։ Իհարկե, կան կոդի բազան բարելավելու առաջադրանքներ, բայց ոչ հաճախ. հաճախ ավելի կարևոր է նոր ֆունկցիոնալություն ավելացնելը կամ սխալները շտկելը: Կենտրոնացեք առաջադրանքների վրա և մի հրաժարվեք դրանցից, քանի որ ինչ-որ տեղ ինչ-որ բան այն չէ:

Refactoring հանուն refactoring

Լավ, դուք եկել եք այն եզրակացության, որ դուք անպայման պետք է վերամշակեք նախագծի մի մասը: Լավ, եկեք վերամշակենք: Թվում է, թե պլանավորված բարելավումներն ավարտվել են, բայց հետո միտք է առաջանում. «Էլ ի՞նչը կարող եմ բարելավել։ Այո, այդ բանն այնտեղ»: Եվ այդ բանից հետո այս բանը կհայտնվի, հետո մեկ ուրիշը, հետո մեկ ուրիշը և այլն: Պետք է հասկանալ, որ կա վատ կոդ, կա լավ կոդ, կա իդեալական կոդ: Դուք երբեք չեք ունենա վերջինս մեծ նախագծում։ Սա չի նշանակում, որ պետք չէ դրան ձգտել, բայց պետք է հասկանալ, որ դա անհասանելի է։ Սովորաբար նպատակը լավ կոդ գրելն է, ոչ թե կատարյալ կոդ: Ասենք, որ վերաֆակտորինգից հետո ունես քիչ թե շատ ակնառու աշխատող լրիվ ընթեռնելի կոդ, որի մեջ հենակներ չկան ու որն այնքան էլ դժվար չէ օգտագործել։ Ինքներդ ձեզ հարց տվեք. «Գուցե ժամանակն է կանգ առնելու»: Այո, կոդը կարող է բարելավվել: Ավելին, բավականաչափ մեծ նախագծում այն ​​կարող է բարելավվել անվերջ: Բայց հենց հիմա այն հաղթահարում է իր գործառույթները, հարմար է օգտագործել, և գործնականում ձեզ ոչ մի անհանգստություն չի առաջացնում: Շատ կարևոր է ինքներդ որոշել ընդունելիկոդի որակը, որից հետո դուք դադարում եք բարելավել այն (մինչև ընդունելիության գույքը չկորցնեք): Հիշեք, որ դեռ շատ տարբեր հետաքրքիր բաներ կան, որոնք կարող եք ավելացնել: Կարիք չկա վերամշակել հանուն ինքն իրեն վերակառուցելու, հանուն կատարյալ կոդի։ Պետք է վերամշակել, երբ ունեք համոզիչդրա պատճառները. կոդը դժվար է կարդալ, ծածկագիրը դժվար է պահպանել, ծածկագիրը դժվար է մշակել, ծածկագիրը դժվար է օգտագործել և այլն: Եթե «դժվարություններ» չառաջանան, ապա համոզիչՈչ մի պատճառ չկա, որ դուք ժամանակ վատնեք վերամշակման վրա:

Refactoring մեկ օր առաջ թողարկման

Պատահում է, որ թողարկումը վաղը/վաղը/այսօր/պետք է երեկ լիներ (ըստ անհրաժեշտության ընդգծեք): Սա կարևոր պահ է նախագծի կյանքում: Հարկավոր է հատուկ ուշադրություն դարձնել թեստավորմանը, կարևոր վրիպակների շտկմանը և վերջնական բարելավմանը: Հավատացեք ինձ, իսկապես վատ գաղափար է վերամշակել կոդերի բազան (և ավելի վատ՝ լավ մշակել այն) այն պահին, երբ դուք պետք է նախագիծն ուղարկեք արտադրության: Փորձառու պրակտիկան հուշում է, որ դուք պետք է ազատեք այն, այնուհետև հանգիստ բարելավեք ծածկագիրը մաքուր խղճով: Ոմանք կհարցնեն. «Ինչո՞ւ»: Եթե ​​այս հարցը ծագել է, ապա հավանաբար դեռ ստիպված չեք եղել կատարել բարդ վերամշակում: Ես ձեզ հուշում եմ. երբ դուք վերագրում եք կոդը, այն միշտ չէ, որ բարելավվում է, երբեմն այն կարող է կոտրվել: Ինչու կա բարդ վերամշակում. երբեմն դուք ուղղում եք մի մեթոդ հինգ տողով, չեք կարողանում հետևել որոշ կախվածության, իսկ նախագծի մյուս ծայրում հայտնվում է սխալ, որին ձեր սիրելի օգտատերերը անմիջապես կհանդիպեն: Թվում է, թե դու ոչ մի սխալ բան չես անում, և հետո հանկարծ «Ակնհայտ չէր» գազանը հարձակվում է քեզ վրա և խեղդում քեզ կեղծ նախնական գնահատականի լճակում: Չնայած, միգուցե հենց այն է, որ ես այնքան վատ ծրագրավորող եմ, ես սիրում եմ կոտրել իրերը: Միանգամայն հնարավոր է, որ դուք միշտ վերափոխեք ամեն ինչ բացարձակապես ճիշտ և ամբողջ նախագծի ամբողջական վերահսկողությամբ: Այս դեպքում ես կարող եմ շնորհավորել ձեզ, բայց ես դեռ չեմ հրաժարվի նախնական թողարկումն արգելելու խորհուրդից։ Հավատացեք, ռեֆակտորինգը մի քանի օրից չի վերանա, և ամբողջ թիմը մի փոքր ավելի հանգիստ կքնի։

Շատ հին կոդի վերամշակում

Հարցը բարդ է, շատ դժվար։ Իրավիճակ. կան հսկայական թվով սարսափելի կոդի տողեր, որոնք դուք ժառանգել եք հին ծրագրավորողներից (հնարավոր է, որ այս հին մշակողները դուք էիք մի քանի տարի առաջ, նույնիսկ նախքան սովորել եք ամեն ինչ ճիշտ և միանգամից գրել): Կոդը պետք է պահպանվի: Այստեղ-այնտեղ հենակներ ու կրկնություններ են առաջանում, էնտրոպիան աճում է։ Ամեն օր ես ավելի ու ավելի եմ ուզում ամեն ինչ նետել ու վերաշարադրել այն զրոյից: Նման պահին անհրաժեշտ է Շատ լավմտածեք ռիսկերի մասին. Այո, հավանական է, որ նման գործունեությունը ապագայում օգտակար կլինի: Բայց կոնկրետ ո՞ր տեսանկյունից և որքանո՞վ է օգտակար: Ամենայն հավանականությամբ, առանձին մասերի մեծ վերամշակման կամ վերաշարադրման գործընթացում դուք կփոխարինեք հին աշխատանքային ծածկագիրը նոր, հիանալի գրված կոդով, բայց սխալներով: Եվ ամենևին այն պատճառով, որ դուք վատ ծրագրավորող եք և վատ եք գրում։ Դուք պարզապես չգիտեք այս կոդը բավականաչափ. Գուցե չգիտեք, թե ինչու է հեղինակն ամեն ինչ գրել այսպես, բայց կարող են լինել պատճառներ: Երբեմն պետք է շատ տարօրինակ ու ծուռ կոդ գրել։ Ես կարող եմ բերել բազմաթիվ օրինակներ՝ ճնշել պրոցեսորի բարդ օպտիմիզացումները, հարմարեցնել սխալները երրորդ կողմի գրադարանում, ճնշել որոշ բազմաշերտ խցանումներ և այլն: Ես չեմ ասում, որ այս բոլոր խնդիրները չեն կարող նորմալ լուծվել: Պարզապես երբեմն անհեթեթ թվացող կոդը նորմալ կոդի մեջ վերագրելիս վրիպակներ են հայտնվում: Այո, հնարավոր էր ամեն ինչ նորմալ անել, բայց դուք կարող եք պարզապես չհասկանալ փայտերի փոխարեն հենակներից պատրաստված խրճիթի մեծությունը, եթե ծածկագրի հեղինակից չպարզեք, թե ինչու է նա գրել այսպես (և այդպիսի հնարավորություն. միշտ չէ, որ տրամադրվում է): Զգույշ եղեք հին ծածկագիրը վերաշարադրելիս, որը լիովին չեք հասկանում (և հատկապես, եթե կարծում եք, որ հասկանալու բան չկա):

Ե՞րբ պետք է վերամշակել:

Ներողություն եմ խնդրում, եթե այս հոդվածը ձեզ տպավորություն է թողնում, որ վերամշակումը ոչ այլ ինչ է, քան խնդիրներ: Ես դեռ պնդում եմ, որ կոդը պետք է լինի ընթեռնելի և գեղեցիկ, այն պետք է լինի հեշտ օգտագործվող, և այն պետք է լինի հեշտ մշակվող: Դրական մոտեցումն ավելի լավ է, քան բացասականը, ուստի վերափոխումը վերաբերվեք ոչ թե որպես խնդիրների աղբյուր, այլ որպես շատ լավ ընկերոջ, ով կօգնի ձեզ դժվար պահերին: Ավելին, այս ընկերը կարող է համոզվել, որ ձեր լուսավոր ապագայում ավելի քիչ դժվար պահեր կան։ Եզրափակելով, ես կցանկանայի առանձնացնել մի քանի կետ, երբ վերակառուցումը իսկապես տեղին է:

• Անելիք չկա։Կան հանգիստ ժամանակներ, երբ բոլոր կարևոր գործերը փակված են, իսկ նորերը դեռ հանձնարարված չեն: Դե, այնպես չէ, որ բացարձակապես անելու բան չկա, բայց կա որոշակի քանակությամբ ազատ ժամանակ: Ծախսեք այն ձեր կոդը բարելավելու վրա: Տվեք սուբյեկտներին հստակ անուններ, ազատվեք կրկնօրինակումից, վերաշարադրեք ճարտարապետության վատ կտորը: Թեև նոր գործառույթ չի ավելացվել, դուք նպաստում եք ծրագրավորողների մտքի խաղաղությանը, ովքեր կշարունակեն նախագիծը: Հավատացեք ինձ, սա կարևոր է:
• Ամենօրյա տառապանք.Եվ պատահում է, որ նախագծի մի հատված կա, որը ստիպում է քեզ ամեն օր ծանր հառաչել։ Իսկ հարեւան սեղաններից լսվում են գործընկերներիդ ծանր հառաչանքները։ Իհարկե, թեև թողարկումը վաղը չէ, դեռևս բավական կարևոր առաջադրանքներ կան։ Այնուամենայնիվ, շաբաթ առ շաբաթ անցնում է, և նախագծի այս հատվածին նայելն ավելի ու ավելի տխուր է դառնում: Ասա ինքդ քեզ. «Դադարեցրե՛ք դա համբերել»: Եթե ​​բիզնես պլանը գրված է ձեր ղեկավարի կողմից, ապա բացատրեք նրան, որ այս կոդը պարզապես պետք է վերաշարադրվի: Եթե ​​դուք աշխատում եք հաճախորդի համար, ապա համոզեք նրան, որ ռեֆակտորինգի վրա ծախսված մեկ շաբաթը ապագայում զգալիորեն կխնայի զարգացման ժամանակ: Եթե ​​դուք աշխատում եք օգտատերերի համար, ապա որոշեք, որ ավելի լավ կլինի այս օգտատերերի համար այս անգամ ևս մեկ շաբաթ սպասեն թողարկմանը, բայց հետո վայելեն կայուն ծրագրակազմը և կանոնավոր թարմացումները: Այո, միշտ չէ, որ հեշտ է համաձայնության գալ բոլորի և ինքդ քեզ հետ, բայց փորձիր։
• Ուշ վերամշակման խնդիրը.Չպետք է բացարձակ դարձնել վաղաժամ վերամշակման կանոնը: Ոմանք մտածում են այսպես. «Հիմա ես ինչ-որ բան բարելավում եմ, բայց դա օգտակար չի լինի, դա ամոթ կլինի»: Դուք պետք է հասկանաք, որ ծրագրի առանցքում կարող են լինել կարևոր մասեր, որոնք ավելի լավ է լավ գրված լինեն: Հիշեք, որ որքան ուշ վերամշակեք, այնքան բարձր կլինի արժեքը, քանի որ ավելի շատ ժամանակ և ջանք կծախսեք վերաշարադրելու վրա: Կրիտիկական հիմունքները (նրանք, որոնք օգտագործվում են նախագծում) պետք է միշտ լինեն հնարավորինս լավագույն վիճակում: Պարզապես հիանալի կլինի, եթե թեզը աշխատի ձեր թիմում «Վերամշակումը չի ուշանում. Նա գալիս է խիստ, երբ հարմար է գտնում»։.
• Հանդիպում հրեշի հետ.Դուք սկսում եք կրճատել նոր ֆունկցիոնալությունը, որը պետք է օգտագործի նախագծի հին հատվածը, որը նման է իսկական հրեշի. դուք վախենում եք հենց այն ժամանակ, երբ նայում եք արտաքին ինտերֆեյսին: Եթե ​​ժամանակը թույլ է տալիս, նախ շտկեք կոդի հիմնական մասը, որպեսզի այնուհետև կարողանաք կենտրոնանալ նոր ֆունկցիոնալության վրա և չշեղվեք՝ կոդի վերօգտագործման համար հենակներով հարվածելով:
• Խելացի պերֆեկցիոնիզմ.Նկատե՞լ եք վատ կոդ: Ցանկանու՞մ եք ուղղել այն: Իսկապե՞ս ուզում եք շտկել այն: Դե, եթե դուք իսկապես ցանկանում եք, ապա կարող եք: Բայց ուշադրություն դարձրեք «ողջամիտ» բառին։ Հավասարակշռեք վերամշակման վրա ծախսված ժամանակը և ծածկագրի բարելավման օգուտը: Բաց մի թողեք վերջնաժամկետները և ընկղմվեք անվերջ բարելավումների մեջ: Այնուամենայնիվ, եթե դուք վերամշակեք ժամանակին և ողջամիտ կերպով, նախագիծը միայն կբարելավվի:

Եզրակացության փոխարեն

Վերը նշված բոլորը մի շարք նախագծերի վրա աշխատելու փորձի զուտ սուբյեկտիվ ընդհանրացում է։ Իհարկե, կյանքի բոլոր իրավիճակները չեմ լուսաբանել։ Յուրաքանչյուր թիմ ունի կոդի իր պահանջները, իր բիզնես պլանը և իր կանոնները: Համոզված եմ, որ շատերն ունեն հինգ պատմություն «Բայց ես ունեի մի դեպք, երբ այս բոլոր խորհուրդները չաշխատեցին»: Սա բացարձակապես նորմալ է, ինչպես և պետք է լինի: Կոդը բարելավելու ջանքերի չափը որոշելու համար չկա ունիվերսալ արծաթե պարբերակ («Մենք ամեն օր կվերափոխենք 47 րոպե 23 վայրկյան, և ամեն ինչ լավ կլինի»): Դուք պետք է, հիմնվելով ձեր կոնկրետ նախագծում ձեր սեփական փորձի վրա, ձեր կոնկրետ թիմում, փորձեք գտնել միջին ճանապարհ նոր կոդ գրելու և հինը բարելավելու միջև: Ես միայն ջատագովում եմ ռացիոնալ վերաբերմունքն ամեն ինչի նկատմամբ՝ առանց ֆանատիզմի («Ինչու՞ բարելավել կոդը, դրանից նոր ֆունկցիոնալություն չի երևա» / «Մենք շտապ պետք է բոլոր ծածկագիրը կատարյալ դարձնենք, որպեսզի հետագայում կարողանանք նորմալ աշխատել դրա հետ»): Խելացի եղեք ձեր ժամանակը հատկացնելով գոյություն ունեցող կոդի վրա աշխատելու համար, և դուք լավ կլինեք:

Ողջունելի են ցանկացած լրացուցիչ միտք այն մասին, թե երբ դուք պետք է կամ ոչ պետք է վերամշակեք: Այս ոլորտում ամենաարժեքավոր բաներից մեկը իրական նախագծերի իրական մշակողների փորձն է:

Կոդի վերամշակում

Հավելվածներ ստեղծելիս շատ ծրագրավորողներ նախ անհանգստանում են ֆունկցիոնալությունից, և երբ դա հասնում է, նրանք վերանախագծում են հավելվածները՝ դրանք ավելի կառավարելի և ընթեռնելի դարձնելու համար: Այն կոչվում է վերամշակում. Refactoring-ը կոդի վերամշակման գործընթաց է՝ բարելավելու համար հավելվածների ընթեռնելիությունը և կատարումը, միաժամանակ ապահովելով տիպի անվտանգությունը և կոդն ավելի համահունչ դարձնելով օբյեկտի վրա հիմնված ծրագրավորման լավագույն փորձին: Բարեբախտաբար, այժմ դուք կարող եք բավականին լավ ավտոմատացնել այս գործընթացը Visual Studio 2010-ում:

Ցանկի օգտագործման միջոցով Refactor, որը հասանելի է բացելով կոդային ֆայլը, ինչպես նաև ստեղնաշարի համապատասխան դյուրանցումները, խելացի պիտակները և/կամ սեղմումները, որոնք բացում են համատեքստային ընտրացանկերը, դուք կարող եք զգալիորեն փոփոխել կոդը նվազագույն ջանքերով: Հետևյալ աղյուսակը թվարկում է վերամշակման ամենատարածված մեթոդներից մի քանիսը, որոնք ճանաչվել են Visual Studio 2010-ի կողմից.

Կոդի վերամշակման ընտրանքներ

Refactoring տեխնիկա	Նկարագրություն
Էքստրակտ մեթոդ (Քաղվածքի մեթոդ)	Թույլ է տալիս սահմանել նոր մեթոդ՝ հիմնված ընտրված կոդի հայտարարությունների վրա
Կափսուլացնել դաշտը (դաշտային պարկուճ)	Թույլ է տալիս հանրային դաշտը վերածել մասնավոր, ձևով ամփոփված C# հատկության
Էքստրակտ ինտերֆեյս (Ինտերֆեյսի արդյունահանում)	Թույլ է տալիս սահմանել ինտերֆեյսի նոր տեսակ՝ հիմնված գոյություն ունեցող տիպի անդամների մի շարքի վրա
Վերադասավորեք պարամետրերը (Վերադասավորել պարամետրերը)	Թույլ է տալիս փոխել արգումենտների հերթականությունը անդամում
Հեռացնել պարամետրերը (Կարգավորումների ջնջում)	Թույլ է տալիս հեռացնել որոշակի փաստարկ ընթացիկ պարամետրերի ցանկից
Վերանվանել (Վերանվանում)	Թույլ է տալիս վերանվանել ձեր կոդի մեջ օգտագործվող մեթոդը, դաշտը, տեղական փոփոխականը և այլն: նախագծի ողջ ընթացքում

Վերագործարկման գործընթացը գործողության մեջ տեսնելու համար եկեք փոփոխենք Main() մեթոդը՝ ավելացնելով հետևյալ կոդը.

Համակարգի օգտագործում; օգտագործելով System.Collections.Generic; օգտագործելով System.Linq; օգտագործելով System.Text; namespace ConsoleApplication1 ( class Program ( static void Main (string args) ( // Կարգավորել վահանակի միջերեսը (CUI) Console.Title = "Իմ հավելվածը"; Console.ForegroundColor = ConsoleColor.Yellow; Console.BackgroundColor = ConsoleColor.Blue; Console.WriteLine("Привет, это мой проект!"); Console.BackgroundColor = ConsoleColor.Black; Console.ReadLine(); } } }!}

Ինչպես կա, այս ծածկագրի մեջ ոչ մի վատ բան չկա, բայց եկեք պատկերացնենք, որ մենք ցանկանում էինք այս ողջույնի ուղերձը երևալ տարբեր վայրերում ծրագրի ընթացքում: Իդեալում, ոչ թե նորից ներմուծելու նույն տրամաբանությունը, որը պատասխանատու է վահանակի ինտերֆեյսի տեղադրման համար, լավ կլիներ ունենալ օգնական ֆունկցիա, որը կարող է կանչվել այս առաջադրանքը կատարելու համար: Հաշվի առնելով դա՝ փորձենք տեխնիկան կիրառել առկա կոդի վրա Էքստրակտ մեթոդի վերամշակում.

Դա անելու համար խմբագրիչի պատուհանում ընտրեք Main(-ի) մեջ պարունակվող բոլոր օպերատորները, բացառությամբ վերջին զանգի Console.ReadLine(), և աջ սեղմեք ընդգծված կոդի վրա։ Համատեքստի ընտրացանկից ընտրեք Refactor --- Extract Method:

Դրանից հետո Main() մեթոդը կկանչի նոր ստեղծված MyConfigCUI() մեթոդը, որը կպարունակի նախկինում ընդգծված կոդը.

Համակարգի օգտագործում; օգտագործելով System.Collections.Generic; օգտագործելով System.Linq; օգտագործելով System.Text; namespace ConsoleApplication1 ( class Program ( static void Main (string args) ( //Կարգավորել վահանակի միջերեսը (CUI) MyConfigCUI(); Console.ReadLine(); ) մասնավոր ստատիկ դատարկ MyConfigCUI() ( Console.Title = " Իմ դիմումը"; Console.ForegroundColor = ConsoleColor.Yellow; Console.BackgroundColor = ConsoleColor.Blue; Console.WriteLine("Привет, это мой проект!"); Console.BackgroundColor = ConsoleColor.Black; } } }!}

Հեշտ է տեսնել, որ նման մոգերը բավականին հեշտացնում են կոդերի վերամշակումը ոչ միայն մեկ էջում, այլև ամբողջ հավելվածում: Այլ մատչելի տարբերակները ներառում են.

Ջորջ Կարետ

Կոդի վերամշակման սահմանում և կիրառում

Դժվար չէ հասկանալ, թե ինչ է կոդի վերամշակումը. ինտերնետում բավականին շատ սահմանումներ կան: Ամենահաջողն ու ամբողջականը, իմ կարծիքով, Վիքիպեդիայում է, և ոչ միայն այն պատճառով, որ այն համապարփակ է, այլ նաև այն պատճառով, որ այն հակադրում է վերամշակումը այնպիսի փուլերի հետ, ինչպիսիք են օպտիմալացումը և վերաճարտարագիտությունը: Սահմանման այս տարբերակին հեշտությամբ կարող եք ծանոթանալ՝ տողում մուտքագրելով «Refactoring» բառը և բացելով (ամենայն հավանականությամբ առաջինը) հղումը դեպի ազատ հանրագիտարանի կայք։

Այսպիսով, կոդի վերամշակումծրագրի սկզբնաղբյուրում փոփոխություններ կատարելու գործընթացն է՝ միջոցով, որի իմաստը համարժեք է նախորդ հատվածներին, բայց արդյունքն ավելի սլացիկ, օրգանական և տրամաբանական է թվում։

Ե՞րբ է նպատակահարմար վերափոխել կոդը:

Յուրաքանչյուր ծրագրի կյանքում, համենայն դեպս, նրանց կյանքում, որոնք մշակվել են պատվերով, գալիս է մի փուլ, երբ հաճախորդի հիմնական պահանջները, մշակողի կարծիքով, ավարտված են, և ծրագրային արտադրանքը առաքվում է . Եվ գուցե նույնիսկ փորձնական շահագործման համար: Թեստավորման ընթացքում, եթե այն անցկացնողի ձեռքերն աճում են ճիշտ տեղից, և նրա ուղեղն աշխատում է ճիշտ ուղղությամբ, ծրագրավորողը սկսում է ռմբակոծվել բացառիկ իրավիճակների հետ կապված մեծ թվով սխալներով, «հիմարների պաշտպանություն», ծայրահեղություն: տվյալների քանակություն, անընդունելի կատարում և այլն (կատարյալ աշխատող ծրագրերը անմիջապես չեն գրվում): Մշակողը փորձում է արագ արձագանքել ճակատագրի մարտահրավերներին և ներմուծում է մեծ թվով տեղական ուղղումներ, երբեմն էլ «կարկատաններ», ինչի արդյունքում կոդը կորցնում է իր սկզբնական ներդաշնակությունն ու հավասարակշռությունը։ Տեխնիկական հսկողության բաժնի կամ պարզապես որակի վերահսկման բաժնի կողմից բողոքների ներհոսքի հիմնական ալիքների միջև ընկած ժամանակահատվածում պետք է իրականացվի կոդի վերամշակում. վերլուծել կոդը և մի շարք արդյունավետ տեխնիկայի միջոցով այն վերածել ավելի հետևողականի: և «թափանցիկ ձև»: Բնականաբար, վերամշակման փուլը չի ​​կարելի համարել մեկանգամյա բան։

Նաև նպատակահարմար է վերափոխել կոդը նոր ֆունկցիոնալություն ավելացնելուց հետո, քանի որ նման գործողությունները հեշտությամբ կարող են հանգեցնել մանիպուլյացիայի և դրանց տարրերի հետ կապված մի շարք վերափոխումների իրականացման անհրաժեշտության: Հաճախ պատճառը նոր ֆունկցիոնալությունն է նոր մեթոդների արդյունահանումկամ նույնիսկ նոր դասեր և/կամ դրանց անվանափոխում, քանի որ վերջիններիս դերը կարող է ընդլայնվել, հստակեցվել կամ մասնագիտանալ։

Ինձ թվում է, ի թիվս այլոց, հատուկ ուշադրություն պետք է դարձնել կոդի այն մասերին, որոնք երկար ժամանակ չեն խմբագրվել (չեն շոշափվել սխալների շտկման կամ ֆունկցիոնալության ընդլայնման գործընթացում), քանի որ դրանք դժվար թե լինեն: այնքան անձեռնմխելի է ձեր կատարած փոփոխություններից, թեև դրանք պահպանում են ճիշտ վարքագիծը: Բայց սա ավելի շուտ պատասխան է ոչ թե «Ե՞րբ է դա տեղին...», այլ «Որտե՞ղ նայել...» հարցին։

Ո՞վ կարող է օգուտ քաղել կոդերի վերամշակումից:

Դե, նախ և առաջ, ձեր կոդի վերամշակումը կարող է դրական ազդեցություն ունենալ ձեր գրած ծրագրային արտադրանքի նկատմամբ ձեր բարոյականության և վերաբերմունքի վրա: Սա շատ կարևոր է, քանի որ դեռ պետք է ուղեկցել և կատարելագործել այն։ Սխալների հայտնաբերումը և ուղղումը նույնպես շատ ավելի արագ և արդյունավետ է ներդաշնակ և թափանցիկ կոդում: Հակառակ եզրակացությունը կարելի է անել. որքան երկար եք սխալներ փնտրում կոդի մեջ, այնքան այն քիչ է համապատասխանում կառուցվածքային և մաքուր կոդի սահմանմանը: Refactoring-ը չի շտկելու կոտրված կոդը, բայց այն կարող է օգնել ախտորոշել, թե ինչն է դրա պատճառը:

Երկրորդ, բարդ ծրագրային բաղադրիչները հաճախ մշակվում են համատեղ բազմաթիվ մարդկանց կողմից: Համագործակցությունը կազմակերպելու համար կան բազմաթիվ գործիքներ. օրինակ՝ Rational Suite-ը, որն իր մեջ ներառում է պայուսակ-հետագծող Clear-Quest և տարբերակների վերահսկման գործիք ծրագրային բաղադրիչների Clear-Case: Վերջին տարբերակներում, օրինակ, կա մի հրաշալի գործիք, որը կոչվում է Team Foundation Server: Հասկանալի է, որ ծրագրային ապահովման ցանկացած «հասուն» բաղադրիչ պետք է ուղեկցվի իր արտաքին ծրագրային ինտերֆեյսների (հատուկ բնութագրերի) մանրամասն նկարագրությամբ, բայց դուք պետք է նաև հասկանաք, որ ցանկացած փորձառու մշակող, իմանալով, թե ինչպես են գրված նման բնութագրերը, կցանկանա ուսումնասիրել դրա տրամաբանությունը: ձեր բաղադրիչը՝ ուղղակիորեն վերլուծելով այն: Այս նպատակների համար լավ կլինի, որ ձեր կոդը «ընթեռնելի» լինի։ Այսպիսով, մենք կարող ենք եզրակացնել, որ կոդի վերամշակումը կարող է օգնել արագացնել համատեղ ծրագրային ապահովման մշակման գործընթացը:

Refactoring vs Reengineering?

Եթե ​​կոդի վերամշակումը չի փոխում ծրագրի վարքագիծը, ապա վերաճարտարագիտությունընդունակ սրա. Դուք կարող եք վերաճարտարագիտությունը դիտարկել որպես վերամշակման ծայրահեղ ձև, բայց ես կարծում եմ, որ դա ամբողջովին ճիշտ չէ: Ավելի շուտ, վերամշակումը կարող է հանգեցնել հեշտ վերակառուցման: Եկեք դիտարկենք մի սցենար, որտեղ ծրագրային արտադրանքի ինտենսիվ փորձարկման ժամանակ պարբերական վերամշակումը կարող է հանգեցնել վերաճարտարագիտության.

Որակի վերահսկման մասնագետները և գուցե նույնիսկ օգտատերերը (կախված ծրագրային արտադրանքի կյանքի ցիկլի փուլից) անընդհատ արձանագրում են սխալներ, որոնք ուղղակիորեն կապված են ձեր կայացրած որոշումների առանձնահատկությունների հետ, երբ . Հնարավոր է, որ մշակման գործընթացում սխալ ճարտարապետություն եք ընտրել ձեր ծրագրի համար: և պարբերական վերամշակումը կարող է բացահայտել այդպիսի վայրեր. դրանք ծանր, անտրամաբանական տեսք ունեն և չեն ենթարկվում վերամշակման հայտնի կանոններին: Դուք որոշում եք փոփոխություններ կատարել ծրագրի ճարտարապետության մեջ, գնահատում եք դրա վարքագծի հետևանքները և ապագա փոփոխությունները, համաձայնում և հայտարարում եք պլանավորված փոփոխությունների մասին և սկսում վերաճարտարագիտությունը:

Բացի այդ, հաճախ անհրաժեշտություն է առաջանում վերակառուցման, երբ անհրաժեշտ է ընդլայնել առկա ֆունկցիոնալությունը կամ անցնել այլ երրորդ կողմի գրադարանների օգտագործմանը կամ օգտագործել այլ տվյալների բազա և այլն: եւ այլն։

Refactoring vs Optimization

Դե, այստեղ ամեն ինչ բավականին հեշտ է, քանի որ կոդի վերամշակումը և կոդի օպտիմալացումը տարբեր նպատակներ են հետապնդում և, ինչպես սովորաբար լինում է, հակառակ ազդեցություն են ունենում կոդերի ընթերցանության վրա, չնայած երկուսն էլ չեն փոխում ծրագրի տրամաբանությունը: Ծրագրի կոդի օպտիմալացման գործընթացում հիմնական նպատակն է ապահովել կրիտիկական բաժինների՝ «խցանների» ընդունելի կատարման արագությունը (կամ կատարման ընթացքում հիշողության ռացիոնալ օգտագործումը): Կարելի է զոհաբերել ոչ միայն ծրագրային կոդի տրամաբանությունն ու «գեղեցկությունը», այլև հիմնական դոգմաները։ Օպտիմալացման արդյունքները կարող են լինել գլոբալ փոփոխականների ի հայտ գալը և «լրացուցիչ» հանրային մեթոդներն ու հատկությունները, որոնք բացահայտում են ձեր դասերի իրականացման մանրամասները և այլն: խայտառակություն. Իմ կարծիքով, դուք պետք է հատուկ ուշադրություն դարձնեք վերամշակմանը և փորձեք նվազագույնի հասցնել օպտիմալացման անհրաժեշտությունը բարձրորակ երրորդ կողմի գրադարանների համապատասխան օգտագործման միջոցով:

Փոփոխականների, հատկությունների, մեթոդների և գործառույթների անվանումներ

Այս թեման ուղղակիորեն կապված չէ կոդի վերամշակման հետ, բայց, այնուամենայնիվ, էական ազդեցություն ունի դրա ընթեռնելիության վրա։ Ժամանակի ընթացքում յուրաքանչյուր ծրագրավորող մշակում է իր սեփական կոդավորման ոճը և արդյունքում օգտագործում է իր կանոնները լեքսեմների անվանման համար՝ մասամբ կամ ամբողջությամբ փոխառված տարբեր նշումներից։ Բավականին հաճախ օգտագործում են այսպես կոչված պայմանագրեր Հունգարական նշում. Այս հոդվածում ես չեմ թվարկի այս հրաշալի նշման բոլոր պայմանականությունները, կքննարկեմ դրա դրական և բացասական կողմերը, բայց ես կկենտրոնանամ դրա օգտագործման հիմնական, իմ կարծիքով, առավելությունների վրա. իմաստաբանությունը, արտացոլում է նաև դրա տեսակը և . Օրինակ՝ m_iIndex – փոփոխական, ամբողջ թվի տիպի դասի անդամ; gc_bUseCache - բուլյան տիպի գլոբալ հաստատուն և այլն: Համաձայն եմ, սա կարող է լրջորեն հեշտացնել կյանքը մեկի համար, ով փորձում է հասկանալ ուրիշի կոդը: Ի լրումն հունգարական նշումների կոնվենցիաների օգտագործման, ես նաև խորհուրդ եմ տալիս հետևել հետևյալ կանոններին.

• Բուլյան տիպի դասի հատկությունների և դաշտերի անվանումները ձևավորվում են մոդալ և օժանդակ բայերի միջոցով՝ իրենց նպատակին համապատասխան, օրինակ. ԷՄիայն կարդալու համար ՈւնիԱրժեք Կարող էՎերականգնել և այլն;


• Փորձեք ձևավորել այն մեթոդների անվանումները, որոնք կատարում են որևէ սպասարկման գործողություն, որը կապված չէ ձեր ծրագրի առանձնահատկությունների հետ, օգտագործելով նույն սպասարկման բայերը, որոնք հաճախ օգտագործվում են այս գործողությունների իմաստը նշելու համար. ԹարմացնելԴիտել ԳնահատելԱրժեք ԹարմացնելՀամատեքստ և այլն:


• Մեթոդներ անվանելիս պետք է հաշվի առնել դասի անունը և չկրկնել այն այս մեթոդների անուններում, օրինակ՝ DbConnection դասի տվյալների բազայի հետ կապ բացելու և փակելու մեթոդներ նշանակելու համար, պետք է ընտրել անունները: Բացեք և փակեք, քան ԲացՄիացում և փակելՄիացում, համապատասխանաբար: Բացառություն կարող են լինել այն դեպքերը, երբ մեթոդով կատարված գործողությունը հատուկ կամ երկրորդական է դասի հիմնական ֆունկցիոնալությանը, օրինակ՝ իրադարձությունների մատյանի հետ աշխատելու մեթոդներ. ԲացՄատյան և փակելՄուտք գործեք նույն DbConnection դասի համար:


• Եթե ​​մեթոդը կամ հատկությունը հրապարակային է, և դրա նպատակը ոչ տրիվիալ է (այն իմաստով, որ այն չի կարող ձևակերպվել մեկ կամ երկու բառով, ինչպիսիք են GetResource կամ SaveChanges), ապա, ամենայն հավանականությամբ, այն չպետք է անվանվի մի քանիսի «սոսնձում» հապավումներ։ այնպիսի բառեր, ինչպիսիք են GetNewClntProf - նման մոտեցումը տեղին է ներքին օգտագործման համար, բայց ոչ մի մեթոդի համար, որը «դուրս է գալիս», լինելով բաց ինտերֆեյսի մաս, ոչ բոլորը ճիշտ կհասկանան այս հապավումը, էլ չենք խոսում այն ​​մասին, որ տարբեր (բնական) լեզուներ բառերի կրճատման տարբեր կանոններ ունեն: Ավելի լավ է տեղ չվատնել և անունը կազմել որպես բոլոր բառերի ամբողջություն՝ GetNewClientProfile:


• Մեթոդի կամ ֆունկցիայի համատեքստում դրա պարամետրերը տեղական փոփոխականներից տարբերելու համար (գլոբալ փոփոխականները և դասի անդամներն արդեն տարբերվում են նախածանցով, ինչպիսիք են m_, c_, g_ և այլն), ես առաջարկում եմ սկսել այս տեղական փոփոխականների անունները. ընդգծված «_» (բնականաբար, եթե դա թույլ է տալիս ձեր ընտրած ծրագրավորման լեզվի շարահյուսությունը) և այնուհետև՝ հունգարական նշումին համապատասխան:

RefactoringԿոդավորումը ծրագրի սկզբնական կոդը փոխելու գործընթաց է՝ առանց դրա վարքագծի վրա ազդելու և նպատակ ունենալով հեշտացնել այն հասկանալը և/կամ պարզեցնել դրա հետագա աջակցությունը: Որպես կանոն, ցանկացած ծրագրի վերամշակումը ներառում է իր կոդի մեջ փոքր փոփոխություններ կատարելը, որոնցից յուրաքանչյուրը չի փոխում հենց ծրագրի վարքագիծը, այլ ինչ-որ կերպ պարզեցնում և/կամ բարելավում է կոդը։ Միևնույն ժամանակ, շատ կարևոր է, որ վերամշակումը կատարվի մանր մասերով, քանի որ երբ ծրագրավորողը փոխում է կոդի մի փոքր մասը, նրա համար շատ ավելի հեշտ է վերահսկել փոփոխությունների ճիշտությունը և չսխալվել: Եթե ​​դուք միանգամից վերամշակեք կոդի մեծ հատվածներ, ապա սխալներ թույլ տալու շատ մեծ հավանականություն կա, ինչի արդյունքում ծրագիրը կարող է ընդհանրապես դադարեցնել աշխատանքը։ Ճիշտ է, այն փաստը, որ խմբագրումները պետք է լինեն փոքր, չի նշանակում, որ վերամշակումը պարզապես փոփոխականների անունների փոխարինումն է կամ կոդի փոքր հատվածները ծրագրի մի տեղից մյուսը տեղափոխելը. վարքագիծը, գլխավորն այն է, որ փոփոխություններ կատարեք փոքր մասերում, և այդ ժամանակ ամեն ինչ լավ կլինի:

Նպատակների վերամշակում

Դուք, հավանաբար, կհարցնեք ինձ, թե ինչու եմ ես գրում սա ամեն դեպքում: Եվ այն փաստին, որ եթե ուշադիր նայեք սկզբնաղբյուրը, օրինակ՝ սկզբնաղբյուր տեքստերը յուրաքանչյուր դասի համար, հավանաբար նկատեցիք, որ ես հաճախ ինչ-որ բան եմ փոխում կոդում, երբեմն փոքր ձևերով, իսկ երբեմն՝ բավականին նկատելի: Դա այն պատճառով է, որ Ես ինքս օգտագործում եմ ռեֆակտորինգև ես ուզում եմ, որ սա սովորություն դառնա նաև ձեզ համար:

Ինչպես արդեն ասացի - վերամշակման հիմնական նպատակըՍա կոդն ավելի պարզ և հստակ դարձնելու համար է: Եթե ​​վերամշակումից հետո ծածկագիրը չի դառնում ավելի լավ և հստակ, նշանակում է, որ դուք կամ չեք վերամշակել, կամ այն ​​ձախողվել է: Այնուամենայնիվ, մի շփոթեք վերամշակման հայեցակարգը օպտիմալացման հետ: Օպտիմալացման արդյունքում կոդը դառնում է ավելի արագ, բայց պարտադիր չէ, որ ավելի պարզ և հստակ, refactoring-ը ծառայում է հենց պարզեցնելու և բարելավելու կոդի ընթեռնելիությունը.

Ինչ կոդը պետք է վերամշակվի

Դուք կարող եք և հաճախ պետք է վերամշակել ցանկացած ծածկագիր. ամենից հաճախ պարզապես պետք է ապավինել ձեր բնազդին, եթե ինչ-որ ծածկագիր ձեզ այնքան էլ հաջող չի թվում կամ ձեզ թվում է, որ մեկ շաբաթից արդեն կմոռանաք, թե ինչ է այս կամ այն ​​բաժինը: code does - ամենայն հավանականությամբ, այս կոդը վերամշակման կարիք ունի: Ես կփորձեմ ձևակերպել հիմնական կանոնները, որոնց հիման վրա դուք կարող եք հասկանալ, որ ձեր կոդը պահանջում է վերամշակում.

Եթե ​​ձեր ծրագիրն ունի կոդերի կրկնօրինակում, ապա ռեֆակտորինգը գրեթե անկասկած պահանջվում է: Ծրագրում կրկնվող կոդը սխալների հիմնական աղբյուրն է: Եթե ​​ձեր ծրագրում ինչ-որ գործողություն կատարվում է մի քանի տարբեր վայրերում, բայց նույն կոդով, պարզապես տեղադրեք այս կոդը առանձին ֆունկցիայի մեջ և կանչեք այն: Հակառակ դեպքում մեծ է հավանականությունը, որ մի օր դուք կխմբագրեք սկզբնաղբյուրը մի տեղ, բայց կմոռանաք ուղղել նմանատիպ կոդը մեկ այլ տեղում, և սխալներ կառաջանան։

Ձեր ծրագիրն ունի շատ երկար մեթոդներ/գործառույթներ: Որպես կանոն, մարդը չի կարող ամբողջությամբ ընկալել և գնահատել կոդի ճիշտությունը, եթե այս ծածկագիրը 2-3 տասնյակից ավելի տող է վերցնում։ Նման մեթոդներն ու գործառույթները պետք է բաժանվեն մի քանի փոքրերի և պետք է կազմվի մեկ ընդհանուր գործառույթ, որը հաջորդաբար կանվանի այդ մեթոդները: Երբեք մի փորձեք կրճատել ձեր կոդի երկարությունը՝ գրելով մի քանի հայտարարություն մեկ տողում!!! Սա ծրագիր կազմակերպելու ամենավատ տարբերակներից մեկն է, և ես ձեզ 100% երաշխիք եմ տալիս, որ նման կոդը ի վերջո կհանգեցնի սխալների:

Գործառույթի/մեթոդի/կոնստրուկտորի պարամետրերի երկար ցուցակ: Մեծ թվով պարամետրերը սովորաբար ոչ միայն դժվարացնում են հասկանալ, թե ինչ է անում մեթոդը կամ ֆունկցիան, այլև դժվարացնում է այդ գործառույթներն օգտագործող կոդը: Եթե ​​ձեզ իսկապես անհրաժեշտ է ֆունկցիա՝ շատ պարամետրեր վերցնելու համար, պարզապես տեղադրեք այս պարամետրերը առանձին կառուցվածքի (կամ դասի) մեջ՝ տալով այս կառուցվածքին ողջամիտ և հասկանալի անուն, և ֆունկցիան փոխանցեք հղում (կամ ցուցիչ) այս օբյեկտին: կառուցվածքը կամ դասը:

Մեծ դասերը նույնպես պահանջում են վերամշակում: Եթե ​​ձեր ծրագրում ունեք մեկ կամ մի քանի մեծ (ավելի քան մի քանի տասնյակ տող կոդ) դասեր, դուք պետք է անմիջապես բաժանեք դրանք ավելի փոքրերի և ներառեք այս դասերի օբյեկտները մեկ ընդհանուր դասում։ Սրա պատճառը նույնն է, ինչ նախորդ պարբերությունում։

Չափից շատ ժամանակավոր փոփոխականները նույնպես վատ կոդի նշան են, որը վերամշակման կարիք ունի: Որպես կանոն, շատ ժամանակավոր փոփոխականներ հայտնաբերվում են չափազանց «փքված» գործառույթներում. երբ դուք վերամշակում եք նման գործառույթները, ամենայն հավանականությամբ, դրանցից յուրաքանչյուրում ժամանակավոր փոփոխականների թիվը կփոքրանա, և ծածկագիրը կդառնա շատ ավելի պարզ և հարմար:

Կան բազմաթիվ «խառնաշփոթ» պահված տվյալներ, որոնք տրամաբանորեն կապված են և կարող են միավորվել կառուցվածքի կամ դասի մեջ: Տրամաբանորեն առնչվող տվյալները միշտ պետք է պահվեն կառուցվածքներում/դասերում, նույնիսկ եթե դրանք ընդամենը 2-3 փոփոխական են, սա ոչ ոքի չի վատացնի, բայց կոդը շատ ավելի պարզ կդառնա:

Եթե ​​մի դասի օբյեկտները շատ/հաճախ են մուտք գործում (հղում դեպի) մեկ այլ օբյեկտի տվյալներ, դուք պետք է վերանայեք օբյեկտների ֆունկցիոնալությունը: Հավանաբար, դուք սխալ ճարտարապետական ​​որոշում եք կայացրել և պետք է հնարավորինս շուտ փոխեք այն, նախքան այս սխալը կտարածվի ամբողջ ծածկագրով:

Փորձեք չպահել շատ գլոբալ փոփոխականներ: Եթե ​​ձեզ իսկապես անհրաժեշտ են հենց այդքան շատ և ոչ պակաս գլոբալ օբյեկտներ, փորձեք գոնե դրանք խմբավորել կառուցվածքների/դասերի մեջ, կամ գոնե դրանք տեղադրել առանձին անվանատարածքում, ապա կա հնարավորություն, որ դուք պատահաբար սխալմամբ օգտագործեք ինչ-որ փոփոխական: դառնալ զգալիորեն ցածր:

Refactoring-ը պետք է անընդհատ օգտագործվի կոդը մշակելիս: Դրա իրականացման հիմնական խթանները հետևյալ խնդիրներն են.

• 1. անհրաժեշտ է ավելացնել նոր գործառույթ, որը լավ չի տեղավորվում ընդունված ճարտարապետական ​​լուծման մեջ.
• 2. անհրաժեշտ է ուղղել սխալը, որի պատճառներն անմիջապես պարզ չեն.
• 3. թիմի զարգացման դժվարությունների հաղթահարում, որոնք պայմանավորված են ծրագրի բարդ տրամաբանությամբ.

Վատ կոդի նշաններ

Շատ առումներով, վերամշակելիս ավելի լավ է ապավինել փորձի վրա հիմնված ինտուիցիային: Այնուամենայնիվ, կան որոշ տեսանելի կոդի հոտեր, որոնք պահանջում են վերամշակում.

• 1. կոդի կրկնօրինակում;
• 2. երկար մեթոդ;
• 3. մեծ դաս;
• 4. պարամետրերի երկար ցուցակ;
• 5. «ագահ» գործառույթները մեթոդ են, որը չափից դուրս մուտք է գործում մեկ այլ օբյեկտի տվյալներին.
• 6. ավելորդ ժամանակավոր փոփոխականներ;
• 7. տվյալների դասեր;
• 8. չխմբավորված տվյալներ.

Կոդի վերամշակում

Ծրագրավորման մեջ refactoring տերմինը նշանակում է փոխել ծրագրի սկզբնական կոդը՝ առանց դրա արտաքին վարքագիծը փոխելու։ Extreme Programming-ում և այլ արագաշարժ մեթոդոլոգիաներում, refactoring-ը ծրագրային ապահովման մշակման ցիկլի անբաժանելի մասն է. մշակողները փոխարինում են նոր թեստեր և ֆունկցիոնալություն ստեղծելու, այնուհետև վերամշակելու կոդի հետևողականությունը և թափանցիկությունը բարելավելու համար: Միավորների ավտոմատ փորձարկումն ապահովում է, որ վերաֆակտորինգները չեն խախտում առկա ֆունկցիոնալությունը:

Երբեմն սխալ refactoring նշանակում է կոդի ուղղում նախապես համաձայնեցված կանոններով՝ նահանջների, տողերի ընդմիջումների, մեկնաբանությունների և այլ տեսողական նշանակալի փոփոխությունների համար, որոնք ոչ մի կերպ չեն ազդում կոմպիլյացիայի գործընթացի վրա, որպեսզի ապահովվի կոդի ավելի լավ ընթերցանություն (տես կոդի ձևաչափումը):

Refactoring-ը ի սկզբանե նախատեսված չէ սխալներ շտկելու և նոր գործառույթներ ավելացնելու համար, այն ընդհանրապես չի փոխում ծրագրաշարի վարքագիծը և օգնում է խուսափել սխալներից և հեշտացնել ֆունկցիոնալությունը: Այն իրականացվում է կոդի հասկանալիությունը բարելավելու կամ դրա կառուցվածքը փոխելու, «մեռած ծածկագիրը» հեռացնելու համար՝ այս ամենը հետագայում կոդի պահպանումն ու զարգացումը հեշտացնելու համար: Մասնավորապես, ծրագրին նոր վարքագիծ ավելացնելը կարող է դժվար լինել գոյություն ունեցող կառուցվածքով. այս դեպքում ծրագրավորողը կարող է կատարել անհրաժեշտ վերամշակումներ, այնուհետև ավելացնել նոր գործառույթներ:

Սա կարող է լինել դաշտը մի դասից մյուսը տեղափոխելը, մեթոդից կոդի մի կտոր հանելը և այն իր մեթոդը դարձնելը կամ նույնիսկ դասի հիերարխիայի շուրջ ծածկագիրը տեղափոխելը: Յուրաքանչյուր առանձին քայլ կարող է տարրական թվալ, բայց նման փոքր փոփոխությունների կուտակային ազդեցությունը կարող է արմատապես բարելավել նախագիծը կամ նույնիսկ կանխել վատ մշակված ծրագրի քայքայումը: