Ինչպես ասում են, եթե չես ամաչում քո հին կոդից, ուրեմն դու չես աճում որպես ծրագրավորող, և ես համաձայն եմ այս կարծիքի հետ։ Ես սկսել եմ ծրագրավորել հաճույքի համար ավելի քան 40 տարի առաջ, իսկ մասնագիտորեն՝ 30 տարի առաջ, ուստի շատ սխալներ ունեմ: շատ. Որպես համակարգչային գիտության պրոֆեսոր՝ ես սովորեցնում եմ իմ ուսանողներին սովորել սխալներից՝ իրենցից, իմից և մյուսներից: Կարծում եմ՝ ժամանակն է խոսել իմ սխալների մասին՝ համեստությունս չկորցնելու համար։ Հուսով եմ՝ դրանք ինչ-որ մեկին օգտակար կլինեն։

Երրորդ տեղ՝ Microsoft C կոմպիլյատոր

Իմ դպրոցի ուսուցիչը կարծում էր, որ Ռոմեոն և Ջուլիետը չի կարելի ողբերգություն համարել, քանի որ հերոսները ողբերգական մեղք չունեն. նրանք պարզապես հիմար էին իրենց պահում, ինչպես պետք է դեռահասները: Ես այն ժամանակ համաձայն չէի նրա հետ, բայց հիմա նրա կարծիքով ռացիոնալության հատիկ եմ տեսնում, հատկապես ծրագրավորման հետ կապված։

Երբ ես ավարտեցի MIT-ի երկրորդ կուրսը, ես երիտասարդ էի և անփորձ, ինչպես կյանքում, այնպես էլ ծրագրավորման մեջ: Ամռանը ես ինտերնավորվեցի Microsoft-ում՝ C կոմպիլյատորների թիմում: Սկզբում ես սովորական գործեր էի անում, ինչպիսիք են պրոֆիլավորման աջակցությունը, իսկ հետո ինձ վստահեցին աշխատել կոմպիլյատորի ամենազվարճալի մասի վրա (ինչպես կարծում էի)՝ backend-ի օպտիմալացում: Մասնավորապես, ես պետք է բարելավեի x86 կոդը մասնաճյուղի հայտարարությունների համար:

Որոշելով գրել մեքենայի օպտիմալ կոդը յուրաքանչյուր հնարավոր դեպքի համար, ես գլխովին նետվեցի լողավազան: Եթե ​​արժեքների բաշխման խտությունը բարձր էր, ես դրանք մուտքագրեցի անցումային աղյուսակ. Եթե ​​նրանք ընդհանուր բաժանարար ունեին, ես այն օգտագործում էի սեղանն ավելի ամուր դարձնելու համար (բայց միայն այն դեպքում, եթե բաժանումը հնարավոր լիներ օգտագործելով bit shift) Երբ բոլոր արժեքները երկուսի ուժ էին, ես կատարեցի ևս մեկ օպտիմալացում: Եթե ​​մի շարք արժեքներ չբավարարեցին իմ պայմանները, ես այն բաժանեցի մի քանի օպտիմալացվող դեպքերի և օգտագործեցի արդեն օպտիմիզացված կոդը:

Դա մղձավանջ էր։ Շատ տարիներ անց ինձ ասացին, որ իմ կոդը ժառանգած ծրագրավորողը ատում է ինձ:

Քաղված դաս

Ինչպես գրում են Դեյվիդ Փաթերսոնը և Ջոն Հենեսին Computer Architecture and Computer Systems Design-ում, ճարտարապետության և դիզայնի հիմնական սկզբունքներից մեկն այն է, որ ընդհանուր առմամբ իրերը հնարավորինս արագ աշխատեն:

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

Ի պաշտպանություն իմ՝ ես փորձեցի պարզել, թե գործնականում ինչ տեսք ունեն ճյուղերի հայտարարությունները (օրինակ՝ քանի ճյուղ կա և ինչպես են բաշխվել հաստատունները), բայց 1988-ին այս տեղեկատվությունը հասանելի չէր: Այնուամենայնիվ, ես չպետք է հատուկ դեպքեր ավելացնեի, երբ ընթացիկ կոմպիլյատորը չկարողացավ ստեղծել օպտիմալ կոդ իմ ստեղծած արհեստական ​​օրինակի համար:

