डेवलपमेंट
- छोटे से शुरू करें, फिर विस्तार करें: नया सिस्टम बनाते समय या मौजूदा सिस्टम में फीचर जोड़ते समय, लगभग बिना ज़रूरी फीचर्स वाला बहुत सरल वर्ज़न से शुरू करें और फिर धीरे-धीरे उसका विस्तार करें
- एक बार में एक ही बदलाव करें: डेवलपमेंट के दौरान टेस्ट फेल हो जाएँ या कोई फीचर काम न करे, तो अगर आपने एक बार में सिर्फ एक बदलाव किया है, तो समस्या ढूँढना बहुत आसान हो जाता है
- लॉगिंग और एरर हैंडलिंग जल्दी जोड़ें: नया सिस्टम बनाते समय शुरुआत से ही लॉगिंग और एरर हैंडलिंग जोड़ना उपयोगी होता है
- नई code lines कम-से-कम एक बार चलनी चाहिए: फीचर पूरा होने से पहले उसका टेस्ट किया जाना चाहिए
- पूरे सिस्टम को टेस्ट करने से पहले हिस्सों को टेस्ट करें: अच्छी तरह टेस्ट किए गए हिस्से समय बचाते हैं
- हर काम सोच से ज़्यादा समय लेता है: खासकर प्रोग्रामिंग में, चीज़ें अक्सर अनुमान से ज़्यादा समय लेती हैं
- पहले मौजूदा कोड को समझें: नया फीचर जोड़ने से पहले मौजूदा समाधान को समझना ज़रूरी है। कोड पढ़ना, कोड लिखने जितनी ही अहम स्किल है
- पढ़ें और चलाएँ: कोड को समझने के दो पूरक तरीके हैं—कोड पढ़ना और कोड चलाना
समस्या समाधान
- बग हमेशा मौजूद रहते हैं: "शुरू से ही सब सही" वाला अप्रोच अच्छा नहीं है
- समस्या रिपोर्ट्स को हल करें: डेवलपर्स को ग्राहकों की समस्या रिपोर्ट्स संभालने और बग ठीक करने में समय देना चाहिए। इससे यह समझने में बहुत मदद मिलती है कि ग्राहक क्या करना चाहते हैं, सिस्टम का इस्तेमाल कैसे हो रहा है, समस्याएँ हल करना कितना आसान या कठिन है, और सिस्टम कितना अच्छी तरह डिज़ाइन किया गया है
- समस्या को reproduce करें: बग फिक्स करने का पहला कदम समस्या को reproduce करना है। उसके बाद फिक्स जोड़ने पर जाँचें कि समस्या गायब हुई या नहीं
- ज्ञात त्रुटियाँ ठीक करने के बाद जो बचा है उसे देखें: जब कई समस्याएँ हों, तो पहले सभी ज्ञात समस्याएँ ठीक करें और फिर देखें कि कौन-से लक्षण अभी भी बचे हैं
- यह न मानें कि सब संयोग है: टेस्टिंग और समस्या समाधान के दौरान संयोग पर भरोसा न करें, जाँच करें। "टाइमर वैल्यू बदली और अब सिस्टम ज़्यादा बार restart हो रहा है—यह संयोग नहीं है। नया फीचर जोड़ा गया और असंबंधित फीचर धीमा हो गया? यह भी संयोग नहीं है। और जाँच करें"
- timestamp के साथ सहसंबंध बनाएँ: समस्या हल करते समय इवेंट्स के timestamp का उपयोग करें
सहयोग
- आमने-सामने की बातचीत सबसे ज़्यादा bandwidth देती है: समस्या हल करने के तरीकों पर चर्चा करते समय आमने-सामने की बातचीत, बाकी सभी तरीकों (वीडियो, फ़ोन, चैट, मेल) से बेहतर होती है
- rubber duck debugging: जब आप किसी समस्या में अटक जाएँ, तो किसी सहकर्मी को समस्या समझाने से अक्सर समाधान समझ में आ जाता है। भले ही सहकर्मी कुछ न कहे, बातचीत करते-करते अक्सर यह साफ हो जाता है कि समस्या क्या है। यह जादू जैसा लगता है, लेकिन हैरानी की बात है कि यह बहुत बार काम करता है
- पूछें: कोड को समझने के लिए उसे पढ़ना और चलाना अक्सर अच्छा तरीका है। लेकिन अगर किसी ऐसे व्यक्ति से पूछना संभव हो जो इसके बारे में जानता हो (शायद मूल लेखक), तो यह तरीका भी साथ में इस्तेमाल करें
- श्रेय साझा करें: जहाँ श्रेय बनता है, वहाँ श्रेय दें। "हमने ... आज़माया" कहने के बजाय "Marcus ने इसे आज़माने का आइडिया दिया" कहें (अगर वास्तव में उसने दिया हो)। किसने मदद की या योगदान दिया, इसका सक्रिय रूप से उल्लेख करें
अन्य
- खुद आज़माकर देखें: अगर आपको यकीन न हो कि किसी भाषा का फीचर कैसे काम करता है, तो उसे टेस्ट करने के लिए एक छोटा प्रोग्राम लिखें
- सो जाएँ: कठिन समस्या का सामना हो, तो फैसला लेने से पहले एक रात की नींद लेना अच्छा होता है
- बदलाव: समय-समय पर अपनी भूमिका या नौकरी बदलने से न डरें। अलग लोगों के साथ, अलग प्रोडक्ट्स पर, या अलग कंपनी में काम करना प्रेरक होता है
- सीखते रहें: सॉफ़्टवेयर डेवलपमेंट की सबसे बड़ी खूबियों में से एक यह है कि हमेशा और सीखने व जानने की गुंजाइश रहती है। अलग-अलग प्रोग्रामिंग भाषाएँ और टूल्स आज़माएँ, सॉफ़्टवेयर डेवलपमेंट पर किताबें पढ़ें, और MOOC कोर्स करें। छोटे-छोटे सुधार मिलकर आपके ज्ञान और क्षमता में वास्तविक बदलाव लाते हैं
7 टिप्पणियां
आमने-सामने संवाद की bandwidth सबसे ज़्यादा होती है - यह एक बेहतरीन अभिव्यक्ति है।
+1.
रबर डक डिबगिंग। किसी ऐसे व्यक्ति को समझाते-समझाते जिसे वास्तव में प्रोग्रामिंग नहीं आती, अक्सर पता चल जाता है कि समस्या क्या है।
+1.
यह तो सचमुच अमूल्य सीखें हैं।
+1
वाह, सब बातें बहुत अच्छी हैं। आमने-सामने की बातचीत का bandwidth सबसे ज़्यादा होना थोड़ा अफ़सोसजनक है। उम्मीद है कि technology और ज़्यादा आगे बढ़ेगी।