मैं कैसे साबित करूं या "ईश्वर की वस्तुओं" को गलत साबित करूं?


56

समस्या सारांश:

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

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

सवाल:

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

अनुसंधान मैं पहले से ही किया है:

  1. मेरे पास यहां कई किताबें हैं और मैंने "देव वस्तु" और "देव वर्ग" शब्दों के उपयोग के लिए उनकी अनुक्रमणिकाएं खोजी हैं। मैंने पाया कि इसका लगभग कभी उपयोग नहीं किया गया था और उदाहरण के लिए मेरे पास मौजूद गोफ़ बुक की प्रति, कभी भी इसका उपयोग नहीं करता (कम से कम मेरे सामने सूचकांक के अनुसार) लेकिन मैंने इसे नीचे दो पुस्तकों में पाया है, लेकिन मैं और अधिक चाहता हूं मैं उपयोग कर सकता हूं।
  2. मैंने "गॉड ऑब्जेक्ट" के लिए विकिपीडिया पृष्ठ की जाँच की और वर्तमान में थोड़ा संदर्भ लिंक के साथ एक स्टब है, हालांकि मैं व्यक्तिगत रूप से इस बात से सहमत हूँ कि यह कहता है, यह मेरे पास ऐसे वातावरण में उपयोग नहीं कर सकता जहाँ व्यक्तिगत अनुभव को मान्य नहीं माना जाता है। उद्धृत पुस्तक को भी उन लोगों द्वारा मान्य माना जाता है जिन्हें मैं इन तकनीकी बिंदुओं पर बहस कर रहा हूं क्योंकि वे जो तर्क दे रहे हैं वह यह है कि "यह एक बार बुरा माना गया था, लेकिन कोई भी इसे साबित नहीं कर सका, और अब आधुनिक सॉफ्टवेयर कहता है" भगवान "वस्तुओं का उपयोग करने के लिए अच्छा है"। मैं व्यक्तिगत रूप से मानता हूं कि यह कथन गलत है, लेकिन मैं सच साबित करना चाहता हूं, चाहे वह कुछ भी हो।
  3. रॉबर्ट सी मार्टिन के "एजाइल प्रिंसिपल्स, पैटर्न, एंड प्रैक्टिस इन सी #" (आईएसबीएन: 0-13-185725-8, हार्डकवर) जहां पेज 266 पर लिखा है, "हर कोई जानता है कि भगवान कक्षाएं एक बुरा विचार हैं। हम चाहते हैं। एक सिस्टम के सभी इंटेलिजेंस को एक ही ऑब्जेक्ट या किसी एक फंक्शन में कंसंट्रेट करने के लिए। OOD के लक्ष्यों में से एक है, कई वर्गों और कई फंक्शन में व्यवहार का विभाजन और वितरण। " - और फिर कभी-कभी ईश्वर वर्गों का उपयोग करने के लिए कभी-कभी इसका बेहतर कहना आगे बढ़ता है (उदाहरण के रूप में माइक्रो-नियंत्रक का हवाला देते हुए)।
  4. रॉबर्ट सी मार्टिन के "क्लीन कोड: ए हैंडबुक ऑफ़ एजाइल सॉफ्टवेयर क्राफ्ट्समैनशिप" पृष्ठ 136 (और केवल इस पृष्ठ पर) "गॉड क्लास" के बारे में बात करता है और इसे "कक्षाओं को छोटा होना चाहिए" नियम के उल्लंघन के प्रमुख उदाहरण के रूप में कहता है वह एकल जिम्मेदारी सिद्धांत को बढ़ावा देने के लिए उपयोग करता है "पेज 138 पर शुरू होता है।

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

गॉड ऑब्जेक्ट्स एंड ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग एंड डिज़ाइन:

जितना अधिक मैं इस बारे में सोचता हूं उतना ही मुझे लगता है कि यह कुछ और है जो आप ओओपी का अध्ययन करते समय सीखते हैं और इसे कभी भी स्पष्ट रूप से नहीं कहा जाता है; इसके अच्छे डिजाइन का निहितार्थ मेरी सोच है (कृपया मुझे सुधारने के लिए स्वतंत्र महसूस करें, कृपया, जैसा कि मैं सीखना चाहता हूं), समस्या यह है कि मैं इसे "जानता" हूं, लेकिन हर कोई ऐसा नहीं करता है, इसलिए इस मामले में इसका एक वैध तर्क नहीं माना जाता है क्योंकि मैं प्रभावी रूप से इसे सार्वभौमिक सत्य कह रहा हूं जब वास्तव में अधिकांश लोग सांख्यिकीय रूप से अनभिज्ञ होते हैं क्योंकि सांख्यिकीय रूप से अधिकांश लोग प्रोग्रामर नहीं होते हैं।

