अल्फोंस मोरालेस द्वारा अनस्प्लैश पर फोटो

"सॉफ्टवेयर के साथ समस्या"

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

मूल कारण

बर्र मूल रूप से कंप्यूटर विज्ञान और प्रौद्योगिकी का एक लंबा इतिहास प्रस्तुत करता है और इस तथ्य पर गंभीर रूप से चर्चा करता है कि मानकों और ध्वनि एसई दृष्टिकोण पर थोड़ा सामान्य समझौता है। उसका कहना है:

अन्य इंजीनियरिंग विषयों के विपरीत, सॉफ्टवेयर इंजीनियरिंग में डिग्री होने की गारंटी नहीं है कि आप प्रोग्रामिंग टूल्स और तकनीकों के एक ज्ञात कोष को समझते हैं, क्योंकि ऐसा कुछ मौजूद नहीं है।

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

अध्यायों के पहले जोड़े ने थोड़ा लंबा-चौड़ा पढ़ा और मेरे लिए दूसरा भाग अधिक रोचक और विचारोत्तेजक दिखाई दिया। यह शायद सिर्फ इस तथ्य के कारण है कि, मेरे कमोडोर C64 और 500 दिनों के बच्चे के रूप में BASIC के कुछ शुरुआती जोखिम के बावजूद, मैं अपने पेशेवर अनुभव से अधिक हाल के घटनाक्रमों से संबंधित हो सकता हूं। हालांकि, यहां तक ​​कि पहले अध्याय एसई अनुसंधान अध्ययन के व्यावहारिक बिट्स का हवाला देते हैं:

“ज्ञान प्राप्ति’ या। प्रोग्राम अंडरस्टैंडिंग ’नामक एक अनूठा रखरखाव पहलू है। यह सॉफ्टवेयर युग के रूप में एक प्रमुख लागत घटक बन जाता है (मान बढ़ाने और दोष को ठीक करने दोनों का 50%)।” आपकी भविष्य की रखरखाव की लागत का आधा हिस्सा खर्च करके पुनः प्राप्त किया जाएगा। आपके कार्यक्रम का विवरण जो आप इस बीच भूल गए होंगे!

या

"... इसलिए अधिकांश प्रोग्रामर प्रभावी रूप से अपने स्वयं के कार्यक्रमों का परीक्षण नहीं कर सकते हैं क्योंकि वे आवश्यक मानसिक दृष्टिकोण बनाने के लिए खुद को नहीं ला सकते हैं: त्रुटियों को उजागर करने की इच्छा का दृष्टिकोण।"

चुनौतियां

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

मैं कॉरपोरेट जीवन के पानी को कैसे नेविगेट कर सकता हूं, इस पर लोगों को सलाह दे सकता हूं, लेकिन यह सामान्य सलाह थी कि वे किसी से भी मिल सकते हैं। दूसरों की तरह, मेरा मार्गदर्शन अस्पष्ट था: "ठीक है, इस एक मामले में मुझे याद है कि इस तरह की चीज ने ठीक काम किया है, इसलिए ऐसा क्यों न करें?"

प्रसंग

एसई परियोजनाओं में संदर्भ के प्रभाव और एक घटना का उल्लेख करते हैं, जिसे "गेल-मान एम्नेसिया प्रभाव" कहा जाता है, जब बरार कहते हैं:

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

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

हालाँकि, इस समय में ग्राउंडेड सॉफ़्टवेयर आर्किटेक्ट, ऑक्सीजन से वंचित लोगों की तुलना में बेहतर माने जाते हैं, यह तथ्य कि आर्किटेक्ट्स को अपनी टीम के वर्तमान प्रोजेक्ट में निरंतर विसर्जन की आवश्यकता है, यह एक और संकेत है कि सॉफ्टवेयर इंजीनियरिंग के आसपास पर्याप्त स्वीकृत ज्ञान और शब्दावली नहीं है।

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

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

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

अनुसंधान

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

कोडिंग Dojo

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

विश्वविद्यालयों में किए गए सॉफ़्टवेयर प्रोजेक्ट को आमतौर पर किसी अन्य व्यक्ति द्वारा बनाए रखने योग्य, प्रयोग करने योग्य या परीक्षण करने योग्य नहीं होता है।

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

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

विशेषज्ञता

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

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

बौद्धिक विनम्रता

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