जब मेरा कोड बदबू आ रही हो तो मुझे क्या करना चाहिए?

Question

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

Comments

डिओडोरेंट का उपयोग करें;)

— पेमदास

और शायद कीड़े से छुटकारा पाने के लिए एक कीटाणुनाशक / कीटनाशक :-)

— स्टीफन सी

कुछ लहसुन खाएं। लोग शायद आपकी बुरी सांसों को अधिक नोटिस करेंगे।

— मतीन उल्हाक

और अब आपके पास है: codereview.stackexchange.com जहाँ आप अपने कोड के विशिष्ट उदाहरणों की मदद ले सकते हैं।

— LRE

खुली खिड़कियां ... ओह रुको ...

— मचल

Answer 1

कुछ सुझाव:

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

2. सॉफ़्टवेयर पैटर्न सीखें और उनका अध्ययन करें । कुछ सामान्य, प्रसिद्ध कार्यों को करने के लिए सॉफ्टवेयर पैटर्न आजमाए और सिद्ध किए गए हैं।

3. डेटा संरचनाओं का अध्ययन और समझना । प्रत्येक प्रकार की डेटा संरचना के लिए उपयुक्त उपयोग और प्रदर्शन विशेषताओं को जानें।

4. अपनी प्रोग्रामिंग लैंग्वेज को अच्छी तरह से जान लें, इसकी खूबियाँ और कमज़ोरियाँ, और इसके फीचर्स का बेहतरीन इस्तेमाल कैसे करें।

आपको यह सब जानने की जरूरत नहीं है, लेकिन आपको समय के साथ इसका अध्ययन करना चाहिए ।

Answer 2

मेरी सलाह है: चिंता करना बंद करो।

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

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

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

Comments

+1 बुरी तरह से डिजाइन किए गए कोड के लिए अलिखित महान कोड से बेहतर है!

— ग्रैंडमास्टरबी

यह एक ट्रिज्म जैसा लगता है, लेकिन ऐसा नहीं है। बुरी तरह से डिज़ाइन किया गया कोड जो इसका मतलब है वह अच्छी तरह से डिज़ाइन किए गए अलिखित कोड से बेहतर है। हालांकि, यदि कोड बुरी तरह से डिज़ाइन किया गया है, तो यह कैसे संभव है कि यह वही करेगा जो यह करने के लिए है?

— मैट एलेन

हम यहां निजी परियोजनाओं के बारे में बात कर रहे हैं। बेशक, अगर हम परमाणु-मिसाइल-नियंत्रित करने वाले सॉफ़्टवेयर पर विचार करते हैं, तो कोई भी कोड खराब कोड से बेहतर नहीं है।

— कोई बात नहीं

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

— स्टीव

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

— मैट एलेन

Answer 3

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

Comments

अच्छा निर्णय! यह जानना कि कुछ बेहतर हो सकता था, एक अच्छी शुरुआत है।

— ozz

Answer 4

क्या मैं एक ही बार में सब कुछ जानने की कोशिश करूं?

मुझे आशा नहीं है। दूसरी ओर, आपको पूरे समय सीखना और सुधार करना चाहिए।

किताबें पढ़ें, पाठ्यक्रम लें, योग्य बनें, उस पर काम करें, और आपको सुधार करना चाहिए।

Answer 5

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

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

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

Answer 6

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

Answer 7

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

जब आप अपने कोड को रिफलेक्टर करते हैं, तो आप पहले से ही डिज़ाइन पैटर्न , इनकैप्सुलेटिंग कोड आदि का उपयोग कर रहे हैं ।

यह इस विषय के बारे में मैंने अब तक पढ़ी सबसे अच्छी पुस्तकों में से एक है। यह बहुत सारे उपयोगी व्यंजन प्रदान करता है।

Answer 8

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

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

• अच्छा डिजाइन कोडबेस में आदर्शों की एक छोटी संख्या का पुन: उपयोग करेगा (आदर्श एक अवधारणा है, लेकिन व्यवहार में आपको कुछ और की आवश्यकता हो सकती है)
• एक अच्छा डिज़ाइन यह पता लगाना आसान बना देगा कि समस्याओं को कैसे ठीक किया जाए (DRY सिद्धांत, SRP सिद्धांत)
• एक अच्छी डिज़ाइन में अच्छी एरर रिपोर्टिंग होगी (उपरोक्त बिंदु से संबंधित, लेकिन इसे एक अलग आइटम के रूप में कहा जाता है क्योंकि यह अक्सर अनदेखा किया जाता है)

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

Answer 9

यदि आपके पास पहले से ही प्रोग्रामिंग में कुछ अनुभव है, तो आप कुछ ओपन सोर्स प्रोजेक्ट्स का अध्ययन क्यों नहीं करते हैं जिनके पास क्लीन कोड है ? आप एसओ से इस प्रश्न को देख सकते हैं जिसमें कुछ प्रासंगिक लिंक हैं।

इसके अलावा, डिज़ाइन पैटर्न को जानना आवश्यक है - इसके बारे में सोचें, पैटर्न होने का पूरा विचार पहिया को फिर से आविष्कार किए बिना या बुगी कोड लिखने के बिना ज्ञात समस्याओं को हल करना है।

अंत में, ऐसा लगता है कि आपको अपना सिर साफ़ करने के लिए कार्यात्मक प्रोग्रामिंग की कुछ खुराक की आवश्यकता है। एक शुरुआत के लिए हास्केल या ओकेमेल में देखें।

Answer 10

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

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

Answer 11

मेरी सलाह प्रत्येक गंध को गंभीरता से लेती है और इसे ठीक करने का प्रयास करती है। विषय पर कई अच्छी किताबें हैं (क्लीन कोड और GOOS सर्वश्रेष्ठ IMHO हैं)। लेकिन पुस्तकों से अधिक अन्य लोगों के साथ और ऑनलाइन कॉम्यूनिटी (मेलिंग सूची, समूह) पर सुनने और चर्चा करने के लिए सम्मेलनों में जाते हैं। फिर भी बेहतर अपने स्थानीय xxug (डॉटनेट, गुड़, xpug, आदि) में शामिल होने की कोशिश करें या एक मिला।

अन्य प्रोग्रामर्स के साथ चर्चा करना एकमात्र तरीका है जिसे मैं वास्तव में सुधार करना जानता हूं (जब तक कि आप सौभाग्य से अन्य समर्पित प्रोग्रामर के साथ काम करने के लिए पर्याप्त नहीं हैं)।