निष्कर्ष:

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


19
उनसे अच्छी वस्तुओं के रूप में देव वस्तुओं के प्रलेखन के लिए कहें।
डॉन रॉबी

43
भाग जाओ! आप वहां काम नहीं करना चाहते हैं।
डॉन रॉबी

11
कृपया "गॉड ऑब्जेक्ट" की अपनी समझ को परिभाषित करें और यह आपके प्रश्न से कैसे संबंधित है। आप यह कहते हुए 4 पैराग्राफ खर्च करते हैं कि ईश्वर वर्ग साहित्य में एक मानक शब्द नहीं है। फिर आप इसका उपयोग क्यों कर रहे हैं? यदि आप उद्योग मानक शर्तों का उपयोग करते हैं, और यह दिखा सकते हैं कि वे अवधारणाएँ आपकी वर्तमान परियोजना पर कैसे लागू होती हैं, तो आप अपनी बात के कुछ लोगों को मना सकते हैं। एक व्यापार बैठक में बने शब्दों का उपयोग केवल आपके तर्क को कमजोर करने वाला है। उद्योग मानक शर्तें मौजूद हैं - आप कभी भी सब कुछ-वैश्विक या एकल-वस्तु दुःस्वप्न या आप जो भी वर्णन करने की कोशिश कर रहे हैं, उसे देखने वाले पहले व्यक्ति नहीं हैं।
ग्लेनपेटर्सन

18
आपको "एंटीपैटर्न" शब्द याद आ रहा है। "भगवान वस्तु antipattern" के लिए एक गूगल खोज कर देता टन कारणों पर पृष्ठों की है कि वे बुरा कर रहे हैं।
इजाकाता

21
आपको ईश्वर की वस्तु पर हमला नहीं करना चाहिए लेकिन इससे समस्याएं पैदा होती हैं। जैसे: हमारे पास हर चीज के बीच बहुत टाइट कपलिंग है और A में बदलाव के लिए B, C और D. में भी बदलाव की आवश्यकता है, ताकि हम उस वर्ग को निकालने में मदद कर सकें। या: हम चाहते हैं कि कोड एक परीक्षण ढांचे में हो, और हम ऐसा नहीं कर सकते, हम क्या करने जा रहे हैं? इसके अलावा, "भगवान" शब्द का उपयोग करने से बचें, ग्रहणशील लोग यह नहीं सोचेंगे कि आप हाइपरबोल्स का उपयोग कर रहे हैं।
पीटर बी

जवाबों:


51

मौजूदा डिजाइन द्वारा बनाए गए दर्द बिंदुओं की पहचान करके अभ्यास के किसी भी परिवर्तन के लिए मामला बनाया गया है। विशेष रूप से, आपको यह पहचानने की आवश्यकता है कि मौजूदा डिज़ाइन की वजह से क्या कठिन होना चाहिए, क्या नाजुक है, अब क्या टूट रहा है, क्या व्यवहार को एक सरल तरीके से प्रत्यक्ष (या कुछ हद तक अप्रत्यक्ष) के रूप में लागू नहीं किया जा सकता है वर्तमान क्रियान्वयन, या, कुछ मामलों में, प्रदर्शन में कितना दम है, एक नए टीम के सदस्य को गति बढ़ाने में कितना समय लगता है, आदि।

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

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

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

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

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

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

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

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


4
अच्छी बात यह है कि यह एक सामाजिक समस्या है। ऐसा क्यों होना चाहिए कि वहां बहुत बुरा लिखित कोड और खराब तरीके से डिजाइन किए गए एप्लिकेशन हैं।
यानिक रोचोन

5
+1 को इस तरह से 'बिज़नेस स्पीक' से जोड़ने के लिए; अपने दर्शकों के लिए इसे उतना ही प्रासंगिक बनाने का लक्ष्य रखें जितना आप कर सकते हैं। यदि आप अधिकारियों से बात कर रहे हैं, तो इस बारे में बात करें कि कैसे कोड के मानक का रखरखाव और प्रदर्शन के साथ सीधा संबंध है, और चर्चा करते हैं कि यह समग्र परियोजना वित्त, दीर्घकालिक स्थिरता और इसी तरह से कैसे जुड़ा है। ऐसा लगता है जैसे आपको अपने ज्ञान के कारण काम पर रखा गया है; यह याद रखना। (बस एक झटका-बंद प्रबंधक न बनें जो सोचता है कि वह हमेशा सबसे अच्छा जानता है - लेकिन इस उदाहरण में आप 100% सही हैं।)
लंदन

