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