खराब सॉफ्टवेअर आर्किटेक्चरसाठी निकष

खराब डिझाइनसाठी निकष

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

बर्‍याच प्रोग्रामरना सिस्टमच्या काही भागांचा अनुभव आला आहे जे खराब डिझाइन केलेले आहेत. पण त्याहूनही खेदाची गोष्ट म्हणजे, अशा व्यवस्थेचे आपणच लेखक आहोत हे कळण्याचा दुःखद अनुभव तुमच्यापैकी बहुतेकांना असेल. आम्हाला सर्वोत्कृष्ट हवे होते, परंतु ते नेहमीप्रमाणेच झाले.

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

"खराब" डिझाइनची व्याख्या नसणे हे या समस्येचे मूळ आहे.

मला असे वाटते की डिझाइनची गुणवत्ता आणि त्याच्या "क्षय" ची कारणे समजून घेणे हे कोणत्याही प्रोग्रामरसाठी सर्वात महत्वाचे गुण आहेत. इतर बर्‍याच प्रकरणांप्रमाणे, मुख्य गोष्ट ही समस्या ओळखणे आहे आणि ती सोडवणे ही तंत्रज्ञानाची बाब असेल.

"खराब डिझाइन" ची व्याख्या

जर तुम्ही एखाद्या सहकारी प्रोग्रामरसमोर तुमच्या कोडबद्दल फुशारकी मारण्याचे ठरवले, तर तुमची बहुधा उपहास होईल: “हे कोण करते?”, 'असे का आहे?' आणि "मी गोष्टी वेगळ्या पद्धतीने करेन." हे खूप वेळा घडते.

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

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

खराब डिझाइन:

• बदलणे अवघड आहे कारण कोणताही बदल सिस्टीमच्या इतर अनेक भागांना प्रभावित करतो. ( कडकपणा , कडकपणा).
• जेव्हा बदल केले जातात, तेव्हा सिस्टमचे इतर भाग अनपेक्षितपणे खंडित होतात. ( नाजूकपणा , नाजूकपणा).
• कोड दुसर्‍या ऍप्लिकेशनमध्ये पुन्हा वापरणे कठीण आहे कारण तो सध्याच्या ऍप्लिकेशनमधून बाहेर काढणे खूप कठीण आहे. ( अचलता , अचलता).

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

अशा प्रकारे, डिझाइन "वाईट" किंवा "चांगले" आहे की नाही हे स्पष्टपणे निर्धारित करण्यासाठी आपण या तीन वैशिष्ट्यांचा वापर करू शकतो.

"खराब डिझाइन" ची कारणे

कशामुळे डिझाइन कठोर, ठिसूळ आणि अचल बनते? मॉड्यूल्सचे कठोर परस्परावलंबन.

एखादे डिझाइन कठोर असते जर ते सहजपणे बदलले जाऊ शकत नाही. ही कडकपणा या वस्तुस्थितीमुळे आहे की विणलेल्या प्रणालीमध्ये कोडच्या तुकड्यात एकच बदल केल्याने अवलंबून असलेल्या मॉड्यूल्समध्ये कॅस्केडिंग बदल होतात. जेव्हा एखादी व्यक्ती कोडवर काम करत असते तेव्हा हे नेहमी घडते.

हे तत्काळ संपूर्ण व्यावसायिक विकास प्रक्रिया गुंतागुंतीचे करते: जेव्हा कॅस्केडिंग बदलांची संख्या डिझायनर किंवा विकासकाद्वारे सांगता येत नाही, तेव्हा अशा बदलाच्या परिणामाचा अंदाज लावणे अशक्य आहे. म्हणून, ते असे बदल अनिश्चित काळासाठी पुढे ढकलण्याचा प्रयत्न करतात.

आणि यामुळे बदलाची किंमत अप्रत्याशित होते. अशा अनिश्चिततेचा सामना करताना, व्यवस्थापक बदल करण्यास नाखूष असतात, म्हणून डिझाइन अधिकृतपणे कठोर बनते.

