अगर मुझे अपनी समस्याओं का समाधान उसी तरह करना चाहिए तो क्या मुझे चिंतित होना चाहिए?

13

मुझे वास्तव में प्रोग्रामिंग गेम्स और पज़ल निर्माता / गेम्स पसंद हैं। मैं अपने आप को इन समस्याओं का एक ही तरह से इंजीनियरिंग का पता लगाता हूं और आखिरकार इसी तरह की तकनीक का उपयोग करके उन्हें प्रोग्राम करता हूं कि मैं वास्तव में सहज हूं।

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

हालांकि यह एक संक्षिप्त उदाहरण है, यह सभी स्थितियों में सटीक नहीं है। यह सिर्फ एक तरीका है जिससे मैं वास्तव में सहज महसूस करता हूं। क्या यह बुरा है?

problem-solving

— ब्रायन हैरिंगटन
स्रोत

यदि आप खुद को दोहराते रहते हैं, तो पुन: प्रयोज्य घटक क्यों नहीं बनाते हैं?

— कुगेल

जरूरी नहीं, अगर यह उन्हें हल करने का एक अच्छा तरीका है :)

— haylem

4

यदि आप हर समय खुद को दोहरा रहे हैं, तो एक पुस्तकालय लिखें।

— अय्यूब

@ ब्रायन हैरिंगटन ने स्वयं उसी समस्या का सामना किया है, मुझे कहना होगा कि मैं व्यापार तर्क (काम पर) से लेकर कर्नेल प्रोग्रामिंग (घर पर) और C # (काम पर) से लेकर C ++ (घर पर) तक विभिन्न डोमेन पर काम कर रहा हूं। मेरी बहुत मदद की। मैं भी खुला स्रोत कोड पढ़ने की आदत में मिल गया है यहाँ हैं कुछ लिंक :) इसके अलावा, आप पढ़ सकते हैं GOF

— Chani

26

नहीं यह ठीक है।

व्यावहारिक प्रोग्रामिंग का उद्देश्य उन समाधानों को खोजना है जो संभवतः कई समान विकासों में उपयोगी होंगे। तुम बस एक मिल गए।

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

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

— कैफीक

12

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

— user281377
स्रोत

1

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

— सातनिकपुप्सी

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

— कैफ़ेगिक

@Chad -

— normanthesquid

5

हमारे दिन के कामों में वास्तविक रूप से हम काफी हद तक समान समस्याओं का सामना करते हैं।

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

यदि आप कुछ अच्छी तरह जानते हैं तो संभावना है कि आप इसे आवश्यकतानुसार फ्लेक्स कर सकते हैं और यह कि आपका कार्यान्वयन ठोस और प्रभावी होगा। नई तकनीकों में आपके पहले प्रयासों से शायद वे चीजें सही नहीं होंगी।

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

शायद कुछ गैर-जरूरी / गैर-महत्वपूर्ण परिवर्तन उठाएं और वैकल्पिक समाधानों के साथ गति प्राप्त करने के लिए उनका उपयोग करें?

— जॉन हॉपकिंस
स्रोत

4

अच्छा सवाल है, और मुझे यह स्वीकार करना होगा कि यह मुझे परेशान करता है।

यह ठीक कब है? अपने कोड का प्रदर्शन विश्लेषण करें - यदि आप देखते हैं कि आप ओ (लॉग एन) या ओ (एन) या ओ (एन लॉग एन) में हैं और इस तरह की समस्या ज्ञात डेटा संरचनाओं के लिए अनुपयुक्त है, तो आप आमतौर पर ठीक हैं।

यह कब ठीक नहीं है? आपका समय या स्थान जटिलता O (n ^ 2) या इससे भी बदतर है, या परिभाषा के अनुसार समस्या NP पूर्ण है। इन स्थितियों में आपको उचित आंकड़ों को लागू करने की आवश्यकता है, अन्य डोमेन से ज्ञान लागू करें आदि।

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

— Fanatic23
स्रोत

3

जरूरी नहीं, अगर यह उन्हें हल करने का एक अच्छा तरीका है :)

आमतौर पर "समाधान" पर काम करते समय, मैं इन चीजों के लिए जाता हूं:

सादगी ,
पुन: प्रयोज्य ,
और केवल अंतिम प्रदर्शन ।

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

अजीब तरह से, जब सी में कोडिंग, मैं जावा में कोडिंग की तुलना में प्रदर्शन के बारे में बहुत अधिक परवाह करता हूं ... आदत का बल :)

— haylem
स्रोत

2

जब तक समस्या कुशल तरीके से हल हो रही है, चिंता करने की कोई जरूरत नहीं है।

— मनोज आर
स्रोत

2

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

— गौरव
स्रोत

2

यदि यह काम करता है, तो यह ठीक है।

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

— जेवियर
स्रोत

2

यदि आप समस्या को हल करते हैं तो यह अच्छा है। और इससे कोई फर्क नहीं पड़ता कि यह किस तरह से अधिक समस्याएँ पैदा नहीं करता।

— डाइनिअस
स्रोत

0

"डेवलपर कला" वास्तव में सही उत्तर है यदि आपका लक्ष्य किसी उत्पाद का उत्पादन करना है। और अगर आपका "कारखाना" उन उत्पादों का उत्पादन करता है जो संतुष्ट करते हैं तो ठंडा करते हैं।

परंतु...

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

यह वास्तव में न्यूरोलॉजिकल अनुसंधान के माध्यम से समर्थित है। तो यह तूम गए वहाँ।

— ElGringoGrande
स्रोत