Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
आर्किटेक्चर स्पेक्स को प्रोसेस करना और मन ही मन एक्सेप्शन केसेज का सिमुलेशन करना बहुत अच्छा लगता है। दिमाग में चलने वाला कोड बिना किसी बग के एकदम सही होता है। लेकिन अगर बिना एडिटर खोले विचार-विमर्श लंबा खिंच जाए, तो यह सावधानी नहीं बल्कि सिर्फ डर है—यानी असफलता का डर। अनिश्चितताओं से बचने के लिए बनाया गया भारी-भरकम डिज़ाइन डॉक्यूमेंट पहली ही रिक्वायरमेंट बदलते ही बिखर जाता है।
एनालिसिस पैरालिसिस (विश्लेषण पक्षाघात) में फंसकर समय बर्बाद करने वाले डेवलपर्स के लिए, मैंने परफेक्टनिज़्म (पूर्णतावाद) को तोड़ने और आज ही एक प्रोटोटाइप पेश करने के तरीके को व्यवस्थित किया है।
कोड की एक लाइन भी लिखे बिना सभी तरह के फ्रेमवर्क और आर्किटेक्चर की तुलना करना भारी कॉग्निटिव ओवरलोड पैदा करता है। 0.1% से भी कम संभावना वाली एरर को ठीक करने में लगे रहना, या बिना किसी रिक्वायरमेंट के एब्स्ट्रैक्शन लेयर बनाना, यह सब लॉस एवर्शन (नुकसान से बचने की प्रवृत्ति) का क्लासिक उदाहरण है।
McKinsey और Leadership IQ द्वारा फॉर्च्यून 500 कंपनियों पर किए गए एक अध्ययन के अनुसार, निर्णय लेने में असमर्थता और अत्यधिक विश्लेषण के कारण हर साल 53,000 दिनों से अधिक का समय बर्बाद होता है। लेबर कॉस्ट के हिसाब से देखें तो 25 करोड़ डॉलर (250 million dollars) बिना किसी परिणाम के हवा में उड़ जाते हैं। प्री-ऑप्टिमाइजेशन के कारण व्यक्तिगत डेवलपर की उत्पादकता भी 40% से अधिक कम हो जाती है.
अगर आपको लगे कि दिमाग में सिमुलेशन बहुत लंबा चल रहा है, तो आपको इसे सिस्टम के जरिए जबरदस्ती रोकना होगा। आप एक्सट्रीम प्रोग्रामिंग (XP) के स्पाइक सॉल्यूशन पैटर्न को अपने दैनिक जीवन में लागू कर सकते हैं।
यदि आप 2 सप्ताह से प्लानिंग चरण में अटके हुए हैं, तो इसका मतलब यह नहीं है कि स्पेक्स की कमी है, बल्कि इसका मतलब यह है कि निष्पादन का संदर्भ (execution context) गायब है। ऐसे में, आपको सभी डिज़ाइन डॉक्यूमेंट बंद कर देने चाहिए और 30 मिनट की टाइम-बॉक्सिंग सेट करनी चाहिए।
30% पूर्णता वाला प्रोटोटाइप वह होता है जिसमें एरर हैंडलिंग, डीबी इंटीग्रेशन और यूआई की बारीकियों को पूरी तरह से हटा दिया जाता है। इसमें केवल यह देखा जाता है कि इनपुट देने पर अपेक्षित परिणाम मिलता है या नहीं। सिलिकॉन वैली की प्रोडक्ट टीमें अमूर्त रिक्वायरमेंट डॉक्यूमेंट्स के बजाय सीधे काम करने वाले प्रोटोटाइप के साथ मीटिंग क्यों करती हैं, इसका कारण यही है। जब आप स्क्रीन को खुद क्लिक करके देखते हैं, तभी अनिश्चितता दूर होती है।
आइए कॉस्ट ऑफ डिले (Cost of Delay) के नजरिए से सोचें। यदि $2,025 प्रति सप्ताह कमाने वाले 4 इंजीनियर 2 सप्ताह तक केवल आर्किटेक्चर मीटिंग करते रहें, तो $16,200 का प्रत्यक्ष और अप्रत्यक्ष नुकसान होता है।
| मूल्यांकन आइटम | स्पेक-केंद्रित विकास | प्रोटोटाइप-प्रथम विकास | प्रभाव |
|---|---|---|---|
| शुरुआती रिक्वायरमेंट की परिभाषा | 2 से 4 सप्ताह (डॉक्यूमेंटेशन) | 30 मिनट से 1 दिन (स्पाइक लिखना) | समय में 90% की बचत |
| प्लानिंग संशोधन मीटिंग | औसतन 8 से 12 बार (अमूर्त बहस) | औसतन 2 से 3 बार (सिमुलेशन आधारित) | बैठकों में 70% की कमी |
| दिशा की त्रुटियों में सुधार | पूरी संरचना का पुनर्निर्माण | 30 मिनट का ड्राफ्ट त्यागना | रीवर्क की लागत न्यूनतम |
| PR समीक्षा की गति | बॉटलनैक उत्पन्न होता है | ड्राफ्ट PR पहले ही जारी करना | समीक्षा की गति में 30% की वृद्धि |
जब सोचना और लागू करना आपस में मिल जाते हैं, तो कोड लिखते समय आप बार-बार पीछे मुड़कर देखने लगते हैं। यही कारण है कि काम के घंटों को विश्लेषण चरण और केवल कार्यान्वयन चरण में स्पष्ट रूप से विभाजित किया जाना चाहिए। यह Basecamp की Shape Up पद्धति के 'निश्चित समय, परिवर्तनशील दायरा' सिद्धांत के समान है। समय पहले ही तय कर लें, और यदि उस समय के भीतर काम पूरा न हो सके, तो फीचर्स को छोड़ दें।
जब आप किसी कठिन हिस्से में फंस जाएं, तो गहरी सोच में डूबने के बजाय मार्टिन फाउलर के तकनीकी ऋण चतुर्भांश (Technical Debt Quadrant) से 'जानबूझकर और विवेकपूर्ण ऋण' (Deliberate and Prudent Debt) की अवधारणा का पालन करें। यदि वह कोड ऐसा है जिसे बाद में आसानी से बदला जा सकता है, तो अभी सबसे सरल रास्ता चुनकर कमिट करना बेहतर है।
जेफ बेजोस ने कहा था कि जब निश्चितता (certainty) 70% के स्तर पर पहुंच जाए, तो निर्णय लें और आगे बढ़ें। 90% या उससे अधिक परफेक्ट होने का इंतजार करना गति को धीमा करना है।
यदि आप कोड के परफेक्ट न होने के कारण उसे छुपा कर रखते हैं, तो वह बाद में और बड़े रीवर्क के रूप में सामने आता है। Shopify की इंजीनियरिंग टीम सही कोड की जांच कराने के बजाय काम की दिशा को सत्यापित करने के लिए Draft PR अपलोड करती है।
PR का आकार 200 से 300 लाइनों से कम रखना सबसे अच्छा है। यदि आप "केवल एल्गोरिदम संरचना की दिशा पर फीडबैक प्राप्त करना है" टैग के साथ इसे अपलोड करते हैं, तो रिव्यूअर पर बोझ कम हो जाता है।
शुरुआती कोड आपकी कोई कलाकृति नहीं है, बल्कि केवल एक परिकल्पना (hypothesis) है जिसे सत्यापित किया जाना है। जब फीडबैक मिले, तो उसे तुरंत लागू करें और आगे बढ़ें।
परफेक्ट वर्चुअल आर्किटेक्चर कभी भी आपके दिमाग से बाहर नहीं आ पाता। आज आपके द्वारा लिखा गया कच्चा लेकिन काम करने वाला ड्राफ्ट ही आपका असली कौशल बनता है। जब आप पूर्णतावाद के बहाने को छोड़ देते हैं, तो आप देरी की लागत (Cost of Delay) के दलदल से बाहर निकल सकते हैं।
