नियम 10: 1 प्रोग्रामिंग और लेखन में

इस लेख में, लेखक पुस्तकों या प्रोग्राम कोड को लिखने में खर्च होने वाले समय की मात्रा का विश्लेषण करता है, और एक दिलचस्प पैटर्न पर आता है। इसका उपयोग प्रोजेक्ट कार्य को शेड्यूल करने के लिए किया जा सकता है।

हॉफ़स्टैटर का नियम: कोई भी व्यवसाय हमेशा अपेक्षा से अधिक समय तक रहता है, भले ही आप हॉफ़स्टैटर के कानून को ध्यान में रखते हों।
- डगलस हॉफस्टैटर, गोदेल, आशेर, बाख

गद्य और कोड लिखना बहुत आम है। लेकिन सबसे अधिक ध्यान देने योग्य समानता शायद यह है कि न तो लेखक और न ही प्रोग्रामर समय पर अपना काम पूरा कर सकते हैं। लेखक समय सीमा तोड़ने के लिए कुख्यात हैं। प्रोग्रामर ने उन लोगों की प्रतिष्ठा अर्जित की है जिनके परिणाम हमेशा प्रारंभिक गणना से गंभीर रूप से भिन्न होते हैं। सवाल उठता है: क्यों?

आज मेरे पास एक विचार था कि इसका उत्तर कैसे दूं। और मेरे निष्कर्षों ने मुझे चकित कर दिया।

मेरी पुस्तकों का अध्ययन

मेरी दोनों किताबें, हैलो, स्टार्टअप और टेराफॉर्म: हम लॉन्च और काम करते हैं , मैंने एटलस बुक क्रिएशन पर्यावरण में लिखा है, जो गिट का उपयोग करके सभी सामग्री के प्रबंधन के लिए प्रदान करता है। इसका अर्थ है कि पाठ की प्रत्येक पंक्ति, प्रत्येक संपादन और प्रत्येक परिवर्तन Git प्रतिबद्ध लॉग के लिए प्रतिबद्ध है।

आइए देखें कि दो पुस्तकों को लिखने में कितना प्रयास किया गया।

हाय स्टार्टअप

चलो मेरी पहली पुस्तक के साथ शुरू करते हैं। हैलो स्टार्टअप । इसमें 602 पृष्ठ और लगभग 190 हजार शब्द हैं। मैंने हैलो में cloc चलाया , स्टार्टअप रिपॉजिटरी और निम्न परिणाम प्राप्त किए (सादगी के लिए, आंशिक भागों को छोड़ दिया जाता है):



602 पृष्ठों में पाठ की 26,571 पंक्तियाँ हैं। शेर का हिस्सा मार्कडाउन के समान एससीडॉक में लिखा गया है। इसका उपयोग एटलस द्वारा लगभग किसी भी सामग्री को लिखने के लिए किया जाता है। HTML और CSS का उपयोग करके, एटलस किसी पुस्तक के लेआउट और संरचना को परिभाषित करता है। उनके अलावा, अन्य प्रोग्रामिंग भाषाएं (जावा, रूबी, पायथन और न केवल) हैं, जिसमें पुस्तक में चर्चा किए गए विषयों के लिए विभिन्न उदाहरण लिखे गए हैं।

लेकिन 602 पृष्ठ और 26,571 लाइनें अंतिम परिणाम हैं। वे 10 महीनों के लेखन, परिवर्तन, संपादन, प्रूफरीडिंग, शैलीगत समायोजन, अनुसंधान, नोट्स और अन्य कार्यों को प्रतिबिंबित नहीं करते हैं जो पुस्तक के प्रकाशन में योगदान करते हैं। इसलिए, अधिक उपयोगी विचारों को प्राप्त करने के लिए, मैंने पूरी पुस्तक कमिट लॉग का विश्लेषण करने के लिए git-quick-stats उपयोग किया।



इसलिए, मैंने 163,756 लाइनें जोड़ीं और 131,425 को हटा दिया, जो कुल मिलाकर संसाधित सामग्री की 295,181 लाइनें देता है। यही है, यह पता चला है कि मैंने कुल 295 181 लाइनें लिखीं या हटा दीं, जिनमें से 26 571 लाइनें एक परिणाम के रूप में रहीं। यह अनुपात 10: 1 से थोड़ा अधिक है। प्रत्येक प्रकाशित पंक्ति प्राप्त करने के लिए, मुझे पहले 10 अन्य लिखना था!

