प्रोग्रामिंग के बारे में 7 मिथक

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

यह पता चला है कि विकसित तर्क वाले ऐसे तर्कसंगत लोग, जैसे डेवलपर्स, मिथकों में विश्वास करते हैं। कुछ प्रोग्रामर विश्वास करते हैं कि वे सब कुछ के बावजूद क्या विश्वास करना चाहते हैं।
उदाहरण के लिए, क्लासिक गलत धारणा यह है कि आप अधिक डेवलपर्स को जोड़कर परियोजना के विकास को गति दे सकते हैं। फ्रेडरिक ब्रूक ने 1975 में अपनी पुस्तक माइथिकल मैन-मंथ में इस मिथक को वापस फैलाया।
ब्रुक का मानना ​​था कि पहले से ही विकसित परियोजना के लिए डेवलपर्स को जोड़ने से प्रक्रिया में तेजी नहीं आएगी। इसके विपरीत, यह आगे भी विकास की प्रक्रिया को धीमा कर देगा। वास्तव में, यह सॉफ्टवेयर परियोजनाओं के प्रबंधन के संबंध में आम तौर पर स्वीकृत अवधारणाओं को खारिज करता है।
बेशक, कुछ ब्रूक्स उदाहरण आज पुराने लग रहे हैं, लेकिन सामान्य विचार अभी भी प्रासंगिक है। उनकी दलीलें बहुत ठोस हैं। 37 साल बाद, प्रोग्रामर के बीच पौराणिक सोच बनी रहती है। हम वही गलतियाँ करते रहते हैं।
यहां आधुनिक प्रोग्रामिंग मिथकों के कुछ उदाहरण दिए गए हैं, जिनमें से कई पुरानी भ्रांतियों से उपजी हैं।

मिथक # 1: अपतटीय सॉफ्टवेयर विकास

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

मिथक # 2: अच्छे डेवलपर्स दिनों के लिए काम करते हैं।

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

मिथक # 3: कूल डेवलपर्स दूसरों की तुलना में 10 गुना अधिक उत्पादक हैं

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

मिथक # 4: आधुनिक उपकरण बेहतर परिणाम प्रदान करते हैं।

सॉफ्टवेयर एक प्रौद्योगिकी व्यवसाय है, और कोई यह मानना ​​चाहता है कि प्रौद्योगिकी सभी समस्याओं को हल कर सकती है। यह अच्छा होगा यदि नई प्रोग्रामिंग भाषा, रूपरेखा या विकास के वातावरण में लागत कम हो, बाजार में समय कम हो, और कोड की गुणवत्ता में भी सुधार हो।
कई कंपनियों ने अपने प्रतिद्वंद्वियों के आसपास जाने के लिए गैर-पारंपरिक भाषाओं का उपयोग करने की कोशिश की है। यमलर सोशल नेटवर्क का पहला संस्करण स्काला में लिखा गया है। ट्विटर ने रूल्स एप्लिकेशन पर रूबी के रूप में जीवन शुरू किया। Reddit और Yahoo स्टोर दोनों को लिस्प का उपयोग करके बनाया गया था।
दुर्भाग्य से, इनमें से अधिकांश प्रयोग अल्पकालिक हैं। जब स्माला सामान्य कामकाज प्रदान करने में असमर्थ थी, तो यमर ने जावा में स्विच किया। ट्विटर रूबी से स्काला और फिर आंशिक रूप से जावा में बदल गया। Reddit ने Phyton पर अपना कोड फिर से लिखा। याहू स्टोर C ++ और Perl पर चला गया।
इसका मतलब यह नहीं है कि उपकरणों की पसंद मायने नहीं रखती है। विशेष रूप से, सर्वर वातावरण में जहां स्केलेबिलिटी प्रदर्शन के रूप में महत्वपूर्ण है। लेकिन, जैसा कि हम देखते हैं, कई कंपनियां अधिक फैशनेबल समाधानों से पारंपरिक लोगों की ओर बढ़ी हैं।
उदाहरण के लिए, जब 1970 में यूएसए में एडीए का विकास हुआ, तो मुख्य लक्ष्य तथाकथित प्रोग्रामिंग क्रांति थी - लेकिन अफसोस। आज यह सबसे अच्छा एक आला उपकरण है।
बेशक, यह नई प्रोग्रामिंग भाषाओं के किसी भी आविष्कारक को रोक नहीं पाएगा, और यह सामान्य है। बस मूर्ख मत बनो। जब आपका लक्ष्य दो तरह से उच्च गुणवत्ता वाला सॉफ्टवेयर, चपलता, लचीलापन, सरलता और कौशल पराजय तकनीक बनाना है। इसलिए, एक परिपक्व साधन चुनने से चोट नहीं पहुंचेगी।

मिथक # 5: अधिक आँखें कोड की जांच करती हैं, कम कीड़े

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

मिथक # 6: कूल डेवलपर्स अधिकतम कोड का अनुकूलन करते हैं

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

मिथक # 7: अच्छा कोड "सुरुचिपूर्ण" कोड है

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