कोडिंग करते समय मैं विश्लेषण द्वारा पक्षाघात को कैसे दूर कर सकता हूं?

Question

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

मैं एक लंबे समय के लिए स्टालिंग को समाप्त करता हूं क्योंकि मैं एक्स्टेंसिबिलिटी और रीसबिलिटी के लिए कोड करना चाहता हूं। लेकिन मुझे लगता है कि पूरी तरह से लागू करने के बारे में पिछली सोच को प्राप्त करना लगभग असंभव है।

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

एक तार्किक / मॉड्यूलर संरचना स्थापित करते समय एक नई परियोजना में लॉन्च करने के लिए आपके पास कुछ तकनीक / तरीके क्या हैं जो अच्छी तरह से स्केल करेंगे?

- - EDIT - -

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

धन्यवाद!

Comments

वापस कदम, एक कलम और कागज को पकड़ो, बड़ी तस्वीर को स्केच करें। यह आपकी मदद करेगा तो विवरणों में अपने आप को खोने के बजाय एक अधिक संरचित तरीके से कार्यान्वयन को डिज़ाइन करें ...

— Darknight

यह एक बड़ा सवाल है। यह एक ऐसा जाल है जिसके दोषी होने के साथ ही मैं भी गिर गया।

— Corv1nus

के संभावित डुप्लिकेट मैं विश्लेषण पक्षाघात से कैसे निपटते हैं?

— gnat

Answer 1

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

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

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

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

एक छोटा जावा उदाहरण:
कहो कि मैं एक प्रोग्राम विकसित करना चाहता हूं जो डीबी से एक संदेश पढ़ता है और लिखता है।

इसलिए मैं पहले अच्छी तरह से परिभाषित कार्रवाई के साथ शुरू करता हूं, मुझे एक डीबी की आवश्यकता है:

@Test
public void testDB() {
  DB db = DbConnector.getDB(address);
  assertNotNull(db);
}

ठीक है, इसलिए यहां मैं देखता हूं कि मुझे DbConnector.getDB वर्ग को लागू करने की आवश्यकता है ताकि यह DB को वापस कर दे, जब तक कि यह परीक्षण विफल नहीं हो जाता। मैं जाता हूँ और करता हूँ कि ...

नहीं, मैं डीबी से संदेश लोड करता हूं, जो मैं करता हूं वह अगली चीज जोड़ें:

@Test
public void testDB() {
  DB db = DbConnector.getDB(address);
  assertNotNull(db);
  String message = db.fetchMessage(key);
  assertEquals("hello world", message);
}

अब मैंने DB में एक और छोटी सुविधा जोड़ी है जो एक संदेश लाने के लिए है, मैं जाता हूं और उस पर अमल करता हूं, एक बार समाप्त होने के बाद मैं एक बार में एक सुविधा को तब तक जारी रखता हूं जब तक कि मैं कुछ इस तरह से नहीं पहुंचता:

@Test
public void testDB() {
  DB db = DbConnector.getDB(address);
  assertNotNull(db);
  String message = db.fetchMessage(key);
  assertEquals("hello world", message);
  message = "foo bar";
  db.storeMessage(message);
  message = db.fetchMessage();
  assertEquals("foo bar", message);
}

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

Comments

और टीडीडी आपको बहुत रिफ्लेक्टर करने के लिए मजबूर करता है, इसलिए आप निरंतर रीफैक्टरिंग के एक कार्य मोड में आ रहे हैं जो प्रोग्रामर.स्टैकएक्सचेंज . com/questions/86364// उल्लेख की तरह, गड़बड़ कोड की ईंट की दीवार के माध्यम से तोड़ने में मदद करेगा ।

— चापलूसी

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

— स्टीवन एवर्स

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

— लग्जरीमोड

Hmmmm यह एक TDD fanboy की तरह लगता है ..... क्या कभी एक वास्तुकला बाहर स्केच करने के लिए कलम और कागज का उपयोग करने के लिए हुआ? या मैं पुराना फैशन हूं और "हिप" पर्याप्त नहीं है ....

— डार्कनाइट

पेन और पेपर (या व्हाइटबोर्ड) अच्छा है। समग्र योजना को स्केच करें, बड़ी तस्वीर। यदि यह कागज के एक टुकड़े पर फिट नहीं होता है, तो यह बहुत जटिल है। एक बार जब आप बड़ी चित्र योजना प्राप्त कर लेते हैं, तो आप BDD, मॉकिंग आदि के साथ व्यस्त हो सकते हैं

— Donal Fellows

Answer 2

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

यह कहना नहीं है कि बहुत योजना नहीं चल रही है, लेकिन यह बहुत जल्दी और अधिक-अक्सर स्क्रैप या मेरे सिर में डूडल के रूप में होता है। सब के सब, मैं कभी-कभी इस छोटी सी प्रक्रिया को सूक्ष्म पुनरावृत्तियों कहता हूं क्योंकि वे प्रत्येक में 5-20 मिनट लेते हैं और अनुभव से यह पूरा करने के लिए 2-3 लेता है कि मैं क्या काम कर रहा हूं (जो मैं बना रहा हूं, उस पर निर्भर करता है)।

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

