मेरा प्रस्तावित डिज़ाइन आमतौर पर मेरे सहयोगी की तुलना में खराब है - मैं कैसे बेहतर हो सकता हूं? [बन्द है]


69

मैं कुछ वर्षों से प्रोग्रामिंग कर रहा हूं और आम तौर पर अच्छा होता है जब समस्याओं को ठीक करने और छोटे-से-मध्यम स्क्रिप्ट बनाने की बात आती है, हालांकि, मैं आम तौर पर ऑब्जेक्ट ओरिएंटेड तरीके से बड़े पैमाने पर प्रोग्राम डिजाइन करने में अच्छा नहीं हूं। कुछ सवाल

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

  2. मेरी नौकरी में पायथन में प्रोग्रामिंग शामिल है। मैं स्रोत कोड पढ़ने की कोशिश करता हूं लेकिन आपको कैसे लगता है कि मैं मुझे डिजाइन कौशल में सुधार कर सकता हूं? क्या कोई अच्छी किताबें या सॉफ्टवेयर हैं जिनका मुझे अध्ययन करना चाहिए?

कृपया मुझे ज्ञान दो। मैं वास्तव में आपकी मदद की सराहना करूंगा।


9
@Oded: मुझे लगता है कि बिंदु ओपी बना रहा है कि उनके पास सहकर्मी के रूप में समान वर्षों का अनुभव है, लेकिन सहकर्मी बेहतर डिजाइन तैयार करता है, और ओपी यह जानना चाहेगा कि वे बेहतर कैसे हों सहकर्मी के रूप में अच्छा है। मुझे लगता है ...
FrustratedWithFormsDesigner

34
@Oded: हाँ, उसे अपने 10 वर्षों में डालने के बिना एक मास्टर होने की उम्मीद नहीं करनी चाहिए, लेकिन दूसरी ओर, उन 10 वर्षों में उसे बहुत अच्छा नहीं करना है अगर उसके पास सीखने के लिए कोई स्रोत नहीं है। । वह यहाँ कुछ बढ़ने की कोशिश कर रहा है; चलो उसे हतोत्साहित नहीं करते, कृपया?
मेसन व्हीलर

6
क्या आपने अन्य डिज़ाइन से कुछ सीखा? क्या आप इसे अन्य कोडिंग स्थितियों पर लागू कर सकते हैं जो आपके पास हैं? इसे चूसो और अपने सहकर्मी से जितना हो सके उतना सीखो। दोपहर का भोजन चढ़ाएं।
जेएफओ

17
मैं चारों ओर से चिपक जाएगा। यदि आप सहकर्मी से सीख सकते हैं, तो ऐसा करें। आप एक अवसर के रूप में अहंकार को प्राप्त न होने दें - क्या होगा यदि आप आगे बढ़ते हैं और उन लोगों के साथ काम करते हैं जिनके पास आपको सिखाने के लिए कुछ भी नहीं है। मेरे पास 25+ साल का अनुभव है, लेकिन खुशी के साथ एक प्रोग्रामर से रचनात्मक आलोचना (और देने का अपना हिस्सा) लेते हैं। 3. मैं एक ऐसे लड़के के साथ काम करता हूं, जो अपने सबसे अच्छे दिन में मेरे सबसे अच्छे दिन से बेहतर है, दोनों के परिणामस्वरूप इन लोगों को मैं 2 साल पहले की तुलना में बेहतर प्रोग्रामर हूं।
मटनज

7
जीवन का एक तथ्य यह है कि आप हमेशा दूसरों को पाएंगे जो आपसे बेहतर हैं। इसे आपको निराश न करें, बस बेहतर होने के लिए अपनी शक्ति में सब कुछ आज़माएं।
मेपल_शफ़्ट

जवाबों:


69

मुझे लगता है कि यह आपके कौशल का एक बहुत ही सकारात्मक संकेत है। यह उन लोगों के लिए कहीं अधिक सामान्य है, जिन्हें एक टीम में 'बेहतर' डिज़ाइन के साथ आने में कठिनाई होती है, यह पहचानने में पूरी तरह से असमर्थ है कि कोई अन्य डिज़ाइन बेहतर क्यों है।

