रचनात्मक कोडिंग के बारे में इतना बुरा क्या है? [बन्द है]


42

मैं आज रात बॉब रॉस को कुछ "खुश पेड़ों" को देख रहा था , और मुझे लगा कि मेरे कोड के बारे में मुझे हाल ही में पता चला है।

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

मुझे समझाएं कि "रचनात्मक रूप से कोडिंग" से मेरा क्या मतलब है:

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

इस प्रक्रिया के दौरान, मैं हमेशा सफाई कर रहा हूं। मैं अप्रयुक्त कोड को हटाता हूं, और कुछ भी टिप्पणी करता हूं जो स्पष्ट नहीं है। मैं लगातार परीक्षण करता हूं।

मेरी प्रक्रिया पेशेवर डेवलपर समुदाय में जो स्वीकार्य है, उसके दाने के खिलाफ जाना लगता है, और मैं समझना चाहूंगा कि क्यों।

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

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

मैं ईमानदारी से आपके इनपुट की सराहना करता हूं, चाहे आपकी कोई भी समस्या हो।

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


6
आपके काम करने के तरीके में कुछ भी गलत नहीं है, आप जानते हैं कि अंतिम परिणाम में क्या महत्वपूर्ण है, और यही वास्तव में मायने रखता है। यह सिर्फ इतना है कि आपके पास इस तरह से एक बड़ी टीम के साथ काम करने का कठिन समय हो सकता है, लेकिन अगर ऐसा है तो आप शायद इसे अपनाएंगे। यह वास्तव में लगता है कि आप विश्लेषण पक्षाघात के लिए सीधे जा रहे हैं: sourcemaking.com/antipatterns/analysis-paralysis
Freund-Hansen

39
महीनों का पुनर्लेखन आपको नियोजन के दिनों को बचाएगा!
जोनास

3
@ जोनास: अच्छा है। लेकिन आपको वास्तव में विश्लेषण पक्षाघात को कम नहीं समझना चाहिए। इन दिनों मेथोडोलॉजी, डिज़ाइन पैटर्न आदि पर सभी "अच्छी सलाह" के साथ, यह धारणा प्राप्त करना वास्तव में आसान है कि आपको कोड की एक पंक्ति को छूने से पहले दिन और दिनों के लिए योजना, विश्लेषण और डिजाइन करना चाहिए। । और यह आसानी से बहुत उल्टा हो सकता है। मेरा मानना ​​है कि यह समझना है कि आगे की योजना और डिजाइनिंग आपको लंबे समय में मदद कर सकते हैं, और समझ सकते हैं कि कब आप किस पर काम कर रहे हैं, और वास्तव में कुछ पाने के लिए कुछ एहसास पाने के लिए गोता लगाएँ।
Bjarke Freund-हैनसेन

4
चंचल घोषणा पत्र से: "कार्य करना सॉफ्टवेयर प्रगति का प्राथमिक उपाय है।"
गैरी रोवे

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

जवाबों:


29

कोड-टेस्ट-रिफलेक्टर-रिपीट के साथ कुछ भी गलत नहीं है, बस लोगों को बताएं कि आप प्रोटोटाइप कर रहे हैं।

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

पुनश्च: आरेख तकनीक आपको विज़ुअल थिंकिंग स्किल्स सीखने में मदद करती है, जो मूल्यवान हैं भले ही कोई भी हो लेकिन आप कभी भी अपने आरेखों को देखते हैं।


4
"कोड-टेस्ट-रिफ्लेक्टर-रिपीट" (या इसके कुछ क्रमपरिवर्तन) कैसे हम कोड लिखते हैं। शायद सुपरमैन "कोड-किया गया" है, लेकिन नश्वर लोगों को पुनरावृति करने की आवश्यकता है।
मार्टिन विकमैन

5
@ मर्टिन: उस लूप में कुछ अप-फ्रंट सोच अक्सर फायदेमंद होती है ;-)
स्टीवन ए। लोव

4
जब तक आप जानते हैं कि "कुछ" कितना है!
फ्रैंक शियरर

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

7
@ ब्रैड, याद रखें कि कभी-कभी प्रोटोटाइप को विकसित होने के बजाय मरने की आवश्यकता होती है।

21

