कैसे एक बड़े कोडबेस को समझने में आसान बनाया जाए

Question

मान लीजिए कि मैं एक अपेक्षाकृत बड़ी परियोजना विकसित कर रहा हूं। मैंने पहले से ही अपने सभी वर्गों और कार्यों को डॉक्सीजेन के साथ दस्तावेजित किया है, हालांकि, मुझे प्रत्येक स्रोत कोड फ़ाइल पर "प्रोग्रामर के नोट्स" डालने का विचार था।

इसके पीछे विचार यह है कि आम आदमी की शर्तों में यह समझाया जाए कि एक विशिष्ट वर्ग कैसे काम करता है (और न केवल इसलिए कि अधिकांश टिप्पणियां क्या करती हैं)। दूसरे शब्दों में, साथी प्रोग्रामरों को एक अन्य दृष्टिकोण देने के लिए कि एक वर्ग कैसे काम करता है।

उदाहरण के लिए:

/*
 * PROGRAMMER'S NOTES:
 *
 * As stated in the documentation, the GamepadManager class 
 * reads joystick joystick input using SDL and 'parses' SDL events to
 * Qt signals.
 *
 * Most of the code here is about goofing around the joystick mappings.
 * We want to avoid having different joystick behaviours between
 * operating systems to have a more integrated user experience, since
 * we don't want team members to have a bad surprise while
 * driving their robots with different laptops.
 *
 * Unfortunately, we cannot use SDL's GamepadAPI because the robots
 * are interested in getting the button/axes numbers, not the "A" or
 * "X" button.
 *
 * To get around this issue, we created a INI file for the most common 
 * controllers that maps each joystick button/axis to the "standard" 
 * buttons and axes used by most teams. 
 *
 * We choose to use INI files because we can safely use QSettings
 * to read its values and we don't have to worry about having to use
 * third-party tools to read other formats.
 */

क्या यह नए प्रोग्रामर्स / योगदानकर्ताओं के लिए एक बड़ी परियोजना को आसान बनाने का एक अच्छा तरीका होगा यह समझने के लिए कि यह कैसे काम करता है? एक सुसंगत कोडिंग शैली और 'मानक' निर्देशिका संगठन को बनाए रखने के अलावा, क्या इन मामलों के लिए कोई 'मानक' या सिफारिशें हैं?

Comments

बिलकुल नहीं। यदि आपका कोड अपठनीय है, तो दस्तावेज़ीकरण मदद नहीं करेगा।

— तेलस्टिन

@ जेजो - समस्या यह है कि ऐसा करने के लिए समय लेने से एक बार हो सकता है। कोड पठनीय रखने का समय समय के साथ होता है। मैं इस तरह के प्रलेखन के साथ स्थानों पर रहा हूँ, जब परियोजना युवा थी, या जब जो पूर्णतावादी अभी भी टीम में था, किया गया। इसके बाद इसे छोड़ दिया गया और इस पर टिप्पणी की गई, अब सटीक नहीं है।

— तेलस्टिन

कम से कम एक उच्च स्तर पर, एक परियोजना क्या करती है, यह कैसे काम करती है, और आउट-कोड कोड का एक आउट-ऑफ-कोड गवाह वर्णन करता है कि वास्तुकला में क्या बनाया गया है, यह अमूल्य है। इस तरह का एक दस्तावेज एक नवागंतुक के लिए एक कोड-टूर लेने से पहले अवश्य पढ़ा जाना चाहिए । वहाँ है की एक बहुत कुछ मेरी-पद्धति है के लिए भी कट्टरपंथी के लिए डॉक्स-दोस्त शुद्ध आसपास बकवास, और जब तक यह है सच है कि एक प्रारंभिक चाप डॉक और एक उभरता मेहराब डॉक जैसी नहीं होगी, एक गद्य वर्णन आवश्यक है किसी के लिए जल्दी से एक बड़े, गैर-तुच्छ कोडबेस को समझ लेना। यहाँ (खराब) उदाहरण है: zxq9.com/erlmud/html/001-002_altecture.html

