Մշակողի հիմնական հմտությունը, որը կդարձնի ձեր ծածկագիրը ավելի լավը
Թարգմանչի առաջաբան. Այս հոդվածը կարդալուց հետո դուք կարող եք զարմանալ կամ նույնիսկ զայրանալ: Այո, մենք նույնպես զարմացանք. հեղինակը, իբր, երբեք չէր լսել թիմում հիերարխիայի մասին, «արա դա արագ և առանց պատճառաբանության» կարգավիճակով առաջադրանքներ դնելու մասին։ Այո, այդպես է, սա մի քիչ տարօրինակ տեքստ է։ Իսկապես, հեղինակն առաջարկում է ծրագրավորողին ստանձնել համակարգի ճարտարապետի դերը. այդ դեպքում ինչո՞ւ է ձեզ անհրաժեշտ ճարտարապետ: Բայց այս բոլոր առարկությունները չպետք է ձեզ կուրացնեն գլխավորի վրա, թե ինչու մենք այնուամենայնիվ վերցրեցինք և թարգմանեցինք այս տեքստը։ Նա չի խոսում դերերի մասին: Այս տեքստը մասնագիտական մոտեցման և իրազեկման մասին է։ Ճշմարտությունն այն է, որ քանի դեռ դուք պարզապես «անում եք այն, ինչ ձեզ ասում են», առանց մտածելու ձեր գործողությունների իմաստի մասին, դուք երբեք չեք դառնա հիանալի ծրագրավորող:
Ասա ոչ ավելորդ կոդի: Ընդամենը պետք է երեք տառ միացնեք և ասեք բառը: Եկեք փորձենք դա անել միասին. «Nooooo!»
Բայց սպասիր։ Ինչու ենք մենք դա անում: Ի վերջո, ծրագրավորողի հիմնական խնդիրը կոդ գրելն է։ Բայց դուք պետք է գրեք որևէ կոդ, որը ձեզանից պահանջվում է: Ո՛չ։ «Հասկանալը, թե երբ չգրել կոդ, հավանաբար ամենակարևոր հմտությունն է ծրագրավորողի համար»: Ընթեռնելի կոդի արվեստը.
Հիշեցում.«Habr»-ի բոլոր ընթերցողների համար՝ 10 ռուբլի զեղչ «Habr» գովազդային կոդով Skillbox-ի ցանկացած դասընթացին գրանցվելիս:
Ծրագրավորումը խնդիրների լուծման արվեստ է: Իսկ դուք այս արվեստի վարպետ եք։
Երբեմն, փորձելով հնարավորինս արագ սկսել աշխատանքը, մենք այլ բանի մասին չենք մտածում, քան մեր առջեւ դրված առաջադրանքը կատարելը: Իսկ դա կարող է էլ ավելի լուրջ խնդիրներ առաջացնել։
Ինչի՞ վրա են աչք փակում ծրագրավորողները.
Ձեր գրած բոլոր ծածկագրերը պետք է հասկանալի լինեն այլ մշակողների համար և պետք է փորձարկվեն և կարգաբերվեն:
Բայց կա մի խնդիր. ինչ էլ որ գրես, դա կբարդացնի քո ծրագրակազմը և, հավանաբար, ապագայում սխալներ կներկայացնի:
«Կոդը վատ է, քանի որ այն սկսում է փտել և մշտական սպասարկում է պահանջում: Նոր գործառույթների ավելացումը հաճախ պահանջում է հին ծածկագրի փոփոխություն: Որքան մեծ է այն, այնքան մեծ է սխալի առաջացման հավանականությունը և այնքան ավելի շատ ժամանակ է պահանջվում կազմելու համար: Մեկ այլ մշակողից ավելի շատ ժամանակ է պահանջվում դա պարզելու համար: Իսկ եթե ռեֆակտորինգի կարիք լինի, ապա անպայման կլինեն բեկորներ, որոնք արժե փոխել։ Խոշոր ծածկագիրը հաճախ նշանակում է նախագծի ճկունության և ֆունկցիոնալության նվազում: Պարզ և էլեգանտ լուծումն ավելի արագ է, քան բարդ ծածկագիրը»:
Ինչպե՞ս իմանալ, թե երբ չգրել կոդ:
Խնդիրն այն է, որ ծրագրավորողները հաճախ ուռճացնում են իրենց կիրառման համար անհրաժեշտ գործառույթների քանակը: Արդյունքում կոդի շատ բաժիններ մնում են անավարտ կամ ոչ ոք չի օգտագործում դրանք, բայց դրանք բարդացնում են հավելվածը։
Դուք պետք է հստակ հասկանաք, թե ինչի կարիք ունի ձեր նախագիծը և ինչը՝ ոչ:
Օրինակ՝ հավելվածը, որը լուծում է ընդամենը մեկ խնդիր՝ էլփոստի կառավարում: Այդ նպատակով ներդրվել է երկու գործառույթ՝ նամակներ ուղարկելն ու ստանալը։ Դուք չպետք է ակնկալեք, որ փոստի կառավարիչը միաժամանակ կդառնա առաջադրանքների կառավարիչ:
Դուք պետք է վճռականորեն «ոչ» ասեք առաջարկներին՝ հավելվածի հիմնական առաջադրանքին չառնչվող գործառույթներ ավելացնելու համար: Սա հենց այն պահն է, երբ պարզ է դառնում, որ լրացուցիչ ծածկագիր պետք չէ։
Երբեք մի կորցրեք ձեր դիմումի կենտրոնացումը:
Միշտ հարցրեք ինքներդ ձեզ.
- Հիմա ի՞նչ գործառույթ պետք է իրականացվի։
- Ի՞նչ ծածկագիր գրեմ:
Կասկածի ենթարկեք ձեր մտքում ծագած մտքերը և գնահատեք դրսից եկող առաջարկները: Հակառակ դեպքում, լրացուցիչ կոդը կարող է պարզապես սպանել նախագիծը:
Իմանալով, թե երբ չպետք է ավելորդ բաներ ավելացնել, կօգնի ձեզ պահել ձեր կոդի բազան ամուր վերահսկողության տակ:
Ճանապարհի հենց սկզբում ծրագրավորողն ունի ընդամենը երկու կամ երեք աղբյուր ֆայլ։ Դա պարզ է. Հավելվածը կազմելու և գործարկելու համար պահանջվում է նվազագույն ժամանակ; Միշտ պարզ է, թե որտեղ և ինչ փնտրել:
Քանի որ հավելվածն ընդլայնվում է, ավելի ու ավելի շատ կոդային ֆայլեր են հայտնվում: Նրանք լրացնում են կատալոգը՝ յուրաքանչյուրը հարյուրավոր տողերով: Այս ամենը ճիշտ կազմակերպելու համար ստիպված կլինեք ստեղծել լրացուցիչ տեղեկատուներ։ Միևնույն ժամանակ, հիշելը, թե որ գործառույթներն են պատասխանատու, թե ինչի համար և որ գործողություններն են դրանք առաջացնում, գնալով դժվարանում է. սխալներ որսալը նույնպես ավելի շատ ժամանակ է պահանջում: Ծրագրի կառավարումը նույնպես դառնում է ավելի բարդ, ոչ թե մեկ, այլ մի քանի ծրագրավորող է պահանջվում, որպեսզի հետևեն ամեն ինչին: Ըստ այդմ՝ ծախսերը՝ թե՛ դրամական, թե՛ ժամանակային, աճում են, իսկ զարգացման գործընթացը դանդաղում է։
Նախագիծը, ի վերջո, դառնում է հսկայական, և յուրաքանչյուր նոր գործառույթ ավելացնելը ավելի ու ավելի շատ ջանքեր է պահանջում: Նույնիսկ շատ աննշան բանի համար պետք է մի քանի ժամ ծախսել։ Գոյություն ունեցող սխալների ուղղումը հանգեցնում է նորերի ի հայտ գալուն, և դիմումների թողարկման ժամկետները բաց են թողնվում:
Այժմ մենք պետք է պայքարենք նախագծի կյանքի համար։ Ինչո՞ւ։
Փաստն այն է, որ դուք պարզապես չհասկացաք, թե երբ չպետք է ավելացնեք լրացուցիչ կոդ, և «այո» պատասխանեցիք յուրաքանչյուր առաջարկի և գաղափարի: Դուք կույր էիք, նոր բաներ ստեղծելու ցանկությունը ստիպեց ձեզ անտեսել կարևոր փաստերը։
Հնչում է սարսափ ֆիլմի սցենար, այնպես չէ՞:
Սա հենց այն է, ինչ տեղի կունենա, եթե դուք շարունակեք այո ասել: Փորձեք հասկանալ, թե երբ կոդը չպետք է ավելացվի: Հեռացրեք ավելորդ բաները նախագծից. սա ձեր կյանքը շատ կհեշտացնի և կերկարացնի հավելվածի կյանքը:
«Իմ ամենաարդյունավետ օրերից մեկն այն էր, երբ ես ջնջեցի 1000 տող կոդ»:
- Քեն Թոմփսոն.
Դժվար է սովորել, թե երբ չգրել կոդը: Բայց դա անհրաժեշտ է։
Այո, ես գիտեմ, որ դուք նոր եք սկսել ծրագրավորողի ճանապարհը և ցանկանում եք կոդ գրել: Լավ է, մի կորցրեք առաջին տպավորությունը, բայց ոգևորության պատճառով մի կորցրեք կարևոր գործոնները։ Մենք ամեն ինչ հասկացանք փորձի ու սխալի միջոցով։ Դուք նույնպես սխալներ կգործեք և կսովորեք դրանցից։ Բայց եթե դուք կարողանաք դասեր քաղել վերը նշվածից, ձեր աշխատանքն ավելի գիտակից կդառնա:
Շարունակեք ստեղծագործել, բայց իմացեք, թե երբ ասեք ոչ: