- 2007, 2000 लाइनों का कोड

 (folklore.org)
1 पॉइंट द्वारा GN⁺ 2024-03-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

  • 1982 की शुरुआत में, Lisa software team अगले 6 महीनों के भीतर software जारी करने के लिए अंतिम चरण के काम पर ध्यान केंद्रित कर रही थी।

  • कुछ managers ने सोचा कि हर engineer द्वारा हर हफ्ते लिखे गए code की मात्रा को track करना एक अच्छा विचार है, और उन्होंने एक form बनाया जिसे हर शुक्रवार जमा करना होता था। इस form में उस हफ्ते लिखी गई code lines की संख्या भरने के लिए एक field शामिल था।

  • Quickdraw के लेखक और प्रमुख user interface designer Bill Atkinson का मानना था कि code lines की संख्या software productivity को मापने का एक मूर्खतापूर्ण तरीका है, क्योंकि यह केवल गंदा, फुलाया हुआ और error-भरा code लिखने के लिए प्रोत्साहित करता है।

  • Atkinson हाल ही में Quickdraw की region calculation machine को optimize करने पर काम कर रहे थे, और उन्होंने एक अधिक सरल और सामान्य algorithm का उपयोग करके region engine को पूरी तरह फिर से लिखा, जिससे कुछ tweaks के बाद region operations लगभग 6 गुना तेज हो गए।

  • इस rewrite के परिणामस्वरूप साथ ही लगभग 2000 lines of code की बचत हुई।

  • Optimization के अंतिम चरण में जब पहली बार management form भरने का समय आया, तो code lines वाले हिस्से पर पहुँचकर उन्होंने थोड़ी देर सोचा और वहाँ संख्या -2000 लिख दी।

  • Managers ने इस पर कैसी प्रतिक्रिया दी, यह निश्चित नहीं है, लेकिन कुछ और हफ्तों बाद उन्होंने Atkinson से form भरने को कहना बंद कर दिया, और उन्होंने भी खुशी-खुशी इसका पालन किया।

GN⁺ की राय

  • यह लेख एक महत्वपूर्ण सीख देता है कि software development में code की मात्रा वास्तविक productivity को नहीं दर्शाती। code lines की संख्या के आधार पर performance मापना न केवल अप्रभावी है, बल्कि कभी-कभी उल्टा असर भी डाल सकता है।
  • Bill Atkinson का उदाहरण software optimization के महत्व को रेखांकित करता है। कम code के साथ तेज performance हासिल करना software engineering के मूल सिद्धांतों में से एक है।
  • यह कहानी यह समझने में मदद करती है कि आधुनिक development practices, खासकर agile methodology और continuous integration/deployment (CI/CD) जैसे approaches, क्यों महत्वपूर्ण हैं। ये methodologies code की मात्रा से अधिक quality, maintainability और user experience को महत्व देती हैं।
  • उद्योग में code quality को मापने और सुधारने के लिए विभिन्न tools और metrics का उपयोग किया जाता है। उदाहरण के लिए, static code analysis tools, code review process और test coverage tracking जैसी चीजें शामिल हैं।
  • यह लेख developers को याद दिलाता है कि code की मात्रा से अधिक quality पर ध्यान देना, अनावश्यक complexity से बचना और performance को optimize करना कितना महत्वपूर्ण है।

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

