कोड की समीक्षा और संभावना सिद्धांत

सभी प्रोग्रामर प्रायिकता सिद्धांत से परिचित नहीं हैं। यह प्रतीत होता है - ठीक है, परेशानी क्या है? किसने क्या अध्ययन किया, कोई सार्वभौमिक प्रतिभा नहीं है। खेल के विकास, क्रिप्टोग्राफी, अच्छी तरह से, यह किसी भी वित्तीय और सांख्यिकीय सॉफ़्टवेयर में हो सकता है, सिवाय इसके कि आपको एक अच्छे स्तर पर सिद्धांत की आवश्यकता है। लेकिन नहीं! कुछ चीजों की गलतफहमी उन परियोजनाओं में भी खराब परिणाम दे सकती है जहां इसके आवेदन में गंध नहीं है। कोई जादू नहीं है, बस मानव मस्तिष्क गलत तरीके से कुछ संभावनाओं का अनुमान लगाता है और परिणामस्वरूप, गलत निर्णय लेता है।

तो, एक निश्चित प्रोग्रामर Vasya की कल्पना करें। वह कोड लिखता है। खैर, क्योंकि वह एक प्रोग्रामर है। मान लीजिए कि वासा एक अच्छा प्रोग्रामर है और उसका 75% कोड त्रुटि-मुक्त है। वास्तव में, मैं, निश्चित रूप से, झूठ है और यह संभावना नहीं है कि वास्या एक ऐसा गुरु है, लेकिन फिर से - कल्पना करें। सादगी के लिए, हम मानते हैं कि इसके कोड की प्रत्येक 100 लाइनों के लिए, 75 को सुधार की आवश्यकता नहीं है, और 25 त्रुटियों में पाया और तय किया जाना चाहिए। और इसलिए हम तय करते हैं कि यह कैसे करना है। हमेशा की तरह, बहुत सी राय हैं, कुछ यूनिट परीक्षणों के लिए, कुछ क्यूए विभाग के विस्तार के लिए, कुछ प्रत्येक प्रतिबद्धों की कोड समीक्षा के लिए, पूर्णतावादी जो बजट की उपेक्षा करते हैं और एक ही बार में सब कुछ के लिए समय सीमा तय करते हैं, आत्म-विश्वास "पेशेवरों" और लालच प्रबंधक एक ही बार में। खैर, हमेशा की तरह। लेकिन कुछ तय करने की जरूरत है। और यहां प्रत्येक प्रकार की गतिविधि और उससे होने वाले लाभ के लिए संसाधनों का मूल्यांकन करने का विचार आता है। और अब चलो दक्षता का अनुमान लगाते हैं, उदाहरण के लिए, कोड समीक्षा।

एक अनुभवहीन गणना कुछ इस तरह दिख सकती है: वास्या ने कोड की 100 लाइनें लिखीं, उनके पास आमतौर पर 75% सही कोड, 25% बग होते हैं। उसे कोड समीक्षा में उसी समय पर खर्च करें - और 2 गुना कम कीड़े (12.5%) प्राप्त करें। खैर, क्योंकि 2 गुना अधिक संसाधन खर्च किए जाते हैं, इसका मतलब 2 गुना कम बग है।

लेकिन ऐसा कुछ भी नहीं है! वसय वसय है। उन्होंने कल यह कोड लिखा था, और यदि वह आज अपने कोड की कोड समीक्षा करेंगे - तो उन्हें कुछ भी नहीं मिलेगा। क्यों? क्योंकि कि ।

अच्छा ठीक है। इसलिए, अगर पेट्या (लगभग समान योग्यता का) अपने कोड को देखता है, तो वह बग की संख्या को आधा (12.5%) तक कम कर देगा। ठीक है, क्योंकि वे एक ही योग्यता के बारे में हैं, लेकिन फिर भी अलग-अलग लोग हैं, और यह पता चला है कि हम इस काम के लिए 2 गुना अधिक संसाधन खर्च करते हैं, जिसका मतलब है कि हमें 2 गुना कम कीड़े मिलते हैं। अब देखते हैं कि यह वास्तव में कैसा है।

प्रायिकता सिद्धांत कहता है कि अगर हमारे पास दो उपकरणों की प्रणाली है जिसमें विश्वसनीयता X और Y है और इसके विफल होने के लिए दोनों उपकरणों को विफल होना चाहिए, तो सिस्टम की समग्र विश्वसनीयता 1 - (1-X) * (1-Y) है। यानी 75% की समान विश्वसनीयता वाले "डिवाइस" वास्या और पेट्या के लिए, समग्र विश्वसनीयता 93.75% होगी! देखिए, बग की संख्या घटकर 12.5% ​​नहीं, बल्कि 6.25% हो गई है! यानी कोड की समीक्षा पर किसी अन्य व्यक्ति के संसाधनों को भी इसी तरह की योग्यताओं पर खर्च करने के बाद, हम बग की संख्या को आधे से कम नहीं करते हैं, बल्कि चार गुना तक कम कर देते हैं! कूल। इसके अलावा, यह देखते हुए कि कोड की समीक्षा आमतौर पर टीम के सर्वश्रेष्ठ डेवलपर्स द्वारा की जाती है (मोटे तौर पर बोलकर, "औसत" 75% से अधिक विश्वसनीयता) और वे लेखक द्वारा कोड लिखने की तुलना में उस पर काफी कम समय बिताते हैं, हमें और भी अधिक प्रभावशाली परिणाम मिलते हैं।

मैं क्यों हूँ?

अब, कोड रिव्यू में कुछ निश्चित संसाधनों का निवेश करके हम क्या प्राप्त कर सकते हैं, इसका एक बेहतर विचार है, हम कोड की गुणवत्ता में सुधार के लिए इसे और / या अन्य तंत्र को लागू करने के बारे में अधिक आसानी से निर्णय ले सकते हैं। हम पहले से ही संख्याओं के साथ काम कर सकते हैं, न कि "हर कोई इसे करता है, यह सही है!" बनाम "हां, यह है, और इसलिए कोई समय नहीं है!" पर्याप्त मार्गदर्शन के लिए, संख्याओं द्वारा समर्थित एक तर्क हमेशा जोर से वाक्यांशों के साथ टॉस करने की तुलना में अधिक वजन ले जाएगा।

एक संक्षिप्त निष्कर्ष, उन लोगों के लिए जो पूरे लेख को पढ़ने के लिए बहुत आलसी हैं

कोड की समीक्षा का उपयोग करना (यदि आप पहले से ही इसका उपयोग नहीं कर रहे हैं) तो आपको पहले से अधिक सोचने में मदद मिलेगी।