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

Question

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

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

इस समस्या से निपटने के लिए मुझे क्या करना चाहिए?

Comments

xkcd ने आज इसे कवर किया ।

— zzzzBov

व्हाइटबोर्ड पर एक सहकर्मी के साथ चर्चा करें। यह अक्सर मामले को स्पष्ट करने में मदद करता है और यदि आप सहमत हो सकते हैं तो इसके पास एक अच्छा विकल्प होने का एक अच्छा मौका है

Answer 1

दो सरल नियम:

1. सबसे सरल काम करें जो संभवतः काम कर सकता है।
2. लगातार रिफ्लेक्टर।

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

याद रखें कि भविष्य के अशुद्धि जाँच का मतलब है कि कोड को बदलना आसान है, न कि आपके कोड को बदलने की आवश्यकता हो सकती है।

Comments

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

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

निश्चित रूप से सहमत हैं। "रेड, ग्रीन, रिफ्लेक्टर" जाने का रास्ता है।

— रीन हेनरिच्स

एक्सपी हैंडबुक से लवली थोड़ा टिडबिट, लेकिन संदर्भ से बाहर ले जाने पर वास्तव में महान सलाह नहीं।

— आरोन

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

— आरोह

"सबसे सरल काम करें जो संभवतः काम कर सकता है" किसी भी अतिरिक्त संदर्भ की आवश्यकता नहीं है। Refactoring करता है, लेकिन जो कोई संदर्भ नहीं जानता है वह कैसे सीख सकता है कि संदर्भ कैसे सीखना है लेकिन संदर्भ सीखना?

— रीन हेनरिच

Answer 2

आमतौर पर जब मुझे लगता है कि इसका मतलब है कि मुझे कोशिश करने की आवश्यकता है:

1. खड़े हो जाओ, चारों ओर चलो, और सुनिश्चित करें कि सभी जीवविज्ञान ठीक काम कर रहा है।
2. एक व्हाइटबोर्ड पर जाएं और तब तक आकर्षित करें जब तक मुझे आत्मविश्वास की भावना न मिल जाए।
3. एक "डिज़ाइन शिकायत मित्र" ढूंढें, जिसके साथ आप समस्या के बारे में बात कर सकते हैं।

यदि समस्या में वाक्य रचना और छोटे टुकड़े शामिल हैं, तो:

1. अपने आप को संतुष्ट करें, भले ही वह बदसूरत हो, यह अच्छी तरह से कहीं से घिरा हुआ है, और शुद्ध रूप से स्थानीय प्रकार के cruft का प्रतिनिधित्व करता है।
2. TODO मार्कर या केवल टिप्पणियां जोड़ें जो बताती हैं कि कोड आपको क्यों परेशान करता है।
3. अगले कार्य के लिए आगे बढ़ें।

Comments

पहले और दूसरे दोनों # 2 के लिए +1। बक्से, लाइनों और लेबलिंग को आकर्षित करना और बड़ी तस्वीरें प्राप्त करना आमतौर पर मुझे विकल्पों के बीच तय करने में मदद करता है। यदि आपके पास एक अच्छा कोड विश्लेषक है जो कार्यों को ट्रैक करता है (हडसन TODOs को ट्रैक कर सकता है और उन्हें आपके बिल्ड में अच्छी तरह से प्रदर्शित करता है), तो आप उन चीजों को आसानी से ट्रैक कर सकते हैं जो आपको पसंद नहीं हैं।

— रैंडी

Answer 3

अपने आप को निष्क्रियता में सोचना बहुत आसान है। यहां तक ​​कि अगर आप प्रबंधन करते हैं, किसी भी तरह, सबसे अच्छा समाधान के साथ आने के लिए जो अभी प्रोजेक्ट को पूरा करने से पहले आसानी से बदल सकता है, और फिर क्या?

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

Comments

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

— ऐनी नॉनिमस

@anne: तुरंत कुछ रचनात्मक करना बेहतर है, सही बात बहुत देर से। केवल एक चीज जो गलत चीज के लिए निश्चित है, वह कुछ भी नहीं करना है।

— सतनिकप्‍पी 20

Answer 4

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

Answer 5

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

यदि आप गैर-पूरी तरह से चुनने की संभावना के बारे में चिंताओं से ग्रस्त हैं, तो यहां कुछ विचार दिए गए हैं:

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

सौभाग्य! :)

Answer 6

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

Answer 7

निर्णय लेने की अनिच्छा को दूर करने के लिए, टाइमबॉक्सिंग लागू करें : कुछ मिनटों में बंद होने के लिए अलार्म घड़ी सेट करें; तब तक के लिए अपने दिमाग को पीड़ा दें, लेकिन जब अलार्म बंद हो जाता है, तब तक के लिए सबसे अच्छा विकल्प चुनें।

Comments

