चांगल्या सॉफ्टवेअर आर्किटेक्चरसाठी निकष

कार्यक्षमता

अनुभवी प्रोग्रॅमर चांगल्या वास्तूचे वाईट ते सहज सांगू शकतात, परंतु जर त्यांना काही शब्दांत वर्णन करायचे म्हटले तर ते तसे करू शकतील अशी शक्यता नाही. चांगल्या वास्तुकलेचा एकच निकष नाही आणि एकच व्याख्या नाही.

तथापि, आपण याबद्दल विचार केल्यास, आपण अनेक निकष लिहू शकता जे चांगल्या वास्तुकला पूर्ण करतात. एक चांगली आर्किटेक्चर , सर्वप्रथम, एक तार्किक आर्किटेक्चर आहे जी प्रोग्राम विकसित करण्याची आणि देखरेख करण्याची प्रक्रिया सुलभ आणि अधिक कार्यक्षम करते.

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

• कार्यक्षमता;
• लवचिकता;
• विस्तारक्षमता;
• स्केलेबिलिटी;
• चाचणीक्षमता
• कोड राखण्याची क्षमता.

प्रणाली कार्यक्षमता. प्रोग्रामने, अर्थातच, नियुक्त केलेल्या कार्यांचे निराकरण केले पाहिजे आणि त्याची कार्ये चांगल्या प्रकारे आणि विविध परिस्थितीत पार पाडली पाहिजेत. असे दिसते की कोणताही प्रोग्राम जे केले पाहिजे ते करतो (जर ते लिहिलेले असेल), परंतु बहुतेकदा असे होत नाही.

तुम्ही सतत असे कार्यक्रम पहाल जे ते करत असल्याचा दावा करत नाहीत.

• लिबर ऑफिस हे मायक्रोसॉफ्ट ऑफिससाठी पूर्ण बदली आहे (खरोखर नाही);
• एज ब्राउझर सर्व वेब मानकांना समर्थन देतो (खरोखर नाही);
• बँक आपल्या वापरकर्त्यांच्या वैयक्तिक डेटाच्या सुरक्षिततेची काळजी घेते (वास्तविक नाही).

आणि आम्ही अद्याप कार्यप्रदर्शन, विश्वासार्हता, वेळेवर दोष निराकरणे किंवा ज्ञात असुरक्षांबद्दल माहितीच्या प्रकाशनाला स्पर्श केलेला नाही.

हे स्पष्ट आहे की कोणीही परिपूर्ण नाही, परंतु प्रोग्रामने त्याची प्राथमिक कार्ये सोडविली पाहिजेत. म्हणून, कार्यक्षमतेशिवाय, कोठेही नाही.

लवचिकता

माझ्या मते कार्यक्षमतेपेक्षा महत्त्वाची एकमेव गोष्ट म्हणजे लवचिकता. कोणताही अनुप्रयोग वेळोवेळी बदलला पाहिजे, आवश्यकता बदलल्याप्रमाणे, नवीन जोडले जातात. विद्यमान कार्यक्षमतेमध्ये बदल करणे जितके जलद आणि अधिक सोयीस्कर असेल, त्यामुळे कमी समस्या आणि त्रुटी निर्माण होतील, सिस्टम आर्किटेक्चर अधिक लवचिक असेल .

बर्‍याचदा, नवशिक्या प्रोग्रामर / वास्तुविशारदांना असे वाटते की त्यांना सध्याच्या कार्यांसाठी एक आदर्श आर्किटेक्चर आवश्यक आहे. नाही. वर्षभरात तुम्हाला जाहीर होणार्‍या कामांसाठी तुम्हाला एक आदर्श वास्तुरचना हवी आहे. तुम्हाला, आधीच भविष्यातील कार्ये माहित नसताना, ते काय असतील हे माहित असले पाहिजे.

त्यांचा अंदाज लावण्याचा प्रयत्न करण्यात काही अर्थ नाही, कारण नेहमीच काहीतरी अनपेक्षित असेल. परंतु आपण हे लक्षात घेतले पाहिजे की अशी कार्ये दिसून येतील. म्हणून, विकास प्रक्रियेत, ते कसे बदलणे आवश्यक आहे या दृष्टीने काय प्राप्त केले जात आहे याचे मूल्यांकन करण्याचा प्रयत्न करा.

स्वतःला विचारा: "सध्याचा वास्तुशास्त्रीय निर्णय चुकीचा ठरला तर काय होईल?", "कोड किती बदलला जाईल?". सिस्टमचा एक तुकडा बदलल्याने त्याच्या इतर तुकड्यांवर परिणाम होऊ नये.