मैं मानता हूं कि Git से जोड़ी गई और हटाई गई लाइनों की संख्या को गिनना संपादन प्रक्रिया के लिए एक आदर्श मीट्रिक नहीं माना जा सकता है। लेकिन, कम से कम, यह हमें यह समझने की अनुमति देता है कि किए गए कार्यों का मूल्यांकन करने के लिए एक सरल गणना पर्याप्त नहीं है। प्रक्रिया का एक बड़ा हिस्सा Git कमिट लॉग में बिल्कुल भी प्रतिबिंबित नहीं हुआ था। उदाहरण के लिए, पहले कुछ अध्याय Google डॉक्स में एटलस में स्थानांतरित होने से पहले लिखे गए थे, और मेरे कंप्यूटर पर कई एडिट बिना कमिट के किए गए थे।

इस तथ्य के बावजूद कि ये डेटा आदर्श से बहुत दूर हैं, मेरा मानना ​​है कि प्रकाशित करने के लिए "मूल पाठ सामग्री" का समग्र अनुपात 10: 1 है।

टेराफॉर्म: हम शुरू करते हैं और काम करते हैं

आइए देखें कि क्या यह अनुपात मेरी दूसरी पुस्तक टेराफॉर्म पर लागू होता है : हम लॉन्च करते हैं और काम करते हैं , जिसमें 206 पृष्ठ और लगभग 52 हजार शब्द हैं।

cloc का सरलीकृत उत्पादन:



206 पृष्ठों में पाठ की 8410 लाइनें हैं। फिर से, अधिकांश पाठ AsciiDoc में लिखे गए हैं, हालांकि इस पुस्तक में एचसीएल में मुख्य रूप से लिखे गए अधिक कोड उदाहरण हैं, जो टेराफॉर्म की मुख्य भाषा है। उनके अलावा, कई मार्कडाउन हैं जो मैंने एचसीएल के उदाहरणों का दस्तावेजीकरण किया था।

हम इस पुस्तक के संशोधन इतिहास को जांचने के लिए git-quick-stats का उपयोग करेंगे:



लगभग पाँच महीनों के लिए, मैंने 32,209 जोड़े और 22,402 पंक्तियों को हटा दिया, कुल 54,611 पुनर्नवीनीकरण पंक्तियाँ। इस पुस्तक के संपादन की प्रक्रिया का मूल्यांकन करने की सटीकता और भी अधिक है, क्योंकि यह काम एटलस और गिट में स्थानांतरित होने से पहले एक ठोस संशोधन के माध्यम से जाने वाले ब्लॉग पोस्टों की एक श्रृंखला के रूप में शुरू हुआ। इन ब्लॉग पोस्टों की मात्रा पुस्तक के कम से कम आधे हिस्से में होती है, इसलिए संसाधित टेक्स्ट की अंतिम दर को 50% तक बढ़ाना तर्कसंगत होगा। यही है, यह संपादन योग्य पाठ के 54611 * 1.5 = 81 916 लाइनों को चालू करेगा, जिसके परिणामस्वरूप कुल 8410 लाइनें होंगी।

और फिर, लगभग 10: 1 का अनुपात!

यह आश्चर्य की बात नहीं है कि लेखक समय सीमा को पूरा नहीं करते हैं। यदि अनुसूची को 250 पृष्ठों की पुस्तक सौंपना है, तो व्यवहार में यह पता चलता है कि इस प्रक्रिया में हम 2500 पृष्ठ लिखेंगे।

प्रोग्रामिंग के बारे में क्या?

कैसा चल रहा है विकास? मैंने विभिन्न परिपक्वता स्तरों के कई ओपन सोर्स गिट रिपॉजिटरी की जांच करने का फैसला किया: कुछ महीनों से 23 साल तक।

टेराफॉर्म-अव्स-काउचबेस (2018)

terraform-aws-couchbase AWS पर काउचबेस को तैनात करने और प्रबंधित करने के लिए मॉड्यूल का एक सेट है, जिसका स्रोत कोड 2018 में खोला गया था।

