"स्वच्छ कोड" प्रथाओं से कोड रखने के दौरान विशाल खुले स्रोत पुस्तकालय कैसे बनाए रखते हैं?

Question

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

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

तो मेरा सवाल यह है कि क्या स्वच्छ संहिता के सिद्धांत भी प्रतिबंधित हैं, और हम इन जैसी कई पुस्तकालयों में उनके बिना कर सकते हैं? यदि नहीं, तो इनमें से कई सिद्धांतों पर विचार किए बिना विशाल पुस्तकालयों का रखरखाव कैसे किया जा रहा है?

मैं किसी भी संक्षिप्त स्पष्टीकरण की सराहना करूंगा। अगर नौसिखिया आदमी से सवाल मूर्खतापूर्ण लगता है तो मैं माफी मांगता हूं।

संपादित करें

बटरकाइफ़ लाइब्रेरी में इस उदाहरण की जाँच करें - एंड्रॉइड समुदाय में सबसे अच्छी तरह से ज्ञात पुस्तकालयों में से एक।

Comments

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

— जोर्ग डब्ल्यू मित्तग

क्या आपने लिनक्स स्रोतों की जाँच की है?

— मार्टिन श्रोडर

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

— whatsisname

कोई आपसे असहमत नहीं है। सवाल यह है कि वर्षों तक खराब कोड को कैसे बनाए रखा जाए? इसे विकसित करने के कई पुनरावृत्तियों पर सफाई क्यों नहीं की गई?

— इस्लाम सलाह

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

— ऑर्बिट

Answer 1

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

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

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

Comments

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— यानिस

Answer 2

"क्लीन कोड" में बताए गए सिद्धांत हमेशा से सहमत नहीं होते हैं। अधिकांश यह सामान्य ज्ञान है, लेकिन लेखक के कुछ मत विवादास्पद हैं और सभी द्वारा साझा नहीं किए गए हैं।

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

पुस्तक में सलाह भी है (सभी सलाह की तरह) एक विशेष प्रकार के सॉफ्टवेयर की ओर गियर: एंटरप्राइज़ अनुप्रयोग। अन्य प्रकार के सॉफ़्टवेयर जैसे गेम या ऑपरेटिंग सिस्टम में एंटरप्राइज़ सॉफ़्टवेयर की तुलना में विभिन्न बाधाएँ होती हैं, इसलिए विभिन्न पैटर्न और डिज़ाइन सिद्धांत खेलने में होते हैं।

भाषा भी एक कारक है: क्लीन कोड जावा या एक समान भाषा को मानता है - यदि आप सी या लिस्प का उपयोग करते हैं तो बहुत सारी सलाह लागू नहीं होती है।

संक्षेप में, पुस्तक सॉफ्टवेयर के एक विशेष वर्ग के बारे में एक ही व्यक्ति की राय है। यह हर जगह लागू नहीं होगा।

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

Comments

"एक विशेष प्रकार के सॉफ्टवेयर की ओर गियर" के लिए +1। यह इस और इसी तरह के विषयों पर अधिकांश पुस्तकों के लिए बढ़ाया जा सकता है। नमक के एक दाने के साथ आप जो कुछ भी पढ़ते हैं उसे ले लें, यह उस समय तक पक्षपाती हो सकता है जब तक यह लिखा जाए, लक्ष्य वातावरण, विकास पद्धति और अन्य सभी प्रकार के कारक।

— रेगिनाल्ड ब्लू

उस पुस्तक का सख्ती से पालन करने से कई कॉल "कचरा कोड" बनते हैं।

— फ्रैंक हिलमैन

@FrankHileman: उस पुस्तक की सिफारिशों में से कोई भी अधिक का पालन नहीं करता है।

— डॉक्टर ब्राउन