और फिर वह खुद को पीड़ा देने में घंटों बिता सकता है कि अलार्म घड़ी को कितनी देर तक सेट किया जाए! :)

— जॉर्डन

जॉर्डन: उस समस्या के कई संभावित समाधान भी हैं। दुर्भाग्य से, मैं यह तय नहीं कर सकता कि कौन सा प्रस्ताव करना है।

— user281377

Answer 8

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

एक बार जब आप इसे बना लेते हैं, और इसे फेंक देते हैं, तो मैं शर्त लगा सकता हूं कि आपके पास उन निर्णयों को बनाने का एक आसान समय होगा।

Comments

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

— मेपल_शफ्ट

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

— डेरेन

एक शाखा में प्रोटोटाइप, आवश्यक परीक्षण करते हैं, और कोर में एक स्वच्छ संस्करण बनाते हैं।

— zzzzBov

Answer 9

मैं इस समस्या से भी ग्रस्त हूं। मैं क्या कहूंगा कि आपके पास पर्याप्त प्रोत्साहन नहीं है।

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

आपको इसे घटकों में विभाजित करने और उन्हें खत्म करने के लिए खुद को पुरस्कृत करने की आवश्यकता है, भले ही यह सिर्फ कुछ कंसोल आई / ओ के साथ हो जो दिखाता है कि यह काम कर रहा है।

Answer 10

मैं अन्य पोस्टरों की पंक्ति के साथ आपके सवाल और सोच को पढ़ रहा था: आप इस नौकरी के अनुकूल नहीं हैं; अपने आप को एक समय सीमा दें; एक पल के लिए कुछ और करो। कुछ प्रतिबिंब के बाद, मुझे यकीन नहीं है कि कोई भी उत्तर वास्तव में उपयोगी है

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

अब मुझे समान समस्याएं हैं, लेकिन कोड के साथ इतना नहीं .. आमतौर पर इसके खाने के लिए क्या है .. पिज्जा या करी .. हम्म ... पिज्जा लेकिन फिर करी अच्छा है, लेकिन क्या मुझे करी पसंद है, पिज्जा सस्ता है , लेकिन फिर आप और अधिक करी, लेकिन ... और इसी तरह। :)

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

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

बेशक, सभी का उत्तरार्द्ध भी महत्वपूर्ण है - आपके पास जितना अधिक काम है, उतना कम विलासिता के लिए आपको समय बिताना होगा।

Comments

स्निपेट प्रोग्रामिंग सबसे खराब तरह का अभ्यास है

— नील बटरवर्थ

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

— जॉर्डन

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

— gbjbaanb

Answer 11

यहाँ एक रणनीति है जो रीन हेनरिक्स ( सरल, प्रारंभकर्ता) और ammoQ ( टाइमबॉक्सिंग ) के सुझावों को जोड़ती है :

1. अपने आप को एक पहले समाधान के लिए बहुत सख्त समय सीमा दें जो बस काम करता है। एक चर नाम के लिए उदा 30 सेकंड। आप पहले किसी चीज़ को लेकर आ सकते हैं x, फिर उसे परिष्कृत कर सकते हैं string, तब nameतक जब तक समय नहीं है।
2. फिर कुछ निर्दिष्ट समय के लिए अन्य कार्यों के लिए आगे बढ़ें , जैसे 10 मिनट।
3. इसके बाद ही अपने निर्णय को और बेहतर बनाने के लिए अपने आप को एक और समय बॉक्स की अनुमति दें , जैसेuserHandle

इस दृष्टिकोण के संभावित लाभ :

• बाद में इसके वापस आने का ज्ञान अब के लिए समस्या को दूर करने में आसानी कर सकता है
• अन्य कार्यों को जारी रखते हुए, आप समय-समय पर अफवाह के बिना एक अच्छा संतोषजनक समाधान के साथ आ सकते हैं
• चरण 1 के बाद जाने दें और चरण 2 के प्रवाह में होने के कारण , चरण 3 को वास्तव में तेज रखना आसान हो सकता है, जैसा कि आप चरण 2 के साथ जारी रखना चाहते हैं , और इस प्रकार खुशी से बस एक सभ्य समाधान चुनें और इसे स्वीकार करें

Comments

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

— एडम लेअर

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

— एरोन थोमा

Answer 12

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

Answer 13

आमतौर पर कारण आप तय नहीं कर सकते अंतर बहुत महत्वहीन है, या आपके पास पर्याप्त जानकारी नहीं है।

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

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

Answer 14

अक्सर, सबसे अच्छा उपाय यह है कि आप अपने निर्णय को किसी सहकर्मी को समझाने की कोशिश करें। हालाँकि, जब से आप इसे बहुत बार नहीं करना चाहते हैं, तो अगली सबसे अच्छी बात कागज पर सोचना है - या तो एक कागज / कलम, या एक खाली नोटपैड खिड़की के साथ।

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