— zxq9

@ टेलस्टाइन: इसका कोई मतलब नहीं है कि कोड पठनीय है या नहीं (और मुझे आशा है कि यह है)। दस्तावेज़ीकरण डिजाइन औचित्य बिल्कुल महत्वपूर्ण है।

— ऑर्बिट

@Telastyn: हाँ, हो सकता है। व्यक्तिगत रूप से मैं इसे एक स्टैंडअलोन डॉक्टर में लिखूंगा। लेकिन स्रोत फ़ाइलों के शीर्ष पर टिप्पणी ब्लॉक इतना बुरा नहीं है।

— ऑर्बिट

Answer 1

यह कमाल का है। मैं चाहता हूं कि अधिक सॉफ्टवेयर डेवलपर्स ने ऐसा करने के लिए समय और प्रयास किया। यह:

• सादे अंग्रेजी में राज्य क्या करता है (यानी यह जिम्मेदारी है),
• कोड को दोहराए बिना, कोड के बारे में उपयोगी पूरक जानकारी प्रदान करता है जो पहले से ही कहता है,
• डिजाइन के कुछ फैसलों की रूपरेखा और वे क्यों बनाए गए, और
• कुछ ऐसे गोचरों पर प्रकाश डाला गया, जो आपके कोड को पढ़ने वाले अगले व्यक्ति को हो सकता है।

काश, कई प्रोग्रामर "यदि कोड ठीक से लिखा गया है," के शिविर में आते हैं, तो इसे प्रलेखित नहीं किया जाना चाहिए। सच नहीं। कोड कक्षाओं, विधियों, मॉड्यूल और अन्य कलाकृतियों के बीच कई निहित संबंध हैं जो केवल कोड को पढ़ने से ही स्पष्ट नहीं हैं।

एक अनुभवी कोडर ध्यान से आसानी से समझ में आने वाली वास्तुकला को डिजाइन कर सकता है, जो कि प्रलेखन के बिना स्पष्ट है। लेकिन इस तरह के कितने कार्यक्रम आपने वास्तव में देखे हैं?

Comments

और "माइथिकल मैन मंथ" क्यों एक स्व-पूर्ति भविष्यवाणी बन जाता है, किसी ने भी नए देव के लिए यह सब लिखने का समय नहीं लिया जब यह उनके दिमाग में ताजा था और परियोजना पीछे नहीं हुई थी।

— जेफ़ो

मैं यहाँ आपके द्वारा की गई हर बात से सहमत हूँ। मुझे उनके पद में प्रयुक्त ओपी शब्द पसंद नहीं है how a class works। यह समय और रखरखाव के साथ बदलता है। हालांकि मेरी टीम उपरोक्त स्रोत में नहीं डालती है। हम निर्णयों के साथ एक विकी को बनाए रखते हैं और दस्तावेज़ में डिज़ाइन किए गए निर्णयों के बारे में सुस्त चैनल चर्चा को कॉपी करते हैं (हम निर्णय सारांश और कच्चे नोटों को निष्कर्ष से एक लिंक प्रदान करते हैं ताकि हमें पुराने निर्णयों को फिर से न करना पड़े)। सभी को गितुब में बड़े करीने से किया जाता है (इसलिए यह सब एक ही स्थान पर है)।

— मार्टिन यॉर्क

मेरा एकमात्र मुद्दा इसे विश्व स्तर पर लागू कर रहा है। यह वर्ग पर्याप्त जटिल है, कुछ उपलब्ध गोचरों के साथ, स्पष्ट रूप से यह वास्तव में उपयोगी है (हालांकि आप अभी भी टिप्पणी रोट के साथ काम करते हैं)। जब कोई कक्षा अधिक स्पष्ट होती है, तो टिप्पणी थोड़ी सी सतही हो सकती है।

— डेवॉर्डे

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

— डेवॉर्डे