2
+1 के लिए "वर्किंग कोड सिद्धांत या अच्छे डिजाइन के बारे में कोई तर्क देता है।" कुछ हम अक्सर सही कोड के लिए हमारी खोज में भूल जाते हैं।
बज्रक फ्रंड-हैन्सन

शानदार जवाब, आकांक्षी टीम के लिए बहुत सारी समझदारी।
jimmy_terra

24

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

  1. गॉड ऑब्जेक्ट एक विरोधी पैटर्न है जो बताता है कि

    सॉफ्टवेयर इंजीनियरिंग में, एक एंटी-पैटर्न (या एंटीपैटर्न) सामाजिक या व्यावसायिक संचालन या सॉफ्टवेयर इंजीनियरिंग में उपयोग किया जाने वाला एक पैटर्न है जो आमतौर पर इस्तेमाल किया जा सकता है लेकिन व्यवहार में अप्रभावी और / या प्रतिप्रतिरूप होता है।

  2. 2009 के Google IO सम्मेलन में , इस विषय को आंशिक रूप से समझाया गया था जब MVP पैटर्न समझाया गया था। यह ईश्वर वस्तु के लिए प्रासंगिक नहीं हो सकता है, लेकिन आपको कुछ बारूद दे सकता है।

  3. इसके अलावा, इस विरोधी पैटर्न का उपयोग वस्तु उन्मुख डिजाइनों में एकल जिम्मेदारी सिद्धांत का उल्लंघन करता है , जो बताता है कि:

    हर वर्ग की एक ही ज़िम्मेदारी होनी चाहिए, और वह ज़िम्मेदारी पूरी तरह से वर्ग की होनी चाहिए। इसकी सभी सेवाओं को उस जिम्मेदारी के साथ संरेखित किया जाना चाहिए।

  4. खस्ताहाल कोड ब्लॉग भी इस बारे में बात करती है और इसके बारे समाधान है।

  5. हम ऑब्जेक्ट युग्मन के बारे में बात किए बिना एकल जिम्मेदारी सिद्धांत के बारे में बात नहीं कर सकते ।

    [...] युग्मन या निर्भरता वह डिग्री है जिसके लिए प्रत्येक प्रोग्राम मॉड्यूल अन्य मॉड्यूल में से प्रत्येक पर निर्भर करता है।

    जहां एक कसकर युग्मित प्रणाली का कारण हो सकता assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.है वस्तु के उच्च स्तर के युग्मन का अर्थ है कम सामंजस्य, और इसके विपरीत। ईश्वर की वस्तुएँ तंग युग्मन का एक अच्छा उदाहरण हैं क्योंकि वे जितना जानते हैं उससे अधिक होना चाहिए, इस प्रकार उन्हें जिम्मेदारी के साथ अधिभारित किया जाता है, इस प्रकार कोड की पुनरावृत्ति को बहुत सीमित कर देता है।

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

    इस तर्क के साथ, हम एंटी-पैटर्न तर्क के लिए लूप बैक करते हैं, लेकिन यह प्रतिमान पैटर्न, वास्तविक दुनिया ऑब्जेक्ट प्रतिनिधित्व और, अल्टीमेटली, डेटा एनकैप्सुलेशन के बारे में है।

  7. आप सही हैं जब आप कहते हैं कि ये "अच्छे व्यवहार" कक्षाओं में अधिक मौजूद हैं। हालाँकि, मुझे कॉलेज (और कुछ विश्वविद्यालय) में शिक्षण के अनुभव हैं और मैंने केवल इन सिद्धांतों को विश्वविद्यालयों में पढ़ाया जा रहा है, खासकर इंजीनियरिंग संकायों में। जो दुखद हो। लेकिन किसी भी अच्छे अभ्यास की तरह, जो लोग खुद को बेहतर बनाने का प्रयास करते हैं, वे आमतौर पर कुछ बुनियादी डिजाइन पैटर्न सीखते हैं , और अंत में समझते हैं कि युग्मन और सामंजस्य के बीच जंगल कैसे करें।

    मैं आमतौर पर छात्रों को जो सिखाता हूं, वह यह है कि अच्छे प्रोग्रामिंग मानकों को अपनाने के लिए अधिक प्रयासों की आवश्यकता हो सकती है, लेकिन यह हमेशा लंबे समय में भुगतान करता है। एक अच्छा उदाहरण कोई होगा जो किसी प्रोग्रामर को सॉर्टिंग फ़ंक्शन लिखने के लिए कहेगा। प्रोग्रामर के पास दो विकल्प हैं; 1) एक त्वरित बबल सॉर्ट फ़ंक्शन (5 मिनट से कम) लिखें, जो टिकाऊ नहीं होगा क्योंकि तत्वों की सूची बढ़ती है, या 2) एक अधिक जटिल (उर्फ अनुकूलित) सॉर्टिंग एल्गोरिथ्म (त्वरित सॉर्ट, आदि) लिखें जो बेहतर पैमाने पर होगा। बड़ी सूचियों के साथ।


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