cloc का सरलीकृत उत्पादन:



और यहाँ git-quick-stats जाँचने का परिणाम है:



हमें वर्किंग कोड की 37 693 लाइनें मिलती हैं, जिसके परिणामस्वरूप 5: 1 अनुपात में अंतिम कोड की 7481 लाइनें हैं। यहां तक ​​कि 5 महीने से कम उम्र के भंडार में, मुझे प्रत्येक पंक्ति को पांच बार फिर से लिखना पड़ा! यह आश्चर्य की बात नहीं है कि सॉफ्टवेयर विकास का मूल्यांकन करना जटिल है: हम यह कल्पना भी नहीं करते हैं कि अंतिम कोड की 7.5 हजार लाइनें प्राप्त करने के लिए, हमें वास्तव में 35 हजार लिखना होगा

आइए देखें कि पुराने उत्पादों के साथ चीजें कैसी हैं।

टेरेटेस्ट (2016)

टेरेटेस्ट एक ओपनसोर्स लाइब्रेरी है जिसे 2016 में इन्फ्रास्ट्रक्चर कोड का परीक्षण करने के लिए बनाया गया था।

cloc का सरलीकृत उत्पादन:



git-quick-stats परिणाम:



ये कोड की 49 126 कामकाजी लाइनें हैं, जो अंतिम पाठ की 6140 लाइनों में बदल गईं। दो साल के भंडार के लिए, अनुपात 8: 1 था। लेकिन टेरेटेस्ट अभी भी काफी युवा है, तो चलो पुराने रिपॉजिटरी को देखें।

टेराफॉर्म (2014)

टेराफॉर्म एक खुला स्रोत पुस्तकालय है जो 2014 में प्रोग्रामिंग विधियों का उपयोग करके बुनियादी ढांचे के प्रबंधन के लिए बनाया गया था।

cloc का सरलीकृत उत्पादन:



git-quick-stats परिणाम:



हमें कोड की 12,945,966 कामकाजी लाइनें मिलती हैं, जिसके परिणामस्वरूप अंतिम परिणाम 1,371,718 लाइनों में मिलता है। 9: 1 अनुपात। टेराफॉर्म लगभग 4 वर्षों के लिए अस्तित्व में है, लेकिन पुस्तकालय अभी तक जारी नहीं किया गया है, इसलिए इस अनुपात के साथ भी, इसके कोड आधार को अभी तक परिपक्व नहीं कहा जा सकता है। चलो अतीत में और भी देखें।

एक्सप्रेस.जेएस (2010)

एक्सप्रेस 2010 में वेब विकास के लिए जारी एक लोकप्रिय खुला स्रोत जावास्क्रिप्ट ढांचा है।

cloc का सरलीकृत उत्पादन:



git-quick-stats परिणाम:



हमें कोड की 224 211 वर्किंग लाइन्स मिलती हैं, जो घटकर 15 325 फाइनल हो जाती हैं। परिणाम 14: 1। एक्सप्रेस लगभग 8 साल पुराना है, इसके नवीनतम संस्करण 4.x हैं। यह Node.js. के लिए सबसे लोकप्रिय और युद्ध-परीक्षणित वेब फ्रेमवर्क माना जाता है

ऐसा लगता है कि जैसे ही अनुपात 10: 1 के स्तर तक पहुंचता है, हम आत्मविश्वास से कह सकते हैं कि कोड आधार पहले से ही "परिपक्व" है। आइए देखें कि क्या होता है यदि आप अतीत में और भी गहरे जाते हैं।

jQuery (2006)

jQuery 2006 में जारी एक लोकप्रिय ओपन सोर्स जावास्क्रिप्ट लाइब्रेरी है।

cloc का सरलीकृत उत्पादन:



git-quick-stats परिणाम:



कोड की कुल 730,146 कामकाजी लाइनें, जिसके परिणामस्वरूप 47,559 अंतिम परिणाम मिले। 15: लगभग बारह वर्ष पुराने भंडार के लिए 1 अनुपात।

दस साल पहले एक और चलते हैं।

MySQL (1995)

MySQL 1995 में बनाया गया एक लोकप्रिय ओपन सोर्स रिलेशनल डेटाबेस है।

