ओरेकल डाटाबेस कोड की पागलपन और सफलता

इस हफ्ते, हैकर न्यूज़ यूजर्स ने इस सवाल पर चर्चा करने का निर्णय लिया कि "अधिकतम राशि क्या है - लेकिन अभी भी काम कर रहा है - कोड आपने देखा है?" (बाद में Reddit उपयोगकर्ता उनके साथ जुड़ गए )। टिप्पणियों में, बहुत सारी "मज़ेदार" कहानियों को उन चीजों के बारे में बताया गया था जो हम समय-समय पर आते हैं; लेकिन "फॉर्च्यून 100 कंपनियों द्वारा प्रयुक्त उन्नत डीबीएमएस" कोड के बारे में कहानी ने सबसे अधिक ध्यान आकर्षित किया।

लवक्राफ्ट हॉरर नामांकन में विजेता पात्र पूर्व ओरेकल डेवलपर की कहानी थी, जो कि संस्करण 12.2 के विकास के दौरान ओरेकल डेटाबेस पर काम करता था। उस समय DBMS का कोड बेस 25 मिलियन सी था - और जैसे ही आपने इन लाइनों में से केवल एक को बदल दिया, पहले लिखे गए हजारों परीक्षण टूट गए।

वर्षों में, प्रोग्रामर की कई पीढ़ियों ने कोड पर काम किया है, जिन्हें नियमित रूप से कठिन समय सीमा का पीछा किया गया था - और इसके लिए धन्यवाद, कोड एक वास्तविक दुःस्वप्न में बदल सकता है। आज इसमें कोड के जटिल "टुकड़े" शामिल हैं जो तर्क, स्मृति प्रबंधन, संदर्भ स्विचिंग, और बहुत कुछ के लिए जिम्मेदार हैं; वे हजारों अलग-अलग झंडों का उपयोग करके एक-दूसरे से जुड़े हुए हैं। सभी कोड एक रहस्यमय मैक्रो द्वारा आपस में जुड़े हुए हैं, जिसे नोटबुक का सहारा लिए बिना डिक्रिप्ट नहीं किया जा सकता है, जिसमें आपको यह लिखना होगा कि मैक्रो के संबंधित हिस्से क्या करते हैं। नतीजतन, एक डेवलपर को यह पता लगाने में एक या दो दिन लग सकते हैं कि मैक्रो वास्तव में क्या करता है।

एक या किसी अन्य मामले में कोड के व्यवहार की भविष्यवाणी करने के लिए, आपको यह समझना और याद रखना होगा कि 20 या (या सौ) झंडे के क्या मूल्य हो सकते हैं। स्थिति इस तथ्य से बढ़ जाती है कि विभिन्न डेवलपर्स ने अपने स्वयं के प्रकारों का उपयोग किया, जो अनिवार्य रूप से एक ही चीज (उदाहरण के लिए, इंट 32) थे - और शायद ही कोई ऐसी विरासत को छूने की हिम्मत करेगा (हम यह सुनिश्चित करने के लिए कह सकते हैं कि यह मामला था Oracle 8i कोड आधार)।

सवाल उठता है: कैसे, इस सब के साथ, ओरेकल डेटाबेस अभी भी अपने पैरों पर रहने में सक्षम है? रहस्य लाखों परीक्षणों में है। उनका पूर्ण कार्यान्वयन 20 से 30 घंटे तक हो सकता है (उसी समय उन्हें 100-200 सर्वर के एक परीक्षण क्लस्टर पर वितरित किया जाता है)।

90 के दशक के अंत में उत्पाद पर काम करने वाली टीम और TDD (परीक्षण-संचालित विकास) के विचारों का पालन करने के लिए, निम्नलिखित राय थी: "स्वचालित परीक्षणों का मतलब है कि आपको ऐसा कोड लिखना होगा जिसे समझा जा सके - इसके बजाय, आपको चाहिए परीक्षण सोचें। " भविष्य में, डेवलपर्स को उनके द्वारा निर्धारित सिद्धांतों का पालन करने के लिए मजबूर किया गया था, और अब हम व्यवहार में देख रहे हैं कि यह विचार लंबे समय में क्या बदल गया - इसके सभी प्लसस और मिनस के साथ।

आज, Oracle डेटाबेस में एक नया बग ठीक करने की प्रक्रिया में कई हफ्तों से लेकर कई महीनों तक का समय लगता है। सबसे पहले, डेवलपर को अपनी ज़रूरत के अनुसार झंडे छांटने में कई दिन बिताने पड़ते हैं (जिसकी रहस्यमय बातचीत से बग पैदा होता है), जिसके बाद उसे अक्सर अपना झंडा जोड़ना पड़ता है, जो बग के कारण बनने वाली विशिष्ट स्क्रिप्ट को संसाधित करने के लिए जिम्मेदार होगा।

