पुनरावृत्ति विकास और रीफैक्टरिंग कोड का सही अर्थ

Question

मैंने हाल ही में एक डेवलपर के रूप में काम करना शुरू कर दिया है और एक और वरिष्ठ डेवलपर के तहत काम करना शुरू कर दिया है जो मुझे पर्यवेक्षण/सलाह दे रहा है।

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

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

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

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

Answer 1

इसके अलावा, वह कोड का दस्तावेजीकरण, beliveing ​​कि यह खुद के लिए बात करनी चाहिए पर frowns।

यह मुझे पढ़ने के लिए बहुत कुछ है। इस व्यक्ति को वास्तव में रखरखाव कोड लिखने के लिए क्या लगता है इसके बारे में कोई जानकारी नहीं है।

इसके साथ ही, यह व्यक्ति स्पष्ट रूप से आपका सलाहकार/पर्यवेक्षक है, इसलिए आप केवल इतना नहीं कह सकते हैं, "अरे, यह बेवकूफ है", आपको इसे कुशलतापूर्वक करना है।

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

मुझे लगता है कि आपको अपने पर्यवेक्षक से बात करनी चाहिए और स्थिति की व्याख्या करनी चाहिए।

इसके साथ ही कहा, वहाँ कभी कभी अगर समय तंग है, जेमी Jawinski, जो नेटस्केप पर काम किया,

"हम उच्चतम गुणवत्ता वाले उत्पाद जहाज के लिए जा रहे हैं के हवाले से शॉर्टकट लेने के लिए कारण हैं हम मार्च 31 "

तो आपको शेष राशि मिलनी है। लेकिन कुल मिलाकर, कोड में मददगार टिप्पणियाँ लिख है कि और अधिक समय लेने के लिए नहीं है, निश्चित रूप से काफी एक परियोजना समय को प्रभावित करने के लिए पर्याप्त नहीं है, और मुझे पसंद है क्या Donald Knuth ने कहा:

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

संक्षेप में, वहाँ अत्यधिक प्रभावी, स्पष्ट, और पोषणीय कोड लिखने, यहां तक ​​कि एक तंग समय रेखा के साथ का कोई विकल्प नहीं है।

Answer 2

नहीं, यह वास्तव में नहीं है कि चीजें आमतौर पर कैसे की जाती हैं। लेकिन कुछ विचार हैं।

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

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

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

Answer 3

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

जहां मैं काम करता हूं, कोड में बहुत कम टिप्पणियां होती हैं लेकिन यदि विधि का नाम वास्तव में इसके कार्य का प्रतिनिधि है, और विधि के अंदर कोड साफ़ है, तो मुझे इसे समझने में कोई समस्या नहीं है।

दुर्भाग्य से मैं समस्याओं को हल करने तुरंत सही कोड पहली बार लिख कर सक्षम किया जा रहा के स्तर पर नहीं कर रहा हूँ।

एक सही कोड जैसी कोई चीज़ नहीं है, यह जानने के बारे में कि कौन से कंप्रेसर स्वीकार्य हैं।

शायद आपका मेटर बस 'डिजाइन के बारे में चिंता न करें' कहकर अपने जीवन को आसान बनाने की कोशिश कर रहा है।

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

Answer 4

विचार के कई स्कूल और कई अलग-अलग शैलियों हैं। मैंने गिनती बंद कर दी है और इसके बजाय व्यावहारिक दृष्टिकोण का उपयोग करने की कोशिश की है।

कार्यान्वयन कोड के संदर्भ में मैं सिद्धांत "इसे काम करता हूं", "इसे सही बनाएं", "इसे तेज़ बनाएं" का उपयोग करें। लेकिन फिर मैं "सबसे आसान चीज जो संभवतः काम कर सकता हूं" का उपयोग करता हूं (DTSTTCPW)

आप कितनी टिप्पणियां लिखते हैं, कई कारकों पर निर्भर करता है। विचारों का एक स्कूल वास्तव में थीसिस की वकालत करता है कि अच्छा कोड स्वयं-दस्तावेज है। इसके अलावा, मैंने अंतहीन टिप्पणियां देखी हैं जो पूरी तरह से कोड के साथ समन्वयित नहीं थीं।

विचार का एक और स्कूल मानता है कि आपको टिप्पणियों की आवश्यकता है।

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

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

परीक्षण संचालित विकास (टीडीडी) की मेरी समझ यह है कि आप अपने सिस्टम के डिजाइन को चलाने के लिए परीक्षणों का उपयोग करते हैं। यह केवल परीक्षण-पहले प्रोग्रामिंग से अधिक है।

इस दृष्टिकोण ने पिछले 10+ सालों से मेरे लिए काम किया है और कई टीमों के साथ मैंने काम किया है। लेकिन मुझे यकीन है कि कई अन्य विकल्प, शैलियों, प्राथमिकताओं, पद्धतियां जो समान रूप से अच्छी तरह से काम करती हैं। यह सब निर्भर करता है!

Answer 5

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

//Get the speed of the train from the database 
int value = GetValue(); 

int trainSpeed = GetTrainSpeedFromDatabase(); 

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

Answer 6

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

• यह आसान है के लिए नए डेवलपर्स सही रास्ता अधिक मातम agonizing में खो जाना सॉफ्टवेयर डिजाइन करने के लिए। यह एक प्रकार का विश्लेषण पक्षाघात है। वह शायद आपको कोड में जल्दी से गोता लगाने के लिए चाहता है ताकि आपको वास्तव में कुछ लिखा जा सके और आप जल्दी से पता लगा सकें कि क्या अच्छा काम नहीं करता है। ऐसा लगता है कि वह आपको सीखने के लिए जल्दी और अक्सर असफल होने देता है।

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

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