70% समस्या यह अवलोकन है कि जेनरेशन सॉफ्टवेयर बिल्ड को कार्यशील बनाने तक का अधिकांश भाग ले जाती है, फिर ऐसे बाकी हिस्से के विरुद्ध रुक जाती है जो स्वचालन का विरोध करते हैं। वह आखिरी हिस्सा पहले जैसा कोड का छोटा हिस्सा नहीं होता; यह गुणात्मक रूप से अलग काम है: इंटीग्रेशन, एज-केस, उत्पादन हार्डनिंग, और वह हिस्सा जिसे किसी ने स्पष्ट रूप से निर्दिष्ट नहीं किया। पहला हिस्सा प्रवाह-योग्यता rewarded; अंतिम हिस्सा निर्णय-शक्ति पर पुरस्कार देता है, और निर्णय boilerplate जैसी संकुचित नहीं होते।
- पहला 70% स्पष्ट-समझ आने वाला सतह है; शेष हिस्सा अस्पष्ट आंतरिक है।
- एक डेमो खुश रास्ते की पुष्टि करता है और उसे तोड़ने वाली परिस्थितियों को छिपाता है।
- एज केस ऐसे तेजी से गुणित होते हैं जितना कोई भी प्रॉम्प्ट सूचीबद्ध कर सके।
- इंटीग्रेशन फ्रिक्शन प्रणालियों के बीच रहता है, जहां किसी एक जनरेटर को पूरी स्थिति देखना संभव नहीं।
- प्रोडक्शन हार्डनिंग मुख्यतः उन इनपुट्स से बचाव करने का कार्य है जिन्हें किसी ने वर्णित नहीं किया।
- यह आंकड़ा समय के साथ चलता रहता है, लेकिन कठिनाई की आकृति नहीं बदलती।
आख़िरी खिंचाव पहली से Qualitative रूप से अलग क्यों है?
बिल्ड का पहला खिंचाव संरचना से भरा होता है जिसे हजारों बार बताया गया है। फॉर्म्स, सूचियाँ, राउटिंग, स्टेट, एक डेटा आकार जिसके Fields पूर्वानुमानित होते हैं। यहाँ जेनरेशन मजबूत होती है क्योंकि पैटर्न सामान्य होते हैं और इरादा स्पष्ट होता है। एक sortable तालिका या मान्य फॉर्म के बारे में अस्पष्टता बहुत कम होती है कि वह क्या करेगा।
बाकी हिस्सा प्रकार में अलग है। यह ऐसी प्रणाली की प्रवृत्ति है जहाँ विवरण समाप्त हो जाता है और वास्तविकता आगे बढ़ती है। जब दो लिखतें एक-दूसरे से रेस करती हैं? जब ऊपर से भेजी गई सतह एक ऐसा आकार लौटाती है जिसे उसने Never लौटाने का वादा किया था? जब उपयोगकर्ता वही व्यवहार करता है जो उचित है पर अप्रत्याशित है? ये प्रश्न शुरुआती सवालों के कठिन संस्करण नहीं हैं; ये एक अलग श्रेणी हैं, जिन्हें कोड लिखने से नहीं बल्कि यह तय करने से परिभाषित किया गया है कि मूल अनुरोध ने जिन परिस्थितियों में कोड का क्या मतलब होना चाहिए, उसे कौन नहीं बताया था।
एक फीडबैक प्रभाव भी है। शुरुआती कोड तेज़ी से जेनरेट होता है, इसलिए यह तेजी से जमा होता है, और मात्रा स्वयं एक ऐसी कठिन भूमि बन जाती है जिसे पार करना पड़ता है। मिनटों में बनने वाला बिल्ड भी घंटों में समझना पड़ता है। पाठक एक ऐसी संरचना पर पहुँचते हैं जिसे उन्होंने लिखा ही नहीं होता, उन मान्यताओं के साथ जिन्हें उन्होंने नहीं चुना होता, और समझने की लागत उसी क्षण उतार पर पहुँचती है जब कठोर निर्णय शुरू होते हैं।
यही कारण है कि प्रतिशत हिस्सा फिसलन भरा रहता है। मॉडलों के उन्नत होने पर सीमा आगे बढ़ती है, पर वह उसी दोष-रेखा के साथ आगे बढ़ती है: जहाँ स्पष्ट स्पेसिफिकेशन समाप्त होता है, ऑटोमेशन धीमा पड़ता है। ढलान उसी जगह तेज़ होती है जहाँ विवरण कम होता है। जो चित्र प्रगति के रूप में पढ़ा जाता है, दरअसल वह एक फ्रंटियर पर संकेतक है जो लगातार उन हिस्सों की ओर शिफ्ट होता है जिन्हें पहले से ही सबसे कम स्पष्ट माना गया था।
डेमो क्या छिपाता है जो उत्पादन खुलासा करता है?
डेमो एक नियंत्रित प्रदर्शन है। यह एक path, चुने हुए इनपुट के साथ, एक आसान-नेटवर्क पर, दर्शकों के सामने जो इसे सफल देखना चाहتا है, चलता है। उत्पादन विपरीत है: हर path एक साथ, शत्रुतापूर्ण इनपुट, आंशिक विफलताएँ, और कोई एक स्टियरिंग नहीं। उन दो स्थितियों के बीच दूरी डेमो-टू-प्रोडक्शन गैप है, और यही वह जगह है जहाँ अधिकांश आख़िरी-mile प्रयास सच में जाते हैं।
यह गैप चौड़ा है क्योंकि एक काम करने वाला डेमो और एक काम करने वाली प्रणाली दोनों एक-सी दीखती हैं लेकिन संरचना में भिन्न होती हैं। डेमो दृश्य के लिए अनुकूलित होती है; प्रणाली को अदृश्य पर विचार करना पड़ता है — retries, idempotency, वह timeout जो सप्ताह में एक बार चलता है, वह migration जो ट्रैफिक जारी रहते हुए चलना होता है। स्क्रीन रिकॉर्डिंग में वह सब नहीं दिखता।
एक व्यापार-समझौता जो उभरता है वह है गति बनाम टिकाऊपन। जेनरेशन एक तेज़, संभाव्य artifact बनाती है। उस artifact को वास्तविक लोड के साथ टिके रहने योग्य बनाने में समय लगता है, और यह अक्सर अधिक कोड बनाने जैसा नहीं दिखता। यह पढ़ना, ट्रेस करना, और जो पहले से मौजूद है उसे सीमित करने जैसा दिखता है।
गैप का एक perceptual cost भी है। एक convincing डेमो यह उम्मीद बनाता है कि काम लगभग समाप्त हो चुका है, जो शेष प्रयास को पुनरावृत्ति की तरह महसूस कराता है, न कि पूरे काम के भार के रूप में। हितधारकों ने इसे काम करते हुए देखा। उस समय और एक reliable system के बीच दूरी वास्तविक है, पर उसे defend करना मुश्किल है क्योंकि यह प्रदर्शन देखने वाले किसी के लिए भी अदृश्य है।
क्यों सबसे कठिन शेष हिस्सा उन चीज़ों में रहता है जिन्हें किसी ने निर्दिष्ट नहीं किया?
निर्दिष्ट नहीं किया गया शेष वह व्यवहार है जो किसी भी अनुरोध में कभी नहीं लिखा गया। यह अंतिम-मील लागत का सबसे बड़ा स्रोत है क्योंकि इसे ऐसे प्रॉम्प्ट से उत्पन्न नहीं किया जा सकता जिसमें वह शामिल नहीं है। जेनरेटर वही प्रश्न का उत्तर देता है जो उसे पूछा गया है। कठिन भाग है वह प्रश्न जिसे किसी ने सोचा ही नहीं पूछना।
स्पेसिफिकेशन खास तौर पर तब महँगा होता है जब यह सबसे अधिक मायने रखता है। कोई भी यह नहीं बताता कि चेकआउट क्या करता है जब पेमेंट सतह पुष्टि करती है पर ऑर्डर लिखना विफल हो जाता है, क्योंकि कोई इसे सोचना नहीं चाहता जब तक वह घटित नहीं हो जाता। इसलिए स्पष्ट इच्छा और आवश्यक व्यवहार के बीच का गैप काम बन जाता है। किसी को यह कमी नोटिस करनी, उसका नाम लेना, और निर्णय लेना होगा।
नोटिस करना यहाँ एक कम आँकी गई कौशल है। एक जनरेटर जो दिया गया है उसे भर देता है और जो नहीं दिया गया उसे चुप रख देता है, और वह चुप्पी खुशी के रास्ते के परीक्षणकर्ता के लिए पूर्णता के रूप में पढ़ी जाती है। शेष स्पष्ट रूप से संरचना के रूप में नहीं दिखता। इसे उजागर करना मतलब तनाव के आने से पहले सिस्टम को तनाव में कल्पना करना, जो एक ध्यान की आदत है न कि किसी भी टूल की ship की गई सुविधा।
- Happy path
- डेमो जिसे दिखाने के लिए एकल घटना-श्रृंखला बनाई गई है, जहाँ हर निर्भरता व्यवहार करती है।
- Unspecified remainder
- ऐसा व्यवहार जिसे सिस्टम को प्रदर्शित करना चाहिए पर किसी भी अनुरोध, प्रॉम्प्ट, या टिकट ने कभी वर्णित नहीं किया।
- Integration seam
- दो प्रणालियों के बीच सीमा, जहाँ एक-दूसरे के बारे में सभी मान्यताएँ बिना उल्लेख के होती हैं।
- Production hardening
- जनरेटेड संरचना को इनपुट, विफलताएँ, और लोड से बचाने के काम का वह भाग जो दिखाया नहीं गया।
जहाँ-human effort relocation होता है जब generation पहले 70% को अवशोषित कर लेती है?
यही प्रयास गायब नहीं होता; यह माइग्रेट होता है। जब शुरुआती, अच्छी तरह से निर्दिष्ट बिल्ड मिनटों में जेनरेट हो जाती है, तो उसे टाइप करने में कभी जो मानवीय घंटे लगते थे, वे उन गतिविधियों की ओर मुड़ते हैं जहाँ जेनरेशन सबसे कमजोर है। अपरिचित कोड पढ़ना अब एक मुख्य कौशल बन जाता है। सिस्टम को अपनी किनारों पर क्या करना चाहिए, यह निर्धारित करना दुर्लभ योगदान बन जाता है।
यह relocation दिन-भर-का आकार बदल देता है। पहले ड्राफ़्ट बनाने में कम समय, उन्हें पढ़ने-जाँचने में अधिक समय। बाधा-रेखा निर्माण से सत्यापन की ओर जाती है — यह पुष्टि करना कि संभावित चीज़ सही है भी, उन परिस्थितियों में जिन पर जेनरेटर ने कभी परीक्षण नहीं किया। निर्णय, Fail-Mode के बारे में स्वाद, और एक साप्ताहिक बग का पीछा करने की धैर्य वह काम बन जाते हैं जो वजन उठाते हैं।
यह भी बदल देता है कि अनुभव कितनी कीमत रखता है। कई प्रणालियाँ फेल होने का अनुभव जेनरेटर को नहीं देता; यह उस व्यक्ति के पास रहता है जो अपरिचित कोड में एक परिचित खुशबू पहचान लेता है। वही पहचान किसी जनरेटेड फ्लो को देखकर यह अनुमान लगाने देती है कि वह कहाँ टेड़ेगा, परीक्षण शुरू होने से पहले। शुरुआती कोड कमोडिटाइस होता है; इसकी किनारों के लिए अंतःसूत्री प्रवृत्ति नहीं घटती।
| गुण | पहला 70% (जनरेट किया गया) | अंतिम 30% (मानव) |
|---|---|---|
| Specification | Explicit, common, legible | Implicit, rare, contested |
| Dominant activity | Producing structure | Constraining behavior |
| Failure visibility | Obvious in a demo | Hidden until production |
| Cost driver | Volume of code | Depth of judgment |
| Compressibility | High | Low |
टीम अंतिम खिंचाव को सचेत रूप से कैसे पार करती हैं?
अंतिम मील पार करना आम तौर पर एक क्रम का पालन करता है, न कि किसी रेसिपी के अस्तित्व के कारण, बल्कि इसलिए कि गलतियाँ एक पूर्वानुमानित क्रम में आती हैं। अनुशासन यह है कि जेनरेटेड आर्टिफैक्ट को एक परिकल्पना के रूप में मानें और बचा हुआ काम उसे गलत साबित करने के रूप में लें।
- सीमे-मैप करें: उन सभी सीमाओं की सूची बनाएं जहाँ बिल्ड किसी ऐसे सिस्टम को छूता है जिसे आप नियंत्रित नहीं करते।
- डेमो ने कभी उपयोग नहीं किए गए इनपुटों की सूची बनाएं, विशेषकर malformed, empty, और duplicate इनपुट्स।
- हर विफलता पथ को एक निर्णय तक ट्रेस करें: retry, reject, degrade, या surface.
- जो अभिव्यक्त नहीं था उसे स्पष्ट बनाकर लिख दें, फिर उसे चुनें।
- वास्तविक concurrency और वास्तविक मात्रा के साथ परिणाम को दबाव दें उससे पहले कि इसे done घोषित करें।
हर चरण अज्ञात को स्पष्ट इरादे में बदल देता है। जेनरेटेड 70% आपको एक ऐसी बॉडी देता है जिसे पूछ-ताछ किया जा सके; यह प्रक्रिया पूछताछ है। यह डिज़ाइन के अनुसार जनरेशन से धीमी है, क्योंकि इसका उत्पाद सतह के बजाय निश्चितता है।
क्रम किसी भी एक कदम से अधिक मायने रखता है। पहले सीमाओं को मैप करना आंतरिक हिस्से की कठोरता की आम गलती को रोकता है जब तक सीमाएं रक्षा-रहित रहती हैं। इनपुट्स को ट्रेस करने से पहले सूचीबद्ध करना यह सुनिश्चित करता है कि जो आ रहा है वह वास्तविक है, बनाम जो कल्पना की गई थी। यह क्रम उस ध्यान को खर्च करने का तरीका है जहाँ अगली विफलता सबसे अधिक संभावना है, बजाय इसके कि कोड पढ़ना सबसे सरल कहाँ है।
जेनरेशन में सुधार होने पर आखिरी-mile सीमा क्या बन जाती है?
सीमा घुल नहीं रही है; यह ऊपर की तरफ स्थानांतरित हो रही है। जब जेनरेशन स्पष्ट-मध्ये का अधिक भाग संभालती है, मानवीय फ्रंटियर उन हिस्सों की ओर चलता है जिन्हें पहले से सबसे कम वर्णन योग्य माना गया था — निर्णय-निर्णय, फेलियर सेमांटिक्स, और वे निर्णय जो बताते हैं कि क्या एक सिस्टम अपने उपयोगकर्ताओं को देनदार है जब कुछ टूटता है। प्रतिशत ऊपर बढ़ सकता है। शेष की प्रकृति कठिन होती जाती है, आसान नहीं, क्योंकि शेष सब कुछ जिसका स्पेसिफिकेशन से सामना हुआ, उसका अवशेष है।
तब जो कम होता है, वह कोडिंग क्षमता नहीं बल्कि किसी सिस्टम के किनारों को ذہن में धारण करने और उनके बारे में सही निर्णय लेने की क्षमता है। क्षेत्र ऐसे लोगों को पुरस्कृत करता है जो तेजी से पढ़ सकते हैं, उत्पादक तरीके से संदेह कर सकते हैं, और खत्म कर सकते हैं। जनरेटेड बिल्ड का अंतिम खिंचाव तब तक human बना रहेगा जब तक हर सिस्टम का कोई न कोई भाग निर्दिष्ट नहीं है — जिसका मतलब है, बहुत देर तक।
टीमें कैसे व्यवस्थित हों, इसके लिए एक शांत संकेत है। अगर उत्पन्न मिडल भाग बढ़ता रहता है, finished सिस्टम और plausible सिस्टम के बीच का काम कम घंटे वाले, अधिक घने घंटों में केंद्रित होता है। यह गहरा-तस्वीर को throughput से अधिक पुरस्कृत करता है, और यह असफल होने पर एक सिस्टम क्या करे, यह बताने की क्षमता को अधिक मूल्यवान बनाता है बनाम इसे और बनाने की क्षमता। फ्रंटियर चलता रहता है; करीब नहीं होता।
F.A.Q.