अब तक आपने देखा सबसे बड़ा Bad Code कौन-सा है?

 (news.ycombinator.com)
21 पॉइंट द्वारा xguru 2020-09-21 | 8 टिप्पणियां | WhatsApp पर शेयर करें

"25 मिलियन लाइन वाला Oracle Database 12.2 code।"

HN पर आए एक सवाल पर Oracle के एक पूर्व कर्मचारी ने यह जवाब छोड़ा:

"यह ऐसी दहशत है जिसकी कल्पना नहीं की जा सकती। 1000 मौजूदा tests पास किए बिना code की एक लाइन भी लिखना संभव नहीं है।

कुछ रहस्यमय macros ऐसे हैं जिन्हें हाथ से notebook में लिखकर सुलझाए बिना समझा नहीं जा सकता, और macro functionality को सच में समझने में एक से दो दिन लग जाते हैं।

कभी-कभी यह अनुमान लगाने के लिए कि code अलग-अलग परिस्थितियों में कैसे काम करेगा, 20 flags के values और effects समझने पड़ते हैं।

कभी-कभी यह 100 से भी ज़्यादा होते हैं। यह अतिशयोक्ति नहीं है।

यह product आज भी जिंदा है और काम कर रहा है, उसका एकमात्र कारण सचमुच millions of tests हैं।"

Oracle DB developer की ज़िंदगी

  1. नए bug पर काम शुरू करो

  2. इस bug को trigger करने वाले, रहस्यमय तरीके से एक-दूसरे के साथ interact करने वाले 20 अलग-अलग flags को समझने में 2 हफ्ते लगाओ

  3. नए special scenario को handle करने के लिए एक और flag जोड़ो। इस flag को check करने के लिए कुछ lines of code लिखो, और problem situation को solve करने व bug रोकने के लिए कुछ और lines जोड़ो

  4. code changes को 100~200 machines से बने test farm में submit करो। फिर नया Oracle DB build होता है और millions of tests को distribute करके चलाया जाता है

  5. घर जाओ। अगले दिन आकर दूसरा काम शुरू करो। tests पूरे होने में 20~30 घंटे लगते हैं

  6. घर जाओ। अगले दिन आकर test results देखो। अच्छे दिन में लगभग 100 failed tests। बुरे दिन में लगभग 1000 tests fail। इनमें से कुछ tests चुनकर पता करो कि तुम्हारी assumptions में क्या गलत था। संभव है कि bug की असली प्रकृति समझने के लिए 10 और flags पर विचार करना पड़े

  7. इस issue को ठीक करने के लिए कुछ और flags जोड़ो। फिर बदलाव को test farm में submit करो। फिर 20~30 घंटे इंतज़ार करो

  8. 2 हफ्तों तक इन flag combinations को ठीक से काम कराने के लिए fix करते रहो और यही दोहराते रहो

  9. आखिरकार, "किसी अच्छे दिन", कोई भी test fail नहीं होता

  10. अपने बदलाव के लिए 100 से ज़्यादा tests और जोड़ो, ताकि बदकिस्मत अगला developer इस fix को तोड़ न दे

  11. final testing के लिए फिर submit करो। फिर review के लिए submit करो। review में फिर 2 हफ्ते से 2 महीने तक लग सकते हैं, इसलिए किसी दूसरे bug पर जाकर काम शुरू करो

  12. 2 हफ्ते से 2 महीने बाद, जब सब खत्म हो जाए, तब code main branch में merge होता है

यही Oracle programmer की bug fix करने वाली ज़िंदगी है। इसमें कोई अतिशयोक्ति नहीं है।

अब ज़रा कल्पना कीजिए कि नई feature develop करना कितना बड़ा horror होगा।

एक छोटी-सी feature develop करने में 6 महीने से 1 साल, और कभी-कभी 2 साल तक लग जाते हैं। (जैसे Active Directory authentication जैसा नया authentication जोड़ना)

यह product काम करता है, यही अपने-आप में एक चमत्कार है।

मैं अब Oracle में काम नहीं करता, और दोबारा कभी Oracle में काम नहीं करूंगा

संबंधित पढ़ाई