मैं हमेशा किसी भी नेत्रहीन, यूएमएलईडी, डिज़ाइन-पैटर्न वाले कोड को स्पष्ट, पठनीय, सरल कोड पसंद करता हूं, जहां कक्षा / इंटरफ़ेस में "ItemVisitor" (!) जैसे पैटर्न नाम शामिल हैं। डिजाइन पैटर्न, OO तकनीक और बाकी सब कुछ नियमों को औपचारिक बनाने के लिए हैं। यह नियम सामान्य ज्ञान से आते हैं।

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

अपने कोड को फिर से लिखने में संकोच न करें। मैं इसके लिए X डाउनवोट्स (X> = 10) लेने जा रहा हूं, लेकिन मैं इसे बोल्ड कर दूंगा: कोड की पुन : प्रयोज्यता सबसे महत्वपूर्ण बात नहीं है

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


4
+1 के लिए "कोड की पुन: प्रयोज्य सबसे महत्वपूर्ण बात नहीं है"। कभी-कभी आपको स्विस आर्मी नाइफ की आवश्यकता होती है, कभी-कभी आपको स्केलपेल की आवश्यकता होती है।
एमयू

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

+1 फिर से "कोड की पुन: प्रयोज्यता सबसे महत्वपूर्ण बात नहीं है" और एक भी डाउनवोट नहीं है (अब तक)
गैरी रोवे

मुझे लगता है कि "पुनरावृत्ति" पर अत्यधिक ध्यान न दें खुद को दोहराएं और दोहराव को समाप्त करने का एक इंच संस्करण था।
रोब के

: "उपयोग पुन: उपयोग से पहले" यहां तक कि यह एक अच्छी छोटी पुस्तक में बनाया 97things.oreilly.com/wiki/index.php/...
Lovis

14

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

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


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

1
@Greg - फिर भी, आपके लिए एक अच्छा, स्पष्ट और तार्किक कारण मेरे लिए पूरी तरह से अतार्किक हो सकता है।
जेसन बेकर

1
+1। जो कोई भी यह कहता है कि आपको बिल्कुल ऐसा करना चाहिए और यह केवल स्पष्ट गलत है। निश्चित रूप से, आपको दूसरों (विशेष रूप से महान और अनुभवी लोगों) का अध्ययन करना और सुनना चाहिए, कठिन सोचें, वैकल्पिक दृष्टिकोणों की तुलना करें और तुलना करें आदि, लेकिन अंत में, वही करें जो आपको सही लगता है। यदि आप बस औसत दर्जे का होना चाहते हैं, तो आगे बढ़ें और डिज़ाइन प्रक्रिया का पालन करें, लेकिन कुछ भी योग्य होने के लिए, आपको खुद पर भरोसा करना चाहिए।
जूनस पुलकका ५’१०

+1 - मैं व्यक्तिगत रूप से आरेख के साथ शुरू कर सकता हूं या इसे आधिकारिक तरीके से कर सकता हूं, लेकिन ऐसा इसलिए है क्योंकि आधिकारिक तरीका मेरे लिए काम करता है। आप वास्तव में लोगों को होशियार या अधिक रचनात्मक बनने की शिक्षा नहीं दे सकते। वे अपने तरीके से सेट किए गए वयस्क हैं। आप या तो उन्हें किराया देते हैं या आप नहीं देते हैं।
जॉब

6

ऐसा लगता है कि आप हैं:

  1. सबसे अच्छा तरीका (प्रयोग, वृद्धिशील डिजाइन) खोजने के लिए सामान की कोशिश करना
  2. क्लीनर पाने के लिए कोड को फिर से भरना (रिफलेक्टिंग)
  3. लगातार लेखन परीक्षण (परीक्षण संचालित विकास)

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

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

इसके अलावा, मुझे नहीं पता कि आप किस "व्यावसायिक विकास समुदाय" के बारे में बात कर रहे हैं, लेकिन अगर आप थे, तो मैं उन्हें उनके हाथी दांतों पर वापस जाने के लिए कहूंगा ताकि आप अपने काम पर लग सकें!


मैं इस पर पूरी तरह से आपके साथ हूं, जो मेरे खुद के जवाब को गूँजता है।
एरिक ओ लेबिगॉट

4

ब्रैड, आप अकेले नहीं हैं। मैं बहुत अच्छे प्रोग्रामर जानता हूं जो ठीक उसी तरह से काम करते हैं जैसे आप वर्णन करते हैं। :)

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

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

मुझे लगता है कि आप पूरी तरह से ठीक कर रहे हैं, और आप जिस प्रोग्रामिंग शैली का वर्णन करते हैं, वह पूरी तरह से वैध है।


4

