सॉफ्टवेयर जीवन का अर्थ

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

हर कोई अपने लिए जीवन का अर्थ ढूंढता है। भौतिक विज्ञानी कह सकते हैं कि जीवन का अर्थ एन्ट्रापी के खिलाफ लड़ाई में है: अराजकता का क्रम में परिवर्तन।
इस मामले में, सॉफ्टवेयर का अर्थ क्रम के निर्माण को अधिक प्रभावी और दिलचस्प बनाने के लिए दिनचर्या को समाप्त करना है।

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

सॉफ्टवेयर इंजीनियरिंग में, डेवलपर्स अपने फॉर्मूलेशन / इंटरफ़ेस से किसी समस्या के समाधान के कार्यान्वयन को अलग करने के लिए, घटकों, मॉड्यूल, सेवाओं या नियंत्रणों में इंटरफेस के पीछे दोहराए गए चरणों और संचालन के विवरण को छिपाने का प्रयास करते हैं।

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

कार्यक्रमों के डिजाइन में मूल तत्व कार्यक्षमता और उसके कार्यान्वयन की जुदाई है। जीवन में कई अन्य चीजों की तरह, यह 3 प्रमुख प्रश्न उठाता है:
1. हम क्या करना चाहते हैं?
2. हम यह कैसे करना चाहते हैं?
3. हम ऐसा क्यों करना चाहते हैं?

पहला एक कार्यात्मक विनिर्देश के लिए एक सवाल है। दूसरा विशिष्ट कार्यक्षमता का तकनीकी कार्यान्वयन है। लेकिन आखिरी सवाल, हम ऐसा क्यों करते हैं और हमें इसकी आवश्यकता क्यों है, एक व्यापक कार्य के ढांचे के भीतर सामान्य दिशा निर्धारित करता है और "क्या" और "कैसे" जैसे सवालों के संभावित जवाबों के बीच हमारी पसंद को निर्देशित करता है।

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

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

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

ऐसे समाधानों की गुणवत्ता का मूल्यांकन कैसे करें? अच्छे विकल्पों में से एक नियमित चरणों का विश्लेषण करना और कार्य को दो भागों में विभाजित करने के बाद समाधानों की तुलना करना है: दोहराव / उबाऊ / सहायक / यांत्रिक और रचनात्मक / दिलचस्प / महत्वपूर्ण / कार्यात्मक।

नियमित पहचान दिखाता है
- कार्यक्रम को कहां और कैसे बेहतर बनाया जा सकता है।
- क्या हम काम करने के लिए सही उपकरणों का उपयोग करते हैं।
- क्या हम प्रोग्रामर और अंतिम उपयोगकर्ताओं के काम में रचनात्मक हिस्से को बढ़ा सकते हैं।

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

उदाहरण एक: MS Word में किसी फ़ाइल को सहेजना

अधिकांश उपयोगकर्ताओं ने वर्ड के साथ काम किया है। किसी दस्तावेज़ को सहेजने के लिए संवाद, विशेष रूप से पहली बार, गंभीरता से पहेली कर सकता है:

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

समय के साथ, आप इस संवाद के आदी हो जाते हैं और जानते हैं कि कौन से मापदंडों को दर्ज करना है और किसको अनदेखा करना है। यह सब बने रहने का सवाल है कि क्या ये सभी पैरामीटर आवश्यक हैं।

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

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

यह देखते हुए कि GMail सभी नियमित क्रियाओं को हटाने और उपयोगकर्ता के लिए दस्तावेज़ों को पूरी तरह से पारदर्शी बनाने में कैसे कामयाब रहा, क्या एमएस वर्ड में भी ऐसा ही किया जा सकता था? बेशक:

- नए दस्तावेजों को बचाने के लिए एक मानक स्थान को परिभाषित करें
- नाम और दस्तावेज़ को स्वचालित रूप से सहेजें
- उपयोगकर्ता को दस्तावेजों का नाम बदलने और स्थानांतरित करने की क्षमता दें

परिणामस्वरूप, उपयोगकर्ता तकनीकी विवरणों से विचलित नहीं होता है:

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

यह केवल अद्भुत है जब आप बाहरी चीजों से विचलित हुए बिना अपने काम पर ध्यान केंद्रित कर सकते हैं।

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

दूसरा उदाहरण: बरसात का दिन

मुझे छाता को भूलने की ज़रूरत नहीं है अगर बारिश की योजना है, जिसके लिए मैं iGoogle पृष्ठ पर मौसम पूर्वानुमान गैजेट का उपयोग करता हूं।

चरण इस प्रकार हैं:

1. सुबह iGoogle की जाँच करें
2. विस्तृत पूर्वानुमान के लिए लिंक पर क्लिक करें, देखें कि किन घंटों में बारिश होने की उम्मीद है
3. दिन के लिए योजना के साथ तुलना करें और तय करें कि छाता लेना है या नहीं।
4. जब मैं बाहर जाता हूं तो छाता के बारे में मत भूलना

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

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

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

सभी जोखिम अब एक ही चरण में छोड़ दिए गए हैं - घर छोड़ने से पहले टैबलेट को देखें।

यदि कोई टैबलेट नहीं है, तो आप स्मार्टफोन का उपयोग कर सकते हैं। रिमाइंडर कब चालू करना है, यह निर्धारित करने में अंतर होगा। आदर्श समय "घर छोड़ने से ठीक पहले" है, लेकिन मेरे मामले में यह उपयुक्त है "जब चार्जर बंद हो जाता है", क्योंकि यह भी छोड़ने से ठीक पहले होता है।

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

निष्कर्ष

उपरोक्त उदाहरण का उपयोग कार्यक्रम की प्रयोज्यता का आकलन करने के लिए "सुरक्षा प्रश्न" बनाने के लिए किया जा सकता है।

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

ऐसे प्रश्न अपने आप में उपयोगी होते हैं, लेकिन वे एक मूल प्रश्न पर आधारित होते हैं:

- काम का कौन सा हिस्सा (कार्यक्रम का उपयोग करते समय) दोहराव, उबाऊ, वैकल्पिक और यांत्रिक के रूप में विशेषता है, और जो रचनात्मक, दिलचस्प और महत्वपूर्ण बना हुआ है?

बेहतर कार्यकाल के अभाव में, मैं पहले भाग को "दिनचर्या" कहता हूं। "रूटीन" उस काम का हिस्सा है जिसे स्वचालित, समाप्त या छिपाया जा सकता है।

इसका बाकी हिस्सा, वास्तव में, वास्तविक काम है - इसका महत्वपूर्ण और / या रचनात्मक घटक। यह वह हिस्सा है जिसके लिए उपयोगकर्ता को सभी उबाऊ, नियमित तत्वों को हटाने के लिए आवश्यक निर्णय लेने और सॉफ़्टवेयर के कार्य करने की आवश्यकता होती है।