आपके पास आपके लिए वास्तव में दो (और आश्चर्यजनक रूप से असामान्य) ताकतें हैं:

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

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

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

तो ठोड़ी और बस याद रखें: वहाँ लोगों का एक समूह है जो दो डिजाइनों का आकलन नहीं कर सकता है और वास्तव में एक को दूसरे पर बेहतर के रूप में पहचानता है, आपको क्या लगता है कि वे अच्छे डिजाइन बनाने में साथ हो रहे हैं?

संपादित करें:
'नोटेर टिप, सिद्धांतों के आसपास अपना सिर पाने और उनके आवेदन का थोड़ा अभ्यास करने के बाद, मुझे लगता है कि यहां एक और सवाल का एक और रत्न है जो विभिन्न प्रकार की भाषाओं के अध्ययन के मूल्य पर बोल रहा है जिनके अलग-अलग उद्देश्य और नियम हैं:

आदर्श रूप से, प्रत्येक प्रोग्रामर को प्रत्येक कक्षा से एक भाषा पता होनी चाहिए। आप क्या सीख सकते हैं:

  1. एक स्थिर टाइप की गई OOP मुख्यधारा की भाषा: जावा, C # (ज्यादातर एंटरप्राइज़ सॉफ़्टवेयर में उपयोग की जाती है) और C ++ (सिस्टम प्रोग्रामिंग और जटिल डेस्कटॉप एप्लिकेशन)
  2. एक प्रोटोटाइप आधारित OOP भाषा: जावास्क्रिप्ट (क्लाइंट साइड वेब प्रोग्रामिंग)
  3. एक प्रक्रियात्मक भाषा: सी (एम्बेडेड सॉफ्टवेयर और सिस्टम प्रोग्रामिंग)
  4. एक कार्यात्मक भाषा: हास्केल, एमएल या लिस्प (कार्यात्मक भाषाएं अत्यधिक समानांतर सॉफ्टवेयर के लिए अच्छी हैं)।

एक लॉजिक प्रोग्रामिंग लैंग्वेज (प्रोलॉग) शायद उद्योग में उपयोगी नहीं है, जिसका उपयोग ज्यादातर एआई में अनुसंधान में किया जाता है।

यह उन विचारों की विविधता को व्यापक बनाने में मदद करेगा जो किसी समाधान को डिजाइन करने की कोशिश करते समय दिमाग में आते हैं।


2
+1 यदि कोई समझ सकता है कि क्यों , वे शानदार डिजाइनों के लिए अपने रास्ते पर हैं (खासकर यदि उनके पास केवल कुछ वर्षों का अनुभव है)।
डैनियल बी

22
  1. कई लोगों के लिए विभिन्न गुणवत्ता के डिजाइन के साथ आने के लिए यह बिल्कुल सामान्य है। मुझे सॉफ्टवेयर डिजाइन में प्रतियोगिताओं को जज करने के लिए अतीत में आमंत्रित किया गया है, इसलिए मैंने इस फर्स्टहैंड को देखा: यहां तक ​​कि सबसे सरल डिजाइनों में काफी अलग गुणवत्ता का समाधान हुआ, जो सभी स्मार्ट और अनुभवी लोगों से आते हैं।
  2. स्रोत डिज़ाइन पढ़ना आपके डिज़ाइन कौशल को बेहतर बनाने में आपकी मदद करने के लिए बहुत कम-स्तरीय है: कोड समग्र डिजाइन की तुलना में निचले स्तर पर जटिलता को संबोधित करता है।