Comments

लेखन का उल्लेख करने के लिए +1। मैंने हाल ही में कोडिंग से लगातार रिफैक्टिंग दृष्टिकोण अपनाया और इसे लेखन में लागू किया; मेरे लिए बहुत अच्छा काम करता है।

— Zsolt Török

Answer 3

कुछ चीजें जो काम कर सकती हैं:

• उस मूल समस्या को पहचानें जिसे आप हल करने की कोशिश कर रहे हैं - उस चीज़ का बहुत दिल जो आप करना चाहते हैं? इसे लागू करने के लिए, और नंगे न्यूनतम समर्थन कोड लागू करें। एक बार जब यह आपकी संतुष्टि के लिए काम करता है, तो हर कदम पर दया के बिना, पुनरावृत्ति का निर्माण करें।
• देखें कि क्या अन्य प्रोग्रामिंग प्रतिमान आपके लिए काम करते हैं। अपनी सभी खूबियों के बावजूद, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग सभी समस्याओं का जवाब नहीं है, और सभी प्रोग्रामर का दिमाग उस तरह से काम नहीं करता है। (शुद्ध) कार्यात्मक भाषा उठाओ; कुछ प्रक्रियात्मक कोड लिखें; हार्डवेयर स्तर तक नीचे गोता लगाएँ और कुछ C या शायद कोडांतरक भी करें; आदि कुछ भाषाएं जो आपके दिमाग को हिला सकती हैं (यह मानते हुए कि आप वर्तमान में C ++ / Java / C # / VB / ... जैसी किसी चीज़ का उपयोग कर रहे हैं: Haskell, ML, Lisp (चुनने के लिए विभिन्न बोलियाँ), Erlang, Prolog, स्मॉलटाकल, जावास्क्रिप्ट (यदि आप इसे जावा की तरह व्यवहार करने की कोशिश करने देते हैं और इसके बजाय इसकी बंद प्रकृति को गले लगाते हैं), सी, पास्कल, जाग, और शायद एक दर्जन से अधिक। मुख्य विशेषता यह है कि आपको अभी जो उपयोग करना है उससे बहुत अलग होना चाहिए। यह वह चीज नहीं है जिसे आप किसी बड़ी परियोजना पर दांव पर लगाना चाहते हैं,
• मौलिक रूप से भिन्न डिज़ाइन विधि का उपयोग करें। देखें कि क्या आप एक अलग कोण से डिजाइन उठा सकते हैं। मुझे लगता है कि आप आमतौर पर अपनी कक्षाएं लगाकर डिजाइनिंग शुरू करते हैं; परिवर्तन के लिए डेटा संरचनाओं के साथ आप कैसे शुरू करते हैं? या कैसे आप यूआई को पहले डिजाइन करते हैं, किसी भी कार्यक्षमता को डिजाइन करने से पहले शाब्दिक रूप से इनपुट फॉर्म बनाते हैं?

Answer 4

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

उसके बाद टीडीडी या बीडीडी दृष्टिकोण का उपयोग करना फायदेमंद है जो आसफ ने परियोजना के कार्यान्वयन के साथ आगे बढ़ने का उल्लेख किया है।

Comments

+1 मैं सहमत हूं। पहले प्रयास को फेंकने की योजना बनाएं। इसे एक सीखने के अनुभव के रूप में मानें। मैं छह से ज्यादा भाग चुका हूं, इससे पहले कि मुझे लगता है कि मैं सातवें के साथ रहना चाहता हूं।

— माइक डनलैवी

Answer 5

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

लक्ष्य और समस्या को समझने के लिए परिभाषित करने के लिए अधिक समय निवेश करें।

"एक्स्टेंसिबिलिटी एंड रियूजेबिलिटी" अच्छी तरह से लिखे गए सॉफ्टवेयर प्रोग्राम के जीवन चक्र का स्वाभाविक परिणाम है।

Answer 6

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

याद रखें, डिजाइन और आर्किटेक्चर पर अच्छा समय बिताने के बावजूद, जरूरत पड़ने पर आर्किटेक्चर को फिर से तैयार करने के लिए हमेशा तैयार रहें।

Answer 7

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

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

• समय का एक सभ्य आकार ब्लॉक को अलग सेट करें जहां आप प्रोजेक्ट पर हैं, बस कंप्यूटर के बिना। उस जादुई ज़ेन को पूरा करने और देखने की कोशिश कर रहे हैं जो ओओ / डिज़ाइन पैटर्न पागलपन को पार करता है।

Answer 8

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

जब भी मैं खुद को कहीं नहीं जाता और हर जगह किसी चीज के बारे में सोचता हूं, तो मैं उन्हें टाइप करता हूं और यह मुझे स्पष्ट रूप से सोचने में मदद करता है।

Answer 9

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

समस्या पूरी तरह से समझने तक अमूर्तता, अनुकूलन या सत्यापन के बारे में चिंता न करें।