मैं इस उत्तर से पूरी तरह सहमत हूं, और अगर मुझे कोड में ओपी के उदाहरण जैसा कुछ मिला तो मैं बहुत खुश होऊंगा। बस एक एकल जोड़: अपनी टिप्पणी में एक तारीख जोड़ने पर विचार करें, बस वर्णन की ताजगी के रूप में अंतिम रूप से पाठकों को एक संकेत देने के लिए, और हर बार जब आप पाठ को अपडेट करते हैं तो इसे अपडेट करें।

— स्वावलोरन

Answer 2

एक बड़े कोडबेस के साथ काम करने की कुंजी एक बदलाव करने के लिए पूरे कोडबेस को पढ़ने के लिए नहीं है। एक प्रोग्रामर को सक्षम करने के लिए जिस कोड को वह ढूंढ रहा है उसे जल्दी से ढूंढने के लिए, कोड को व्यवस्थित किया जाना चाहिए, और संगठन को स्पष्ट करना चाहिए। अर्थात्, कोड में प्रत्येक तार्किक इकाई, निष्पादन योग्य से, अलग-अलग वर्ग के लिए लाइब्रेरी, नेमस्पेस, स्पष्ट रूप से स्पष्ट जिम्मेदारी होनी चाहिए। इसलिए मैं न केवल स्रोत फ़ाइलों को दस्तावेज़ित करूंगा, बल्कि उन निर्देशिकाओं को भी जो वे रहते हैं।

आपके प्रोग्रामर के नोट्स भी डिजाइन निर्णयों पर पृष्ठभूमि देते हैं। हालांकि यह मूल्यवान जानकारी हो सकती है, मैं इसे जिम्मेदारी के बयान से अलग करूंगा (पाठक को यह चुनने में सक्षम करने के लिए कि वह कक्षा की जिम्मेदारी या इसके डिजाइन तर्क के बारे में पढ़ना चाहता है), और इसे उस स्रोत के करीब ले जाएं जो इसका वर्णन करता है संभव के रूप में, कोड को अपडेट करने के अवसर को अधिकतम करने के लिए जब कोड होता है (प्रलेखन केवल उपयोगी होता है अगर हम इसकी सटीकता पर भरोसा कर सकते हैं - पुराना प्रलेखन किसी से भी बदतर हो सकता है!)।

उस ने कहा, दस्तावेज़ीकरण DRY ही रहना चाहिए, अर्थात ऐसी दोहराई जाने वाली जानकारी जो कोड में व्यक्त नहीं की जा सकती थी या पहले ही कहीं और वर्णित की गई थी (वाक्यांश "जैसे प्रलेखन राज्यों" एक चेतावनी संकेत हैं)। विशेष रूप से, भविष्य के अनुचर केवल परियोजना की प्रोग्रामिंग भाषा में कुशल होंगे, क्योंकि वे अंग्रेजी में हैं; टिप्पणियों में क्रियान्वयन को परिभाषित करना (जो कि मैं पूरी तरह से बहुत बार देखता हूं जब लोग अपने दस्तावेज पर गर्व करते हैं) का कोई लाभ नहीं होता है, और कार्यान्वयन से विचलित होने की संभावना होती है, विशेष रूप से अगर प्रलेखन उस कोड के पास नहीं है जो इसका वर्णन करता है।

अंत में, दस्तावेज़ की संरचना को पूरे प्रोजेक्ट में मानकीकृत किया जाना चाहिए ताकि हर कोई इसे पा सके (यह बग ट्रैकर में पीटर दस्तावेजों का एक शाही गड़बड़ है, विकी में मुकदमा, रीडमे में एलन और स्रोत कोड में जॉन ...) ।

Comments

आपका पहला वाक्य ठीक यही है कि मैं इसे कैसे देखता हूं। बड़े कोडबेस को कई छोटे घटकों के रूप में तैयार किया जाना चाहिए, जहां एक नया प्रोग्रामर किसी अन्य को खतरे में डाले बिना एक को मज़बूती से बदल सकता है।

