XP, TDD, और vibe coding: Kent Beck के Programmatic Engineer इंटरव्यू के कुछ हिस्सों का अनुवाद

• XP और TDD के जनक Kent Beck के Programnatic Engineer इंटरव्यू में से मुझे प्रभावशाली लगे कुछ हिस्सों का सार
• जिन्हें Kent Beck पसंद हैं, उनके लिए पूरा वीडियो देखने की सिफारिश

---

Q. XP का मूल क्या है?

इन 4 गतिविधियों को करना।

1. पता लगाना कि क्या करना है
2. वह संरचना समझना जो 1 को करने लायक बनाती है
3. 2 का उपयोग करके 1 को लागू करना
4. यह जांचना कि 3 अपेक्षा के अनुसार काम कर रहा है या नहीं

बस यही है। और समय को बहुत छोटे हिस्सों में बांटकर, हर समय-खंड में इन चारों गतिविधियों को थोड़ा-थोड़ा, लेकिन सभी करना।

Q. तो क्या pair programming XP में अनिवार्य नहीं है?

जब मैं पहली बार XP टीम चला रहा था, हम हर 3 हफ्ते में deploy करते थे, और स्वाभाविक रूप से bugs भी होते थे।

मैंने उन bugs के पैटर्न का विश्लेषण किया जो 'deploy के बाद' मिले, तो पाया कि वे सभी bugs अकेले लिखे गए code से आए थे। उल्टा कहें तो, pair में लिखा गया code production environment में report हुई defects से मुक्त था।

Q. तो फिर यह अनिवार्य नहीं, बल्कि बहुत ज़ोरदार सिफारिश है?

वह भी नहीं। बात है experiment करने की। आप पहले की तरह develop कर सकते हैं। बस, जागरूक रहकर।

चाहे continuous design हो, continuous verification, continuous implementation, या ग्राहक के साथ continuous interaction — अगर आप उससे मिलने वाला लाभ चाहते हैं, लेकिन हमेशा की तरह काम करने से वह नहीं मिल रहा, तो तरीका बदलना होगा।

अगर कोई मेरे पास आकर कहे, "Kent, मैं TDD नहीं करता।" तो मैं जवाब दूंगा, "तो?"

अगर आप अपने code की defect density और design decisions पर मिलने वाले feedback के स्तर से संतुष्ट हैं, तो ठीक है। लेकिन अगर संतुष्ट नहीं हैं, तो pair हो या TDD, उसे आज़माइए।

Q. इसी बात पर, आपने TDD क्यों बनाया?

मैं बहुत चिंता करने वाला और बेचैन व्यक्ति हूं, और मेरे लिए programming लगातार anxiety का स्रोत थी। मैंने क्या भूल गया? मैंने क्या तोड़ दिया?

लेकिन TDD के साथ develop करने पर यह बेचैनी गायब हो जाती है। अगर अब और कोई ऐसा test case नहीं सूझ रहा जो fail हो सकता हो, तो मैं आश्वस्त हो सकता हूं कि मेरा program काम कर रहा है। ज़रा-सी भी बेचैनी होती है? तो बस अगला test case लिख देता हूं.

बेशक TDD के कई technical फायदे भी हैं, जैसे defect density कम करना, design decisions पर जल्दी feedback पाना, implementation design को evolve करना आदि। लेकिन programming से जुड़ी anxiety से मुक्त हो जाना, programming के emotional experience का पूरी तरह बदल जाना — मेरे लिए यही सबसे महत्वपूर्ण है। यही कारण है कि मैंने TDD बनाया।

Q. TDD करने पर अच्छे design के लिए जगह नहीं बचती — John Ousterhout की इस आलोचना पर आपका क्या विचार है?

(अनुवादक की टिप्पणी: John Ousterhout प्रसिद्ध पुस्तक Philisophy of Software Design के लेखक हैं, और कुछ महीने पहले Programmatic Engineer पॉडकास्ट में आकर TDD पर आलोचनात्मक दृष्टिकोण भी रख चुके हैं)

