तीन प्रमुख सॉफ्टवेयर सिद्धांतों को आपको समझने की आवश्यकता है

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

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

DRY - अपने आप को दोहराएं नहीं

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

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

जटिलता को कम करने का सबसे आसान तरीका सिस्टम को प्रबंधनीय भागों में विभाजित करना है।

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

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

DRY सिद्धांत की आवश्यकता है कि जानकारी के ऐसे टुकड़े आपके कोड में एक बार दिखाई दें, और केवल एक बार।

इन भागों में एक विचार होना चाहिए।

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

डेटा के प्रत्येक टुकड़े में सिस्टम का एक स्पष्ट, विश्वसनीय दृष्टिकोण होना चाहिए।

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

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

वास्तुकला का कार्य जटिलता का प्रबंधन करना है

दोहराना बंद करो

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

DRY एक दर्शन है जो तर्क को निरूपण में तोड़ता है।

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

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

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

यदि अचानक आप खुद को पकड़ लेते हैं कि आपने पहले ही इस कोड को लिखा / मिला है, तो रोकें, सोचें, और खुद को दोहराएं नहीं।

वास्तविक परियोजनाओं में, 100% DRY प्राप्त करना लगभग असंभव है। लेकिन, बदले में, ऐसी कई परियोजनाएं हैं जो अस्वीकार्य स्तर पर गैर-डीआरवाई हैं, और जिन्हें प्रबंधित करना मुश्किल है। और शायद यह आपके लिए एक आश्चर्य के रूप में आएगा - यदि आप उनके कोड को देखते हैं तो हमारी सभी परियोजनाओं में से 50% विफल हो जाती हैं।

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

उदाहरण

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

शायद ही बुरा कोड खराब प्रोग्रामर द्वारा लिखा जाता है।

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

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

DRY सहयोगी योजना द्वारा प्राप्त किया जाता है।

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

और प्रोग्रामर जो श्रृंखला में अंतिम हैं, सिस्टम में त्रुटियों को जल्दी से ठीक करने के लिए बाध्य हैं। यदि वे ऐसे अकाउंटेंट के साथ सीज किए जाते हैं जो ग्राहक की हर मिनट का सामना करने में सक्षम नहीं हैं, तो सारी योजना नरक में चली जाती है और खराब, बहुत बुरा कोड लिखा जाता है। कोड अब DRY नहीं है।

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

यदि आपसे पूछा जाए कि आपको अपनी नाक को नहीं टटोलना है जहाँ आपको ज़रूरत नहीं है, तो पढ़ें - YAGNI सिद्धांत आपको बचाएगा!

KISS - (आसान बनाने के बातें) रखने के यह सरल बेवकूफ

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

अक्सर सबसे सरल स्पष्टीकरण सबसे सही समाधान है।

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

और इसी तरह की अवधारणाएं कई क्षेत्रों में पाई जाती हैं। सॉफ्टवेयर विकास (और कुछ अन्य) में, हम यह KISS कहते हैं। इस परिचित के कई अर्थ हैं, लेकिन वे सभी एक बात पर आते हैं - आपको चीजों को यथासंभव सरल बनाने की कोशिश करनी चाहिए।

मानव इतिहास में अधिकांश प्रगति असाधारण विचारकों की बदौलत हुई है।

HTTP

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

चीजों को आसान बनाने का दृष्टिकोण बहुत स्पष्ट है, लेकिन सॉफ्टवेयर विकास का इतिहास विभिन्न बुरे, कच्चे निर्णयों से भरा है। उन्हें अक्सर एक अलग शब्द कहा जाता है - ब्लोटवेयर, या डीओए (आगमन पर मृत) - जन्म के समय मृत। ऐसे सॉफ़्टवेयर के सापेक्ष, आप गैर-DRY कोड के सिद्धांत के समान एक सिद्धांत लागू कर सकते हैं ... फिर भी, इंटरनेट की सफलता को सरल, प्रभावी समाधानों द्वारा समझाया जा सकता है।

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

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

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

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

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

आपको इसकी आवश्यकता नहीं है - आपको इसकी आवश्यकता नहीं होगी

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

मैं प्रोग्रामिंग कर रहा हूं। मैं चीजों का निर्माण करता हूं।

सिद्धांत "आपको इसकी आवश्यकता नहीं है" (YAGNI) ऐसी समस्याओं को हल करने के लिए बनाया गया है।

इसका मतलब यह है कि सिस्टम में जो इरादा नहीं है वह कोड में नहीं दिखाई देना चाहिए। उदाहरण के लिए, डेटाबेस में अक्सर पहुंच एक अमूर्त के माध्यम से होती है, जिसमें विभिन्न ड्राइवरों के लिए कार्यान्वयन हो सकता है - MySQL, PostgreSQL, Oracle। यदि आप LAMP स्टैक पर होस्ट की गई साइट पर काम कर रहे हैं, तो क्या संभावना है कि क्लाइंट डेटाबेस को बदल देगा? यह मत भूलो कि अवधारणा हमेशा बजट के तहत लिखी जाती है - सही है?

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