— जॉन चेस्टरफील्ड

इसे उस स्रोत के करीब ले जाएं जहां यह संभव हो सके, कोड होने पर दस्तावेज़ को अपडेट किए जाने की संभावना को अधिकतम करने के लिए । यह बहुमूल्य अनुभव है।

— laike9m

प्रलेखन के लिए एक दिशानिर्देश के रूप में DRY एक बहुत अच्छी बात है! यह स्वचालित रूप से फोकस को सही सेट करता है और प्रसिद्ध अप्रिय "// वेतन वृद्धि x 1" टिप्पणियों से मना करता है।

— हंस-पीटर स्टॉर्र

Answer 3

मैं इस बात से सहमत नहीं हूँ कि यह एक बहुत अच्छा दृष्टिकोण है, जिसका मुख्य कारण है

1. जब आप अपने प्रोजेक्ट को रिफलेक्टर करते हैं, तो तरीकों को इधर-उधर करें, डॉक्यूमेंटेशन टूट जाता है।

2. यदि दस्तावेज़ीकरण ठीक से अपडेट नहीं किया गया है, तो कोड को समझने में मदद करने की तुलना में अधिक भ्रम का परिणाम होगा।

यदि आपके पास प्रत्येक मॉड्यूल के लिए प्रत्येक विधि / एकीकरण परीक्षणों के लिए यूनिट परीक्षण हैं, तो यह कोड टिप्पणियों की तुलना में एक आत्म प्रलेखन अधिक रखरखाव योग्य और समझने में आसान होगा।

हां, एक उचित निर्देशिका संरचना होने से निश्चित रूप से मदद मिलेगी।

Comments

टेस्ट के लिए +1 एक आधार को समझने का सबसे अच्छा तरीका है। यूनिट परीक्षण, एकीकरण परीक्षण, स्वीकृति परीक्षण सभी कहानी के बारे में बताते हैं कि आवेदन कैसे काम करना चाहिए, और इसका उपयोग कैसे किया जाना चाहिए।

— 17

Answer 4

मैं व्यक्तिगत रूप से एक उच्च-स्तरीय डिज़ाइन दस्तावेज़ का प्रशंसक हूं - अधिमानतः किसी भी कोड को लिखा गया है - जो डिज़ाइन और कक्षाओं और संसाधनों की एक सूची का अवलोकन देता है। एक टॉप-डाउन डिज़ाइन चीजों को बहुत सरल करता है - आपका "गेम इंजन -> हार्डवेयर -> कंट्रोलर -> जॉयस्टिक" हो सकता है; इस प्रकार, एक नए प्रोग्रामर ने "xyz कंट्रोलर" पर 'ए' बटन को ठीक करने के लिए कहा था।

बहुत सी आधुनिक भाषाएं सैकड़ों छोटी फाइलों में कोड को तोड़ देती हैं, इसलिए सही फाइल को ढूंढना एक मामूली परियोजना पर भी चुनौती हो सकती है।

Comments

20 साल पहले मेरा सारा कोड एक बड़ी फाइल में था। अब यह हजारों छोटी फाइलों और परीक्षण फाइलों में है। इसके लिए एक अच्छा कारण है और यह 20 साल के सॉफ्टवेयर विकास (सामान्य पारिस्थितिकी तंत्र, मेरा ज्ञान नहीं) को दर्शाता है। हालांकि एक टिप्पणी के लिए वाया बहुत लंबा है।

— माइकल डुरंट

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

— jwenting

@ जेंटिंग: आपको इसे दूर तक ले जाने की जरूरत नहीं है। लेकिन यह अभी भी अच्छा है कि कुछ विचार है कि आप क्या बना रहे हैं।

— रॉबर्ट हार्वे

निश्चित रूप से बिना इस बात के कि इस नियम को कैसे तोड़ा जाए और नियमों को कैसे तोड़ा जाए, आप बहुत जल्दी एक ऐसा दस्तावेज बनाने जा रहे हैं, जो या तो पुराना हो या चक्की का पत्थर हो। "मुझे एक नया वर्ग जोड़ने की ज़रूरत है; डोकुमंतो, बीहेमथ जो समय खाता है!"

