श्रेणियाँ: प्रोग्रामिंग
प्रकाशन वर्ष: 2008
पढ़ाई का वर्ष: 2020
उच्चतम
पढ़ने की संख्या: 1
कुल पृष्ठ: 233
सारांश (पृष्ठ): 0
प्रकाशन की मूल भाषा:
अंग्रेजी
अन्य भाषाओं में अनुवाद: रूसी, चीनी
सामान्य जानकारी
2008 का एक पुस्तक, जिसमें डेवलपर्स और प्रोग्रामिंग के बारे में 55 तथ्य और 10 भ्रांतियाँ हैं। सभी सामग्री को विभिन्न समूहों में बांटा गया है, जैसे: प्रबंधन, विकास और अन्य।
पहले ही यह स्पष्ट कर देना चाहिए कि लेखक द्वारा चर्चा किए गए लगभग सभी विषय और सवाल विवादास्पद (होलिवार्न) हैं, और विभिन्न पाठकों के बीच इन पर राय में काफी अंतर हो सकता है। समय और स्थान की बचत के लिए मैं प्रत्येक बिंदु पर अपनी राय और दृष्टिकोण नहीं बताने जा रहा हूँ। यहाँ मैं केवल सभी तथ्यों और भ्रांतियों को संक्षेप में सूचीबद्ध करूंगा, और अंत में पुस्तक का सामान्य मूल्यांकन दूंगा। प्रत्येक तथ्य या भ्रांति औसत लेख के आकार में प्रस्तुत की गई है, इसलिए यदि आप चाहें तो आप पूरी किताब नहीं पढ़ सकते, बल्कि विशिष्ट विषयों को चुन सकते हैं। सभी तथ्यों और भ्रांतियों को सूचीबद्ध करने से पहले, यह भी उल्लेख करना चाहूंगा कि लेखक सामग्री की प्रस्तुति में एक स्पष्ट संरचना का पालन करते हैं:
- सबसे पहले, वह तथ्य या भ्रांति पर चर्चा करते हैं।
- फिर, उस पर बहस और विवादों का वर्णन करते हैं।
- अंत में, विषय से संबंधित सूचना स्रोतों को प्रस्तुत करते हैं।
प्रोग्रामिंग के तथ्य
मानव तत्व
- सॉफ़्टवेयर विकास में सबसे महत्वपूर्ण तत्व प्रोग्रामर्स द्वारा उपयोग की जाने वाली विधियों और उपकरणों से नहीं, बल्कि स्वयं प्रोग्रामर्स से संबंधित है।
- व्यक्तिगत अंतर पर किए गए एक शोध के अनुसार, सर्वश्रेष्ठ प्रोग्रामर्स, सबसे कमजोर से 28 गुना अधिक प्रभावी होते हैं। यदि हम यह मानें कि उनका वेतन कभी भी समान नहीं होता, तो सबसे अच्छा प्रोग्रामर सॉफ़्टवेयर उद्योग में सबसे लाभकारी अधिग्रहण होता है।
- यदि परियोजना समय सीमा में नहीं समाती है, तो अतिरिक्त श्रमिकों को जोड़ने से यह और भी देरी हो जाएगी।
- कामकाजी परिस्थितियाँ उत्पादकता और परिणाम की गुणवत्ता पर गहरा प्रभाव डालती हैं।
- सॉफ़्टवेयर उद्योग में उपकरणों और विधियों के इर्द-गिर्द प्रचार एक महामारी है। अधिकांश उपकरणों और विधियों में सुधार से उत्पादकता और गुणवत्ता में लगभग 5-35% की वृद्धि होती है। लेकिन इन सुधारों में से कई को "कई गुना बेहतर" के रूप में प्रस्तुत किया गया था।
- नए विधि या उपकरण को सीखने से पहले प्रोग्रामर्स की उत्पादकता और उत्पाद की गुणवत्ता घटती है। प्रशिक्षण से फायदा केवल तब उठाया जा सकता है जब आप लर्निंग कर्व से गुजर चुके हों। इसलिए नए विधियों और उपकरणों को अपनाने का अर्थ है, केवल अगर अ) उनकी वास्तविक मूल्य को देखा जाए और ब) विजय की प्रतीक्षा में धैर्य दिखाया जाए।
- डेवलपर्स उपकरणों के बारे में बहुत बातें करते हैं। वे उन्हें काफी मात्रा में खरीदते हैं, लेकिन उनका सही इस्तेमाल नहीं करते।
- परियोजना के असंतुलन के कारणों में से एक प्रमुख कारण खराब आकलन है। (दूसरे कारण को तथ्य 23 में चर्चा की गई है।)
- सॉफ़्टवेयर परियोजनाओं में अधिकांश आकलन जीवन चक्र के प्रारंभ में किए जाते हैं। और यह हमें परेशान नहीं करता, जब तक हम यह नहीं समझते कि आकलन उन आवश्यकताओं से पहले किए गए हैं, जो अभी तक परिभाषित नहीं हैं, और इसलिए पहले किए गए हैं, इससे पहले कि काम की समझ बनाई गई हो। इसका मतलब यह है कि आकलन आमतौर पर समय से पहले किया जाता है।
- सॉफ़्टवेयर परियोजनाओं में अधिकांश आकलन शीर्ष प्रबंधक या विपणन कर्मचारियों द्वारा किए जाते हैं, न कि वे लोग जो सॉफ़्टवेयर बनाएंगे, या उनके प्रबंधक। इस प्रकार, आकलन करने वाले लोग सही नहीं होते।
- सॉफ़्टवेयर परियोजनाओं में आकलन को बाद में कभी ठीक नहीं किया जाता। दूसरे शब्दों में, जब आकलन सही लोगों द्वारा और सही समय पर नहीं किए जाते हैं, तो उन्हें आमतौर पर सुधारा नहीं जाता।
- जब आकलन इतने गलत होते हैं, तो यह चिंतित होने का बहुत कारण नहीं है कि सॉफ़्टवेयर परियोजनाएँ समय सीमा में नहीं पूरी होतीं, जो आकलन द्वारा निर्धारित की गई थीं। हालांकि, सभी को इस बात की चिंता होती है।
- प्रबंधकों और प्रोग्रामर्स के बीच संपर्क नहीं होता। एक परियोजना पर किए गए एक शोध में, जिसमें दिए गए आकलन के आधार पर निर्धारित पैरामीटरों का पालन नहीं किया गया था और जिसे प्रबंधन द्वारा एक विफल परियोजना के रूप में देखा गया था, यह कहा गया था कि तकनीकी टीम ने इसे अब तक की सबसे सफल परियोजना के रूप में देखा था।
- परियोजना की संभावना का विश्लेषण लगभग हमेशा "हां" का उत्तर देता है।
- मिनी स्केल पर पुन: उपयोग (सबप्रोग्राम लाइब्रेरी में) लगभग 50 साल पहले आया था, और इसका समाधान अच्छे से तैयार किया गया है।
- वृहद पैमाने पर पुन: उपयोग (कंपोनेंट्स में) की समस्या अब तक मुख्यतः हल नहीं हो पाई है, जबकि यह सभी के लिए स्पष्ट है कि इसे करना बहुत महत्वपूर्ण है।
- वृहद पैमाने पर पुन: उपयोग की सफलता सबसे अधिक सुसंगत प्रणाली परिवारों में होती है, और इस कारण यह विशिष्ट क्षेत्र पर निर्भर होती है। यह वृहद पैमाने पर पुन: उपयोग की संभावित उपयोगिता को संकुचित करता है।
- पुन: उपयोग की प्रैक्टिस में दो "तीन के नियम" होते हैं: अ) बार-बार उपयोग किए जाने वाले घटक तीन गुना अधिक श्रमसाध्य होते हैं, जबकि एक बार उपयोग होने वाले घटक; और ब) बार-बार उपयोग होने वाला घटक तीन अलग-अलग अनुप्रयोगों में परखा जाना चाहिए, इससे पहले कि उसे घटक लाइब्रेरी में जोड़ा जा सके।
- पुन: उपयोग किए गए कोड में परिवर्तन बेहद खतरनाक हो सकता है। अगर घटक कोड के 20-25% से अधिक बदला जाता है, तो उसे पूरी तरह से फिर से लिखना बेहतर होता है।
- डिजाइन पैटर्न्स का पुन: उपयोग – यह उन समस्याओं का समाधान है जो कोड पुन: उपयोग से संबंधित होती हैं।
- कार्य की जटिलता को 25% बढ़ाने से प्रोग्राम समाधान की जटिलता 100% बढ़ जाती है। यह कोई ऐसा स्थिति नहीं है जिसे आप बदलने की कोशिश कर सकते हैं (हालांकि जटिलता को हमेशा कम करना अच्छा होता है), यह वास्तविक स्थिति है।
- सॉफ़्टवेयर बनाने का 80% कार्य बौद्धिक गतिविधि पर आधारित होता है। इसका एक अच्छा हिस्सा रचनात्मक होता है, और केवल एक छोटा हिस्सा तकनीकी होता है।
आवश्यकताएँ
- परियोजनाओं के असंतुलन के दो सबसे सामान्य कारणों में से एक परिवर्तनशील आवश्यकताएँ हैं। (दूसरा कारण तथ्य 8 में चर्चा की गई है।)
- आवश्यकताओं में गलती को सुधारना सबसे महंगा होता है यदि यह उपयोग के चरण में पाया जाता है, और सबसे सस्ता होता है यदि यह विकास के प्रारंभिक चरणों में होता है।
- जो आवश्यकताएँ नहीं होतीं, वे सबसे कठिन गलती होती हैं, जिसे सुधारना सबसे मुश्किल होता है।
डिजाइन
- प्रारंभिक आवश्यकताओं से आर्किटेक्चर तक बढ़ने के साथ हम "उत्पन्न आवश्यकताओं" की बाढ़ का सामना करते हैं (विशिष्ट डिजाइन समाधान के लिए आवश्यकताएँ), जो प्रक्रिया की जटिलता से उत्पन्न होती हैं। इन उत्पन्न आवश्यकताओं की सूची अक्सर प्रारंभिक से 50 गुना लंबी होती है।
- सॉफ़्टवेयर डिजाइन के लिए सबसे अच्छा समाधान शायद एकमात्र नहीं होता।
- डिजाइन एक जटिल इटरेटीव प्रक्रिया है। प्रारंभिक डिज़ाइन समाधान सबसे अधिक संभावना है कि गलत और निश्चित रूप से अनुकूलित नहीं होगा।
कोडिंग
- प्रोग्रामर डिजाइन से कोडिंग में तब जाते हैं जब कार्य को "प्रिमिटिव्स" तक तोड़ा जाता है, जो डिजाइनर के पास होते हैं। यदि कोडर और डिजाइनर अलग-अलग लोग होते हैं, तो डिजाइनर के प्रिमिटिव्स कोडर के प्रिमिटिव्स से मेल नहीं खा सकते हैं और यह समस्याएँ पैदा करेगा।
- COBOL एक बहुत खराब भाषा है, लेकिन अन्य सभी (बिजनेस डेटा प्रसंस्करण के लिए) उससे भी बदतर हैं।
- त्रुटि उन्मूलन का चरण जीवन चक्र का सबसे श्रमसाध्य चरण होता है।
परीक्षण
- यह पता चला है कि सॉफ़्टवेयर में, जिसके बारे में एक सामान्य प्रोग्रामर सोचता है कि इसे सावधानीपूर्वक परीक्षण किया गया है, अक्सर केवल 55-60% तार्किक मार्गों का परीक्षण किया जाता है। स्वचालित उपकरणों का उपयोग, जैसे कि कवरिज़ एनालाइज़र, इस अनुपात को लगभग 85-90% तक बढ़ाने में मदद करता है। 100% तार्किक मार्गों का परीक्षण करना लगभग असंभव है।
- यहां तक कि अगर 100% परीक्षण कवरिज़ संभव होता, तो यह परीक्षण की पर्याप्तता के मानदंड के रूप में काम नहीं करता। लगभग 35% सॉफ़्टवेयर दोष लापता तार्किक मार्गों के कारण होते हैं और 40% दोषों का संबंध विशिष्ट तार्किक मार्गों के संयोजन से होता है। इन्हें 100% परीक्षण कवरेज से नहीं पहचाना जा सकता।
- बिना औजारों के, गलतियों को ठीक करने का काम गुणवत्ता से करना लगभग असंभव है। डिबगर्स का व्यापक रूप से उपयोग किया जाता है - यह अन्य उपकरणों, जैसे कि परीक्षण कवरेज विश्लेषकों के विपरीत है।
- परीक्षण शायद ही कभी स्वचालित किए जाते हैं। अर्थात, कुछ परीक्षण प्रक्रियाओं को स्वचालित किया जा सकता है और किया जाना चाहिए। लेकिन परीक्षण से संबंधित काफी हद तक काम स्वचालित नहीं किया जा सकता है।
- परीक्षण उपकरणों के लिए एक महत्वपूर्ण अतिरिक्त वह है जो प्रोग्रामर द्वारा बनाई गई अंतर्निहित डिबग कोड होती है, जो संकलन निर्देशों के आधार पर ऑब्जेक्ट कोड में शामिल की जाती है।
- सावधानीपूर्वक निरीक्षणों से सॉफ़्टवेयर उत्पाद में 90% तक त्रुटियों को ठीक किया जा सकता है, इससे पहले कि पहला मानक परीक्षण चलाया जाए।
- सावधानीपूर्वक निरीक्षण कई लाभ प्रदान करते हैं, लेकिन वे परीक्षण को प्रतिस्थापित नहीं कर सकते।
- यह सामान्य रूप से स्वीकार किया जाता है कि पोस्ट-फैक्टम समीक्षाएँ (जिन्हें रेट्रोस्पेक्टिव भी कहा जाता है) उपभोक्ता (सॉफ़्टवेयर उपयोगकर्ता) के हितों और प्रक्रिया को सुधारने के दृष्टिकोण से महत्वपूर्ण हैं। हालांकि, अधिकांश संगठनों में रेट्रोस्पेक्टिव समीक्षाएँ नहीं की जाती हैं।
- निरीक्षणों में, तकनीकी पहलुओं के अलावा सामाजिक कारक भी होते हैं। किसी एक को दूसरे के नुकसान पर अधिक ध्यान केंद्रित करना - यह सीधे तौर पर आपदा का मार्ग है।
- सहायता की लागत सामान्यतः सॉफ़्टवेयर की लागत का 40-80% (औसतन 60%) होती है। इसलिए, इसका जीवन चक्र चरण संभवतः सबसे महत्वपूर्ण होता है।
- सहायता पर खर्च का लगभग 60% कोड सुधारने पर और 17% त्रुटियों को ठीक करने पर खर्च होता है। इस प्रकार, मुख्य रूप से सॉफ़्टवेयर सहायता और समर्थन में नई विशेषताएँ जोड़ने का कार्य किया जाता है, न कि इसे सुधारने का।
- सहायता एक समाधान है, न कि समस्या।
- अगर हम सॉफ़्टवेयर विकास और समर्थन कार्यों की तुलना करें, तो वे अधिकांशतः समान होते हैं - केवल एक अतिरिक्त कार्य, जिसे "सहायता उत्पाद का अध्ययन" कहा जाता है, को छोड़कर। यह आमतौर पर सहायता के कुल समय का लगभग 30% लेता है, और यह प्रकार की गतिविधि सहायता में प्रमुख होती है। इसलिए, हम कह सकते हैं कि सहायता, विकास से अधिक श्रमसाध्य है।
- सॉफ़्टवेयर विकास की गुणवत्ता में सुधार करने से सहायता का कार्य बढ़ता है, घटता नहीं।
गुणवत्ता
- गुणवत्ता गुणों का एक संग्रह है।
- गुणवत्ता का निर्धारण उपयोगकर्ता की संतुष्टि, ग्राहक की आवश्यकताओं की पूर्ति, कीमत की स्वीकार्यता, उत्पाद के समय पर सौंपने या विश्वसनीयता से नहीं होता है।
- ऐसी गलतियाँ हैं जिनकी संभावना अधिकांश प्रोग्रामरों में होती है।
- गलतियाँ झुंडों में पाई जाती हैं।
- गलतियों को सुधारने के लिए अभी तक कोई एक, सर्वोत्तम तरीका विकसित नहीं हुआ है।
- गलतियों से बचना असंभव है। उद्देश्य यह है कि गंभीर गलतियों से बचा जाए या उन्हें न्यूनतम किया जाए।
प्रभावशीलता
- प्रभावशीलता एप्लिकेशन के गुणवत्ता डिज़ाइन पर अधिक निर्भर करती है, न कि उच्च गुणवत्ता वाले प्रोग्रामिंग पर।
- उच्च-स्तरीय भाषा में कोड की प्रभावशीलता, जब उपयुक्त अनुकूलन पैरामीटर के साथ संकलित होती है, तो यह असेंबली कोड के तुलना में 90% तक प्रभावी हो सकती है। और कुछ जटिल आधुनिक आर्किटेक्चर में यह और भी अधिक हो सकती है।
- आकार अनुकूलन और गति अनुकूलन के बीच समझौते होते हैं। अक्सर एक संकेतक में सुधार दूसरे को बिगाड़ता है।
वैज्ञानिक अनुसंधान
- कई वैज्ञानिक, जो सॉफ़्टवेयर उद्योग में काम कर रहे हैं, अपनी थ्योरीज़ को बचाने के बजाय अनुसंधान करने की प्रवृत्ति रखते हैं। परिणाम: क) कुछ प्रचारित थ्योरीज़ का मूल्य उन लोगों से कम होता है जो इन्हें बढ़ावा देते हैं; ख) इन थ्योरीज़ का वास्तविक मूल्य निर्धारित करने में मदद करने वाले अनुसंधान की कमी है।
प्रोग्रामिंग के मिथक
- आप उस चीज़ का प्रबंधन नहीं कर सकते जिसे आप माप नहीं सकते।
- मैनेजमेंट सॉफ़्टवेयर उत्पाद को गुणवत्ता बना सकता है।
- प्रोग्रामिंग को और चाहिए और इसे अनामित किया जा सकता है।
- उपकरण और तकनीकें सार्वभौमिक हैं।
- प्रोग्रामिंग को और अधिक विधियों की आवश्यकता है।
- लागत का मूल्यांकन और समय निर्धारित करने के लिए, पहले कोड की लाइनों की गिनती करें।
- यादृच्छिक इनपुट डेटा का उपयोग परीक्षण को अनुकूलित करने का एक अच्छा तरीका है।
- “सभी त्रुटियाँ तब स्पष्ट हो जाती हैं जब उन पर पर्याप्त आंखें लगी होती हैं।”
- यह जानकर कि पिछले मामले में सहायता का क्या खर्च आया, भविष्य में इसके खर्च का अनुमान लगाया जा सकता है और उत्पाद को बदलने के बारे में निर्णय लिया जा सकता है।
- लोगों को प्रोग्रामिंग सिखाया जा सकता है, अगर उन्हें दिखाया जाए कि कैसे प्रोग्राम लिखें।
निष्कर्ष
हालाँकि यह पुस्तक 2008 में लिखी गई थी, मैं इसे प्रोग्रामिंग सीखने वालों के लिए पढ़ने की सलाह देता हूँ। नकारात्मक पहलू यह है कि कुछ आँकड़े और प्रतिशत जो लेखक ने कुछ तथ्यों में दिए हैं, उनका प्रमाण या खंडन करना मुश्किल है। कुछ तथ्यों में भी ऐसी जानकारी है जो अब प्रासंगिक नहीं है। बाकी अधिकांश सामग्री अब भी प्रासंगिक है, और इसे न केवल डेवलपर्स, बल्कि मैनेजर्स के लिए भी पढ़ना उपयोगी होगा।