Ինձ անհրաժեշտ էր զանգահարել փորձառու ծրագրավորողին և նրա հետ միասին մտածել, թե որոնք են սովորական դեպքերը և կոնկրետ զբաղվել դրանցով։ Ես ավելի քիչ կոդ կգրեի, բայց դա լավ բան է: Ինչպես գրել է Stack Overflow-ի հիմնադիր Ջեֆ Էթվուդը, ծրագրավորողի ամենավատ թշնամին հենց ինքը ծրագրավորողն է.

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

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

Երկրորդ տեղը՝ գովազդ սոցիալական ցանցերում

Երբ ես աշխատում էի Google-ում սոցիալական մեդիայի գովազդի վրա (հիշո՞ւմ եք Myspace-ը), C++-ում այսպիսի բան գրեցի.

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

Ծրագրավորողները կարող են անմիջապես տեսնել սխալը. վերջին արգումենտը պետք է լինի j, ոչ թե i: Միավորի փորձարկումը չբացահայտեց սխալը, և ոչ էլ իմ գրախոսը: Գործարկումն իրականացվեց, և մի գիշեր իմ կոդը գնաց սերվեր և խափանեց տվյալների կենտրոնի բոլոր համակարգիչները:

Ոչ մի վատ բան չի եղել։ Ոչ ոքի համար ոչինչ չի կոտրվել, քանի որ մինչ գլոբալ մեկնարկը կոդը փորձարկվել է մեկ տվյալների կենտրոնում: Եթե ​​SRE-ի ինժեներները որոշ ժամանակ չդադարեն բիլիարդ խաղալ և մի փոքր հետ չդարձնեն: Հաջորդ առավոտ ես նամակ ստացա վթարի մասին, ուղղեցի կոդը և ավելացրի միավորի թեստեր, որոնք կբռնեն սխալը: Քանի որ ես հետևեցի արձանագրությանը, այլապես իմ կոդը պարզապես չէր աշխատի, այլ խնդիրներ չկար:

Քաղված դաս

Շատերը վստահ են, որ նման խոշոր սխալն անպայման կարժենա մեղավորին աշխատանքից հեռացնել, բայց դա այդպես չէ՝ նախ բոլոր ծրագրավորողները սխալվում են, երկրորդ՝ հազվադեպ են կրկնում նույն սխալը։

Իրականում, ես ունեմ ծրագրավորող ընկեր, որը փայլուն ինժեներ էր և հեռացվեց աշխատանքից մեկ սխալ թույլ տալու համար: Դրանից հետո նա աշխատանքի ընդունվեց Google-ում (և շուտով բարձրացվեց) - նա անկեղծորեն խոսեց հարցազրույցում իր թույլ տված սխալի մասին, և դա ճակատագրական չհամարվեց։

Ահա թե ինչ պատմել IBM-ի լեգենդար ղեկավար Թոմաս Ուոթսոնի մասին.

Հայտարարվել է մոտ մեկ միլիոն դոլար արժողությամբ կառավարության պատվեր։ IBM Corporation-ը, ավելի ճիշտ՝ անձամբ Թոմաս Ուոթսոն ավագը, իսկապես ցանկանում էր ստանալ այն: Ցավոք, վաճառքի ներկայացուցիչը չկարողացավ դա անել, և IBM-ը պարտվեց հայտին: Հաջորդ օրը այս աշխատակիցը մտավ պարոն Ուոթսոնի գրասենյակ և ծրար դրեց նրա գրասեղանի վրա։ Պարոն Ուոթսոնը նույնիսկ չփորձեց նայել դրան. նա սպասում էր աշխատակցի և գիտեր, որ դա աշխատանքից ազատման դիմում է։

Ուոթսոնը հարցրեց, թե ինչն է սխալ եղել:

Վաճառքի ներկայացուցիչը մանրամասն խոսեց մրցույթի ընթացքի մասին։ Նա նշել է թույլ տված սխալներ, որոնցից կարելի էր խուսափել. Ի վերջո, նա ասաց. «Պարոն Ուոթսոն, շնորհակալություն, որ թույլ տվեցիք ինձ բացատրել: Ես գիտեմ, թե մեզ ինչքան էր պետք այս պատվերը։ Ես գիտեմ, թե որքան կարևոր էր նա», և պատրաստվեց հեռանալ:

Ուոթսոնը մոտեցավ նրան դռան մոտ, նայեց նրա աչքերի մեջ և վերադարձրեց ծրարը հետևյալ գրությամբ. «Ինչպե՞ս կարող եմ քեզ բաց թողնել։ Ես հենց նոր մեկ միլիոն դոլար ներդրեցի քո կրթության համար:

Ես ունեմ մի շապիկ, որի վրա գրված է. «Եթե դու իսկապես սովորում ես սխալներից, ուրեմն ես արդեն վարպետ եմ»: Իրականում, երբ խոսքը վերաբերում է սխալներին, ես գիտությունների դոկտոր եմ։

Առաջին տեղ՝ App Inventor API

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

Ինչքան վատ, այնքան լավ

Ես կարդում եմ Ռիչարդ Գաբրիելի էսսե Այս մոտեցման մասին իննսունականներին՝ որպես ասպիրանտ, և դա ինձ այնքան է դուր գալիս, որ դա հարցնում եմ իմ ուսանողներին: Եթե ​​լավ չես հիշում, թարմացրու հիշողությունդ, փոքր է։ Այս շարադրությունը հակադրում է «ճիշտը ստանալու» ցանկությունը և «ավելի վատը, ավելի լավը» մոտեցումը շատ առումներով, ներառյալ պարզությունը:

Ինչպես պետք է լինի. դիզայնը պետք է լինի պարզ իրականացման և ինտերֆեյսի մեջ: Ինտերֆեյսի պարզությունն ավելի կարևոր է, քան իրականացման պարզությունը:

Որքան վատ, այնքան լավ. դիզայնը պետք է լինի պարզ իրականացման և ինտերֆեյսի մեջ: Իրականացման պարզությունն ավելի կարևոր է, քան ինտերֆեյսի պարզությունը:

Եկեք մի րոպե մոռանանք այդ մասին։ Ցավոք սրտի, ես երկար տարիներ մոռացել եմ դրա մասին:

Appրագրերի գյուտարար

Google-ում աշխատելու ընթացքում ես թիմի մի մասն էի Appրագրերի գյուտարար, Android-ի ձգտող ծրագրավորողների համար քաշել և թողնել առցանց զարգացման միջավայր: 2009 թվականն էր, և մենք շտապում էինք ժամանակին թողարկել ալֆա տարբերակը, որպեսզի ամռանը վարպետության դասեր անցկացնենք ուսուցիչների համար, ովքեր կարող են օգտագործել միջավայրը աշնանը դասավանդելիս։ Ես կամավոր ներկայացա սփրայթներ իրականացնելու, կարոտով, թե ինչպես էի TI-99/4-ով խաղեր գրում: Նրանց համար, ովքեր չգիտեն, sprite-ը երկչափ գրաֆիկական օբյեկտ է, որը կարող է շարժվել և փոխազդել ծրագրային ապահովման այլ տարրերի հետ: Սփրայթների օրինակներ են տիեզերանավերը, աստերոիդները, մարմարները և ռակետները։

Մենք իրականացրել ենք օբյեկտի վրա հիմնված App Inventor-ը Java-ում, այնպես որ այնտեղ ընդամենը մի խումբ օբյեկտներ կան: Քանի որ գնդակներն ու սփրայթներն իրենց շատ նման են պահում, ես ստեղծեցի աբստրակտ սփրայթ դաս՝ X, Y, Արագություն (արագություն) և Վերնագիր (ուղղություն) հատկություններով (դաշտեր): Նրանք ունեին նույն մեթոդները՝ բախումներ հայտնաբերելու, էկրանի եզրից ցատկելու և այլն։

Գնդակի և սփրայթի հիմնական տարբերությունն այն է, թե կոնկրետ ինչ է գծված՝ լցված շրջանակը, թե ռաստերը: Քանի որ ես նախ կիրառեցի sprites-ը, տրամաբանական էր նշել նկարի գտնվելու վայրի վերին ձախ անկյունի x- և y- կոորդինատները:

Երբ sprites-ները աշխատում էին, ես որոշեցի, որ կարող եմ իրականացնել գնդակի առարկաներ շատ քիչ կոդով: Միակ խնդիրն այն էր, որ ես գնացի ամենապարզ ճանապարհը (իրականացնողի տեսանկյունից)՝ նշելով գնդակը շրջանակող եզրագծի վերին ձախ անկյունի x- և y- կոորդինատները:

Փաստորեն, անհրաժեշտ էր նշել շրջանագծի կենտրոնի x- և y- կոորդինատները, ինչպես ուսուցանվում է մաթեմատիկայի ցանկացած դասագրքում և շրջանակներ հիշատակող ցանկացած այլ աղբյուրում:

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

Ես վերջապես կարկատեցի այս սխալը միայն վերջերս՝ տասը տարի անց: «Կարկատանված», ոչ թե «ֆիքսված», քանի որ, ինչպես ասում է Ջոշուա Բլոխը, API-ները հավերժ են: Չկարողանալով փոփոխություններ կատարել, որոնք կազդեն գոյություն ունեցող ծրագրերի վրա, մենք ավելացրեցինք OriginAtCenter հատկությունը հին ծրագրերում false արժեքով և բոլոր ապագա ծրագրերում true արժեքով: Օգտատերերը կարող են տրամաբանական հարց տալ. ո՞վ է մտածել ելակետը կենտրոնից բացի այլ տեղ տեղադրել: Ում? Մի ծրագրավորողի, ով տասը տարի առաջ շատ ծույլ էր ստեղծել նորմալ API:

Քաղված դասերը

API-ների վրա աշխատելիս (ինչը երբեմն պետք է անի գրեթե յուրաքանչյուր ծրագրավորող), դուք պետք է հետևեք Ջոշուա Բլոխի տեսանյութում շարադրված լավագույն խորհուրդներին:Ինչպես ստեղծել լավ API և ինչու է դա այդքան կարևոր" կամ այս կարճ ցուցակում:

• API-ն կարող է ձեզ և՛ մեծ օգուտ բերել, և՛ մեծ վնաս:. Լավ API-ն ստեղծում է կրկնվող հաճախորդներ: Վատը դառնում է քո հավերժական մղձավանջը։
• Հանրային API-ները, ինչպես ադամանդները, հավերժ են գործում. Տվեք ամեն ինչ. ամեն ինչ ճիշտ անելու այլ հնարավորություն երբեք չի լինի:
• API-ի ուրվագծերը պետք է լինեն հակիրճ — մեկ էջ դասի և մեթոդի ստորագրություններով և նկարագրություններով՝ տողից ոչ ավելի: Սա թույլ կտա հեշտությամբ վերակառուցել API-ն, եթե այն առաջին անգամ կատարյալ չստացվի:
• Նկարագրեք օգտագործման դեպքերընախքան API-ի ներդրումը կամ նույնիսկ դրա ճշգրտման վրա աշխատելը: Այս կերպ դուք կխուսափեք ամբողջովին ոչ ֆունկցիոնալ API-ի ներդրումից և նշելուց:

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

Ռիչարդ Գաբրիելի էսսեի վերնագիրը՝ «Ավելի վատն է, ավելի լավն է», վերաբերում է այն առավելությունին, որը վերաբերում է շուկայում առաջինը լինելուն, նույնիսկ անկատար արտադրանքով, մինչդեռ ինչ-որ մեկը հավերժություն է ծախսում՝ հետապնդելով կատարյալին: Անդրադառնալով սփրայթ կոդի վրա՝ ես հասկանում եմ, որ ես նույնիսկ կարիք չունեի ավելի շատ կոդ գրել՝ այն ճիշտ ստանալու համար: Ինչ էլ ասի, ես չարաչար սխալվեցի։

Ամփոփում

Ծրագրավորողները ամեն օր սխալներ են թույլ տալիս՝ անկախ նրանից՝ դա սխալ կոդ գրելն է, թե չցանկանալը փորձել ինչ-որ բան, որը կբարելավի իրենց հմտություններն ու արտադրողականությունը: Իհարկե, դուք կարող եք ծրագրավորող լինել՝ առանց ինձ նման լուրջ սխալներ թույլ տալու։ Բայց անհնար է դառնալ լավ ծրագրավորող՝ չճանաչելով քո սխալները և սովորել դրանցից։

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

Source: www.habr.com