— डेवॉर्ड

@deworde: मैंने पढ़ा है कि "प्रलेखन बनाए रखने के लिए बहुत आलसी।"

— रॉबर्ट हार्वे

Answer 5

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

डिज़ाइन दस्तावेज़ में शामिल करने के लिए चीजें हैं;

• अनुप्रयोग वास्तुकला
• तार्किक कोड संरचना
• डेटा प्रवाह
• मुख्य पैटर्न का उपयोग किया और उनके उपयोग के पीछे प्रेरणा
• कोड स्रोत संरचना
• इसे कैसे बनाया जाए (यह अंतर्निहित निर्भरता और भौतिक कोड स्रोत संरचना में अंतर्दृष्टि प्रदान करता है)

इस पर से, कक्षाओं के लिए प्रलेखन, और कार्यों / विधियों को उचित रूप में पूरा किया जाना चाहिए । विशेष रूप से सार्वजनिक एपीआई; यह स्पष्ट होना चाहिए कि प्रत्येक मामले में निम्नलिखित सभी क्या हैं;

• पूर्व शर्त
• प्रभाव
• अपरिवर्तनशीलताओं
• अपवाद स्थितियों (फेंकता)

Comments

+1 प्रत्येक वर्ग का वर्णन करने से बेहतर है, क्योंकि यह समग्र डिजाइन की तुलना में अधिक पुराना हो जाएगा।

— लोड

Answer 6

नए डेवलपर्स के लिए कोडबेस को समझना आसान बनाने के लिए मैंने जो सबसे महत्वपूर्ण नियम पाया है, वह है सही समझौता महंगा।

यदि नए डेवलपर्स को पूरी तरह से उस सिस्टम को समझना चाहिए, जिस पर वे काम कर रहे हैं, तो यह नौकरी सीखने के सभी अवसरों को रोकता है। मुझे लगता है कि प्रोग्रामर के नोट्स एक शानदार शुरुआत हैं, लेकिन मैं और आगे जाऊंगा। कोड लिखने की कोशिश करें, अगर नए सिरे से संपर्क किया जाता है, तो एक डेवलपर को यह पता लगाने की अनुमति देगा कि वे मक्खी पर क्या कर रहे हैं, बजाय इसके कि उन्हें सीखने से पहले सीखने की आवश्यकता हो। आपके द्वारा ज्ञात मामलों के लिए छोटी चीजें जैसे कि कभी नहीं हो सकती हैं, साथ ही टिप्पणी के साथ यह समझाते हुए कि क्यों मान्य है, एक लंबा रास्ता तय करें। यदि आप कुछ भी गलत करते हैं, तो कोड लिखना जो सुंदर तरीके से विफल होने के बजाय विफल हो जाता है।

Comments

मेरा नियम है कि टिप्पणियां WHY के बारे में होनी चाहिए , न कि HOW । कोड HOW का वर्णन करता है।

— user11393

Answer 7

मैंने बड़ी कक्षाओं को प्रलेखन के साथ देखा है, और प्रलेखन को पढ़ने के बाद मुझे कोई सुराग नहीं मिला है कि यह वर्ग किसके लिए अच्छा है और कोई भी इसका उपयोग क्यों करेगा! और एक ही समय में, मुझे कुछ कार्यक्षमता की आवश्यकता थी और मुझे पूरा यकीन था कि इसे संभालने के लिए एक वर्ग होना चाहिए, और इसे कहीं भी नहीं मिल सकता है - क्योंकि कोई भी दस्तावेज नहीं था जो मुझे उस वर्ग की ओर ले जाता था जिसकी मुझे आवश्यकता थी। इसे कर रहा हूँ।

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

Answer 8