आपने YAGNI और DRY सिस्टम के बीच अंतर देखा होगा। बाद को सिस्टम को प्रबंधनीय घटकों में विभाजित करके जटिलता को कम करने के लिए डिज़ाइन किया गया है, जबकि पूर्व इन घटकों की संख्या को कम करके जटिलता को कम करता है। YAGNI सिद्धांत को चूमने के लिए इसी तरह की है - वह यथासंभव आसान चीजें बनाने के लिए कोशिश करता है। लेकिन KISS सरल समाधान के लिए देखने के लिए कोशिश करता है और YAGNI बस किसी भी निर्णय लेने के लिए नहीं है!

एक अमेरिकी विज्ञान कथा लेखक, थियोडोर स्टर्जन, ने कानून को आगे रखा - "90% सब कुछ पूर्ण बकवास है।" काफी मौलिक कथन, और वास्तविक परियोजनाओं में हमेशा लागू नहीं होता है। यह मत भूलो कि "बकवास" में बहुत समय लग सकता है। एक अलिखित नियम है: विकास का लगभग 80% समय प्रणाली की कार्यक्षमता के केवल 20% के कार्यान्वयन पर खर्च किया जाता है। अपनी परियोजनाओं को याद रखें। जब भी मैं अपनी समीक्षा करता हूं, मैं लगातार देखता हूं कि 80/20 नियम कैसे काम करता है।

विकास पर खर्च होने वाले समय का 80% सिस्टम की कार्यक्षमता के केवल 20% के कार्यान्वयन पर खर्च किया जाता है।

यह रणनीति एक कंपनी में बहुत अच्छी तरह से लागू होती है जिसमें यह बहुत स्पष्ट अवधारणाओं के साथ मिश्रित समय सीमा का पालन करने के लिए प्रथागत है। कोई भी आपके DB अमूर्त की सराहना नहीं करेगा। यहां तक ​​कि एक मौका है कि आपके बॉस को पता नहीं है कि डेटाबेस एब्सट्रैक्शन क्या है।

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

परियोजना की योजना

एक नई परियोजना की योजना बनाते समय, निम्नलिखित पर विचार करें:

• गर्भपात के स्तर को कम करके कम जटिलता प्राप्त करें
• सुविधाओं से अलग कार्यक्षमता
• छोटी गैर-कार्यात्मक आवश्यकताओं को ध्यान में रखें
• इनसे छुटकारा पाने के लिए समय लेने वाले कार्यों को पहचानें

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

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

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

खराब अवधारणाओं को अक्सर गैर-कार्यात्मक आवश्यकताओं की अनुपस्थिति से पहचाना जा सकता है।

गैर-कार्यात्मक आवश्यकताएं सिस्टम के व्यवहार का वर्णन नहीं करती हैं, वे अतिरिक्त गुणों का वर्णन करती हैं जिनका उपयोग उत्पाद की गुणवत्ता का मूल्यांकन करने के लिए किया जा सकता है। क्योंकिगुणवत्ता के विवरण में उत्पाद के ज्ञान की आवश्यकता होती है, खराब अवधारणाओं को अक्सर गैर-कार्यात्मक आवश्यकताओं की अनुपस्थिति से पहचाना जा सकता है। समर्थन करने की क्षमता, प्रलेखन का स्तर, एकीकरण में आसानी गैर-कार्यात्मक आवश्यकताओं के सभी उदाहरण हैं। इन आवश्यकताओं को मापने योग्य होना चाहिए। यानी"साइट को जल्दी से लोड करना चाहिए" बहुत सामान्यीकृत है, लेकिन "साइट को प्रदर्शन परीक्षण के दौरान 2 सेकंड में लोड करना चाहिए" बहुत ही ठोस और स्पष्ट है। यदि आप YAGNI दृष्टिकोण को लागू करना चाहते हैं, तो कुछ गैर-कार्यात्मक आवश्यकताओं को ध्यान में रखने की कोशिश करें, भले ही उन्हें अवधारणा में ध्यान में न रखा जाए (या ध्यान में रखा गया हो, लेकिन बहुत स्पष्ट नहीं है)। जब आप ऐसी आवश्यकता लिखते हैं, तो यथार्थवादी बनें - प्रति दिन 20-50 यात्राओं वाली एक छोटी साइट को तीन-दिन के प्रदर्शन ट्यूनिंग की आवश्यकता नहीं होती है, क्योंकि साइट जल्दी से लोड होगी और इसलिए यदि सर्वर ओवरलोड नहीं है। यहां तक ​​कि अगर कोई कंपनी अपनी उपस्थिति बढ़ा सकती है, तो अधिक शक्तिशाली होस्टिंग खरीदना एक समस्या नहीं होनी चाहिए।

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

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

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

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

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

निष्कर्ष

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