"अच्छा पर्याप्त" सॉफ़्टवेयर के बारे में

आज दैनिक स्टैंड-अप पर मैंने टीम के लिए बहुत ही हार्दिक भाषण दिया कि हम लोगों के लिए सॉफ्टवेयर लिखते हैं और कोई भी परवाह नहीं करता है कि उपयोगकर्ता अंदर से काम करने में सहज नहीं है तो कोड अंदर से कितना सुंदर लगेगा।

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

और, ज़ाहिर है, मुझे तुरंत अच्छे पर्याप्त सॉफ़्टवेयर की अवधारणा याद आई। तो, यहाँ उसका मुख्य संकेत है: हम पूरी तरह से करने का प्रयास नहीं करते हैं, हम बुरी तरह से नहीं लिखते हैं, हम एक अच्छा उत्पाद बनाते हैं।

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

गुणवत्ता

हम युवा अधिकतमवाद से ग्रस्त नहीं हैं और त्रुटियों की संख्या को शून्य करने के लिए अंतहीन समय नहीं बिताते हैं। हां, यह असंभव है (यदि कोई चाहता है, तो यह विशुद्ध रूप से गणितीय रूप से सिद्ध हो सकता है)। हम यह भी समझते हैं कि सिस्टम के उद्देश्य के आधार पर, त्रुटि सीमा अलग-अलग होनी चाहिए।

जाहिर है, एरोड्रम के नियंत्रण के लिए अस्पताल में रोगी की महत्वपूर्ण गतिविधि या सॉफ्टवेयर सुनिश्चित करने के लिए सिस्टम में व्यावसायिक तर्क के महत्वपूर्ण हिस्सों में कोई त्रुटि नहीं होनी चाहिए। लेकिन ऐसे अनुप्रयोगों के विकास और परीक्षण के लिए एक पूरी तरह से अलग दृष्टिकोण लिया जाता है, और एक पूरी तरह से अलग समय और बजट को परीक्षण में डाल दिया जाता है।

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

वास्तुकला और संहिता

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

हम अपने उड़ान कौशल का सम्मान करते हुए दिन-ब-दिन हारते जाते हैं, लेकिन हम कहीं भी उड़ान भरने वाले नहीं हैं। हम नहीं रोक सकते हैं और कह सकते हैं: "यह बात है! अब आप उड़ान भर सकते हैं ", क्योंकि हमेशा पूरी तरह से महारत हासिल करने वाली उड़ान तकनीक के एक जोड़े नहीं होते हैं: एक बैरल, नेस्टरोव का लूप और अन्य चालें (नागरिक विमानन में समान रूप से अनावश्यक)।

तो चलो अपने आप को एक अच्छा कार्यान्वयन के लिए सीमित करें। कोई यह भी तर्क नहीं देता कि यह बेहतर हो सकता है। लेकिन यह कोड कार्यक्षमता के लिए हमारी आवश्यकताओं को भी पूरी तरह से संतुष्ट करता है, यह पर्याप्त रूप से समझ में आता है , अच्छी तरह से पर्याप्त है , और इसे बदलना काफी सरल है।

कार्यक्षमता

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

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

ट्विटर पर एक नजर डालें। इसकी कार्यक्षमता न्यूनतम है। यह पर्याप्त है ताकि उपयोगकर्ता अपने संदेश भेज सकें और अजनबियों को पढ़ सकें। संदेश में न तो चित्र जोड़ने की क्षमता ("उनके बिना कोई कैसे कर सकता है," कई लोग सोचेंगे), और न ही एक पूर्ण सामाजिकता (केवल अनुसरण करें और उत्तर दें), इससे ज्यादा कुछ नहीं।

गूगल पर एक नजर डालें। उन्होंने उस समय कभी भी उन श्रेणियों को नहीं बनाया जो सभी खोज इंजनों के पास थे और यह कल्पना करना कठिन था कि "उनके बिना" कैसे संभव था।

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

कुछ लाइनों को समाप्त करने के लिए

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

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