@ jpmc26 - आपका जुड़ा हुआ उत्तर एक क्षेत्र से संबंधित है जिसे मैं वैज्ञानिक प्रोग्रामिंग से परिचित हूं। मुझे हाल ही में एक इच्छा सूची आइटम प्रदान किया गया था, जो कि कई जॉनसन स्पेस सेंटर सिमुलेशन में इस्तेमाल किए गए गुरुत्वाकर्षण मॉडल को सापेक्षतावादी रूप से सही बनाने के लिए था। टिप्पणियों और रिक्त लाइनों की गणना करते हुए, मैंने जो कोड लिखा था, वह न्यूटोनियन गुरुत्वाकर्षण के सापेक्ष सापेक्षता की गणना करता है, जो कि 145 लाइनों की लंबी है, और यह सभी एक फ़ंक्शन में है। आम तौर पर मैं यह देखकर क्रोधित हो जाता हूं कि मैंने स्वयं एक समारोह लिखा है जो 45 पंक्तियों का लंबा है, अकेले को 145। लेकिन इस मामले में नहीं। ...

— डेविड हैम्मन

... प्रश्न में फ़ंक्शन एक एकल समीकरण, जर्नल पेपर वाई में समीकरण एक्स को लागू करता है, इसलिए यह निश्चित रूप से एकल उद्देश्य नियम का पालन करता है। (यह समीकरण किसी पृष्ठ के एक चौथाई हिस्से को विवरण में शामिल करता है।) इस फ़ंक्शन को भागों में विभाजित करने के लिए कोई सार्थक स्थान नहीं है, और ऐसा करने का कोई सार्थक कारण नहीं है। टिप्पणियाँ, जो चाचा बॉब तुच्छ? वे इस मामले में बिल्कुल आवश्यक हैं, और यह वैज्ञानिक प्रोग्रामिंग में विशिष्ट है। जबकि मॉडल के TeX दस्तावेज़ीकरण में प्रासंगिक जर्नल संदर्भों को देखना अच्छा है, उन्हें कार्यान्वयन में देखना भी अच्छा है।

— डेविड हैम्मन

Answer 3

सारांश

जैसा कि जैक्सबी लिखते हैं, हर कोई रॉबर्ट सी। मार्टिन के "क्लीन कोड" से सहमत नहीं है।

खुले स्रोत की परियोजनाएं जो आपको मिली "उन सिद्धांतों का उल्लंघन करती हैं" जिनसे आपको उम्मीद थी कि आपके पास बस अन्य सिद्धांत होने की संभावना है।

हमारे दृष्टिकोण

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

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

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

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

उदाहरण

"एक लंबी विधि से कई निजी विधियों में कोड विभाजन" के अभ्यास पर विचार करें।

रॉबर्ट सी मार्टिन का कहना है कि इस शैली अमूर्त में से एक स्तर के लिए प्रत्येक विधि की सामग्री को सीमित करने के लिए अनुमति देता है - एक सरल उदाहरण के रूप में, एक सार्वजनिक विधि शायद ही तरह निजी तरीकों के लिए कॉल शामिल होंगे verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)और अंत में sendJsonToClient(...), और इन तरीकों के लिए होता है कार्यान्वयन विवरण।

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

सबक है: वे सभी सही हैं, क्योंकि वे एक राय होने के हकदार हैं।

Answer 4

कई खुले स्रोत संग्रहालय वास्तव में से ग्रस्त है निष्पक्ष गरीब कोडिंग प्रथाओं और लंबी अवधि के योगदानकर्ताओं के एक छोटे समूह जो गरीब पठनीयता के साथ सौदा कर सकते हैं, क्योंकि वे कोड है कि वे सबसे अधिक बार बनाए रखने के कुछ हिस्सों के साथ बहुत परिचित हैं द्वारा मुश्किल से रखा जाता है । इस तथ्य के बाद पठनीयता में सुधार करने के लिए कोड को रीक्रिएट करना अक्सर एक Herculean प्रयास होता है क्योंकि सभी को एक ही पृष्ठ पर होना चाहिए, यह मज़ेदार नहीं है और यह भुगतान नहीं करता है क्योंकि कोई नई सुविधाएँ लागू नहीं होती हैं।

जैसा कि दूसरों ने कहा है, किसी भी पुस्तक में किसी भी चीज के बारे में बताते हुए क्लीन कोड के बारे में जरूरी सलाह है, जो सार्वभौमिक रूप से सहमत नहीं है। विशेष रूप से, लगभग किसी भी नियम का अत्यधिक उत्साह के साथ पालन किया जा सकता है, एक दूसरे के साथ पठनीयता समस्या की जगह ले सकता है।

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

