लक्ष्य की तुलना में लक्ष्य अधिक महत्वपूर्ण है

कार्यक्रम का एक लक्ष्य है जिसे कभी-कभी भुला दिया जाता है

एक ब्लैकबोर्ड पर पड़ी हथौड़े की छवि। बोर्ड में एक पेंच फंस गया था, जिसे उन्होंने वहां मुश्किल से खेला था

ऐसा लगता है कि प्रोग्रामर सॉफ़्टवेयर के उद्देश्य के बारे में भूल गए हैं - वास्तविक दुनिया की समस्याओं को हल करने के लिए।

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

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

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

एक स्टार्टअप ने एक उपकरण बनाया जिसने ब्लूटूथ के माध्यम से एक घर का दरवाजा खोला। डिवाइस के साथ संचार के लिए ग्राफिकल इंटरफ़ेस - एक लॉक फोन स्क्रीन पर एक विजेट। उसके पास एक बटन है जिसका नाम है "दरवाजा खोलो।"

जब उपयोगकर्ता घर पहुंचता है, तो वह फोन लेता है, विजेट ढूंढता है और बटन दबाता है।

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

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

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

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

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

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

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

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


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

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

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

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

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

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

हर टीम विवरण के लायक नहीं है।

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

और वहां टीम एक असामान्य क्षेत्र सत्यापन समारोह को एनकोड करना चाहती थी। हालाँकि, यह मान्यता प्रत्येक नियोजक पर वापस आ गई थी क्योंकि समय सीमा समाप्त हो गई थी। अंत में, उन्होंने फैसला किया कि यह असामान्य कार्य बिल्कुल भी समझ में नहीं आता है।

और यहाँ क्यों: सत्यापन पहले से ही मजबूर है!

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

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

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

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

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

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

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

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

यदि आपको वास्तव में इस नाखून को हथौड़ा करने की आवश्यकता है।