जेव्हा शक्य असेल तेव्हा, स्थापत्यविषयक निर्णय दगडात ठेवू नयेत आणि वास्तुशास्त्रीय त्रुटींचे परिणाम वाजवी मर्यादित असावेत. "चांगले आर्किटेक्चर तुम्हाला मुख्य निर्णय घेण्यास विलंब करण्यास अनुमती देते" (बॉब मार्टिन) आणि चुकांची "किंमत" कमी करते.

या पद्धतींपैकी एक म्हणजे ऍप्लिकेशनला मायक्रोसर्व्हिसेसमध्ये विभाजित करणे: आधीपासून अस्तित्वात असलेले तर्क वेगळे भागांमध्ये खंडित करणे सोपे आहे. परंतु सर्वात मोठी समस्या म्हणजे भविष्यातील एक डझन सेवांमध्ये एकाच वेळी एक लहान वैशिष्ट्य लागू करण्यासाठी बदल करणे.

स्केलेबिलिटी

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

असे दिसते की हा नियम स्वतःच चालतो, परंतु सराव मध्ये सर्वकाही अगदी उलट आहे. द मिथिकल मॅन-मंथ हे एक सुपर-लोकप्रिय पुस्तक देखील आहे , जे एखाद्या प्रकल्पात नवीन लोक जोडले जातात तेव्हा विकासाची वेळ का वाढते हे स्पष्ट करते.

विस्तारक्षमता

एक्स्टेंसिबिलिटी ही प्रणालीची मूळ रचना न मोडता नवीन वैशिष्ट्ये आणि घटक जोडण्याची क्षमता आहे. सुरुवातीच्या टप्प्यावर, सिस्टममध्ये फक्त मूलभूत आणि सर्वात आवश्यक कार्यक्षमता ठेवणे अर्थपूर्ण आहे.

हे तथाकथित यज्ञ तत्व आहे - तुम्हाला त्याची गरज नाही , "तुम्हाला याची गरज नाही". त्याच वेळी, आर्किटेक्चरने आपल्याला आवश्यकतेनुसार अतिरिक्त कार्यक्षमता सहजपणे वाढविण्याची परवानगी दिली पाहिजे. आणि म्हणून सर्वात संभाव्य बदलांच्या परिचयासाठी कमीतकमी प्रयत्न करणे आवश्यक आहे.

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

दुसऱ्या शब्दांत: सिस्टमचे विद्यमान भाग पुन्हा न लिहिता सिस्टमचे वर्तन बदलणे आणि वाढवणे शक्य असावे .

याचा अर्थ असा की अॅप्लिकेशन अशा प्रकारे डिझाइन केले पाहिजे की त्याचे वर्तन बदलणे आणि नवीन कार्यक्षमता जोडणे हे विद्यमान कोड न बदलता नवीन कोड (विस्तार) लिहून प्राप्त केले जाईल.

या प्रकरणात, नवीन आवश्यकतांच्या उदयामुळे विद्यमान तर्कशास्त्रात बदल करणे आवश्यक नाही, परंतु ते प्रामुख्याने विस्तारित करून लागू केले जाऊ शकते. हे तत्त्व "प्लग-इन आर्किटेक्चर" (प्लगइन आर्किटेक्चर) चा आधार आहे. ज्या तंत्रांद्वारे हे साध्य केले जाऊ शकते त्याबद्दल नंतर चर्चा केली जाईल.

सर्व्हलेट्स आणि फिल्टर्स आठवतात? फिल्टर्सची गरज का होती, आणि अगदी वेगळ्या इंटरफेससह, खरं तर, सर्व समान तर्कशास्त्र सर्व्हलेट्स वापरून लागू केले जाऊ शकते?

फिल्टर्स (सर्व्हिस सर्व्हलेट्स) च्या संकल्पनेचा हा शोध होता ज्यामुळे विविध सेवा कार्ये वेगळ्या स्तरावर हलवणे शक्य झाले. आणि भविष्यात, फिल्टरचे वर्तन बदलताना, सर्व्हलेट्स बदलणे आवश्यक नव्हते.

फिल्टरचा शोध लागण्यापूर्वी, विनंत्या पुनर्निर्देशित करण्यासाठी जबाबदार असलेले सर्व सेवा तर्क स्वतः सर्व्हलेट्समध्ये स्थित होते. आणि बर्‍याचदा तर्कशास्त्रातील एक छोटासा बदल सर्व सर्व्हलेटमधून जाण्याची आणि सर्वांमध्ये विविध बदल करण्याची गरज निर्माण करतो.

चाचणीक्षमता

