"सही प्रोग्रामर के सिंड्रोम" को तोड़ने के तरीके [बंद]


16

मैं शायद अकेला नहीं हूं जो इस तरह से महसूस करता है। लेकिन मेरे पास वह है जिसे मैं "सही प्रोग्रामर का सिंड्रोम" कहता हूं, जो कई लोग कह सकते हैं कि यह पूर्णतावादी होने के समान है, लेकिन इस मामले में यह प्रोग्रामिंग के क्षेत्र में है। हालांकि, इस तरह के एक सिंड्रोम के लिए प्रोग्रामिंग का डोमेन थोड़ा समस्याग्रस्त है।

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

शायद यह संगठन की कमी है? शायद यह अनुभव की कमी है? शायद अभ्यास की कमी है? हो सकता है कि यह किसी और चीज़ की कमी हो जो कोई इंगित कर सकता है? क्या किसी भी तरह से उस सिंड्रोम से छुटकारा पाने का कोई तरीका है?


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

मैं वहाँ सहमत नहीं हूँ .. मुझे विश्वास है कि हर कोई जो भी पृष्ठभूमि को इस तरह महसूस कर सकता है शायद कुछ अलग-अलग डिग्री पर लेकिन फिर भी।
रशिनो

2
जबकि हर कोई समान लक्षणों का अनुभव कर सकता है, कारण वास्तव में बहुत भिन्न होता है, और इस तरह "इलाज" करता है।
back2dos

कोई सही प्रोग्रामर नहीं है। आप अनुभवी और विस्तार से उन्मुख हो सकते हैं, जिसकी गति और उसके कौशल में सुधार करने की इच्छा है। - आप उन्हें "गेट गेटर्स" कह सकते हैं ...
यूसुबोव

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

जवाबों:


21

प्राथमिकता दें । पहली चीजें पहले। किन बातों पर ध्यान दें।

आपकी प्राथमिकताएँ भिन्न हो सकती हैं, लेकिन सामान्य तौर पर आपको इसकी परवाह करनी चाहिए:

  • सही कोड
  • बनाए रखने योग्य कोड
  • साफ कोड
  • सरल, सुरुचिपूर्ण कोड
  • कुशल कोड

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

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

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

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

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

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


9
सबसे अच्छा अनुकूलन वह है जो आपके कार्यक्रम को गैर-कार्यशील स्थिति से कार्यशील स्थिति में लाता है।
deadalnix

1
@deadalnix सही सलाह! यह इतना सरल है, इतना स्पष्ट है, फिर भी सभी कोड में इतना सच है।
zxcdw

7
+1। मैं सही से ऊपर रखने योग्य विचार करना चाहता हूँ । ); Maintainable कोड के सभी एक गुणवत्ता के बाद कि यह सही बनाने उचित प्रयास करने की बात है है
back2dos

1
EFficient सब कुछ से ऊपर होना चाहिए, लेकिन अगर आप डेटाबेस कोड और सुरुचिपूर्ण तरीके से ऊपर के बारे में बात कर रहे हैं तो सही है। अच्छा sql कोड (डेटाबेस के लिए अच्छा है जो डेवलपर नहीं है) शायद ही कभी सुरुचिपूर्ण हो। चीजों को करने के अयोग्य तरीकों को जाना जाता है और वे नियमित रूप से उपयोग करने से पहले एक बार समझने के लिए कम बनाए रखने योग्य या कठिन नहीं होते हैं।
HLGEM

2
@HLGEM वास्तव में, विशिष्ट क्षेत्रों में प्राथमिकताएं पूरी तरह से उलट हो सकती हैं। उदाहरण के लिए कई बार मैं लिखता हूं और रिवर्स-असेंबली असेंबली कोड जो कि चरम आकार और गति की कमी (डिमोसीन उत्पादों) के तहत लिखा गया है। ऐसी स्थितियों में, यहां तक ​​कि कार्यक्रम की शुद्धता पर भी सवाल उठाया जा सकता है - कोड के कई खराबी टुकड़े बहुत अच्छी तरह से काम करने के लिए निकले हैं (उदाहरण के लिए, गलत कोड पर आधारित सुंदर दृश्य और ऑडियो कलाकृतियां)।
zxcdw

6

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

इसका मतलब यह नहीं है कि आपको पहली बार में अच्छे, साफ कोड के लिए प्रयास नहीं करना चाहिए, बेशक, लेकिन आपको अपने पहले प्रयास को "अच्छा पर्याप्त" मानना ​​चाहिए जब तक कि अन्यथा साबित न हो।


+1 मैं इस भाग को पसंद करता हूँ .. "आपका पहला प्रयास" बहुत अच्छा "जब तक अन्यथा सिद्ध न हो।"
रशिनो

द्वितीय और उत्थित। निश्चित रूप से सुनहरी सलाह!
zxcdw

4

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

अंत में, किसी भी चीज से ज्यादा मायने रखता है कि सॉफ्टवेयर काम करता है और इसका इस्तेमाल किया जा सकता है। और ऐसा नहीं होगा यदि आप इसे पूरा नहीं करते हैं।

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


2

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

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


1

इसे अन्य तरीके से करें।

इसके बजाय "क्या बेहतर किया जा सकता है?" "मुझे क्या करना है?" जब तक कुछ नहीं करता।


4
"एक किताब समाप्त हो जाती है जब कुछ भी नहीं जोड़ा जा सकता है, लेकिन जब इससे कुछ भी नहीं निकाला जा सकता है।" - कोड पूरा
जोनाथन

यह वास्तव में सेंट-एक्सुप्री से एक पैराफेरेस है, मजेदार है कि वह कम विश्वसनीयता कैसे पकड़ सकता है फिर यहां कोड पूरा करें।
रद्दी

1

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


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

1

यह काम करो, इसे साफ करो, इसे ठोस बनाओ, इसे प्रदर्शन करने वाला बनाओ।

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

कोड में लालित्य प्राप्त किया जाना है जहां प्रोग्रामर एक अवसर को नोटिस करता है, और आमतौर पर पिछले चरणों का पालन करते हुए कोड की पठनीयता और रखरखाव में सुधार को सरल, सफाई और आम तौर पर सुधारने का एक कार्य है। यह अधिकतम होने के लिए कुछ नहीं है ।

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


0

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

अपने पेशेवर जीवन में "प्राप्त करने के लिए" दृष्टिकोण है। उद्धार करो और आगे बढ़ो। व्यक्तिगत परियोजनाओं के लिए अपनी पूर्णता को बचाएं।


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