मैं कोड लिख सकता हूं ... लेकिन अच्छी तरह से डिजाइन नहीं कर सकता। कोई सुझाव? [बन्द है]

Question

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

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

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

तो मेरा सवाल यह है कि मैं अपने डिजाइन कौशल में सुधार कैसे करूं? यही है, छोटे / मध्यम पैमाने के अनुप्रयोगों को डिजाइन करने की क्षमता जो कोड की कुछ हजार पंक्तियों में जाएगी? मैं डिज़ाइन कौशल कैसे सीख सकता हूं जो मुझे बेहतर html संपादक किट बनाने में मदद करेगा, या कुछ ग्राफिक्स प्रोग्राम जैसे जिम्प?

Comments

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

— जियोर्जियो

मेरे प्रस्तावित डिज़ाइन की डुप्लिकेट आमतौर पर मेरे सहयोगी की तुलना में बदतर है - मैं कैसे बेहतर हो सकता हूं? और वस्तु-उन्मुख विश्लेषण और डिजाइन (OOAD) में अच्छा बनने के लिए कैसे?

— gnat

Answer 1

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

कोई वास्तविक शॉर्टकट नहीं हैं, लेकिन ऐसी चीजें हैं जो आप अनुभव प्राप्त करने के दौरान हाथ से निकलने वाली समस्याओं से बचने के लिए कर सकते हैं।

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

Comments

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

— मर्ट अक्काया

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

— विस्की

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

— S.Robins

एक संरक्षक प्राप्त करने के लिए +1। आदर्श रूप से, अपने संरक्षक को अपने साथ कोड समीक्षा करने के लिए प्राप्त करें। आपके कोड को किसी और ने पढ़ा और उसकी आलोचना करने से वास्तव में बेहतर और क्लीनर डिजाइन के लिए आपकी मदद कर सकता है।

— सिंह

"कभी कोशिश की। कभी असफल। कोई बात नहीं। फिर से कोशिश करें। फिर से असफल। बेहतर विफल।" --- सैमुअल बेकेट।

— पीटर के।

Answer 2

खैर, इस तरह के प्रश्न के लिए कोई सुनहरा सेब नहीं है, और मुझे लगता है कि शायद यह हर कोडर खुद के लिए है जो उसके लिए सही है। यहाँ मेरा, वैसे भी है।

आप इस विषय पर किताबें पढ़ सकते हैं। महान पुस्तकें। शानदार किताबें। लेकिन मुझे लगता है कि ये पुस्तकें केवल एक बार आपकी मदद करती हैं, जब आपने किसी एप्लिकेशन को बनाने और डिजाइन करने की कोशिश की - और असफल रही।

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

अब, मैं नई गलतियाँ करना और पुराने लोगों से सीखना जारी रखता हूं।

Comments

यहाँ एक शानदार बिंदु है जो अच्छी तरह से पुकारने लायक है: नई गलतियाँ करते रहें ; वही पुरानी गलतियाँ न करें - उनसे सीखें, और कुछ नया करें।

— बेवन

Answer 3

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

Comments

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

— रॉबिन्स

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

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

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

— रॉबिन्स

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

— जियोर्जियो

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

— गियोर्जियो

Answer 4

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

उदाहरण के लिए http://sourcemaking.com/antipatterns/software-development-antipatterns देखें ।

कोड लिखें ताकि आवश्यकताओं को बदल देने पर इसे जल्दी से समायोजित किया जा सके (जो उत्पादन वातावरण में बहुत आम है)।

"बस एक और छोटी सी हैक" जोड़ने के बारे में सुपर-संदेहवादी बनें। एक और यहाँ, एक और वहाँ, और कोड अचूक हो जाता है।

मूल्य खुला / बंद सिद्धांत ।

परीक्षण लिखें (टीडीडी में)। वे आपको वास्तव में इसे लागू करने से पहले ही आपके डिजाइन के बारे में सोचने के लिए मजबूर करते हैं।

ओपन सोर्स प्रोजेक्ट्स के कोड ब्राउज़ करें (यथोचित आकार वाले, जो हैं)। मैं आश्चर्यचकित रह जाता था - आमतौर पर - अमूर्तता के इतने स्तर को देखकर। अब मैं समझता हूं कि यह कला के लिए कला नहीं है, एक कारण है कि यह इस तरह से किया जाता है।

Answer 5

एक सिद्धांत जो मुझे अच्छे डिजाइन के लिए बहुत महत्वपूर्ण लगता है, वह है अपघटन: यदि कोई वर्ग बहुत बड़ा है (अधिक से अधिक, 300-400 पंक्तियों की संहिता) इसे छोटी कक्षाओं में तोड़ देते हैं; यदि कोई विधि बहुत बड़ी है (कहते हैं, कोड की 50 से अधिक पंक्तियाँ) इसका विघटन करती हैं; यदि किसी परियोजना में 50 से अधिक वर्ग हैं, तो इसे विघटित करें।

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

Comments

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

— jer

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

— जियोर्जियो

"परियोजना में 50 से अधिक कक्षाएं शामिल हैं, इसे विघटित करें" गंभीर नहीं है

— गतिशील

@ Yes123: यह एक विचार देने के लिए था। यह वास्तव में इस बात पर निर्भर करता है कि आप क्या विकसित कर रहे हैं, किस भाषा में हैं, आदि

— जियोर्जियो

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

— क्रेग बोविस

Answer 6

यह कठिन है, जो हम वास्तव में बात कर रहे हैं वह बेहतर कोड बनाने के बजाय अमूर्त करने की क्षमता है, लेकिन दो चीजें आपको बेहतर बनाएंगी और एक चीज आपको खुश कर देगी:

"बेहतर"

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

बी) व्यक्तिगत अभिनेताओं और उनके बीच बातचीत के रूप में सब कुछ कल्पना करो। प्रत्येक अभिनेता की एक ही भूमिका / जिम्मेदारी होनी चाहिए और उनमें से समूह विभिन्न प्रणालियों को संभालते हैं। यदि वह वार्तालाप काम करता है और प्रत्येक अभिनेता सुसंगत और सामंजस्यपूर्ण लगता है तो आप अपने रास्ते पर हैं।

और "हैपीयर"

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

Answer 7

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

आप अनुसंधान के लिए बहुत सारे ओपन-सोर्स प्रोजेक्ट पा सकते हैं।

वैसे भी आपको अभ्यास की आवश्यकता है।

Answer 8

डर में मत जीना

सादगी के लिए प्रयास करें

अपने उपयोगकर्ताओं को सुनें

बहुत सारे विचारों की कोशिश करो

कुछ बनाएं, फिर उसे बेहतर बनाएं

उन चीजों पर काम करें जो मूल्य जोड़ते हैं, उन चीजों को छोड़ दें जो नहीं करते हैं

Answer 9

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