वहाँ वास्तुकला गंध हैं?

Question

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

संपादित करें: मैं वास्तव में उत्तरों में एक सूची की तलाश नहीं कर रहा था, लेकिन वास्तुकला की गंध के बारे में प्रलेखन (वेब ​​पर या किताब में)।

Comments

केवल जब आर्किटेक्ट की व्यक्तिगत स्वच्छता की आदतें खराब होती हैं ...

— FrustratedWithFormsDesigner

मैं वास्तव में यहाँ गंध की सूची के लिए y'all का मतलब नहीं था। शायद एक सूची में लिंक?

— सी। रॉस

रॉस माफ करना मुझे एहसास नहीं था। मैंने अभी कुछ अनुभव जोड़े हैं।

— आमिर रज़ाई

@Amir रीज़ाई तुम्हारा सबसे अच्छा है, कम से कम आपने अपनी सूची को एक पोस्ट में समेकित किया है।

— सी। रोस।

आर्किटेक्चर एस्ट्रोनाटस

— लैवि

Answer 1

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

विपरीत का कुल अभाव भी सत्य है।

यहां टॉप टेन सॉफ्टवेयर आर्किटेक्चर मिस्टेक्स का लिंक दिया गया है ।

Comments

मैं इस पर सहमत हूं, मैंने बेतुका स्तरित आवेदन (9 परतों तक) देखा है

बकलव वास्तुकला?

— एंड्रयू अर्नोल्ड

आह, स्पेगेटी कोड के करीबी रिश्तेदार, मुझे यह '

— लासंगना

ऊह @GSto - लासगना वास्तुकला में स्पेगेटी कोड। पूर्ण पहनावा को "छोटा इटली" कहा जा सकता है।

— ग्लेनट्रॉन

कुछ स्थानों में application_layers == (Developers_assigned - 1) क्योंकि कोई व्यक्ति पीएम होने के नाते समाप्त होता है।

— साल

Answer 2

सब कुछ कॉन्फ़िगर करने योग्य है । जब एक वास्तुकार आपको बताता है कि व्यापक विन्यास के कारण उसका सिस्टम परिवर्तन-सबूत या उच्च-अनुकूलन योग्य है, तो यह एक वास्तुकला गंध है।

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

और फिर आप सॉफ्टवेयर नरक में हैं।

Comments

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

— ग्लेनट्रॉन

@glenatron: शायद यही बात है? क्यों न सिर्फ तौलिया फेंक दिया जाए और मान लिया जाए कि यह होने वाला है। फिर आप अपने DSL के साथ विकास कर सकते हैं और अधिक कॉन्फ़िगरेशन से निपटने के लिए कार्यान्वयन को संशोधित कर सकते हैं।

— जेरेमी हेइलर

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

— एडम क्रॉसलैंड

मैं DSL के हाल के बारे में पढ़ रहा था, Jetbrains के पास उनका MPS है जो दिलचस्प लगता है, लेकिन मैं अभी तक इसका उपयोग करने की कल्पना नहीं कर सकता। वे अपने कुछ उत्पादों पर इसका उपयोग करने का दावा करते हैं, इसलिए मैं यह देखने के लिए पूछताछ कर सकता हूं कि कौन से और कैसे।

— इयान

अगर मैं कर सकता तो मैं इस 100,000,000 बार अपवोट करता। यदि आपने कभी क्लैरिटी नामक परियोजना प्रबंधन उपकरण का उपयोग किया है, तो आप समझेंगे कि यह एक भयानक वास्तुकला पसंद क्यों है!

— एचएलजीईएम

Answer 3

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

Comments

यह मर चुका है। अफसोस की बात है, यह एक बड़ी समस्या के रूप में हार्डवेयर तेजी से हो रहा है। यह 10 रिकॉर्ड पर तेजी से काम करता है, यह 100,000,000 के साथ काम क्यों नहीं करेगा?

— जेफ डेविस

मेरे लिए, ORM वास्तुकला गंध है।

— क्रिस्टोफर महान

Answer 4

कोड की गंध और स्थापत्य की खुशबू एक सी होती है। उप-इष्टतम वास्तुकला के कारण कोड "गंध" शुरू होता है।

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

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

Comments

दिलचस्प बिंदु, क्या आप एक उदाहरण प्रदान कर सकते हैं?

— ट्रैविस क्रिश्चियन

चतुर कोडिंग कोड गंध है।

— क्रिस्टोफर महान

एक उत्तर जो तथ्यों का समर्थन किए बिना एक बयान देता है। उत्तर गंध?

— इवान प्लाइस

@EvanPlaice मेरी क्षमायाचना। उम्मीद है कि मेरा संपादन मेरे जवाब में कैसे आया, इस बारे में कुछ और जानकारी प्रदान करता है।

— माइकल ब्राउन

@MikeBrown +1 मैं बेहतर लेकिन अच्छा सुधार किया जा रहा था।

— इवान प्लाइस

Answer 5

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

उस ने कहा: कोई भी युग्मन अक्सर प्रदर्शन के मुद्दों को नहीं सुलझाता है।

Comments

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

— एचएलजीईएम

+1 लेकिन YMMV। सावधानी से प्रयोग करें।

— माइकल के

यही कारण है कि मैंने "कोई युग्मन नहीं किया है जो अक्सर प्रदर्शन मुद्दों को सूंघता है"। मैं सहमत हूं कि आपको प्रदर्शन बढ़ाने के लिए युग्मन का उपयोग करना होगा। यह तब होता है जब हर जगह बहुत से युग्मन होते हैं (विभिन्न मॉड्यूल / वर्गों / आपके आवेदन के जो भी) के बीच एक वास्तुशिल्प समस्या होती है।

— Klaim

Answer 6

यहाँ एक ठोस वास्तुकला / डिज़ाइन की गंध है जिसका मैं हर समय सामना करता हूँ: विश्लेषण और रिपोर्टिंग सीधे एक ट्रांसेक्शनल डेटाबेस से।

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

यह आमतौर पर एंटरप्राइज़ LOB ऐप्स, btw में देखा जाता है। मैं समझता हूं कि कई एसएमबी के पास केवल गोदाम या डेटामार बनाने के लिए संसाधन या पता नहीं है (क्यूब्स के बारे में भूल जाओ, या मैप-कम सेटअप), लेकिन कई बड़े ओर्गास जो मैंने काम किया है, वही मुद्दे हैं।

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

Answer 7

मुझे यकीन नहीं है कि यह सही ढंग से वास्तुकला स्तर पर फिट बैठता है, लेकिन अगर मुझे एक ओओ डिजाइन माना जाता है, तो प्रबंधक कक्षाओं / मॉड्यूल का एक गुच्छा दिखाई देता है, तो यह गारंटी है कि एकमात्र व्यक्ति जो वास्तुकला / डिजाइन को समझेगा दूसरों द्वारा बहुत सारे स्पष्टीकरण / सीखने के बिना वास्तुकार / डिजाइनर खुद है।

Answer 8

समुदाय द्वारा प्रलेखित कई वास्तुकला गंध हैं। आमतौर पर होने वाला सेट निम्नलिखित है।

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

मैंने हाल ही में बदबू आ रही है । वर्तमान में, यह 38 वास्तुकला बदबू आ रही है और 260 से अधिक कुल कोड बदबू आ रही है।