Մի համաձայնեք զարգացնել մի բան, որը դուք չեք հասկանում

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

Բանն այն է, որ կոդի որակը (և վերջնական արտադրանքը) սերտորեն կապված է այն բանի հետ, թե որքանով են տեղյակ մարդիկ, ովքեր նախագծում և գրում են կոդը, թե ինչ են անում:

Դուք կարող եք հենց հիմա մտածել. «Շնորհակալություն, գլխ. Իհարկե, լավ կլիներ հասկանալ, թե ինչ եք գրում ընդհանրապես։ Հակառակ դեպքում, դուք կարող եք նաև վարձել կապիկների խումբ, որպեսզի կամայական ստեղներ խփեն և թողեք այն»: Եվ դուք միանգամայն իրավացի եք։ Համապատասխանաբար, ես ընդունում եմ, որ դուք գիտակցում եք, որ ընդհանուր պատկերացում ունենալն այն մասին, թե ինչ եք անում, անհրաժեշտ է: Սա կարելի է անվանել հասկացողության զրոյական մակարդակ, և մենք այն մանրամասն չենք վերլուծի։ Մենք մանրամասն կանդրադառնանք, թե կոնկրետ ինչ պետք է հասկանաք և ինչպես է դա ազդում ձեր ամենօրյա որոշումների վրա: Եթե ​​ես նախօրոք իմանայի այս բաները, դա ինձ կփրկեր շատ անիմաստ ժամանակ և կասկածելի ծածկագիր։

Թեև ստորև դուք չեք տեսնի կոդի ոչ մի տող, ես դեռ կարծում եմ, որ այստեղ ասված ամեն ինչ մեծ նշանակություն ունի բարձրորակ, արտահայտիչ կոդ գրելու համար:

Հասկանալու առաջին մակարդակ. Ինչու՞ դա չի աշխատում:

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

Ստանդարտ սխեման այսպիսի տեսք ունի.

1. Գտեք կոդի այն հատվածը, որն առաջացնում է խնդիրը (ինչպես դա անել դա առանձին թեմա է, ես այն լուսաբանում եմ ժառանգական կոդի մասին իմ գրքում)
2. Փոփոխություններ կատարեք այս հատվածում
3. Համոզվեք, որ սխալը շտկված է, և ռեգրեսիայի սխալներ չեն առաջացել

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

Առաջին մոտեցումը ճիշտ է. Ինչպես Սթիվ Մակքոնելը բացատրում է իր «Code Complete» գրքում (որը, ի դեպ, ես խորհուրդ եմ տալիս), ամեն անգամ, երբ մենք ինչ-որ բան փոխում ենք կոդում, մենք պետք է կարողանանք վստահորեն կանխատեսել, թե ինչպես դա կազդի հավելվածի վրա: Ես մեջբերում եմ հիշողությունից, բայց եթե սխալի ուղղումը չի աշխատում այնպես, ինչպես դուք ակնկալում էիք, դուք պետք է շատ անհանգստանաք և կասկածի տակ դնեք ձեր ամբողջ գործողությունների ծրագիրը:

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

Հասկանալու երկրորդ մակարդակ. Ինչու է դա աշխատում:

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

Այս անգամ, եկեք պատկերացնենք, որ դուք միանգամից երկու վրիպակի հաղորդում եք ստացել՝ առաջինը A սցենարի մասին է, երկրորդը՝ B սցենարի: Երկու սցենարներում էլ ինչ-որ սխալ է տեղի ունենում: Համապատասխանաբար, դուք առաջին հերթին հաղթահարում եք առաջին սխալը: Օգտագործելով սկզբունքները, որոնք մենք մշակել ենք XNUMX-ին մակարդակի ըմբռնման համար, դուք խորանում եք խնդրին առնչվող ծածկագրի մեջ, պարզում եք, թե ինչու է այն ստիպում հավելվածն իրեն պահել այնպես, ինչպես դա անում է Սցենար Ա-ում, և կատարել ողջամիտ ճշգրտումներ, որոնք տալիս են ձեր ուզած արդյունքը: . Ամեն ինչ հիանալի է ընթանում։

Այնուհետև դուք անցնում եք B սցենարին: Դուք կրկնում եք սցենարը՝ փորձելով սխալ առաջացնել, բայց՝ ​​անակնկալ: - Հիմա ամեն ինչ աշխատում է այնպես, ինչպես պետք է: Ձեր ենթադրությունը հաստատելու համար դուք չեղարկում եք փոփոխությունները, որոնք արել եք սխալ A-ի վրա աշխատելիս, և վրիպակ B-ն վերադառնում է: Ձեր սխալի ուղղումը լուծեց երկու խնդիրները: Բախտավոր!