उन्होंने एक पक्ष को गलत समझा है। वह बस decision का परिणाम है। अगर TDD को सिर्फ Red-Green की repetition मान लिया जाए, तो स्वाभाविक रूप से उसमें design के लिए जगह नहीं बचेगी।

TDD practitioner के रूप में मैं हमेशा abstraction के अलग-अलग levels के बीच आना-जाना करता हूं। उदाहरण के लिए:

• अभी मैं Red state में हूं। अगले test case को pass कराने के लिए(Green) implementation कैसे करूं?
• कुछ कठिन लग रहा है। क्यों कठिन है?
• Green तक पहुंचने वाली implementation को आसान बनाने के लिए design कैसे बदलूं?
• इस idea को कब introduce करना चाहिए? अभी, या बाद में?
• अगर अभी introduce करूं, तो कितना? जितना अभी कर सकता हूं उतना थोड़ा-सा, या बड़ा chunk?

यानी test लिखने से पहले भी, मेरे पास हमेशा design का एक क्षण होता है.

Implementation करने से पहले मैं interface पर decision लेता हूं, Red test बनाता हूं, और क्योंकि मुझे Red state पसंद नहीं, मैं जितनी जल्दी हो सके Green तक पहुंचता हूं। Green हो जाने पर बेचैनी थोड़ी देर के लिए गायब होती है, तो सोचने की जगह मिलती है। "हम्म, यह pass तो हो गया, लेकिन दूसरे cases में शायद नहीं चलेगा। implementation को और generalize करना होगा।"

Red है? उसे Green बनाओ। Green है? सांस लो और सोचो। यही मेरा TDD cycle है।

Q. कभी-कभी implementation इतना obvious लगता है कि मैं पहले implementation कर लेता हूं और फिर Red-Green tests करता हूं। इस तरीके पर आपका क्या विचार है?

शायद ऐसा इसलिए है क्योंकि आप मान रहे हैं कि 'यह implementation approach सही है', और वह मान्यता जितनी सही होगी, test पहले लिखने के तरीके का फायदा उतना कम होगा।

लेकिन मैं हमेशा ऐसा सोचता हूं: "मैं लगातार सीखता और अनुभव जुटाता रहूंगा, और यही वह क्षण है जब मैं सबसे कम जानता हूं।"

यानी मैं मानकर चलता हूं कि मैं सीखता रहूंगा, और परिस्थितियां बदलेंगी। जितना ज़्यादा मुझे सीखना है और जितना ज़्यादा हालात बदल सकते हैं, उतना ही मैं decisions को जितना संभव हो उतना देर से लेना चाहता हूं। यह एक सामान्य सिद्धांत है। dating हो या cooking, बात वही है।

अगर आप ज़्यादा predict कर सकते हैं, तो बड़े jumps ले सकते हैं। लेकिन programming में मेरा सबसे पसंदीदा क्षण वह है जब मैं यह सोचकर आगे बढ़ रहा होता हूं कि मुझे सब पता है, और अचानक पता चलता है कि implementation का इससे कहीं बेहतर तरीका मौजूद था। मैं ऐसे क्षण जितनी बार हो सके उतनी बार अनुभव करना चाहता हूं। इसलिए मैं TDD करता हूं।

अगर आपके दिमाग में तस्वीर बिल्कुल साफ है, और आपको भरोसा है कि कौन-सा input कौन-सा output देगा, तो बस implementation कर दीजिए। लेकिन जितनी ज़्यादा गलतियां होती हैं, जितना ज़्यादा आप सीखते हैं, और जितनी ज़्यादा दुनिया unpredictable होती जाती है, उतना ही अभी commit न करके बाद के लिए टालना फायदेमंद होता है।

Q. AI के साथ coding करते हुए भी क्या आप पहले की तरह TDD से develop करते हैं?

इसका सीधा जवाब देना मुश्किल है।

मैं tests का उपयोग AI के साथ communication के माध्यम के रूप में करता हूं, खासकर यह बताने के लिए कि AI ने क्या गलत किया है। यह बार-बार मेरे tests को delete या modify करने की कोशिश करता है, और मैं हर बार इसे डांटता हूं। मेरे tests सही हैं, इसलिए ठीक से काम करो।