8 टिप्पणियां

 
neocoin 2020-09-28

Test Cycle है

  1. Code लिखो

  2. Test लिखो

  3. Code को Refactor करो, और 1 पर वापस जाओ

लेकिन 1, 2 में बहुत समय लग जाता है, इसलिए लगता है कि 3 बार-बार छूटता रहता है और नतीजे में यही सब जमा हो जाता है।
 
kunggom 2020-09-21

अब तक आपने देखा हुआ सबसे बड़ा Bad Code कौन सा है?

इस मौके पर Martin Fowler का व्याख्यान फिर से देखने लायक है। लगता है कि Oracle Database की ‘आंतरिक गुणवत्ता’ (Internal Quality) अच्छी नहीं है।

https://hi.news.hada.io/topic?id=2752
 
kbumsik 2020-09-21

Oracle के नज़रिए से देखें तो यह किसी तरह स्वाभाविक ही लगता है, बल्कि इतना भरोसा होता है कि लगता है यह सॉफ़्टवेयर वाकई enterprise के लिए ही बना है...

लेकिन उस लेख की तरह, वहाँ काम करना मैं नहीं चाहूँगा।
 
exitmusic 2020-09-21

मुझे तो उल्टा यह लगता है कि कहीं test-केंद्रित development culture की वजह से development process ही खराब तो नहीं हो गया।

जैसे किसी भी तरह बस test pass हो जाए तो वही काफी है, उसी अंदाज़ में development होता है... शायद ऐसे माहौल में refactoring के बारे में सोचना भी मुश्किल होगा।
 
sduck4 2020-09-22

टेस्ट अपने-आप में समस्या कम है; उससे बड़ी बात शायद यह डिज़ाइन संबंधी समस्या है कि किसी फीचर को संशोधित/जोड़ने के लिए 20~100 फ्लैग्स तक को ध्यान में रखना पड़ता है, है न?

हालाँकि DBMS की जटिलता की वजह से यह कुछ हद तक अपरिहार्य भी लगता है।
 
kunggom 2020-09-21

टेस्ट भी आखिरकार डेवलपर द्वारा लिखा गया कोड ही होता है। यह याद आते ही मैंने टेस्ट के बारे में एक लेख साझा किया।

https://hi.news.hada.io/topic?id=2883
 
ffdd270 2020-09-21

अगर प्रोजेक्ट उस स्तर का न हो, तो टेस्ट लगातार यह सुनिश्चित कर सकते हैं कि इंटरफेस को पूरी तरह बदल देने पर भी पुराना व्यवहार वैसा ही रहे, इसलिए उल्टा रिफैक्टरिंग करने का साहस मिलता है। मैंने हाल ही में जो emulator बनाया है, उसमें parameter को BYTE value से Enum value में बदलने का काम किया था। Build सफल हो गया, लेकिन टेस्ट फेल हो गए, तो उस समय लगा कि अगर टेस्ट ही न होते तो मैं क्या करता। एक बार तो सच में घबरा गया था.

अगर codebase उस स्तर का हो, तो रिफैक्टरिंग करने की सोच भी आए, लेकिन वह इतना विशाल होता है कि आखिरकार छोड़ना पड़ता है, और उसके ऊपर कोड और जुड़ता जाता है... शायद वे भी ऐसे ही किसी अंतहीन लूप में फँस गए हों, ऐसा मैं सावधानी से अनुमान लगाता हूँ.
 
xguru 2020-09-21

मैं समझ सकता हूँ कि उस व्यक्ति के लिए यह कितना कठिन रहा होगा,

लेकिन विडंबना यह है कि यह ऐसा लेख है जो यह सोचने पर मजबूर करता है कि "testing वाकई इतनी महत्वपूर्ण होती है," इसलिए मैंने इसका अनुवाद किया।

इस जवाब के मूल प्रश्न पोस्ट पर कुल 578 जवाब आए थे।

Ask HN: What's the largest amount of bad code you have ever seen work?

https://news.ycombinator.com/item?id=18442637

सिर्फ़ 1-level जवाबों को देखना भी मज़ेदार है। ऐसा लगता है कि लोग जहाँ भी हों, सब एक जैसे ही जीते हैं..