Comments

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

— कैन-नेड_फूड

Answer 5

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

यह उन सभी परियोजना स्वामियों / प्रबंधकों की आलोचना नहीं है, जिनकी परियोजनाओं के बारे में मैं बात कर रहा हूं, यह बस समय की बात है। इन लोगों के पास अपने समय के साथ करने के लिए बेहतर चीजें हैं, जैसे कि उनकी वास्तविक भुगतान वाली नौकरी।

शुरुआत में कोड एक व्यक्ति का काम है और शायद छोटा है। और छोटे कोड को साफ होने की जरूरत नहीं है। या यों कहें, कोड को स्वच्छ बनाने के लिए आवश्यक प्रयास लाभ से बड़ा है।

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

मालिक के पास चीजों को साफ करने का समय नहीं है और किसी और की परवाह नहीं है।

और कोड बड़ा हो रहा है। और भद्दा।

जैसे-जैसे कोड के आसपास अपना रास्ता खोजना कठिन होता जाता है, वैसे-वैसे लोग गलत जगह पर फीचर जोड़ना शुरू करते हैं। और बग को ठीक करने के बजाय, वे कोड में अन्य स्थानों पर वर्कअराउंड जोड़ते हैं।

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

मेरे पास कोड आधारों को "क्रूर और असामान्य सजा" के रूप में वर्णित करने वाले लोग हैं।

मेरे व्यक्तिगत अनुभव काफी बुरे नहीं हैं, लेकिन मैंने कुछ बहुत ही अजीब चीजें देखी हैं।

Comments

यदि आप इस उत्तर में "खुले" और "स्रोत" शब्दों को समाप्त करते हैं तो यह केवल सच के रूप में जारी रहेगा।

— स्टीफन एम। वेब

मैं कहूंगा कि यह बंद-स्रोत सॉफ़्टवेयर के लिए भी उतना ही सच है।

— मार्क रोटेवेल

Answer 6

यह मुझे लगता है, आप पूछ रहे हैं कि यह सामान कैसे काम करता है अगर कोई भी ऐसा नहीं कर रहा है जो वे करने जा रहे हैं। और अगर यह काम करता है, तो हम इन चीजों को क्यों कर रहे हैं ?

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

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

समाधान एक पूरी नई प्रणाली भी कहा जाता आविष्कार करने के लिए था LibreSSL है, जो किया गया था साफ-ish कोड का उपयोग करने जा , और निश्चित रूप से लगभग कोई भी इसे इस्तेमाल करता है ।

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

तो आपको किसी और को ' सही तरीका ' करने की जहमत क्यों उठानी चाहिए ?

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

Comments

कई लिंक सोओ ... पहली नज़र में मुझे लगा कि यह जवाब होवर विज्ञापन के साथ दिया जा सकता है या यह एक विकिपीडिया पेज था।

— जॉनी हेनली

Answer 7

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