मुझे लगता है कि एलन जे। पर्ल के एक उद्धरण के साथ उपरोक्त उत्तरों को पूरा करने के लायक है, जो कि प्रसिद्ध एमआईटी पुस्तक "संरचना और कंप्यूटर प्रोग्राम की व्याख्या" के प्राक्कथन से है, जिसे आमतौर पर "एसआईसीपी" कहा जाता है:

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


अच्छे से कहा। वे आदिम मॉडल, मानवतावादी मॉडल और अंत में अलौकिक मॉडल हैं क्योंकि प्रोग्रामर कोड के भीतर होने वाली क्रियाओं में अधिक से अधिक विचार करता है।
easymoden00b

3

वहाँ अच्छा चालाक और बुरा चालाक है।

अच्छा चतुर - गैर-चालाक विकल्प में कोड बनाम लाइनों की चतुर लाइनों के बीच उच्च अनुपात। कोड की 20 पंक्तियाँ जो आपको 20000 लिखने से बचाती हैं, अत्यंत उत्तम है। अच्छा चतुर अपने आप को काम बचाने के बारे में है।

खराब क्लीवर - कोड की पंक्तियों के बीच कम अनुपात बनाम लिखित कोड की लाइनें। चतुर कोड की एक पंक्ति जो आपको कोड की पांच पंक्तियाँ लिखने से बचाती है, वह है बैड क्लीवर। बुरा चालाक "सिंटैक्टिक हस्तमैथुन" के बारे में है।

बस ध्यान दें: बैड क्लीवर को लगभग कभी भी "बैड क्लीवर" नहीं कहा जाता है; यह अक्सर उपनाम "सुंदर", "सुरुचिपूर्ण", "संक्षिप्त", या "रसीला" के तहत यात्रा करेगा।


1
"सुंदर", "सुरुचिपूर्ण", "संक्षिप्त", या "रसीला।" ..... मुझे लगता है कि मैंने एक समय में रूबी ऑन रेल्स पेज पर रूबी को देखा था। :-D
ब्रैड

1
शायद यह सिर्फ मुझे है, लेकिन मुझे लगता है कि एलओसी में 80% की कमी कुछ चतुरता के लायक है।
पुनरावर्ती

मैंने बहुत से सामान "सिंथैटिक हस्तमैथुन" के लेबल में पाए हैं, जब वास्तव में यह उनके बस की बात है कि वास्तव में वे जिस भाषा का उपयोग कर रहे हैं उसे सीखना बहुत ही आलसी है ...
Svish

3

मैं निश्चित रूप से अपने आप को अपने वर्कफ़्लो का वर्णन करने के तरीके से पहचान सकता हूं। यहाँ यह बात है: जब मैंने एक समूह के वातावरण में काम करना शुरू किया, तो लगभग सभी सामानों को बदलने के लिए एचएडी।

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

यहाँ मुख्य बात मैंने महसूस की है: यदि यह स्पष्ट नहीं है कि आप क्या कर रहे हैं, तो आप शायद एक सहयोगी का अगला सिरदर्द लिख रहे हैं। यहाँ जो "प्रक्रिया-उन्मुख" उपद्रव आप देखते हैं, उनमें से अधिकांश का इस तथ्य से लेना-देना है कि हम में से बहुत से सहकर्मी सिरदर्द के साथ हैं। और अधिकांश सॉफ्टवेयर प्रक्रिया प्रबंधन सिद्धांत को उस सिरदर्द को कम करने के साथ करना है।

तो समय से पहले एक सहमत-योजना की योजना बनाने जैसी चीजें, आदि ... वे बोर्ड पर और सिंक में एक टीम होने के बारे में हैं। यदि आप टीम हैं, तो आप पहले से ही अपने आप के साथ सिंक कर रहे हैं, और यह वास्तव में आवश्यक नहीं है।


2

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

एक पेशेवर काम के माहौल में, यदि आपकी परियोजना का समय कम है, शायद लगभग 2 - 3 सप्ताह या उससे कम है, तो आपके दृष्टिकोण को तेजी से प्रोटोटाइप कहा जाता है और आगे के कार्यों के लिए काफी उपयुक्त है।

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


2

दो दृष्टिकोण:

  1. किसी को पेंटिंग नहीं रखनी है।

  2. जो भी कभी बॉब रॉस पेंटिंग देखता है वह जानता है कि पेंटिंग में संरचना है। यदि आप बॉब रॉस से एक सबक लेने जा रहे हैं, तो यह होगा कि आगे की योजना बनाना और एक संगठित तरीके से काम करना प्रक्रिया को सुचारू रूप से चलना और सरल दिखना है।