1 टिप्पणियां

 
GN⁺ 2024-03-25
Hacker News राय

  • Microsoft और IBM के बीच code line count को लेकर टकराव

    • PBS TV series "Accidental Empires" में एक दृश्य है जहाँ Steve Ballmer, OS/2 के संयुक्त विकास के समय के अपने अनुभव बताते हैं। उनके अनुसार Microsoft काम को एक छोटी कंपनी के नज़रिए से संभालता था, जबकि IBM अंदरूनी तौर पर code line count (हज़ार लाइनों की इकाई, KLoC) को programmer productivity के पैमाने के रूप में देखने पर केंद्रित था। Ballmer ने आलोचना की कि IBM को code की quality से ज़्यादा केवल quantity की परवाह थी.

  • पिछली चर्चाओं के लिंक

    • code line count को productivity metric के रूप में इस्तेमाल करने पर बहस बार-बार सामने आती है। 2010 से 2022 तक की विभिन्न चर्चाओं को दिखाने वाले लिंक दिए गए हैं.

  • code line count को productivity metric बनाना बेहद मूर्खतापूर्ण है

    • एक टिप्पणी में बताया गया है कि 20 साल पुराने bug को एक लाइन के code से ठीक किया गया, और 3 साल पुराने bug को 'order by' से सुलझाया गया। इससे यह सवाल उठता है कि एक लाइन के code के प्रभाव को कैसे मापा जा सकता है। यह अनुभव भी साझा किया गया कि खराब programmer ज़्यादा code लिखते हैं, और Microsoft के एक developer ने IBM के 33,000 characters के code को 220 characters में फिर से लिखा। इसके कारण Microsoft के काम को 'negative' माना जाने जैसी स्थिति पैदा हुई.

  • कभी-कभी साधारण सवाल सबसे बड़ा असर डालते हैं

    • किसी feature को implement करने से पहले एक सीधा सवाल ("X को कैसे handle करेंगे?") यह फैसला दिला सकता है कि वह feature बनाया ही न जाए। इससे उसे बनाने की कोशिश में लगने वाली पूरी लागत बच सकती है। ऐसे योगदान को संख्याओं में नहीं मापा जा सकता, और कभी-कभी इससे विरोध भी पैदा हो सकता है, फिर भी ऐसा करने वालों को सम्मान दिया गया है.

  • करियर की शुरुआत में code optimization का अनुभव

    • एक व्यक्ति ने 10,000 से अधिक lines वाले C program को 500 lines से कम में optimize करने का अनुभव साझा किया। उसने यह मानकर code देखा कि शायद पिछला developer function का उपयोग करना या SQL query में variable data देना नहीं जानता था, और पाया कि वही SQL statement बार-बार inline लिखी गई थी। बाद में SQL calls को function calls में बदला गया, और बदले हुए bind values को array से लेकर loop के अंदर function call करने के तरीके से duplicate code को हटाया गया.

  • project की शुरुआत में स्पष्ट दिशा का अभाव

    • project शुरू करते समय हमेशा सटीक दिशा पता नहीं होती। project में गहराई से काम करते-करते समस्या और मनचाहे उत्तर की समझ बेहतर होती है, और नतीजतन बड़े हिस्सों को हटाकर उन्हें छोटे और बेहतर हिस्सों से बदला जा सकता है। ऐसे हालात में वे developers, जिन्हें सब कुछ 64KB ROM में समेटना पड़ता था, code को छोटा बनाने के लिए कड़े दबाव में रहते थे.

  • code हटाने को metric बनाने पर एक thought experiment

    • यह thought experiment पेश किया गया कि अगर कोई manager यह लेख पढ़कर सरल तरीके से हटाई गई code lines की संख्या को metric बना दे, तो हालात बेहतर होंगे या बदतर.

  • Bill Atkinson का Atkinson Dither

    • Bill Atkinson और उनकी Atkinson Dither technique के बारे में एक लिंक दिया गया है.

  • code lines के बारे में सोचने का नज़रिया

    • code लिखते समय 'added lines - removed lines' का उपयोग करने पर सवाल उठाया गया। जैसे एक 10km की दौड़, जो उसी जगह से शुरू होकर उसी जगह खत्म होती है, उसे 0km की दौड़ नहीं कहा जाता, वैसे ही code lines के मामले में भी यही तर्क लागू होता है.

  • कर्मचारी के रूप में भूमिका

    • यह सीख साझा की गई कि चाहे आप Einstein जितने बुद्धिमान हों, फिर भी आप एक employee हैं, और employee के रूप में कुछ ज़िम्मेदारियाँ निभानी ही होती हैं.