Դուք ընդհանրապես չէիք հաշվում սրա վրա: Դուք գտել եք A սցենարի սխալը շտկելու միջոց և չեք պատկերացնում, թե ինչու է այն աշխատել B սցենարի համար: Այս փուլում շատ գայթակղիչ է մտածել, որ երկու առաջադրանքն էլ հաջողությամբ ավարտվել են: Սա միանգամայն տրամաբանական է. խնդիրն այն էր, որ վերացնել սխալները, այնպես չէ՞: Բայց աշխատանքը դեռ ավարտված չէ. դուք դեռ պետք է հասկանաք, թե ինչու ձեր գործողությունները շտկեցին B սցենարի սխալը: Ինչո՞ւ: Որովհետև դա կարող է սխալ սկզբունքներով աշխատել, և այդ ժամանակ ձեզ հարկավոր կլինի այլ ելք փնտրել: Ահա այսպիսի դեպքերի մի քանի օրինակ.

• Քանի որ լուծումը հարմարեցված չէր B սխալին, հաշվի առնելով բոլոր գործոնները, դուք կարող եք անգիտակցաբար կոտրել C ֆունկցիան:
• Հնարավոր է, որ ինչ-որ տեղ թաքնված լինի նաև երրորդ վրիպակ՝ կապված նույն ֆունկցիայի հետ, և ձեր սխալի շտկումը կախված է դրանից՝ B սցենարի համակարգի ճիշտ աշխատանքի համար: Այժմ ամեն ինչ լավ է թվում, բայց մի օր այս երրորդ սխալը կնկատվի և կշտկվի: Այնուհետև B սցենարում սխալը նորից կհայտնվի, և դա լավ է, եթե միայն այնտեղ:

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

Հասկանալու երրորդ մակարդակ. Ինչու՞ է այն աշխատում:

Իմ վերջին խորաթափանցությունը վերաբերում է հենց այս մակարդակին, և դա, հավանաբար, այն է, որն ինձ առավելագույն օգուտ կբերեր, եթե ես ավելի վաղ հանգեի այս գաղափարին:

Որպեսզի ավելի պարզ լինի, եկեք դիտարկենք մի օրինակ. ձեր մոդուլը պետք է համատեղելի լինի X ֆունկցիայի հետ: Դուք առանձնապես ծանոթ չեք X ֆունկցիային, բայց ձեզ ասացին, որ դրա հետ համատեղելի լինելու համար անհրաժեշտ է օգտագործել F շրջանակը: Այլ X-ի հետ ինտեգրված մոդուլներն աշխատում են հենց նրա հետ:

Ձեր կոդը կյանքի առաջին օրվանից ոչ մի կապ չի ունեցել F շրջանակի հետ, ուստի այն իրականացնելն այնքան էլ հեշտ չի լինի։ Սա լուրջ հետևանքներ կունենա մոդուլի որոշ մասերի համար: Այնուամենայնիվ, դուք ինքներդ ձեզ նետում եք զարգացման. ռեգրեսիայի սխալների շտկում - այս ամենը F շրջանակն իրականացնելու համար:

Եվ ինչ-որ պահի դուք հանկարծ հասկանում եք, կամ գուցե ինչ-որ մեկից լսում եք, որ միգուցե F շրջանակը ձեզ ընդհանրապես համատեղելիություն չի տա X հատկանիշի հետ: Գուցե այդ ամբողջ ժամանակն ու ջանքերը լիովին սխալ են ծախսվել դրա համար:

Նման մի բան եղել է մի անգամ, երբ աշխատում էի մի նախագծի վրա, որի պատասխանատուն ես էի: Ինչու՞ դա տեղի ունեցավ: Քանի որ ես քիչ էի հասկանում, թե ինչ գործառույթ է X-ը և ինչպես է այն կապված F շրջանակի հետ: Ի՞նչ պետք է անեի: Խնդրեք զարգացման առաջադրանքը հանձնարարող անձին հստակ բացատրել, թե ինչպես է գործողությունների նախատեսվող ընթացքը հանգեցնում ցանկալի արդյունքի, այլ ոչ թե պարզապես կրկնել այն, ինչ արվել է այլ մոդուլների համար կամ ընդունել իրենց խոսքն այն մասին, որ դա այն է, ինչ X հատկանիշը պետք է անի:

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

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

Հասկանալու չորրորդ մակարդակ. ???

Ծրագրավորման մեջ միշտ սովորելու ավելին կա, և ես կարծում եմ, որ ես միայն քերծել եմ հասկանալու թեմայի մակերեսը: Փոխըմբռնման ի՞նչ այլ մակարդակներ եք հայտնաբերել կոդի հետ աշխատելու տարիների ընթացքում: Ի՞նչ որոշումներ եք կայացրել, որոնք դրական ազդեցություն են ունեցել կոդի և հավելվածի որակի վրա: Ո՞ր որոշումները սխալ եղան և ձեզ արժեքավոր դաս տվեցին: Կիսվեք ձեր փորձով մեկնաբանություններում։

Source: www.habr.com