1
मेरा मानना ​​है कि इस सवाल के लिए यह थोड़ा ऑफ-टॉपिक है। हम यहां गॉड ऑब्जेक्ट विरोधी पैटर्न के बारे में बात नहीं कर रहे हैं, लेकिन कोड युग्मन और सामंजस्य, जो एक बहुत व्यापक विषय है और बहुत व्यक्तिपरक है।
यानिक रोचोन

7

ओह यहाँ मैं जाता हूँ, एक और पुराने सवाल को टालता हूँ, लेकिन मुझे लगता है कि आप इस तर्क को नहीं जीते हैं और यहाँ क्यों है।

यह एक संस्कृति समस्या की तरह लगता है

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

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

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

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

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

असंभव घटना में नहीं है कि यह एक अचूक संस्कृति समस्या नहीं है ...

अब शीर्ष पर बैठे लोगों को बदलने के लिए ग्रहणशील हैं, और वे वास्तव में आपको इसे बनाने के लिए विश्वास करने के लिए तैयार हैं, आपको वास्तव में केवल पैसे और खोए हुए अवसर के साथ अपने सभी तर्कों को विराम देने की आवश्यकता है।

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

बस यह मान लें कि एक विशेष रूप से जिद्दी और बेवकूफ संस्कृति हर कीमत पर यथास्थिति बनाए रखेगी, भले ही कंपनी की वास्तविक भौतिक छत वास्तव में आग की वजह से हो।


3
मैंने कुछ ही समय बाद कंपनी छोड़ दी। उन्होंने मुझे पूरा समय देने और मुझे प्रस्ताव स्वीकार करने के लिए सिएटल से एनवाई करने की कोशिश की; मैंने मूल रूप से उन्हें कहा "कोई रास्ता नहीं, मैं एनवाई में स्थानांतरित नहीं होने जा रहा हूं जब मैं जिस टीम का प्रबंधन कर रहा हूं वह बेलव्यू, डब्ल्यूए में होगा" और उस समय मैं मूल रूप से सड़क पर चला गया और एमएसएफटी में नौकरी मिली जब तक कि मुझे कुछ नहीं मिला। बेहतर।
ईमानदार

1
@honestduane हाँ, उम्मीदों का एक सेट अकेले बोलता है। जीटीएफओ पर आपके लिए अच्छा है।
एरिक रेपेने

3

आप इस तरह के ढीले युग्मन और उच्च सामंजस्य के रूप में सबसे बुनियादी OOP रियासतों में से कुछ का हवाला दे सकते हैं। एक "गॉड ऑब्जेक्ट" ऐसा लगता है जैसे यह जोड़े असंबंधित वर्ग और कम सामंजस्य रखते हैं।


2

आप हमेशा खुद अंकल बॉब से पूछ सकते थे।

बात यह है, यह किसी भी अर्थ के साथ लोगों को इतना स्पष्ट है कि एक बार जब यह वर्तनी है, यह लेखकों की एक भीड़ द्वारा फिर से संदर्भित करने की आवश्यकता नहीं है। केवल एक स्रोत होने की जरूरत है।

अन्य शर्तें जिन्हें आप स्रोतों की तलाश में शुरू करना चाहते हैं:

  • ठोस
  • क़ानून का निर्माता
  • मिट्टी की बड़ी गेंद

ये सभी संबंधित अवधारणाएं हैं जो व्यवहार्य संदर्भ स्रोतों को प्राप्त कर सकती हैं, भले ही वे वास्तव में इस तरह का नाम न दें।