AI अक्सर लंबे समय के लिहाज़ से खराब decisions लेता है। coupling कम करना और cohesion बढ़ाना भी इसे वास्तव में नहीं आता। अगर बहुत स्पष्ट रूप से बताया जाए कि क्या करना है, तो कभी-कभी यह कर लेता है, लेकिन सामान्य तौर पर design इसमें अच्छा नहीं है।

इसीलिए मैं बहुत सारे tests पहले से तैयार रखता हूं। मैं इन्हें इस बात को पकड़ने के साधन के रूप में इस्तेमाल करता हूं कि कहीं AI कुछ तोड़-फोड़ तो नहीं कर रहा।

(अनुवादक की टिप्पणी: Kent Beck vibe coding में TDD का उपयोग कैसे करते हैं, इसके लिए यह लेख देखें)

Q. अगर "tests को कभी मत बदलो, test pass न हो तो pass होने तक सिर्फ implementation code ही बदलो" जैसे agent rules आम हो जाएं, तो शायद चीजें और आसान हो जाएं। लगता है जैसे आज का समय 2000s की महत्वपूर्ण बातों को फिर से खोजने का है। आप क्या सोचते हैं?

हमें लगातार experiment करते रहना चाहिए। जो कुछ संभव है, सब आज़माना चाहिए। क्योंकि अभी हमें नहीं पता कि वास्तव में सबसे अच्छा क्या है।

क्या 'सस्ता' है और क्या 'महंगा', इस बारे में हमारी पूरी समझ बदल गई है। पहले जिन कई चीज़ों को महंगा या कठिन मानकर नहीं किया जाता था, वे अब हैरान कर देने वाली हद तक सस्ती हो गई हैं.

अगर किसी दिन अचानक कारें मुफ्त हो जाएं, तो आपको क्या लगता है क्या होगा? निश्चित ही कुछ बदलेगा, लेकिन उसके second-order और third-order effects क्या होंगे? कोई नहीं जानता। इसलिए अभी हमारे पास बस इतना ही विकल्प है कि तरह-तरह की चीजें आज़माएं।

Q. आपने कहा कि 50 साल से अधिक programming करने के बावजूद आजकल सबसे ज़्यादा आनंद आ रहा है। इसका क्या मतलब है?

मेरे बड़े ideas को साकार करना अब पहले से कहीं आसान हो गया है। यह देखना और guide करना कि AI इस idea को implement कर पाएगा या नहीं, और कैसे करेगा, बहुत addictive है। यह किस समय अच्छा काम करेगा, यह कभी ठीक से पता नहीं होता, और जब यह जादू की तरह अच्छा काम करता है तो अनुभव लगभग मदहोश कर देने वाला होता है — इस मायने में यह slot machine जैसा है। टहलने या lunch पर जाने से पहले भी मन करता है कि इसे खेलने के लिए कम से कम एक prompt तो लिखकर जाऊं।

दो साल पहले मैंने tweet किया था: "ChatGPT इस्तेमाल करने को लेकर मेरे मन में झिझक थी, और आज समझ आया कि क्यों। मेरी 90% skills की कीमत अब $0 हो गई है। और बाकी 10% की leverage 1000 गुना बढ़ गई है। अब मुझे खुद को recalibrate करना होगा."

> I've been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
>
> The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
>
> -- Kent Beck 🌻 (@KentBeck) April 18, 2023

(अनुवादक की टिप्पणी: उस समय यह tweet चर्चा में आने पर Kent ने थोड़ा लंबा लेख भी लिखा था।)

तब उन्होंने कहा था कि वह अभी भी खोज रहे हैं कि 90% क्या है और 10% क्या है, लेकिन अब वह कुछ हद तक जवाब दे सकते हैं। एक साहसी vision रखना, उस vision तक पहुंचने के milestones तय करना, design को लगातार समायोजित करते हुए आगे बढ़ना, और complexity को control में रखने की क्षमता। यह किसी खास language की syntax की जानकारी (जैसे Rust में &, *, [ कहाँ रखना है) से कहीं ज़्यादा महत्वपूर्ण skill है।