कार्यात्मक प्रोग्रामिंग: एक निराला खिलौना जो श्रम उत्पादकता को मारता है। भाग २

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

सफलता मार्ग है, लक्ष्य नहीं।

आइए मानते हैं कि हम प्रोग्रामर को हमारे समय के लिए भुगतान किया जाता है। बिलकुल वैसे बिल्डरों की तरह जो अब दो साल से मेरे घर के पास छेद खोद रहे हैं (वैसे, वे एक दीवार बना रहे हैं, यानी एक सड़क)।

आइए प्रोग्रामर के उत्पादकता सूत्र की तलाश करें। हर कोई जो किसी भी बड़े निगम में काम करता है, वह सफलता का एक सरल फार्मूला जानता है:

 = __ x __ 

.Number की कीड़े तय

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

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

गलतियों? हां - बाजीगरी की प्रक्रिया के दौरान, कुछ गेंदें गिरती हैं। प्रोग्रामर 50 वस्तुओं की बातचीत के बारे में कुछ छोटी चीजें याद कर सकता है। लेकिन कौन, खुलकर परवाह करता है? उपयोगकर्ताओं द्वारा उत्पादन त्रुटियों की रिपोर्ट की जानी चाहिए। यह कितना बड़ा, गंभीर संगठन है। तब त्रुटि संदेश JIRA पत्रिका पर जाते हैं (यह, जैसा कि आप समझते हैं, एक गंभीर उद्यम-स्तर सॉफ्टवेयर उत्पाद है)। कुछ साल भी नहीं बीते हैं, और त्रुटियों को सुधारा जाएगा। समस्या हल हो गई!

भगवान, मैं अपने मोबाइल बैंकिंग एप्लिकेशन से कैसे प्यार करता हूं। यह बहुत कार्यात्मक है, बैंक मेरे व्यवसाय को महत्व देता है और मेरे व्यक्तिगत डेटा का ख्याल रखता है। गलतियाँ सिर्फ संभावनाएं हैं (मुझे बताया गया था)!

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

कोड की लाइनों का linesNumber

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

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

वही सलाह उन ठेकेदारों पर लागू होती है जो काम किए गए घंटों के आधार पर ग्राहकों से शुल्क लेते हैं। यहाँ उनके लिए एक सरल सफलता सूत्र है:

 __ = ____ = $$$$$$ 

यह सफलता का सूत्र, निश्चित रूप से उन गंभीर ठेकेदारों पर भी लागू होता है, जिन्हें कोड की लाइनों की संख्या के लिए भुगतान किया जाता है:

 if (1 == '1') {  doStuff(); } else {  //  } 

.स्पगेटी कोड हमारी रोटी और मक्खन है

कार्यात्मक प्रोग्रामिंग के विपरीत, OOP हमें स्पेगेटी कोड लिखने के लिए एक सुसंगत दृष्टिकोण प्रदान करता है। यह डेवलपर उत्पादकता के लिए बेहद फायदेमंद है। स्पेगेटी कोड लिखने का मतलब है कि कोड लिखने पर अधिक घंटे खर्च करना। यह किसी भी गंभीर वस्तु-उन्मुख प्रोग्रामर के लिए सीधा लाभ है। स्पेगेटी न केवल बहुत स्वादिष्ट है। यह OOP की शैली में लिखने वालों के लिए भी एक अत्यंत महत्वपूर्ण अवधारणा है।

OOP गंभीर कंपनियों के ठेकेदारों और कर्मचारियों के लिए एक वास्तविक उपहार है।

त्रुटि निवारण विभाग

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

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

▍ त्रुटि रिपोर्टिंग प्रक्रिया

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

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

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

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

मुझे आशा है कि अब आप आश्वस्त हैं कि त्रुटियां वह नहीं हैं जो प्रोग्रामर को परवाह करनी चाहिए। डेवलपर्स आमतौर पर समय की अनावश्यक बर्बादी से डेवलपर्स को बचाने के लिए गंभीर उपाय करते हैं।

साक्षात्कार में "शुरुआत गलतियाँ" से बचें

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

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

सुनिश्चित करें कि आपके फिर से शुरू में प्रौद्योगिकी के आपके व्यापक ज्ञान को प्रदर्शित करने वाले संदर्भ हैं जो बड़ी कंपनियों द्वारा मूल्यवान हैं। "वर्ग," "वंशानुक्रम," डिजाइन पैटर्न, "" निर्भरता इंजेक्शन, "" ठोस, "" सार कारखाना, "और" सिंगलटन "जैसे शब्द और वाक्यांश शामिल करें।

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

कार्यात्मक प्रोग्रामिंग का उपयोग संभवतः गंभीर सॉफ्टवेयर समाधान विकसित करने के लिए नहीं किया जा सकता है।

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

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

सारांश: देवताओं का उपहार

यहां आपके पास एक सवाल हो सकता है कि तथाकथित "कार्यात्मक" प्रोग्रामिंग में कौन से विकल्प हैं। यह, ज़ाहिर है, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग है। OOP को प्रोग्रामिंग के असली भगवान द्वारा हमारे पास भेजा जाता है। ओओपी एक ताकत है जिसके साथ प्रतिहिंसा की जानी चाहिए। यह एक Capitalized Tool है जो प्रोग्रामर को उत्पादक बनाता है। OOP के लिए धन्यवाद, आप और आपकी टीम हमेशा व्यवसाय में व्यस्त रहेंगे (और आपने अपनी नौकरी नहीं खोई)। यहाँ मेरा लेख है जिसमें मैं OOP के बारे में विस्तार से बात करता हूं।
हो सकता है (वस्तु-उन्मुख) बल आपके साथ हो। और आपका कोड। मैं ताकत वाला एक हूं। सभी को शांति।

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

फंक्शनल प्रोग्रामिंग बढ़िया है। इस प्रोग्रामिंग प्रतिमान की खोज में कुछ समय बिताएं और आप अपने आप को टीम के कई साथियों से आगे पाएंगे।

मुझे आशा है कि आप इसे पढ़ने में उतने ही इच्छुक थे जितना कि मैं लिख रहा था।

प्रिय पाठकों! आप OOP के बारे में सबसे अधिक क्या पसंद करते हैं?