cloc का सरलीकृत उत्पादन:



git-quick-stats परिणाम:



हमें 58 562 999 वर्किंग लाइन्स, अंतिम कोड की 3 662 869 लाइन्स और लगभग तेईस साल पुरानी रिपॉजिटरी के लिए 16: 1 का अनुपात मिलता है। वाह! MySQL कोड की प्रत्येक पंक्ति को 16 बार फिर से लिखा गया है।

निष्कर्ष

मेरी पुस्तकों के लिए सामान्यीकृत परिणाम निम्नानुसार हैं:

नाम	काम की लाइनें	सारांश रेखाएँ	अनुपात
हाय स्टार्टअप	295 181	26571	11: 1
टेराफॉर्म: हम शुरू करते हैं और काम करते हैं	81 916 है	8410	10: 1

और यहाँ विभिन्न प्रोग्रामिंग परियोजनाओं के लिए एक सारांश तालिका है:

नाम	निर्माण का वर्ष	काम की लाइनें	सारांश रेखाएँ	अनुपात
terraform-एडब्ल्यूएस-Couchbase	2018	37,693	7481	5: 1
Terratest	2016	४ ९ १२६	6140	8: 1
terraform	2014	12 945 966	१ ३ 1१ 37१18	9: 1
एक्सप्रेस	2010	224 211	15 325	14: 1
jQuery	2006	730,146	४। ५५ ९	15: 1
MySQL	1995	५। ५६२ ९९९	3 662 869	16: 1

इन सभी नंबरों का क्या मतलब है?

नियम 10: 1 गद्य और प्रोग्रामिंग में

यह देखते हुए कि मेरा डेटा सेट सीमित है, मैं केवल कुछ प्रारंभिक निष्कर्ष निकाल सकता हूं:

1. पुस्तक के लिए "फीडस्टॉक" से "अंतिम उत्पाद" का अनुपात लगभग 10: 1 है। जब आप सामग्री जमा करने के लिए संपादक के साथ चर्चा करते हैं तो इस आंकड़े को ध्यान में रखें। यदि आपको 300 पृष्ठों की पुस्तक लिखने की आवश्यकता है, तो वास्तव में आपको लगभग 3 हजार पृष्ठों की रचना करनी होगी।
   
2. एक समान नियम को परिपक्व और गैर-तुच्छ सॉफ़्टवेयर के लिए घटाया जा सकता है: संसाधित कोड की मात्रा का कुल अनुपात कम से कम 10: 1 है। इसे ध्यान में रखें जब एक प्रबंधक या ग्राहक आपको समय की लागत का अनुमान लगाने के लिए कहता है। 10 हजार लाइनों के आवेदन के लिए आपको लगभग 100 हजार लाइनें लिखने की आवश्यकता होगी।
   

लेखन और प्रोग्रामिंग के लिए इन निष्कर्षों को 10: 1 नियम के रूप में संक्षेपित किया जा सकता है:

अच्छा सॉफ्टवेयर या टेक्स्ट लिखने के लिए आवश्यक है कि प्रत्येक पंक्ति को औसतन 10 बार फिर से लिखा जाए।

अगले चरण

बेशक, कोड की पंक्तियों और पाठ की पंक्तियों को एक आदर्श उपाय नहीं माना जा सकता है। लेकिन, मेरा मानना ​​है कि यदि आप पर्याप्त मात्रा में डेटा एकत्र करते हैं, तो आप यह निर्धारित कर सकते हैं कि क्या एक परियोजना को पूरा करने की समय सीमा निर्धारित करने के लिए 10: 1 नियम सार्वभौमिक और उपयोगी है।

कुछ प्रश्न जिनका मैं उत्तर प्राप्त करना चाहूंगा:

• क्या किसी विशेष सॉफ्टवेयर की परिपक्वता का मूल्यांकन करने के लिए एक त्वरित मीट्रिक के रूप में कोड की संसाधित लाइनों के अनुपात को अंतिम लाइनों के रूप में उपयोग करना संभव है? उदाहरण के लिए, क्या हम डेटाबेस, प्रोग्रामिंग भाषाओं, या ऑपरेटिंग सिस्टम के लिए महत्वपूर्ण बुनियादी ढांचे की समस्याओं के समाधान पर भरोसा कर सकते हैं यदि उनके लिए यह अनुपात कम से कम 10: 1 तक पहुंच गया है?
  