तुम्ही जावा बॅकएंड डेव्हलपर असल्यास, तुमचे सर्व्हर अॅप्लिकेशन अनेकदा REST API म्हणून पद्धतींचा संच उघड करतात. आणि तुमच्या सर्व पद्धती इच्छेनुसार कार्य करतात हे तपासण्यासाठी, त्यांना चाचण्यांसह संरक्षित करणे आवश्यक आहे.

सर्वसाधारणपणे, API चाचणी कव्हरेज एक चांगली शैली आहे. हे तुम्हाला हे सुनिश्चित करण्यास अनुमती देते की तुमचे API खरोखर जे करायचे होते तेच करते. आणि सर्वात महत्त्वाचे म्हणजे, तुम्ही सर्व्हर लॉजिकमध्ये बदल करू शकता आणि तुम्ही चुकून काहीही तोडले नाही हे सहजपणे तपासू शकता .

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

"कोड कार्य करत असल्यास आम्हाला चाचण्यांची आवश्यकता का आहे?", नवशिक्या विचारेल.

"जर त्याची चाचणी करता येत नसेल तर आम्हाला वर्किंग कोडची आवश्यकता का आहे?", व्यावसायिक विचारेल.

चाचणी करणे सोपे असलेल्या कोडमध्ये कमी दोष असतील आणि ते अधिक विश्वासार्ह असतील. परंतु चाचण्या केवळ कोड गुणवत्ता सुधारत नाहीत. जवळजवळ सर्व विकासक शेवटी निष्कर्षापर्यंत पोहोचतात की "चांगली चाचणीक्षमता" ची आवश्यकता देखील एक मार्गदर्शक शक्ती आहे जी आपोआप चांगल्या डिझाइनकडे नेत आहे.

आयडियल आर्किटेक्चर या पुस्तकातील एक कोट येथे आहे: “क्लासच्या “टेस्टेबिलिटी” या तत्त्वाचा वापर चांगल्या क्लास डिझाइनची “लिटमस टेस्ट” म्हणून करा. जरी तुम्ही चाचणी कोडची एक ओळ लिहिली नाही तरीही, या प्रश्नाचे उत्तर 90 मध्ये द्या. % प्रकरणे त्याच्या डिझाइनसह सर्वकाही कसे चांगले" किंवा "वाईट" हे समजण्यास मदत करेल.

चाचण्यांवर आधारित कार्यक्रम विकसित करण्यासाठी एक संपूर्ण कार्यपद्धती आहे, ज्याला चाचणी-चालित विकास (TDD) म्हणतात. हे अर्थातच दुसरे टोक आहे: कोड लिहिण्यापूर्वी कोड लिहा.

कोड राखण्याची क्षमता

नियमानुसार, बरेच लोक प्रोग्रामवर काम करतात - काही सोडतात, नवीन येतात. आयटी कंपनीत प्रोग्रामरचा सरासरी कामाचा कालावधी दीड वर्ष असतो. म्हणून जर तुम्ही 5 वर्षे जुन्या प्रकल्पावर आलात, तर तुमच्या फक्त 20% सहकाऱ्यांनी सुरुवातीपासूनच त्यावर काम केले.

इतरांनी लिहिलेला प्रोग्राम राखणे आणि विकसित करणे खूप कठीण आहे. जरी प्रोग्राम आधीच लिहिलेला असला तरीही, तो कायम ठेवणे आवश्यक आहे: त्रुटी दूर करा आणि किरकोळ दुरुस्त्या करा. आणि बहुतेकदा हे अशा लोकांना करावे लागते ज्यांनी ते लिहिण्यात भाग घेतला नाही.

म्हणून, चांगल्या वास्तुकला नवीन लोकांना प्रणाली समजणे तुलनेने सोपे आणि जलद बनवते . प्रकल्प असा असावा:

• चांगली रचना.
• डुप्लिकेशन समाविष्ट करू नका.
• चांगले स्वरूपित कोड ठेवा.
• कागदपत्रे समाविष्ट करणे इष्ट आहे.
• प्रोग्रामरसाठी मानक आणि परिचित उपाय लागू करणे आवश्यक आहे.

तुम्ही 5-पॉइंट स्केलवर काम करत असलेल्या प्रोजेक्टला तुम्ही सहजपणे रेट करू शकता . या प्रत्येक गरजांसाठी फक्त दोन गुण मोजा . आणि जर तुम्हाला 5 किंवा अधिक मिळाले तर तुम्ही भाग्यवान आहात.

प्रोग्रामरकडे किमान आश्चर्याचा सिद्धांत देखील आहे : प्रणाली जितकी अधिक विदेशी असेल तितकी इतरांना समजणे अधिक कठीण आहे. सहसा, हे वापरकर्ता इंटरफेसच्या संबंधात वापरले जाते, परंतु ते कोड लिहिण्यासाठी देखील लागू होते.