Mars Climate Orbiter-ի սխալը․ փոքր չափման սխալ, մեծ դաս

Երբեմն ծրագրային խնդիրը կոտրված ալգորիթմը չէ։ Խնդիրը սխալ ենթադրությունն է։

Ինժեներական պատմության ամենահայտնի օրինակներից մեկը Mars Climate Orbiter տիեզերական սարքի կորուստն է 1999 թվականին։ Խնդիրն այն չէր, որ նախագծում չկային տաղանդ, տեխնոլոգիա կամ մեծ նպատակ։ Ձախողման պատճառը շատ պարզ էր․ մի թիմ օգտագործել էր անգլիական չափման միավորներ, իսկ մյուս համակարգը սպասում էր մետրական միավորներ։

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

Ինչ է տեղի ունեցել պարզ բառերով

Տիեզերական սարքը պետք է շատ ճշգրիտ հաշվարկներով մտներ ճիշտ ուղեծիր Մարսի մոտ։ Բայց տվյալների մի մասը մշակվել էր մեկ չափման համակարգով, իսկ մյուս մասը սպասում էր այլ չափման համակարգի։

Առօրյա օրինակով՝ դա նման է այն իրավիճակին, երբ մեկը հեռավորությունը տալիս է մղոններով, իսկ մյուսը կարծում է, որ թիվը կիլոմետրերով է։ Թիվը կարող է ճիշտ տեսք ունենալ, բայց դրա իմաստը սխալ է։

Ծրագրավորման և ինժեներիայի մեջ այսպիսի անհամապատասխանությունը վտանգավոր է, որովհետև համակարգիչները սովորաբար անում են այն, ինչ իրենց տրված է, ոչ թե այն, ինչ մարդիկ նկատի ունեին։

Ինչու այս սխալը դեռ կարևոր է

Այս պատմությունը միայն տիեզերքի մասին չէ։ Նույն տեսակի խնդիր կարող է լինել սովորական ծրագրային նախագծերում՝

• մեկ ծառայությունը ուղարկում է ցենտեր, մյուսը սպասում է դոլարներ
• մեկ համակարգը ուղարկում է կիլոգրամներ, մյուսը սպասում է ֆունտեր
• մեկ ամսաթիվը տեղական ժամով է, մյուսը սպասում է համաշխարհային ժամանակ
• մեկ համակարգը ուղարկում է վայրկյաններ, մյուսը սպասում է միլիվայրկյաններ
• մեկ թիմը կարծում է, որ դաշտը պարտադիր չէ, մյուսը կարծում է, որ պարտադիր է

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

Իրական դասը․ ենթադրությունները պետք է գրված լինեն

Շատ սխալներ առաջանում են, որովհետև մարդիկ ենթադրում են, որ բոլորը նույն բանն են հասկանում։ Բայց ծրագրային համակարգերը անվտանգ չեն աշխատում թաքնված ենթադրությունների վրա։

Եթե արժեքը ունի չափման միավոր, ձևաչափ, ժամային գոտի, արժույթ, սահմանափակում կամ կոնկրետ իմաստ, դա պետք է հստակ գրված լինի։ Միայն թիվը հաճախ բավարար չէ։ Համակարգը պետք է իմանա՝ այդ թիվը ինչ է նշանակում։

Լավ կոդը իմաստը տեսանելի է դարձնում

amount անունով փոփոխականը կարող է անհասկանալի լինել։ Դա դոլա՞ր է, ցե՞նտ, եվրո՞, թե՞ միավորներ։ duration անունով դաշտը նույնպես կարող է անհասկանալի լինել։ Դա վայրկյա՞ն է, րոպե՞, թե՞ միլիվայրկյան։

Ավելի հստակ անունները նվազեցնում են շփոթությունը՝

• amountInCents
• durationInSeconds
• weightInKg
• createdAtUtc
• distanceInMeters

Հստակ անունները չեն լուծում բոլոր խնդիրները, բայց սխալները ավելի դժվար են թաքնվում։

Թեստավորումը պետք է ստուգի ոչ միայն արժեքը, այլ նաև իմաստը

Թեստը, որը միայն ստուգում է՝ թիվ կա, թե ոչ, թույլ թեստ է։ Ավելի ուժեղ թեստերը ստուգում են՝ թիվը ճիշտ է տվյալ իրավիճակում, թե ոչ։

Օրինակ՝ եթե վճարման համակարգը սպասում է ցենտեր, թեստը պետք է հաստատի, որ 10 դոլարը դառնում է 1000 ցենտ, ոչ թե պարզապես “10”։ Եթե համակարգը սպասում է միլիվայրկյաններ, թեստերը պետք է հաստատեն, որ ժամանակի արժեքները ճիշտ են փոխակերպվում։

Լավ թեստերը պաշտպանում են թիմերին լուռ թյուրըմբռնումներից։

Ինչու հաղորդակցությունը նույնքան կարևոր է, որքան կոդը

Mars Climate Orbiter-ի պատմությունը հիշեցնում է նաև, որ տեխնիկական համակարգերը կառուցվում են մարդկանց կողմից։ Տարբեր թիմեր կարող են ունենալ տարբեր սովորություններ, գործիքներ, չափանիշներ և մտածելակերպ։

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

Օգտակար սովորություններ ծրագրավորողների և թիմերի համար

• Հնարավորության դեպքում չափման միավորները գրիր դաշտերի անուններում։
• Հստակ փաստաթղթավորիր համակարգերի միջև պայմանավորվածությունները։
• Մուտքային տվյալները ստուգիր՝ մինչև դրանց վստահելը։
• Օգտագործիր ընդհանուր չափանիշներ ամսաթվերի, արժույթների և չափումների համար։
• Ավելացրու թեստեր փոխակերպումների և սահմանային դեպքերի համար։
• Մի ենթադրիր, որ մյուս թիմը հասկանում է քո ձևաչափը։

Թաքնված դասը․ պարզ մանրուքները նույնպես հարգանք են պահանջում

Մեծ ձախողումները միշտ չէ, որ առաջանում են բարդ խնդիրներից։ Երբեմն դրանք գալիս են հիմնական մանրուքներից, որոնք ոչ ոք բավական ուշադիր չի ստուգել։

Ծրագրավորման մեջ «փոքր» մանրուքները՝ չափման միավորները, ժամային գոտիները, կլորացումը և ձևաչափերը, հաճախ որոշում են՝ համակարգը ճիշտ է աշխատում, թե լուռ սխալվում է։

Եզրակացություն

Mars Climate Orbiter-ի սխալը սովորեցնում է, որ ծրագրային որակը կախված է հստակությունից, ոչ միայն խելքից։ Երբ թիմերը բացահայտ են դարձնում չափման միավորները, ձևաչափերը և ենթադրությունները, նրանք նվազեցնում են լուռ սխալները և կառուցում են համակարգեր, որոնց ավելի հեշտ է վստահել։