• जब मैं एक पुस्तकालय, या एक पुस्तकालय से आयात करता हूं, तो मैं शायद इसकी आंतरिक संरचना में एक विशेषज्ञ के लिए पर्याप्त नहीं हूं, यह जानने के लिए कि इसके टूलकिट का छोटा सा हिस्सा मुझे जो कुछ भी काम करने की आवश्यकता है, जब तक मैं कॉपी नहीं कर रहा हूं स्टैक एक्सचेंज उत्तर ने मुझे करने के लिए कहा। इसलिए मैं टाइप करना शुरू करता हूं from A import(यदि यह पायथन में है, तो कहो) और देखो कि क्या आता है। लेकिन इसका मतलब यह है कि मैं सूचीबद्ध कार्यों को उन तार्किक कार्यों को प्रतिबिंबित करने के लिए देखता हूं, जिन्हें मुझे उधार लेने की आवश्यकता होगी, और यही कोडबेस में होना चाहिए। अनगिनत सहायक विधियाँ जो इसे छोटा बनाती हैं, वे मुझे भ्रमित करेंगी।
• पुस्तकालयों वहाँ सबसे अनुभवहीन प्रोग्रामर के लिए कुछ एल्गोरिथ्म का उपयोग करने की कोशिश कर रहे हैं ज्यादातर लोगों को केवल अस्पष्ट सुना है। उन्हें बाहरी दस्तावेज़ीकरण की आवश्यकता होती है, और इसके लिए कोड को ठीक से मिरर करने की आवश्यकता होती है, जो यह नहीं कर सकता है यदि हम शॉर्ट-मेथड और डू-वन-चीज़ का पालन करने वालों को खुश करने के लिए सब कुछ ठीक करते रहें।
• हर पुस्तकालय विधि उधार लेने वाले लोगों को विनाशकारी परिणामों के साथ दुनिया भर में कोड तोड़ सकता है अगर इसे नीचे ले लिया जाए या नाम बदला जाए। निश्चित रूप से, मेरी इच्छा है कि कैलिनस्की -हरबासज़ में स्केलेरो टाइपो को ठीक करेगा , लेकिन यह एक और बाएं-पैड की घटना का कारण बन सकता है । वास्तव में, मेरे अनुभव में पुस्तकालय विकास के साथ सबसे बड़ी समस्या यह है कि जब वे सब कुछ संरचना को बनाने के लिए कुछ अच्छे-नए नए "सुधार" को अपनाने की बहुत कोशिश करते हैं।
• इन-हाउस, टिप्पणियां काफी हद तक एक आवश्यक बुराई हैं, जिन सभी कारणों से मुझे पुनर्जन्म की आवश्यकता नहीं है (हालांकि वे बिंदु कुछ हद तक अतिरंजित करते हैं)। एक अच्छी टिप्पणी कहती है कि कोड क्यों काम करता है, कैसे नहीं। लेकिन पुस्तकालयों को पता है कि उनके पाठक सक्षम प्रोग्रामर हैं, जो यह नहीं कह सकते हैं, लिखने-रेखीय-बीजगणित एक पेपर बैग से बाहर निकलते हैं। दूसरे शब्दों में, सब कुछ फिर से टिप्पणी की जरूरत है: क्यों यह काम करता है! (ठीक है, यह एक और अतिशयोक्ति है।) इसीलिए आप सिग्नेचर लाइन, 100-लाइन कमेंट ब्लॉक, 1 लाइन का कोड देखते हैं जो सचमुच हस्ताक्षर लाइन (भाषा की अनुमति, निश्चित रूप से) पर जा सकता है।
• मान लीजिए कि आप गितुब पर कुछ अपडेट करते हैं और यह देखने के लिए प्रतीक्षा करें कि आपका कोड स्वीकार किया जाएगा या नहीं। यह स्पष्ट होना चाहिए कि आपका कोड परिवर्तन क्यों काम करता है। मैं अनुभव से जानता हूं कि कैंपसाइट क्लीनर को एक कार्यात्मक कमिट के हिस्से के रूप में बनाने का मतलब अक्सर लाइन-सेविंग, पुनर्व्यवस्था और पुनर्नामकरण का मतलब होता है, जो आपके वेतनविहीन समीक्षक की नौकरी को कठिन बनाता है, और अन्य समस्याओं का कारण बनता है।

मुझे यकीन है कि मुझसे अधिक अनुभव वाले लोग अन्य बिंदुओं का उल्लेख कर सकते हैं।

Comments

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

— एफसीएन

@FC यह व्यवहार्य दृष्टिकोण है, जब तक कि रखवाले याद रखें कि हर एक विधि के सामने हमेशा सही कीवर्ड का उपयोग करें क्योंकि वे आते और जाते हैं। या वे ऐसा कुछ कर सकते हैं जो आसान और कम त्रुटि वाला हो।

— JG

C #, जावा (जिसे अंकल बॉब के बारे में आमतौर पर बात करते हैं) जैसी भाषाओं में, एक्सेस मॉडिफायर किसी भी कोड को वास्तव में लिखने के लिए उपयोग किए जाने वाले सबसे बुनियादी उपकरण हैं। सही कीवर्ड का उपयोग करना किसी भी कोड को लिखने का हिस्सा है।

— एफसीएन