अंततः, हालांकि, आप मालिक हैं। ऐसा करने का कारण यह है कि आप ऐसा कहते हैं, और यद्यपि एक अच्छा प्रबंधक माना जाने के लिए आपको अपने निर्णयों को सही ठहराने के लिए वास्तव में तैयार रहना चाहिए; आपने ऐसा किया है, और यदि अभी भी प्रतिरोध है, तो कार्रवाई का सही तरीका आपकी टीम के लिए है जैसा कि उन्होंने बताया है।


"अगर अभी भी प्रतिरोध है, तो कार्रवाई का सही कोर्स आपकी टीम के लिए है जैसा कि उन्हें बताया गया है" हो सकता है कि आपकी टीम को दयनीय बनाने के बजाय कार्रवाई का सही कोर्स छोड़ दिया जाए ..?
टॉम

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

3
निष्पक्ष बिंदु। यह निर्भर करता है कि आप टीम को कैसे चलाना चाहते हैं। लेकिन मेरे अनुभव में लोगों को उनके खिलाफ काम करने के लिए मजबूर करना सिर्फ दुख की ओर ले जाएगा। मैं एक दयनीय विकास टीम की तुलना में कोड बेस में ईश्वर की वस्तुओं को देखना चाहूंगा। शायद इसका जवाब उन्हें एक प्रशिक्षण पाठ्यक्रम पर भेजना है। हर कोई एक प्रशिक्षण पाठ्यक्रम प्यार करता है। फायदे का सौदा।
टॉम

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

1

मैं "ईश्वर" वस्तुओं को गलत साबित या नापसंद कैसे करूं?

आप नहीं कर सकते।

इस तरह का अनुमान गणितीय प्रमाण के लिए उत्तरदायी नहीं है, और गणितीय प्रमाण एकमात्र प्रकार का प्रमाण है जो ध्वनि है।

यहां तक ​​कि अगर आप देव शब्द का उपयोग करने के प्रभावों के साथ भावनात्मक शब्द "गलत" को बदलने की कोशिश करते हैं, तो आप पाएंगे कि:

  1. उपलब्ध उपाय कच्चे हैं,
  2. कुछ विश्वसनीय अध्ययन हैं जहां उन उपायों को पेशेवर प्रोग्रामर द्वारा उत्पादित कोड के लिए निर्धारित किया गया है
  3. अगर कोई विश्वसनीय अध्ययन करता है, जहां भाषा निर्माण या डिजाइन (विरोधी) पैटर्न उन उपायों से बंधा हुआ है, तो बहुत कम हैं।

और यह तय करने के मुद्दे की अनदेखी कर रहा है जब एक विशेष वस्तु "भगवान" वस्तु है।

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


आप वास्तव में जो कुछ कर रहे हैं, वह "भगवान" वस्तुओं के पेशेवरों और विपक्षों पर बहस कर रहा है, अन्य लोगों की राय बदलने की दृष्टि से ... और फिर आपके संगठन का अभ्यास।

"सबूत" या उन लोगों के साथ शब्दों का उपयोग न करें जिनके साथ आप बहस कर रहे हैं जो आपके चेहरे पर हंसी के लिए उत्तरदायी हैं।


0

आप सप्ताह के गुरु को देखना चाह सकते हैं # 84 । यह सभी देव वस्तुओं (मोनोलिथ्स) के बारे में है और वे कैसे खराब हैं।

निकालें:

(मेजर) यह एक वर्ग के अंदर संभावित स्वतंत्र कार्यक्षमता को अलग करता है [...] (माइनर) यह नई कार्यक्षमता के साथ कक्षा को विस्तारित करने को हतोत्साहित कर सकता है [...]


0

यदि आपकी टीम को वास्तव में शैक्षिक प्रस्ताव में दिलचस्पी है कि "भगवान की वस्तुएं गलत हैं" तो मैं श्योर नहीं हूं।

मनोवैज्ञानिक दृष्टिकोण से आपकी रिफैक्टिंग ऑप्रैच को गलत समझा जा सकता है क्योंकि टीम की क्षमता पर ला पर हमला करना: "टीम ने एक बुरा काम किया है" हालांकि प्रोग्राम अपेक्षा के अनुरूप काम कर रहा है।

आप वास्तव में क्या करना चाहते हैं "स्पैगेटी कोड" और "गॉड ऑब्जेक्ट्स" के नकारात्मक दुष्प्रभावों का सामना करना है: साइडइफेक्ट्स की वजह से बढ़ती कीड़े के कारण नई सुविधाओं को जोड़ने के लिए एक्सप्लोडिग कॉस्ट।

जवाब देने के बजाय बहुत विशिष्ट और प्रश्न पूछना अधिक उपयोगी हो सकता है:

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.