• क्या काम करने वाले टेक्स्ट का वॉल्यूम सॉफ्टवेयर के प्रकार पर निर्भर करता है? उदाहरण के लिए, बिल स्कॉट ने पाया कि नेटफ्लिक्स में केवल 10% उपयोगकर्ता इंटरफ़ेस कोड एक वर्ष तक रहता है , और इस समय तक शेष 90% पूरी तरह से फिर से लिखे जाते हैं। बैकएंड, डेटाबेस, कमांड लाइन उपयोगिताओं और अन्य प्रकार के कार्यक्रमों के लिए कोड प्रतिस्थापन की गति क्या है?
  
• प्रारंभिक रिलीज़ के बाद कोड का कितना प्रतिशत संसाधित होता है? यही है, काम का कितना प्रतिशत "सॉफ्टवेयर समर्थन" माना जा सकता है?
  

यदि आप पुस्तकों के लेखक हैं और एक समान विश्लेषण कर सकते हैं, तो मुझे आपके परिणामों के बारे में जानकर खुशी होगी। और अगर किसी के पास इस तरह के विश्लेषण को स्वचालित करने का समय है, तो विभिन्न खुले स्रोत परियोजनाओं में पाए जाने वाले संबंधों के बारे में सीखना बहुत अच्छा होगा।

13 अगस्त का अपडेट

हैकर न्यूज़ और रेडिट के r / प्रोग्रामिंग पर एक पोस्ट की चर्चा से दो अन्य दिलचस्प बातें सामने आईं :

1. जाहिर है, एक समान 10: 1 नियम फिल्मों , पत्रकारिता, संगीत और फोटोग्राफी पर लागू होता है! किसने सोचा होगा?
2. पाठकों ने बहुत सारी टिप्पणियां छोड़ दीं कि एक भी वर्ण परिवर्तन को एक लाइन के सम्मिलन या विलोपन के रूप में गिना जा सकता है, इसलिए 100 हजार परिवर्तित लाइनों के एक आंकड़े का मतलब यह नहीं है कि प्रत्येक पंक्ति में प्रसंस्करण हुआ है।

अंतिम टिप्पणी सही है, लेकिन, जैसा कि मैंने ऊपर लिखा था, मेरा डेटा अन्य प्रकार के परिवर्तनों को ध्यान में नहीं रखता है:

1. मैं प्रत्येक अलग लाइन के लिए कमिट नहीं करता। मैं इसे दस बार बदल सकता हूं, लेकिन केवल एक ही प्रतिबद्ध कर सकता हूं।
   
2. पिछले पैराग्राफ में वर्णित स्थिति प्रोग्रामिंग के लिए और भी अधिक प्रासंगिक है। कोड परीक्षण के दौरान, मैं केवल एक प्रतिबद्ध करते हुए, एक पंक्ति को 50 बार बदल सकता हूं।
   
3. कई संपादन और लेखन चक्र Git के बाहर किए गए थे (कुछ अध्याय Google डॉक्स या माध्यम में लिखे गए थे, और शैलीगत संपादन पीडीएफ में किए गए थे)।
   

मुझे लगता है कि ये सभी कारक गिट में लाइनों को डालने या हटाने के लिए लेखांकन की ख़ासियत की भरपाई करते हैं। बेशक, मेरे अनुमान गलत हो सकते हैं, और वास्तविक अनुपात 8: 1 या 12: 1 होगा। लेकिन सामान्य तौर पर, अंतर बहुत अच्छा नहीं है, और 10: 1 को याद रखना आसान है।

14 अगस्त का अपडेट

Github Decagon ने एक bash स्क्रिप्ट के साथ hofs-churn नामक एक रिपॉजिटरी बनाई, जिससे आसानी से गणना की जा सके कि आपकी रिपॉजिटरी में कितना कोड काम किया गया है। उन्होंने इसका उपयोग कई रिपॉजिटरी का विश्लेषण करने के लिए भी किया, जैसे रिएक्ट.जेएस, व्यू, एंगुलर, आरएक्सजाव और कई अन्य, और परिणाम काफी दिलचस्प थे।