@FC वे कुछ अन्य भाषाओं में अक्सर कम स्पष्ट किए जाते हैं, लेकिन मैंने इन-हाउस C # कोडबेस पर भी काम किया है, जहां लोगों को आवश्यक रूप से उन संशोधक का उपयोग नहीं करना चाहिए जो उनके पास होने चाहिए।

— JG

इसलिए उन्हें अंकल बॉब की पुस्तक :)

— FCin

Answer 8

पहले से ही बहुत सारे अच्छे उत्तर हैं - मैं एक ओपन सोर्स मेंटेनर का दृष्टिकोण देना चाहता हूं।

हमारे दृष्टिकोण

मैं महान कोड से कम के साथ ऐसी कई परियोजनाओं का अनुरक्षक हूं। शायद ही कभी मुझे इस तरह के कोड को सुधारने से रोका जाता है क्योंकि अनुकूलता की चिंताओं के कारण पुस्तकालयों को हर हफ्ते लाखों बार डाउनलोड किया जाता है।

यह कठिन बनाए रखने में मदद करता है - एक नोड.जेएस के मुख्य सदस्य के रूप में कोड के कुछ हिस्से हैं जिन्हें मैं छूने से डरता हूं लेकिन कुछ भी करने के लिए बहुत काम है और लोग प्लेटफ़ॉर्म का उपयोग करते हैं और इसका आनंद लेते हैं। सबसे महत्वपूर्ण बात यह है कि यह काम करता है।

पठनीय कोड पर

जब आप कहें:

मैंने उनमें से कई में कोड को साफ कोड लिखने के लिए संबोधित सिद्धांतों से बहुत दूर पाया - जैसे कि कोड की सैकड़ों लाइनें शामिल हैं।

कोड की पंक्तियाँ इस बात का एक बड़ा पैमाना नहीं हैं कि यह कितना पठनीय है। अध्ययन में मैंने लिंडक्स कर्नेल से जुड़ा विश्लेषण किया गया था और प्रोग्रामरों के एक सर्वेक्षण में "नियमित" कोड (कोड जिसे लोग मूल रूप से उम्मीद करते हैं) और संगत कोड समझ में "क्लीन" कोड से बेहतर होना पाया। यह भी मेरे व्यक्तिगत अनुभव के साथ संरेखित करता है।

कुछ ओपन सोर्स प्रोजेक्ट भी स्वागत नहीं कर रहे हैं

लाइनस "प्रसिद्ध" ने कहा कि लिनक्स में डिबगर का निर्माण नहीं होना चाहिए क्योंकि डिबगर्स का उपयोग करने वाले लोग लिनक्स पर काम करने के लिए पर्याप्त नहीं हैं और वह उनमें से अधिक को आकर्षित नहीं करना चाहते हैं।

व्यक्तिगत रूप से मैं वहां उनके रुख से पूरी तरह असहमत हूं - लेकिन यह भी कुछ लोग करते हैं।

Answer 9

ओपन सोर्स सॉफ़्टवेयर का मतलब यह नहीं है कि कई लेखक शामिल हैं। जब एक सॉफ्टवेयर (या सॉफ्टवेयर की इकाई) किसी एकल लेखक द्वारा लिखा जाता है, तो लंबे कार्य अक्सर दिखाई देते हैं।

यह विकास प्रक्रिया की प्रकृति से आता है। एक सरल विधि समय के साथ विस्तारित होती जाती है, नई सुविधाओं को जोड़ा जा रहा है और बग को ठीक किया जा रहा है।

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

आपने कोई उदाहरण नहीं दिखाया है, लेकिन मेरी समझ से यह भी अक्सर विकास भाषा से जुड़ा होता है। कुछ भाषाएँ शुरुआत और भारी इकाई परीक्षण (या यहां तक ​​कि TDD) से सख्त लाइनिंग नियम लागू करती हैं। दोनों लाइनिंग और यूनिट परीक्षण आमतौर पर उस समस्या को रोकते हैं (यह इकाई परीक्षण जटिल / लंबे तरीकों के लिए कठिन है)।

सामान्य तौर पर, कोड को साफ करना कठिन होता है यदि सॉफ्टवेयर किसी एकल लेखक द्वारा विकसित किया जाता है और अन्य योगदानकर्ता केवल छोटे मुद्दों को ठीक कर रहे हैं।