जूनियर डेवलपर्स द्वारा की जाने वाली गलतियाँ
काम करने वाला कोड शिप करना एक बुनियादी स्तर है। यह लक्ष्य नहीं है।
मैंने एक बार एक पुल रिक्वेस्ट (pull request) की समीक्षा की जिसे समझने में 45 मिनट लग गए। लॉजिक सही था। टेस्ट पास हो गए थे। लेकिन कोड ऐसे लिखा गया था जैसे उसे केवल लेखक ही कभी पढ़ेगा।
जब मैंने फीडबैक दिया, तो डेवलपर ने कहा, "लेकिन यह काम कर रहा है।"
वे सही थे। यह काम कर रहा था। समस्या बिल्कुल यही थी।
जूनियर डेवलपर्स अक्सर तकनीकी कौशल पर ध्यान केंद्रित करते हैं। लेकिन असली कमियाँ अक्सर आदतों और मानसिकता में होती हैं।
यहाँ वे सूक्ष्म गलतियाँ दी गई हैं जो आपकी गति धीमी कर देती हैं:
दूसरों के बजाय अपने लिए लिखना कोड जितना लिखा जाता है, उससे कहीं अधिक बार उसे पढ़ा जाता है। आज आपके द्वारा लिखा गया एक फंक्शन दो वर्षों में तीन अलग-अलग लोगों द्वारा इस्तेमाल किया जा सकता है। यदि कोई अजनबी आपके कोड को 30 सेकंड में नहीं समझ सकता, तो आप असफल रहे।
बिना समझे कोड कॉपी करना Stack Overflow का उपयोग करना ठीक है। लेकिन यह जाने बिना कि कोई regex पैटर्न कैसे काम करता है, उसे कॉपी करना खतरनाक है। आप अपने कोडबेस में एक 'ब्लैक बॉक्स' बना देते हैं। जब वह टूटता है, तो आप उसे डिबग (debug) नहीं कर पाते।
अनावश्यक जटिलता जोड़ना जूनियर अक्सर जटिलता को कौशल के बराबर मानते हैं। वे सरल कार्यों पर डिज़ाइन पैटर्न (design patterns) लागू करते हैं। अनावश्यक एब्स्ट्रैक्शन (abstraction) कोड को डिबग करना और बदलना कठिन बना देता है। एब्स्ट्रैक्शन तभी जोड़ें जब आपको उसकी कमी महसूस हो।
एरर मैसेज को नज़रअंदाज़ करना एरर मैसेज मुफ्त डॉक्यूमेंटेशन हैं। जैसे ही आप स्टैक ट्रेस (stack trace) देखें, तुरंत गूगल पर न कूदें। पूरा मैसेज पढ़ें। यह अक्सर आपको बताता है कि ठीक कौन सी लाइन फेल हुई और क्यों।
बहुत जल्दी या बहुत देर से मदद मांगना 10 मिनट की समस्या पर तीन घंटे तक न अटके रहें। यह अक्षम है। लेकिन बिना किसी संदर्भ (context) के केवल एक स्क्रीनशॉट भेजकर सीनियर को पिंग न करें। 20-मिनट के नियम का पालन करें: इसे हल करने की कोशिश में 20 मिनट बिताएं। आपने क्या कोशिश की, उसका दस्तावेजीकरण (document) करें। फिर उस डॉक्यूमेंटेशन के साथ मदद मांगें।
जो पहले से मौजूद है उसे फिर से बनाना कोई नया यूटिलिटी (utility) लिखने से पहले, कोडबेस में खोजें। आपकी टीम ने संभवतः उस समस्या को पहले ही हल कर लिया होगा।
खराब कमिट मैसेज "fix bug" जैसा कमिट मैसेज आपकी टीम को कुछ नहीं बताता। क्या बदला और क्यों, यह समझाएं। Git हिस्ट्री को डॉक्यूमेंटेशन की तरह मानें।
आवश्यकताओं (requirements) को कानून मानना आवश्यकताओं में अक्सर एज केस (edge cases) छूट जाते हैं। केवल वही लागू न करें जो आपको बताया गया है। पूछें कि जब चीजें गलत होती हैं तो क्या होगा।
"Merged" बटन पर ही रुक जाना स्वामित्व (ownership) तब समाप्त नहीं होता जब आपका PR मर्ज हो जाता है। अपने फीचर को QA तक फॉलो करें। इसे प्रोडक्शन (production) में देखें। एरर रिपोर्ट पढ़ें।
सबसे बड़ी कमी जवाबदेही (accountability) की है। सीनियर डेवलपर्स केवल कोड नहीं लिखते। वे नई समस्याएँ पैदा किए बिना समस्याओं का समाधान करते हैं।
"done" के लिए ऑप्टिमाइज़ करना बंद करें। "good" के लिए ऑप्टिमाइज़ करना शुरू करें।