मेरे दृष्टिकोण में, डिजाइन क्षमता विकास/कोडिंग कौशल से अधिक कठिन है।सॉफ्टवेयर डिजाइन कौशल में सुधार कैसे करें?
एक आवश्यकता का सामना करते समय, फ़ंक्शन मॉड्यूल को कैसे डिज़ाइन किया जाए, प्रोग्राम आर्किटेक्चर को सही तरीके से कैसे बनाया जाए?
वैसे, क्या कुछ किताबें संबंधित हैं?
मुझे लगता है कि उत्तर यह है कि अधिकांश माध्यमिक प्रोग्रामर अक्सर ऐसा नहीं करते हैं: अन्य लोगों के कोड को पढ़ें और इससे सीखें, इसकी ताकत और कमजोरियों का विश्लेषण करें, और अपने प्रोग्रामिंग ट्रिक्स बैग में भी शामिल करें जो आप दिलचस्प देखते हैं। कई अच्छी तकनीकें जिनका पहले से आविष्कार किया गया है, आपके कोडिंग कौशल को सशक्त बनाएगा और आपको बहुत समय बचाएगा।
अनुसंधान के लिए ओपन सोर्स प्रोजेक्ट्स में कई उच्च गुणवत्ता वाले कोड हैं।
परीक्षण और त्रुटि यह देखने का सबसे अच्छा तरीका है कि आपके स्वयं के डिज़ाइन कैसे सुधार सकते हैं। हमेशा एक बेहतर समाधान की तलाश करें। आपने क्या गलतियां की? यह आवश्यक होने की तुलना में कम लचीला हिस्सा क्या था? आपके द्वारा किए गए डिज़ाइन निर्णय के आसपास आपको क्या करना है?
पूरी तरह से लचीलापन और लालित्य की बजाय डिजाइन के प्रभावों के बारे में सोचें। इस पुन: प्रयोज्य बनाने के लिए आपने किन व्यापारिक बंद किए हैं? क्या आप seperation of concerns और single responsibility principle का पालन कर रहे हैं? Open closed principle? क्या आप जानते हैं कि ये क्या हैं और उनके प्रभाव क्या हैं?
डिजाइन पैटर्न के रूप में विशेषज्ञों के काम का भी अध्ययन करें।
पढ़ें Design Patterns Explained by Shalloway, पढ़ें Head first design patterns
हालांकि याद रखें कि ये जादुई गोली समाधान नहीं हैं और नमक की एक चुटकी के साथ सब कुछ ले लो। अपनी रचनात्मकता का प्रयोग करें और व्यावहारिक रहें।
मुझे लगता है कि यह सब अनुभव करने के लिए नीचे आता है। आवश्यकताओं के एक सेट को पढ़ने और उन्हें एक अच्छे, स्वच्छ, रखरखाव योग्य सॉफ्टवेयर डिजाइन में अनुवाद करने में सक्षम होने के कारण प्रोग्रामिंग (इम्हो) में सबसे कठिन चीज है और आप केवल एक पुस्तक पढ़कर नहीं सीखते हैं। यह गलतियों को करने, गलतियों को सीखने, और सीखने के बारे में है कि अतीत में आपके लिए किस डिजाइन ने काम किया है या नहीं।
मेरे लिए, यह वास्तव में मेरा समय लेने और यूएमएल में एक अच्छा डिजाइन बनाने में मदद करता है, उदाहरण के लिए एक कक्षा आरेख। यह अक्सर मुझे पहचानने और घटकों में मदद करता है कि मैं पूरे सॉफ्टवेयर एप्लिकेशन का पुन: उपयोग कर सकता हूं, जहां मैं एक निश्चित डिजाइन पैटर्न, इत्यादि का उपयोग कर सकता हूं।
कुछ किताबें मैं सिफारिश कर सकते हैं: Software Architecture in Practice है, जो सॉफ्टवेयर वास्तुकला के बारे में एक बहुत अच्छी किताब है, और Design Patterns चार के गिरोह है, जो किसी भी डिजाइन पैटर्न आप उपयोग कर सकते हैं के लिए एक महान संदर्भ है कर रहा है।
मैं नहीं मानता कि अनुभव और प्रतिभा के लिए किसी भी विकल्प नहीं है, और मैं सॉफ्टवेयर डिजाइन पर एक किताब है कि मैं शिक्षण डिजाइन की दृष्टि से की सिफारिश कर सकता है कभी नहीं पढ़ा है, के बावजूद पढ़ काफी कुछ । कुछ लोग इसमें अच्छे होते हैं, और अनुभव प्राप्त करते समय बेहतर होते हैं, और कुछ नहीं होते हैं, और कभी नहीं सीखते हैं। दुखद लेकिन सत्य।
मुझे लगता है कि कुछ महान ओपन सोर्स परियोजनाओं के डिजाइन को देखकर मुझे लगता है। कोड पढ़ना और ओपनसोर्स परियोजनाओं के डिजाइन को देखना मेरी राय में डिजाइनिंग सीखने का सबसे अच्छा तरीका है।
"परीक्षण और त्रुटि" कहने के बजाय, मान लें "पुनरावृत्ति"।
जो भी आप डिज़ाइन कर रहे हैं, बस इसे आपके पास दी गई जानकारी के साथ अपना सर्वश्रेष्ठ शॉट दें, यह जानकर कि आपके पास पूर्ण ज्ञान नहीं है। फिर आप निस्संदेह एक अप्रत्याशित मुद्दे में भाग लेंगे जो चीजों को जटिल बनाता है। यह तब होता है जब आपको खुद से पूछना पड़ता है कि क्या गलत हुआ और अलग-अलग क्या करना है। फिर वापस जाएं और अपनी नई समझ के साथ दोबारा डिजाइन करें। दोहराएँ। हमेशा अपने डिजाइन का अनुमान लगाएं और बेहतर समाधान के लिए अपने आस-पास देख रहे हों। उदाहरण के लिए, "फ़ायरफ़ॉक्स कैसे कार्यान्वित करता है? ओह, मैं देखता हूं, वे पॉपअप विंडो का उपयोग नहीं करते हैं, और इसका अधिक क्लीनर।"
इस तथ्य को स्वीकार करते हुए कि आप गलतियां करेंगे और उन्हें ठीक करने के इच्छुक हैं, आप पहले से ही पैक से आगे हैं।
जैसे ही आप अनुभव प्राप्त करते हैं, आप पुनरावृत्ति लंबे हो जाएंगे, और थोड़ी देर में आपको पहली बार चीज़ें मिलेंगी - इसमें कोई संदेह नहीं है क्योंकि आप गलतियों और अतीत से उनके समाधान की भविष्यवाणी कर सकते हैं।
जहां तक किताबें चिंतित हैं, अगर मुझे सही याद है, "स्टीव के मस्तिष्क के अंदर" इस बात के बारे में बात की गई कि पुनरावृत्ति ऐप्पल के विकास के लिए आंतरिक है।
मैं अब तक के अधिकांश सुझावों से सहमत हूं, वे सभी मान्य हैं - कोड पढ़ें, किताबें पढ़ें, सामानों को आजमाएं।
जहां मैंने सबसे बड़ा लाभ देखा है, व्यक्तिगत रूप से और टीम के सदस्यों दोनों में दो गुना हमला है: 1. उन्हें अपने आराम क्षेत्र से बाहर निकालें - यानी एक अपरिचित डोमेन या भाषा, क्रश को दूर करें। 2. और, शायद अधिक महत्वपूर्ण बात यह है कि उन्हें किसी ऐसे व्यक्ति के साथ जोड़ दें जो पहले से ही अनुभवी है।
सलाह देने के लिए बहुत कुछ है, तो आप वहां स्वयं पहुंच सकते हैं, लेकिन एक अच्छा सलाहकार आपको वर्ष दर्द से बचा सकता है।
निश्चित रूप से, अनुभव सही जवाब है। लेकिन इससे परे, मुझे लगता है कि अपने संदर्भ में पैटर्न को समझने के लिए कुछ कहा जाना चाहिए: जैसे ही आप अपने अनुप्रयोग बना रहे हैं, डिजाइन निर्णय लेते हैं जो आपको व्यावहारिक समझ देते हैं। बुद्धिमानी के लिए, उन्हें मत करें क्योंकि यह 'सर्वोत्तम अभ्यास' है, या क्योंकि एक अनुभवी प्रोग्रामर ने आपको बताया है। उन्हें करें क्योंकि आप समझते हैं कि क्यों और यह आपको (या अन्य प्रोग्रामर) कोड के साथ काम करने में मदद करता है और इसे बेहतर समझता है। मुझे लगता है कि डेटाबेस डिजाइन जैसी चीजों के साथ भी यही सच है। एक अंतर्ज्ञानी, रखरखाव दृष्टिकोण से क्या समझ में आता है। 8 में से 7 बार, यदि आपने वास्तव में इसे (या विभिन्न नुकसान से सीखा) के माध्यम से सोचा है, तो आप पाएंगे कि आप सक्रिय रूप से बिना किसी प्रयास के 'पैटर्न' या अभ्यास के कुछ वर्ग कर रहे हैं।
बेशक, मैं किसी को वैक्यूम में काम करने का सुझाव नहीं दे रहा हूं; न ही वे निश्चित रूप से डिजाइन पैटर्न को सक्रिय रूप से आगे बढ़ाने और एकीकृत नहीं करते हैं। मुझे लगता है कि उन्हें अपने स्वयं के संदर्भ में समझना (और विशिष्ट, व्यावहारिक कारणों से) यह है कि चीज को कम करने में सबसे ज्यादा मदद मिलती है। वैसे भी मेरा अनुभव रहा है। किताबें पढ़ना हमेशा मुझे सीखने की तरह लगता है। अच्छी सहायक सामग्री, लेकिन ढलान में आने के बगल में छोटे आलू। अपने फैसलों को सोचें और उनकी रक्षा करने में सक्षम हों। हमेशा एक बेहतर तरीके से खुला रहें।
मैं कहूंगा कि परीक्षण और त्रुटि आपके डिज़ाइन को बेहतर बनाने के लिए सबसे खराब तकनीक होगी। अक्सर टाइपिंग के बिना सोचने में कुछ दिन बिताते हैं और बाद में बहुत सारे प्रयास बचाते हैं और परियोजना की सफलता के लिए एक बेहतर डिजाइन तैयार करते हैं जो निर्णायक होता है। – piotr
मैं असहमत हूं। मुझे लगता है कि रॉब का मतलब है आपकी पिछली गलतियों से सीखना। जैसा कि मैंने अपनी पोस्ट में भी कहा है, मुझे नहीं लगता कि आप बिना किसी छोटे अनुभव के, एक पुस्तक उठा सकते हैं, सॉफ्टवेयर डिज़ाइन के बारे में कुछ सामान पढ़ सकते हैं, और उसके बाद कुछ बढ़िया हो सकते हैं, खासकर अगर सॉफ्टवेयर बहुत जटिल नहीं है ।आपको वास्तव में अपने लिए अनुभव करना होगा कि क्या काम करता है और काम नहीं करता है, और दो बार एक ही गलती नहीं करता है। यह निश्चित रूप से नहीं कहना है कि कुछ दिन सोचने से आपके डिजाइन में मदद नहीं मिलती है - लेकिन यह सब कुछ नहीं है। – Razzie
हाँ, मेरा मतलब हैक और उम्मीद डिजाइन नहीं है, मैं आपके डिजाइन को लागू करने और आपके मूल से क्या काम करता है और क्या नहीं देख रहा हूं। इसलिए रज़ी ने स्पष्ट किया कि मेरा मतलब है कि गलतियों से सीखना एक दृष्टि अनुभव है। –