🤸🏻 🥜 👩🏻‍🔧 जनता के लिए प्रोग्रामिंग ⭐️ 📬 😀

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

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

दृश्य

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

बैल और गायों के खेल का प्रवाह

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

जिम्मेदारी का विभाजन

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

चर नामकरण

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

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

सूखी, KISS

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

DRY के साथ बहें

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

KISS अनुरूप फ्लो

YAGNI

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

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

चलो खेलें

स्व-समीक्षा और रीफैक्टरिंग के चरणों को पारित किया जाता है, कोई अनावश्यक कार्यक्षमता नहीं है, और सभी प्रवाह का अर्थ समझ के लिए पारदर्शी है। इसका मतलब है कि खेल तैयार है और यह पुरस्कार के लिए प्रतिस्पर्धा करने का समय है। प्रतियोगिता की शर्तों के अनुसार, 22 मई, 2020 से पहले सबसे अधिक अंक प्राप्त करने वाले शीर्ष 10 खिलाड़ियों को मैनचैट टीम से पुरस्कार मिलेगा।

नियमों के बारे में थोड़ा। हमारे कार्यान्वयन में, खेल एक व्यक्ति के लिए डिज़ाइन किया गया है। बॉट गैर-दोहराए जाने वाली संख्याओं के साथ 4-अंकीय अनुक्रम बनाता है। खिलाड़ी संख्या का अनुमान लगाने का प्रयास करता है। बॉट ने अपने पदों के साथ संयोग के बिना कितनी संख्या का अनुमान लगाया था, यानी गायों की संख्या, और कितने की स्थिति के लिए सही अनुमान लगाया गया था, यानी बैल की संख्या के जवाब में बॉट रिपोर्ट करता है। नतीजतन, खेल परिदृश्य कुछ इस तरह दिखाई दे सकता है:

संख्या 1234 का अनुमान लगाया गया है।
प्रतिभागी पहली धारणा बनाता है: 1165
जवाब मिलता है: 0 बैल और 4 गाय।
प्रतिभागी दूसरी धारणा बनाता है: 1678
और जवाब मिलता है: 1 बैल और 0 गाय।

प्रयास करने के लिए, लिंक का अनुसरण करें और संकेतों का पालन करें। आपको याद दिला दूं कि गेम फेसबुक मैसेंजर के माध्यम से जाता है। हम 2 कठिनाई स्तर प्रदान करते हैं: एक सीमित और असीमित संख्या में चाल के लिए एक खेल। एक मुश्किल में जीतना आपको 3 अंक लाएगा, एक साधारण में - 2. हारना, स्तर की परवाह किए बिना, 1 अंक लगेगा।

खेल को एक मानक प्रौद्योगिकी स्टैक पर लागू किया गया था: नगनेक्स 1.17, पीएचपी 7.4, पोस्टग्रेक्यूएल 12.1। यदि आप चाहें, तो आप रिपॉजिटरी को अपने सर्वर पर क्लोन कर सकते हैं , अपने मानवेस्ट पेज पर टेम्पलेट स्थापित कर सकते हैं और अपने स्वयं के टूर्नामेंट की व्यवस्था कर सकते हैं।

जाँच - परिणाम

"इस देश में हर किसी को कंप्यूटर पर प्रोग्राम करना सीखना होगा क्योंकि यह आपको सोचना सिखाता है।" मुझे लगता है कि इस कथन की प्रासंगिकता लंबे समय से केवल एक देश की सीमाओं से परे है। प्रोग्रामिंग टर्मिनल में गुप्त चरित्र नहीं है, जो एक uninitiated व्यक्ति के लिए मुश्किल है, और एक प्रोग्रामर एक निर्वाचित नहीं है। सबसे पहले, यह सोच का एक तरीका है और समस्याओं को हल करने के लिए कौशल का एक सेट है।

लेख के शीर्षक और मूल नारे की ओर मुड़ते हुए, मैं इसे फिर से बताना चाहता हूं: “प्रोग्रामिंग लोगों का है। व्यापक कार्यशील जनता की गहराइयों में इसकी गहरी जड़ें होनी चाहिए। इसे इन लोगों द्वारा समझा जाना चाहिए और उनके द्वारा प्यार किया जाना चाहिए। ”

मैंने कभी नहीं सोचा होगा कि एक लेख में मैं स्टीव जॉब्स और लेनिन का उद्धरण दूंगा।

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

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

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

जनता के लिए प्रोग्रामिंग