अच्छे सॉफ्टवेयर आर्किटेक्चर के लिए मानदंड

क्षमता

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

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

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

• क्षमता;
• लचीलापन;
• विस्तारशीलता;
• मापनीयता;
• परीक्षण योग्यता;
• कोड रखरखाव।

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

आप लगातार ऐसे कार्यक्रमों से रूबरू होंगे जो वह नहीं करते जो वे करने का दावा करते हैं।

• लिब्रे ऑफिस माइक्रोसॉफ्ट ऑफिस (वास्तव में नहीं) के लिए एक पूर्ण प्रतिस्थापन है;
• एज ब्राउज़र सभी वेब मानकों का समर्थन करता है (वास्तव में नहीं);
• बैंक अपने उपयोगकर्ताओं के व्यक्तिगत डेटा की सुरक्षा की परवाह करता है (वास्तव में नहीं)।

और हमने अभी तक प्रदर्शन, विश्वसनीयता, समय पर बग फिक्स या ज्ञात कमजोरियों के बारे में जानकारी के प्रकाशन को नहीं छुआ है।

यह स्पष्ट है कि कोई भी पूर्ण नहीं है, लेकिन कार्यक्रम को अपने प्राथमिक कार्यों को हल करना चाहिए। इसलिए, दक्षता के बिना कहीं नहीं।

FLEXIBILITY

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

बहुत बार, नौसिखिए प्रोग्रामर / आर्किटेक्ट सोचते हैं कि उन्हें वर्तमान कार्यों के लिए एक आदर्श वास्तुकला की आवश्यकता है। नहीं। आपको एक वर्ष में घोषित किए जाने वाले कार्यों के लिए एक आदर्श वास्तुकला की आवश्यकता है। आप, पहले से ही अब भविष्य के कार्यों को नहीं जानते हैं, आपको पता होना चाहिए कि वे क्या होंगे।

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

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

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

इनमें से एक दृष्टिकोण एप्लिकेशन को माइक्रोसर्विसेज में विभाजित कर रहा है: पहले से मौजूद लॉजिक को अलग-अलग हिस्सों में तोड़ना आसान है। लेकिन सबसे बड़ी समस्या एक छोटी सी सुविधा को लागू करने के लिए एक बार में दर्जनों सेवाओं में भविष्य में बदलाव करना है।

अनुमापकता

स्केलेबिलिटी परियोजना में नए लोगों को जोड़कर विकास के समय को कम करने की क्षमता है। वास्तुकला को विकास प्रक्रिया को समानांतर करने की अनुमति देनी चाहिए ताकि एक ही समय में कई लोग कार्यक्रम पर काम कर सकें।

ऐसा लगता है कि यह नियम अपने आप ही लागू हो जाता है, लेकिन व्यवहार में सब कुछ ठीक इसके विपरीत होता है। यहाँ तक कि एक सुपर-लोकप्रिय पुस्तक, द मिथिकल मैन-मंथ भी है , जो बताती है कि जब किसी परियोजना में नए लोगों को जोड़ा जाता है, तो विकास का समय क्यों बढ़ जाता है।

विस्तार

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

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

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

दूसरे शब्दों में: सिस्टम के मौजूदा हिस्सों को फिर से लिखे बिना सिस्टम के व्यवहार को बदलना और विस्तारित करना संभव होना चाहिए ।

इसका मतलब यह है कि एप्लिकेशन को इस तरह से डिज़ाइन किया जाना चाहिए कि इसके व्यवहार को बदलने और नई कार्यक्षमता जोड़ने से मौजूदा कोड को बदले बिना नया कोड (एक्सटेंशन) लिखकर हासिल किया जा सके।

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

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

यह फ़िल्टर (सर्विस सर्वलेट्स) की अवधारणा का आविष्कार था जिसने विभिन्न सेवा कार्यों को एक अलग परत में स्थानांतरित करना संभव बना दिया। और भविष्य में, फ़िल्टर के व्यवहार को बदलते समय, सर्वलेट्स को बदलना आवश्यक नहीं था।

फ़िल्टर के आविष्कार से पहले, अनुरोधों को पुनर्निर्देशित करने के लिए जिम्मेदार सभी सेवा तर्क स्वयं सर्वलेट्स में स्थित थे। और अक्सर तर्क में एक छोटे से परिवर्तन से सभी सर्वलेटों के माध्यम से जाने और सभी में विभिन्न परिवर्तन करने की आवश्यकता होती है।

परीक्षण योग्यता

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

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

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

नौसिखिए पूछेंगे, "अगर कोड काम करता है तो हमें परीक्षणों की आवश्यकता क्यों है?"

"हमें कार्य कोड की आवश्यकता क्यों है यदि इसका परीक्षण नहीं किया जा सकता है?", पेशेवर पूछेगा।

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

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

परीक्षणों के आधार पर कार्यक्रम विकसित करने की एक पूरी पद्धति है, जिसे टेस्ट-संचालित विकास (टीडीडी) कहा जाता है। यह निश्चित रूप से दूसरा चरम है: कोड लिखने से पहले कोड लिखें।

कोड रखरखाव

एक नियम के रूप में, बहुत से लोग कार्यक्रम पर काम करते हैं - कुछ छोड़ देते हैं, नए आते हैं। एक आईटी कंपनी में एक प्रोग्रामर का औसत कार्य समय डेढ़ वर्ष होता है। इसलिए अगर आप किसी ऐसे प्रोजेक्ट पर आए हैं जो 5 साल पुराना है, तो शुरुआत से ही आपके केवल 20% सहयोगियों ने उस पर काम किया।

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

इसलिए, एक अच्छे आर्किटेक्चर को नए लोगों के लिए सिस्टम को समझना अपेक्षाकृत आसान और त्वरित बनाना चाहिए । परियोजना होनी चाहिए:

• अच्छी तरह से संरचित।
• दोहराव शामिल नहीं है।
• अच्छी तरह से स्वरूपित कोड है।
• दस्तावेज़ शामिल करना वांछनीय है।
• प्रोग्रामर के लिए मानक और परिचित समाधान लागू करना आवश्यक है।

आप जिस प्रोजेक्ट पर काम कर रहे हैं, उसे आप 5-पॉइंट सिस्टम पर आसानी से रेट कर सकते हैं । इनमें से प्रत्येक आवश्यकता के लिए बस दो अंक गिनें । और अगर आपको 5 या अधिक मिलते हैं, तो आप भाग्यशाली हैं।

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