काही क्षणी, तुमचा प्रकल्प "इव्हेंट क्षितीज" पार करतो आणि कठोर आर्किटेक्चरच्या "ब्लॅक होल" मध्ये पडणे नशिबात आहे.

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

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

जेव्हा एखाद्या प्रकल्पाची रचना नाजूक असते तेव्हा विकासक उत्पादनाच्या गुणवत्तेची हमी देऊ शकत नाहीत.

ऍप्लिकेशनच्या एका भागात साध्या बदलांमुळे इतर असंबंधित भागांमध्ये बग येतात. या चुका दुरुस्त केल्याने आणखी समस्या निर्माण होतात आणि एस्कॉर्ट प्रक्रिया प्रसिद्ध कुत्र्यामध्ये स्वतःच्या शेपटीचा पाठलाग करते.

जेव्हा सिस्टमचे आवश्यक भाग इतर अवांछित तपशीलांशी जोरदारपणे जोडलेले असतात तेव्हा डिझाइन स्थिर असते . त्यांचे स्वतःचे कोड, त्यांचे स्वतःचे अनन्य पध्दती आणि उपाय.

तुम्हाला JUL लॉगर आठवतो का, ज्याचे विकसक कोणतेही कारण नसताना त्यांचे स्वतःचे लॉगिंग स्तर घेऊन आले होते? हे फक्त प्रकरण आहे.

डिझायनरला विद्यमान डिझाइनचा पुनर्वापर करणे किती सोपे आहे याची कल्पना देण्यासाठी, नवीन अनुप्रयोगामध्ये वापरणे किती सोपे आहे याचा विचार करणे पुरेसे आहे.

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

प्रासंगिकता

सर्व काही बदलते, परंतु सर्व काही तसेच राहते. (चीनी म्हण)

वर खूप चांगले प्रश्न उपस्थित केले आहेत. नाजूक आणि कठोर प्रणालींचे धोके काय आहेत? होय, कारण अशा प्रकल्पाचे व्यवस्थापन करण्याची प्रक्रिया अप्रत्याशित आणि अनियंत्रित होते. आणि किंमत कमालीची आहे.

एखाद्या व्यवस्थापकाला काही वैशिष्ट्य जोडण्यासाठी पुढे जाण्यासाठी किती वेळ लागेल हे माहित नसल्यास ते कसे देऊ शकतात किंवा देऊ शकत नाहीत? जर तुम्ही त्यांच्या अंमलबजावणीचा वेळ आणि गुंतागुंतीचा पुरेसा अंदाज घेऊ शकत नसाल तर कार्यांना प्राधान्य कसे द्यावे?

आणि विकासक तेच तांत्रिक कर्ज कसे फेडतील जेव्हा आम्ही ते भरणार आहोत, आणि आम्ही रेक करेपर्यंत आम्ही किती कर्ज काढू हे समजू शकत नाही?

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

या प्रकरणासाठी बॉब मार्टिनचे एक कोट येथे आहे: "तुमचा कोड पुन्हा वापरण्यासाठी, तुम्हाला सुरवातीपासून विकसित करण्याच्या खर्चापेक्षा कमी पुनर्वापर करण्याचा प्रयत्न करणे आवश्यक आहे . " अन्यथा, या प्रकरणाला कोणीही जुमानणार नाही.

डिझाइन तत्त्वे आणि नमुने यांचा वापर एक उद्देश पूर्ण करतो - डिझाइन चांगले बनवणे. जर त्यांचा वापर तुम्हाला कोणताही फायदा देत नसेल (किंवा त्याउलट, "चांगल्या डिझाइन" च्या तत्त्वांचे उल्लंघन करत असेल), तर तुमच्या कंझर्व्हेटरीमध्ये काहीतरी योग्य नाही आणि कदाचित, साधन इतर हेतूंसाठी वापरण्यास सुरुवात झाली आहे.