"बहुत वस्तु उन्मुख"

Question

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

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

मैं अपने सहकर्मियों को अपनी प्रेरणा स्पष्ट रूप से बताने में संघर्ष करता हूं। क्या किसी को इस बारे में कोई सलाह है कि मैं अपने सहकर्मियों को कैसे समझा सकता हूं कि OO और TDD का उपयोग करने से कोड आसानी से बनाए रखा जा सकता है?

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

Comments

आपकी भूमिका क्या है? ग्रंट डेवलपर? तुम खराब हो - एक बेहतर काम करो। प्रमुख डेवलपर? आप एक फर्क करने में सक्षम हो सकते हैं ...

— मैथ्यू फ्लिन

नहीं इतना तकनीक ऋण, बदल गरीब डिजाइन और लोगों के साथ काम कर के रूप में है कि नहीं

— ozz

मैं तकनीकी और व्यावसायिक तर्कों से अवगत हूं, मैं पूछ रहा हूं कि इस ज्ञान को अपने सहकर्मियों के सामने कैसे लाया जाए जो इस बात से बेखबर हों। वे बहुत सारी कक्षाएं देखते हैं, मुझे एक परीक्षण योग्य, एक्स्टेंसिबल सिस्टम दिखाई देता है

— ThuneGrill

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

— केविन क्लाइन

प्रश्न में कोड देखे बिना (हां, अच्छा पर्याप्त नमूना प्रदान करना कठिन है, इसलिए हमें बस यहां आपके निर्णय पर भरोसा करना होगा), यह बताना कठिन है कि क्या वास्तव में OO की कमी है, या यदि आप अधिक इंजीनियर कार्गो पंथ पर जोर दे रहे हैं कोई अच्छा कारण के लिए OO abtractions मुझे लगता है कि हर किसी ने ओवर-इंजीनियर

— ओओपी के

Answer 1

आपने इसके बारे में शिकायत नहीं की, यह आपके लिए पसंद नहीं है। यदि यह एक जानबूझकर शैली की पसंद है, तो यह सिर्फ अपूरणीय रचनात्मक मतभेदों का मामला हो सकता है, और आपको अपनी शैली को फिट करने के लिए समायोजित करना चाहिए, या कहीं और ढूंढना चाहिए जो आपकी पसंद की शैली में फिट हो।

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

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

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

दूसरी ओर, यदि कोड या तो प्रतिमान में गड़बड़ी है, तो आपको संभवतः अपने नुकसान को कम करना चाहिए।

Comments

यह प्रक्रियात्मक और गड़बड़ है। लेकिन मैं नए कोड के बारे में बात कर रहा हूं जिसे मैं "बहुत ऑब्जेक्ट ओरिएंटेड" लिखा जा रहा हूं

— ThuneGrill

गन्दा प्रक्रियात्मक कोड OO कोड के साथ बढ़ाया जा रहा है, सब के बाद सुधार नहीं हो सकता है, बस भ्रम को जोड़ने।

— 21

@ThuneGrill, आप मान रहे हैं कि उन्होंने अपनी कोडिंग शैली को ऑब्जेक्ट ओरिएंटेड डिज़ाइन की अनदेखी से चुना है, कि यदि आप उन्हें शिक्षित कर सकते हैं, तो वे प्रकाश को देखेंगे। यदि कोई लाभदायक सॉफ़्टवेयर व्यवसाय वाला व्यक्ति दृढ़ता से ऑब्जेक्ट-ओरिएंटेड भाषा में है, तो अब तक OOD के लाभों पर ध्यान नहीं दिया गया है, कोई रास्ता नहीं है कि "नया आदमी" उसे समझाने जा रहा है। इसके लिए मेरा शब्द और अन्य टिप्पणीकारों का शब्द लें। यदि आप टीम को पढ़ने में आसान बनाने के लिए अपनी शैली को समायोजित नहीं कर सकते हैं या नहीं कर सकते हैं, तो आपको अपने नुकसान में कटौती करनी चाहिए।

— कार्ल बेज़ेलफेल्ट

@ThuneGrill: कार्ल का अधिकार। धार्मिक कारणों से चिपके रहते हैं, धार्मिक नहीं। ओओपी निश्चित रूप से एक अच्छा विचार है, लेकिन मैंने इसे हास्यास्पद चरम सीमा तक पहुंचाया है। नतीजा पहाड़ को तिलहन से बाहर कर रहे हैं। कोड की 1000 लाइनों में काम आने वाली चीजें, कक्षाओं के साथ 10,000 लाइनों के कोड के अंत तक हो सकती हैं। फिर, जी, इसे बनाए रखना कठिन है, और प्रदर्शन बेकार है। (कोई फर्क नहीं पड़ता कि संग्रह कक्षाओं का क्या उपयोग किया जाता है।)

— माइक डनलैवी

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

— ।stackexchange.com

Answer 2

आपके प्रश्न को पढ़ते हुए, मुझे पुस्तक प्रोगामेटिक प्रोग्रामर की एक टिप याद आई।

इसके सुझावों में से एक है Be a Catalyst for Change:

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

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

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

Comments

होने की कोशिश कर रहा है, लेकिन uber- वास्तुकार (जो कोड नहीं करता है) इसके पास कोई भी नहीं होगा।

— ThuneGrill

जैसे ही वह टीडीडी और बेहतर ओओ (विश्वसनीयता, उत्पादकता, ...) के लाभों को नोटिस करता है, आपको अपना ध्यान मिलेगा!

— रोड्रिगो

Answer 3

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

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

मैं "सच्चा ऊ" में बहुत बार देखता हूं कि उन्नत तकनीकों का उपयोग अत्यधिक जटिल तरीके से वास्तव में सरल समस्याओं को हल करने के लिए किया जाता है।

यदि आप केवल उसी वस्तु को बनाने जा रहे हैं तो आप किसी कारखाने का लाभ कैसे दिखा सकते हैं? अपने कोड में एक समस्या का पता लगाएं जो उन्नत तकनीकों से लाभान्वित करता है और आपकी बात दिखाता है और वहां से काम करता है।

युद्ध एक समय में एक युद्ध जीते जाते हैं।

Answer 4

आप केवल कोड का एक छोटा हिस्सा लेने और उस पर TDD और बेहतर OO प्रथाओं को लागू करने के लाभों को महसूस करने के लिए उन्हें मना सकते हैं। आप उन्हें वादा किए गए देश में ले जाते हैं, न कि इसके अच्छे पोस्ट कार्ड दिखाते हैं।

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

Comments

बस, यही व्हाट्स ने पूरी चर्चा का कारण बना। एक मैं केवल मौजूदा कार्यक्षमता के शीर्ष पर 3-4 कपोल-कल्पना शुरू की

— ThuneGrill