फिर वह परीक्षण के लिए कोड भेजता है, और अगले दिन वह शांति से किसी अन्य कार्य के लिए स्विच करता है, परीक्षण क्लस्टर के लिए एक नए ओरेकल डीबी असेंबली को इकट्ठा करने और उस पर सभी परीक्षण चलाने के लिए इंतजार करता है। यदि डेवलपर भाग्यशाली है, तो लगभग 100 परीक्षण "ब्लश" करेंगे; यदि नहीं (और यह विकल्प अधिक बार होता है) - लगभग 1000, और उसे जांचना होगा कि मौजूदा कोड के संचालन के बारे में उसकी कौन सी धारणा गलत है; यह बहुत संभव है कि वह यह पाएगा कि उसे एक दर्जन अलग-अलग झंडों का अध्ययन करने की आवश्यकता है, जो कि एक स्पष्ट तरीके से उस कोड के काम में भाग लेता है जिसे उसने बदल दिया।

उसे कुछ हफ़्ते के लिए इस प्रक्रिया को दोहराना होगा, क्योंकि भाग्य अंततः उस पर मुस्कुराता है और सभी परीक्षण अंततः पास हो जाते हैं। जिसके बाद उसे कई दर्जन परीक्षण लिखने होंगे - यह सुनिश्चित करने के लिए कि डेवलपर, जो भविष्य में अपने कोड को परेशान करेगा, अपने "फिक्स" को नहीं तोड़ देगा। फिर सुधारों को एक समीक्षा के लिए भेजा जाएगा, जिसमें कई हफ्तों से लेकर कुछ महीनों तक का समय लग सकता है, जिसके बाद बग को आखिरकार मुख्य कार्य शाखा में मिला दिया जाएगा।

इस तथ्य के कारण कि DBMS बनाने और परीक्षण चलाने में कम से कम एक दिन लगता है, यह उम्मीद की जाती है कि प्रत्येक डेवलपर 2-3 बग पर एक साथ काम करता है और परीक्षण के परिणामों की प्रतीक्षा करते समय उनके बीच स्विच करता है।

अगर आपने सोचा कि DBMS में नई कार्यक्षमता जोड़ने वाले डेवलपर्स का जीवन आसान है, तो आप व्यर्थ हैं। नए प्रमाणीकरण मोड की तरह एक छोटी सी नई सुविधा को जोड़ने में 6 महीने से लेकर एक साल तक का समय लग सकता है, विशेष रूप से उन्नत मामलों में - दो साल तक।

वर्णित मामले में, टीडीडी "स्पेगेटी" कोड को क्रम्बल नहीं करने की अनुमति देता है, जिसमें पहले से ही कुछ समझना बहुत मुश्किल है, और आउटपुट पर एक कार्यशील उत्पाद है। इसी समय, लागत में वृद्धि जारी है, और नए कोड की गुणवत्ता अक्सर वांछित होने के लिए बहुत कुछ छोड़ देती है। न केवल यूएसए से डेवलपर्स की एक टीम, बल्कि भारत से भी एक टीम DBMS पर काम कर रही है, इसलिए कुछ ओरेकल डेवलपर्स, स्थापित परंपरा के अनुसार, उन पर कोड की गुणवत्ता को दोष देते हैं। अन्य लोग उनसे असहमत हैं, और चैंज के आधार पर वे कहते हैं कि कोड की गुणवत्ता टीम के भूगोल पर निर्भर नहीं करती है, और खराब कोड समय-समय पर दोनों टीमों से "मक्खियों"। उत्पाद के लिए एक बहुत गंभीर समस्या डेवलपर्स की है जो इस परियोजना को "उद्योग में प्रवेश" के रूप में अनुभव करता है और DBMS पर 1-2 साल से काम नहीं कर रहा है; इस समय के दौरान इस परियोजना की जटिलताओं को समझना असंभव है।

एक और डेवलपर की गवाही के अनुसार, जो 90 के दशक के अंत में एक यूनिक्स संस्करणों में Oracle 8i कोड बेस को पोर्ट कर रहा था, उस समय पहले से ही कोड "स्पेगेटी" की एक गेंद थी जिसे पूरी तरह से समझना पूरी तरह से असंभव था। 80 के दशक के उत्तरार्ध में DBMS कोड के साथ काम करने वाले एक अन्य डेवलपर का दावा है कि कोड का आधार तब C स्रोतों का एक विशाल समूह और विधानसभा के लिए मेकफाइल्स का एक समूह था - जिनमें से कई कर्नेल कोड से बहुत अधिक जटिल थे। बेशक, यह यथार्थवादी होने के लायक है - शायद ही स्थिति समान उत्पादों, उद्योग के नेताओं में बेहतर है, जिसका विकास कई दशकों तक किया गया है।