@Meriton ने जो कहा, उसके समान कोड को अलग-अलग घटकों में विभाजित करें। इससे भी बेहतर, कोडबेस को अलग-अलग पैकेज (JAR, रत्न, अंडे, जो भी हो) में तोड़ें ताकि यह भी स्पष्ट हो सके कि घटकों को अलग कैसे किया जाता है। यदि कोई बग है, तो एक डेवलपर को केवल उस पैकेज को खोजने की आवश्यकता है जहां बग है, और (उम्मीद है) केवल इसे वहां ठीक करें। उल्लेख नहीं करने के लिए, यूनिट परीक्षण करना आसान है, और आप निर्भरता प्रबंधन का लाभ उठाते हैं।

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

Answer 9

जटिल प्रणालियों के लिए यह प्रत्येक फ़ाइल को न केवल दस्तावेज़ करने के लिए इसके लायक हो सकता है, लेकिन उनकी बातचीत और पदानुक्रम, और प्रोग्राम संरचनाएं और क्यों।

उदाहरण के लिए एक गेम इंजन आमतौर पर काफी जटिल होता है और यह तय करना मुश्किल होता है कि अमूर्त की सौ परतों के बाद क्या कॉल करता है। यह "आर्किटेक्चर.टेक्स्ट" जैसी फाइल बनाने के लायक हो सकता है कि यह समझाने के लिए कि इस तरह से कोड को कैसे और क्यों संरचित किया गया है, और क्यों उस व्यर्थ दिखने वाली अमूर्त परत है।

Answer 10

यह आंशिक रूप से हो सकता है क्योंकि एक एकल प्रोग्रामर के लिए इसे लिखना कठिन है, क्योंकि प्रत्येक व्यक्ति केवल परियोजना के अपने हिस्से को समझता है।

कभी-कभी आप इस जानकारी को प्रोजेक्ट मैनेजर के नोट्स से प्राप्त कर सकते हैं, लेकिन यह सब आपको मिलेगा, क्योंकि वे इस प्रारूप में शायद ही कभी अपने नोट्स को फिर से लिखेंगे।

Comments

यदि आप गिथब को देखते हैं, तो आपको बहुत सारी परियोजनाएँ मिलेंगी, जिनमें README.md फ़ाइल में इस तरह के नोट हैं। यह विशेष रूप से ज्यादातर लोगों के लिए सामान्य और जावास्क्रिप्ट परियोजनाओं में गिट की संस्कृति का एक हिस्सा बन गया है, ज्यादातर लोग एक पुस्तकालय का उपयोग नहीं करेंगे, जिसमें इस तरह के उच्च स्तर के दस्तावेज नहीं हैं। तो यह असत्य है कि "कोई प्रोग्रामर इसे नहीं लिखेगा" क्योंकि आपको केवल jQuery या socket.io जैसी किसी चीज़ को देखना होगा और ऐसे प्रोग्रामर्स को ढूंढना होगा जो इस तरह की चीजें लिखते हैं। यह एक संस्कृति भी बन गई है कि README फाइलें जो बग रिपोर्ट को सटीक रूप से उत्पन्न नहीं करती हैं।

— स्लीपबेटमैन

यह प्रश्न का उत्तर देने के लिए प्रतीत नहीं होता है, जो उन कारणों की तलाश कर रहा था कि क्यों प्रस्तावित प्रलेखन शैली काम करेगी या नहीं, और दस्तावेज़ मानकों के लिए भी।

— user52889

यदि आपके पास किसी उत्पाद पर काम करने वाले प्रोग्रामर की एक टीम है, और प्रत्येक प्रोग्रामर केवल उस विशिष्ट कोड को समझता है, जिस पर उन्होंने काम किया है, तो न केवल आपकी टीम एक बेतुका बस कारक के साथ अविश्वसनीय रूप से बेकार है, लेकिन एक कोड की गुणवत्ता पर सवाल उठाता है। एक ही सिस्टम में बाकी कोड को समझे बिना किसी उत्पाद में कोड को कैसे एकीकृत किया जाता है ??

— को ऑर्बिट