आपके द्वारा हल की गई समस्या आपके द्वारा लिखे गए कोड से अधिक महत्वपूर्ण है

प्रोग्रामर को लगता है कि सॉफ्टवेयर का वास्तविक उद्देश्य वास्तविक समस्याओं को हल करना है।

50 साल पहले, 1968 में, सॉफ्टवेयर इंजीनियरिंग पर एक कार्य सम्मेलन आयोजित किया गया था, जिसे नाटो विज्ञान समिति के समर्थन से आयोजित किया गया था। उस समय, लोग यह ध्यान देने लगे कि सॉफ्टवेयर समाज का एक मूलभूत हिस्सा बन रहा है। हालाँकि, यह समझना भी मुश्किल हो गया। इस सम्मेलन के बाद, प्रोग्रामिंग एक उद्योग बन गया है। और यह व्यापारिक लोगों को नियंत्रित करने से दूर जाने लगा।

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

यहाँ एक उदाहरण है।

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

जब उपयोगकर्ता घर के करीब आया, तो उसने फोन लिया, विजेट पाया और फिर दरवाजा खोलने के लिए एक बटन दबाया।

किसी ने इसे देखा और पूछा:

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

यह ब्लूटूथ कहानी एक संकीर्ण फोकस का एक शानदार उदाहरण है: लक्ष्य न्यूनतम प्रयास के साथ दरवाजा खोलना था। सेंसर के वायरलेस होने पर विज़ुअल इंटरफ़ेस विकसित करने का कोई मतलब नहीं है।

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

यह अनलॉक कोड के अलावा कोई अतिरिक्त कोड लिखने के लिए बिना किसी तकनीकी समस्या को हल करने का एक शानदार उदाहरण है। हालाँकि, टेक डेट के साथ, कुछ भी लिखने के लिए उचित नहीं होना चाहिए ।

हर कोड लिखने लायक नहीं है।

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

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



ऊपर वर्णित पुन: जमा समस्या एक उपयोगकर्ता को प्रभावित करने वाली असुविधा की श्रेणी में आती है। इसलिए, प्राथमिकता 3।

हर बग फिक्सिंग के लायक नहीं है।

यह एक बहुत ही सामान्य बात है जब डेवलपर्स सब कुछ के लिए एक स्क्रिप्ट लिखने की कोशिश करते हैं। हालांकि, कुछ दोहराए जाने वाले कार्य स्वचालित होने के लायक नहीं हैं। यदि आपको मुख्य टीम कैसे काम करती है, इसके बारे में आवश्यक ज्ञान को छिपाने के लिए आपको प्रोग्रामिंग स्क्रिप्ट्स खर्च करने की आवश्यकता नहीं है।

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

सीएलआई में उच्च-स्तरीय कमांड की तुलना में कुछ प्रकार के निम्न-स्तरीय कमांड का उपयोग करना अधिक उपयोगी है जो ज्ञान को सार करता है, जैसे कि थिट ।

कुछ साल पहले मैं वृद्धिशील वितरण का उपयोग कर एक परियोजना पर काम कर रहा था। यह एक पहचान सत्यापन प्रणाली थी जिसे उपयोगकर्ता को तीसरे पक्ष के प्रदाता द्वारा सत्यापन के लिए कुछ व्यक्तिगत डेटा प्रदान करने की आवश्यकता थी।

यह एक विशेष क्षेत्र सत्यापन विशेषता थी जिसे टीम बनाना चाहती थी। हालांकि, प्रत्येक स्प्रिंट की योजना बनाने में ऑडिट इतिहास को प्राथमिकता दी गई थी, क्योंकि समय सीमा करीब और करीब हो रही थी। अंत में, टीम को पता चला कि विचित्र सत्यापन होने का कोई मतलब नहीं था।

और यहाँ क्यों है: सत्यापन अनिवार्य था!

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

सबसे खराब स्थिति में, जो उपयोगकर्ता स्वयं को सत्यापित नहीं कर सकते थे वे मैन्युअल रूप से सब कुछ जांचने के लिए समर्थन को कॉल कर सकते थे।

प्रत्येक फ़ंक्शन प्रोग्रामिंग के लायक नहीं है।

यदि आप एक डेवलपर हैं और आप उस समस्या को समझते हैं जिसे आप हल करने की कोशिश कर रहे हैं, तो आप बेहतर कोड के साथ आ सकते हैं, और कभी-कभी आप कोड के बिना सामना कर सकते हैं। आप एक " कोड बंदर " नहीं हैं जो स्क्रीन पर पात्रों को लिखने के लिए भुगतान किया जाता है। आप एक पेशेवर हैं जिन्हें समस्याओं को हल करने के लिए भुगतान किया जाता है।

हालाँकि, यदि आप बिना किसी विचार के तकनीक की मदद से सभी समस्याओं को हल करने का प्रयास करते हैं, तो आपको यह समझने में समस्याएँ होंगी कि ग्राहक के लिए क्या मूल्यवान है और महान विचारों के साथ आ रहा है।

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

एक कहावत है: "यदि आपके पास केवल एक हथौड़ा है, तो सब कुछ एक नाखून की तरह दिखता है।"

पहले एक नाखून रखना बेहतर है ताकि आप एक हथौड़ा की आवश्यकता पर विचार कर सकें।

यही है, अगर आपको पहले एक नाखून की आवश्यकता है।

लेख पढ़ने के लिए धन्यवाद!

अगर मुझे अनुवाद में त्रुटियाँ हैं, तो कृपया टिप्पणियों में इसके बारे में लिखें!
जावास्क्रिप्ट प्रश्नों और उत्तरों की त्वरित पहुँच के लिए मेरी साइट भी देखें - जावास्क्रिप्ट प्रश्न और उत्तर

मैं आपका बहुत आभारी और कृतज्ञ रहूंगा)

मैं ट्विटर पर हूं और वी.के.

आपका ध्यान के लिए बहुत बहुत धन्यवाद!