सॉफ्टवेयर डिजाइन करने में सुधार करने का सबसे अच्छा तरीका सॉफ्टवेयर डिजाइन करना है * । इसे करने का एक तरीका डिज़ाइन प्रतियोगिताओं को देखकर है: TopCoder में 100+ घटक डिज़ाइनों का एक संग्रह है, जो यूएमएल डिज़ाइन प्रलेखन और जावा और / या C # में कार्यान्वयन के साथ पूरा होता है। एक तैयार घटक चुनें जिसे आप पसंद करते हैं, आवश्यकताओं के विनिर्देश पढ़ें, और आवश्यकताओं को पूरा करने के लिए एक मूल डिजाइन के साथ आने की कोशिश करें। समस्या के बारे में एक या दो घंटे बिताएं और एक वर्ग चित्र को स्केचिंग करें, फिर विजेता डिजाइन खोलें, और पढ़ें कि लेखक ने क्या किया। उनके डिजाइन की आप से तुलना करें, मतभेदों को देखें और देखें कि क्या आपका डिजाइन बेहतर है। प्रतियोगिता स्कोरकार्ड देखें कि कैसे न्यायाधीशों ने डिजाइन का मूल्यांकन किया। यह आपको प्रतिक्रिया देगा कि आपको यह तय करने की आवश्यकता है कि आपके डिजाइन कौशल को कैसे बेहतर बनाया जाए।


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


1
TopCoder को मेरे ध्यान में लाने के लिए धन्यवाद, एक शिक्षण उपकरण के रूप में उपयोग करने के लिए दिलचस्प विचार।
नेणतापिर

क्या आप, कृपया, एक संग्रह को लिंक प्रदान करने के लिए बहुत दयालु हो सकते हैं TopCoder archive of 100+ component designs,। ऐसी फाइलें नहीं मिल रही हैं।
StepUp

1
@StepUp यहाँ है । इसे एक्सेस करने के लिए आपको लॉगिन करना पड़ सकता है।
dasblinkenlight

अगर मुझे ASP.NET का अच्छा डिज़ाइन देखना है तो मुझे कहाँ देखना चाहिए? मैं आपको दिए गए लिंक पर "घटक खोजें" देखें।
StepUp

1
@StepUp ASP.NET बहुत सामान्य है। TopCoder घटक बहुत अधिक विशिष्ट हैं: SQL पार्सर, अभिव्यक्ति मूल्यांकनकर्ता, आदि
dasblinkenlight

11

खैर अपनी नौकरी मत छोड़ो। किसी ऐसे व्यक्ति के साथ काम करना बेहतर है जिसके पास आपके कौशल से बेहतर है, ताकि आप उससे या उससे सीख सकें।

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

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


3

एक बेहतर डिजाइन को पहचानना एक महत्वपूर्ण क्षमता है। डिजाइनों को देखने के बारे में पहले के कुछ सुझावों का पालन करते हुए आपको इसे बढ़ावा देना चाहिए।

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

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

आपको निम्नलिखित कुछ स्रोतों से डिजाइन के लिए विभिन्न सिद्धांतों पर विचार मिलेगा: http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf सॉफ्टवेयर डिजाइन विकिपीडिया पर "सॉफ्टवेयर डिजाइन सिद्धांत"

  • सॉफ़्टवेयर डिज़ाइन के लिए अलग-अलग मॉडल को समझें, जैसे ऑब्जेक्ट ओरिएंटेड डिज़ाइन या फ़ंक्शनल डिज़ाइन या स्ट्रक्चर्ड एनालिसिस डिज़ाइन। ये पूरी तरह से अलग मानसिकता हो सकते हैं जिसमें से एक डिजाइन कार्य करने के लिए और उनके पास प्रत्येक क्षेत्र है जहां वे उत्कृष्टता प्राप्त करते हैं। इन्हें अपने टूलबॉक्स के टूल के रूप में जानें। http://userpages.umbc.edu/~khoo/survey2.html

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

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

कुछ मज़ा है - अगर आप इसे कम से कम एक छोटा सा मजा नहीं करते हैं तो यह मत करो!


2

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

दूसरा चरण विश्लेषण करना है। उसके काम को देखो और यह मत कहो कि यह बेहतर है; यह बेहतर है क्यों यह पता लगाना । विशिष्ट विवरणों और बिंदुओं के लिए देखें जो उसने बेहतर किया।