समस्या को बताएं, फिर संभावित समाधान बताएं, प्रत्येक के बारे में क्या अच्छा है, आदि।

हालांकि यह हमेशा काम नहीं करता है, आपके सिर (रैम) और बाहरी मीडिया (नोटपैड दस्तावेज़) पर विचारों को प्राप्त करने की प्रक्रिया आपको नए कनेक्शन बनाने और विभिन्न दृष्टिकोणों से निर्णय देखने की अधिक स्वतंत्रता देती है।

Answer 15

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

बड़ी समस्याओं के लिए, मुझे लगता है कि पहले आपके विकल्पों के माध्यम से सोचने में योग्यता है, लेकिन इसे टाइमबॉक्स करें। बड़ी समस्याओं के बड़े समाधान स्थान हैं, आप हर संभावना का मूल्यांकन नहीं कर सकते हैं, न ही आपको करने की कोशिश करनी चाहिए।

TLDR; एक उचित समाधान चुनें, इसे सुधारें जैसे आप जाते हैं।

यह भी प्रासंगिक है:

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

खैर, समय आ गया और एक जिज्ञासु तथ्य सामने आया: उच्चतम गुणवत्ता के कार्यों को समूह द्वारा मात्रा के लिए वर्गीकृत किया गया। ऐसा लगता है कि जब "मात्रा" समूह व्यस्त रूप से काम के ढेरों का मंथन कर रहा था - और अपनी गलतियों से सीख रहा था - "गुणवत्ता" समूह पूर्णता के बारे में सिद्धांतबद्ध कर बैठे थे, और अंत में ग्रैंड थ्योरी और सिद्धांतों की तुलना में उनके प्रयासों को दिखाने के लिए बहुत कम था। मरी हुई मिट्टी का ढेर।

से http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html ।

Answer 16

मुझे यह कभी समझ नहीं आया। जब मैं एक प्रशिक्षक था, तो मैं कुछ कहना चाहूंगा:

"OK, create an integer variable and assign the return value of strlen() to it."

बहुत जटिल नहीं है, आप सोच सकते हैं, और 95% लोगों ने कुछ ऐसा लिखा है:

int x;   // or y, or len, or whatever
x = strlen( s );

लेकिन कभी-कभार ऐसा होगा जो हेडलाइट्स में लकवाग्रस्त खरगोश की तरह बैठा हो। मैं सहानुभूतिपूर्वक पूछूंगा कि समस्या क्या थी, और वे कहेंगे "मुझे नहीं पता कि इसे क्या कहा जाए!"।

ये वे लोग हैं जिन्हें दूसरे करियर की तलाश करनी चाहिए। जैसा कि शायद आपको होना चाहिए।

Comments

@ कोई भी धारणा नहीं बना रहा है - आपने स्वयं कहा कि आपको चीजों के लिए नामों पर विचार करना कठिन लगता है - "बहुत बार, मैं सबसे अच्छा डिजाइन निर्णय चुनते समय अटक जाता हूं। यहां तक ​​कि छोटे विवरणों के लिए भी, जैसे ... चर नाम"।

— नील बटरवर्थ

और मुझे दूसरे कैरियर की तलाश क्यों करनी चाहिए क्योंकि मुझे कुछ चीजों के नामकरण में कठिनाई होती है? प्रत्येक अवधारणा में प्राकृतिक भाषा के लिए एक साफ, छोटी मानचित्रण नहीं है।

— ऐनी नॉनिमस

@Anne आपके मूल प्रश्न का जोर मुझे लगता है कि आपको स्वाभाविक रूप से अच्छे प्रोग्रामर के लिए क्या करने में समस्या आ रही है। इसमें कोई शर्म की बात नहीं है - ज्यादातर लोग (यहां तक ​​कि अधिकांश प्रोग्रामर!) इन चीजों को करने के लिए भयानक हैं। हालांकि, यह मानते हुए कि मेरी तरह आप केवल कुछ ऐसा कर के खुश रह सकते हैं जो आप वास्तव में अच्छा है, मैंने सुझाव दिया कि प्रोग्रामिंग वह नहीं हो सकती है जिसे आप के लिए काट रहे हैं। मैंने अपने वयस्क जीवन के पहले 10 वर्षों को एक सूक्ष्म जीवविज्ञानी के रूप में बिताया। जब मैं एक प्रोग्रामर के रूप में परिवर्तित हुआ तो मैं इसमें बहुत अच्छा नहीं था, और बहुत खुश था।

— नील बटरवर्थ

सभी के लिए एक अनुकूल अनुस्मारक: यदि आप जवाब से असहमत हैं, तो उसे व्यक्त करने के लिए डाउनवोट का उपयोग करने के लिए स्वतंत्र महसूस करें। दोनों ओर से व्यक्तिगत हमलों को हटा दिया जाएगा।

— एडम लेअर

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

— डेडएमजी