बड़ी टीमों में, हर PR की समीक्षा कम से कम एक अन्य इंजीनियर करता है। Sage Ideas में, मैं अकेला इंजीनियर हूँ। कोई मेरे कोड की समीक्षा नहीं करता।
यह एक समस्या है। इसलिए नहीं कि मैं खराब कोड लिखता हूँ — बल्कि इसलिए कि मैं अपनी खुद की मान्यताओं के प्रति अंधा हूँ। हर डेवलपर ऐसा होता है।
मैंने एक स्व-समीक्षा प्रक्रिया विकसित की है जो अधिकांश उन चीज़ों को पकड़ लेती है जो दूसरी जोड़ी आँखें पकड़तीं। यह परफेक्ट नहीं है, लेकिन "ठीक लग रहा है, मर्ज करो" से कहीं बेहतर है।
24-घंटे का नियम
मैं आज लिखे गए कोड की कभी समीक्षा नहीं करता। लिखने और समीक्षा करने के बीच न्यूनतम अंतराल 24 घंटे है। आदर्श रूप से 48 घंटे।
यह धीमा लगता है। वास्तव में यह तेज़ है। उन 24 घंटों में, मैं कुछ और बना रहा होता हूँ। जब मैं समीक्षा करने वापस आता हूँ, तो मैं अपने कार्यान्वयन को आंशिक रूप से भूल चुका होता हूँ। यह भूलना ही मुद्दा है — यह मुझे कोड को ऐसे पढ़ने देता है जैसे किसी और ने लिखा हो।
समीक्षा चेकलिस्ट
मैं 4 चरणों में समीक्षा करता हूँ। प्रत्येक चरण अलग-अलग चीज़ों की तलाश करता है:
चरण 1: उपयोगकर्ता की तरह पढ़ें (5 मिनट)
कोड को न देखें। PR diff खोलें और केवल फ़ाइल नाम और लाइन गणनाएँ पढ़ें।
प्रश्न:
- क्या फ़ाइल नामों से ही परिवर्तन समझ में आता है?
- क्या यह बहुत अधिक फ़ाइलों को छू रहा है? (युग्मित परिवर्तन का संकेत)
- क्या इस परिवर्तन में ऐसी फ़ाइलें हैं जो नहीं होनी चाहिए?
चरण 2: तर्क के लिए पढ़ें (15 मिनट)
अब कोड पढ़ें। लेकिन शैली, नामकरण या फ़ॉर्मेटिंग की जाँच न करें। केवल तर्क।
प्रश्न:
- क्या हैप्पी पाथ काम करता है?
- null/undefined इनपुट के साथ क्या होता है?
- क्या ऐसे कोई मामले हैं जहाँ यह चुपचाप विफल होता है?
- क्या मैं एरर केस को संभाल रहा हूँ, या सिर्फ लॉग करके आगे बढ़ रहा हूँ?
- क्या कोई रेस कंडीशन है? (विशेषकर async कोड में)
चरण 3: सुरक्षा के लिए पढ़ें (10 मिनट)
\\