एक बार जब आप समझ जाते हैं कि, इसके पीछे के सिद्धांतों को निकालें। ऐसे पूछें सवाल:

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

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


2

मैं यह भी जोड़ना चाहता हूं (महान उत्तरों के अलावा) कि "इससे भी बेहतर डिजाइन वह मेरे लिए बना सकता है" से अधिक है। अन्य उत्तर इस बात पर ध्यान केंद्रित करते हैं कि आप डिज़ाइन में बेहतर कैसे हो सकते हैं, जो सभी और अच्छा है ... लेकिन ...

मुझे लगता है कि आप अपने सहकर्मी से बेहतर कुछ कर सकते हैं। एक पिसिंग मैच या कुछ भी बनाने के लिए नहीं (आप वाई बेहतर कर सकते हैं? आप स्क्रू करें, मैं एक्स बेहतर कर सकता हूं!), लेकिन इस सच्चाई को इंगित करने के लिए कि सभी में ताकत और कमजोरियां हैं।

मेरी नौकरी पर 4 डेवलपर्स हैं। ऐसे समय होते हैं जहां दो मुख्य "प्रोग्रामर" सामान बना सकते हैं जो मुझे धूल में छोड़ देते हैं। मेरे सिर को अपनी रचनाओं के आसपास मेरे सिर को लपेटने की कोशिश करता है।

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

क्या वे मुझसे बेहतर हैं? किसी न किसी क्षेत्र में जरूर। हेल, बहुत सारे क्षेत्र में वे हैं - मैं अपनी दुकान पर सबसे ज्यादा जूनियर डेवलपर हूं और व्यक्तिगत रूप से उन्हें मुझ पर वर्षों का अनुभव है। उन वर्षों के अनुभव के बावजूद, मैं किसी क्षेत्र की तुलना में बेहतर हूं।

इस तथ्य पर ध्यान देना बंद कर दें कि कोई व्यक्ति आपसे बेहतर X है। वह व्यक्ति, बिना किसी कोशिश या इस बारे में सोचे भी हो सकता है कि अगले 10 वर्षों तक आप इसका अभ्यास कर सकें। ऐसा नहीं है कि आपको अपनी कमजोरियों को ठीक करने पर काम नहीं करना चाहिए, लेकिन याद रखें कि हर ताकत के लिए कमजोरी होती है।

दोनों पर ध्यान केंद्रित करें - ताकत और कमजोरियां - आपकी और आपके सहकर्मियों की।


1

जीवन के हर पहलू में आपको ऐसे लोग मिलेंगे जो आपके जितना अच्छा नहीं है, साथ ही ऐसे लोग भी हैं जो आपसे बेहतर हैं, खासकर "सिर्फ एक-दो साल" के अनुभव के बाद।

आपको हर किसी से सीखना होगा।

बुरा मत मानना। हो सकता है कि आप सहकर्मी स्वाभाविक हों। आपको उसे ईमानदारी से बधाई देना चाहिए और उससे जितना हो सके उतना सीखना चाहिए।

पेशेवर ईर्ष्या आप के बीच पाने के लिए और एक oportunity जानने के लिए मत देना।


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

  2. डिजाइन कौशल ज्यादातर अनुभव के साथ आते हैं और आप कुछ महत्वपूर्ण पुस्तकों को पढ़ने के बाद। मैं आपको अनुसरण करने की सलाह दूंगा:

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

इन पुस्तकों में से कोई भी एक जादू की गोली नहीं है, लेकिन पहले 2 सिफारिशों को पढ़ने से संभवतः प्रोग्रामिंग के बारे में आपका दृष्टिकोण और धारणा हमेशा के लिए बदल जाएगी।


0

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

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

संक्षेप में, "अनुभव का वर्ष" हमेशा समकक्ष नहीं होता है। जाओ अपने साल को कुछ बनाने लायक बनाओ।


0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.