1
बॉब रॉस ने अपने पीछे आकाश को चित्रित करने से पहले खुश पेड़ों को कभी नहीं चित्रित किया।
रोब के

1

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

लेकिन मैं इस बारे में उत्सुक हूं:

यहाँ और स्टैक ओवरफ्लो पर लोगों का समुदाय किसी भी प्रकार की अपूर्णता को अस्वीकार करता है। [..] मेरी प्रक्रिया पेशेवर डेवलपर समुदाय में जो स्वीकार्य है, उसके दाने के खिलाफ जाना लगता है, और मैं समझना चाहूंगा कि क्यों।

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

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


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

किसी भी मामले में, यहां मेरे प्रश्न की प्रतिक्रियाओं को पढ़ने के बाद, मुझे लगता है कि मैंने समुदाय को गलत तरीके से पढ़ा है, और पूर्ण परियोजनाओं की आलोचना के उत्तरों की आलोचना की है, जो कि आपने स्पष्ट किया है, दो अलग-अलग चीजें हैं।
ब्रैड

1

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

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

इस प्रकार एक सरल स्केच को ध्यान में रखना एक डिज़ाइन के रूप में पर्याप्त है, इससे पहले कि आप इसे जीवन में लाना शुरू करें। नया स्वरूप, सार और refactor की जरूरत के रूप में


1

मुझे लगता है कि अगर आप प्रोग्रामिंग में अच्छा होने जा रहे हैं, तो कम से कम कभी-कभी इसे मज़ेदार बनाना होगा, और इसका मतलब है कि रचनात्मक होना।

निश्चित रूप से जब समूहों में प्रोग्रामिंग कम से कम न्यूनतम मानक होते हैं जिनका पालन किया जाना चाहिए, "नैतिक" कारणों के लिए नहीं, बल्कि व्यावहारिक लोगों के लिए, जब वे लागू होते हैं।

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

एक बार मैंने Edsger Dijkstra की एक बात सुनी, प्रोग्रामिंग में रचनात्मकता के बारे में बात की। उन्होंने उल्लेख किया कि कैसे एक छात्र ने n + m-bit शब्द के एन-बिट रोटेट करने का एक तरीका पाया। यह 3 बिटवाइस के साथ किया गया था। पहले आप n बिट्स को स्वैप करते हैं, फिर आप m बिट्स को स्वैप करते हैं, फिर आप पूरे n + m बिट्स को स्वैप करते हैं। उपयोगी? नहीं? हाँ।

उन चीजों की कोशिश करने के लिए स्वतंत्र महसूस करना अच्छा है जो उनके सही दिमाग में कोई भी नहीं करेगा।


1

यह "एक आकार सभी फिट नहीं है" का मामला हो सकता है। आपने अपनी शैली को उन परियोजनाओं के लिए काम किया है, जिन पर आप चल रहे हैं, तो उससे बहस करने के लिए कौन है? हालाँकि, आप जो आलोचक यहां और एसओ पर पढ़ रहे हैं, वह बड़ी परियोजनाओं, या उन परियोजनाओं पर काम कर सकता है, जिनके लिए टीम के सदस्यों के बीच जटिल समन्वय की आवश्यकता होती है।

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

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


1
आपके जवाब के लिए धन्यवाद। आपकी टिप्पणियाँ मेरे लिए उपयोगी हैं।
ब्रैड

1

बहुत आश्वस्त है कि आपका तरीका गलत नहीं है, लेकिन मुझे कुछ व्यक्तिगत अनुभव जोड़ने दें। मैंने आपका रास्ता बंद कर दिया, लेकिन इस बीच मैंने पहले से ही सामान्य संरचना के कम से कम हिस्से के नियोजन का लाभ सीख लिया, और यह कई कारणों से है:

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

  • स्कीम होने से आप न केवल कोड, बल्कि स्कीम को भी रिफलेक्टर कर सकते हैं। कभी-कभी मैं एक वर्ग लिखने में व्यस्त रहता हूं जो अचानक योजना में किसी अन्य भाग के लिए भी उपयोगी होता है। परिणामस्वरूप जब यह प्रोजेक्ट चलता है तो यह योजना सरल हो जाती है

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

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

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

और जैसा कि दूसरों ने कहा: यह मेरा तरीका है, आपका माइलेज अलग हो सकता है।

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