आपने अभी-अभी जो legacy C++ codebase विरासत में पाया है, अब क्या करें?

 (gaultier.github.io)
1 पॉइंट द्वारा GN⁺ 2024-03-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें

अगर आपने एक मौजूदा C++ codebase विरासत में पाया है, तो क्या करना चाहिए?

  • नई नौकरी शुरू करने, टीम बदलने, या अनुभवी सहकर्मी के जाने के बाद, आपको जटिल और अनोखी संरचना वाले बड़े C++ codebase की ज़िम्मेदारी मिल सकती है.
  • बग फिक्स करने और नई features जोड़ने की ज़रूरत होती है, लेकिन codebase को नज़रअंदाज़ करना या हटा देना संभव नहीं होता. यह उस व्यक्ति के लिए महत्वपूर्ण है जो आपका वेतन देता है, इसलिए यह आपके लिए भी महत्वपूर्ण है.

पहला कदम: कोड को लोकल में चलाना

  • कोड और build system में जितने कम बदलाव संभव हों, उतने ही करके उसे लोकल में चलाएँ. अभी बड़े पैमाने पर refactoring न करें.

गैर-ज़रूरी चीज़ें हटाना

  • कंपनी या open source project जिन features का प्रचार और बिक्री करता है, उन्हें देने के लिए जो बिल्कुल आवश्यक नहीं है, उसे हटा दें.

प्रोजेक्ट को 21वीं सदी में लाना

  • CI (continuous integration), linter, fuzzing, automatic formatting आदि जोड़ें.

क्रमिक code improvement

  • कोड में छोटे और क्रमिक बदलाव करें. इसे बार-बार दोहराएँ ताकि application सुरक्षा, developer experience, correctness और performance के लिहाज़ से स्वीकार्य स्थिति में आ जाए.

memory-safe भाषा में आंशिक rewrite पर विचार

  • अगर संभव हो, तो कोड के कुछ हिस्सों को memory-safe भाषा में फिर से लिखने पर विचार करें.

supported platforms को स्पष्ट करना

  • README में आधिकारिक रूप से समर्थित <architecture>-<operating system> जोड़े लिखें. उदाहरण के लिए x86_64-linux या aarch64-darwin.

मशीनों पर build को काम करने लायक बनाना

  • यह सुनिश्चित करें कि सभी supported platforms पर build भरोसेमंद और एकसमान तरीके से हो सके.

मशीनों पर tests पास कराना

  • अगर tests नहीं हैं, तो कोड में बदलाव करने से पहले tests लिखें, उन्हें पास कराएँ, फिर वापस आएँ.

README में application को build और test करने का तरीका लिखना

  • build और test के commands को इतना सरल बनाएँ कि गैर-विशेषज्ञ भी उन्हें आसानी से follow कर सकें.

build और test की गति बढ़ाने के लिए low-hanging fruit ढूँढना

  • build system बदले बिना build और test की गति बढ़ाने के सरल तरीके खोजें.

गैर-ज़रूरी कोड हटाना

  • compiler warnings और linter का उपयोग करके unused code खोजें और हटाएँ.

linter

  • linter rules को लेकर अत्यधिक आसक्त हुए बिना, कुछ बुनियादी नियम जोड़ें और उन्हें development cycle में शामिल करें.

code formatting

  • सही समय पर पूरे codebase पर एक बार में code style लागू करें और configuration को commit करें.

sanitizers

  • sanitizers का उपयोग करके वास्तविक bugs और memory leaks का पता लगाएँ और उन्हें ठीक करें.

CI pipeline जोड़ना

  • जो भी अच्छी चीज़ें सेट की गई हैं (linter, code formatting, tests आदि), उन्हें automate करें, और हर बदलाव पर production environment में binaries बनाएँ.

क्रमिक code improvement

  • security, correctness, performance जैसे ठोस लक्ष्यों पर ध्यान दें, और 'clean code' जैसे व्यक्तिपरक मानकों से दूर रहें.

memory-safe भाषा में rewrite?

  • यह अभी भी चल रहा काम है और इसमें कई सावधानियाँ हैं. इसे तभी करें जब उसके लिए स्पष्ट कारण हो.

निष्कर्ष

  • जटिल legacy C++ codebase से बाहर निकलने के लिए एक ठोस, चरण-दर-चरण योजना प्रस्तुत करता है.

परिशिष्ट: dependency management

  • C++ में dependency management वास्तव में नहीं होता, और अधिकांश लोग system package manager का उपयोग करते हैं. लेकिन यह अच्छा विचार नहीं है.
  • dependency management पर लेखक की राय है कि git submodule और source compilation approach का उपयोग किया जाए.

GN⁺ की राय

  • यह लेख C++ codebase विरासत में पाने वाले शुरुआती software engineers के लिए उपयोगी step-by-step guide देता है.
  • legacy code को संभालना कई developers के लिए एक आम चुनौती है, और यह लेख ऐसी स्थिति में व्यावहारिक सलाह देता है.
  • codebase सुधारने की प्रक्रिया में tests के महत्व पर ज़ोर देना अच्छी software development practices को दर्शाता है.
  • dependency management पर लेखक की राय विवादास्पद हो सकती है, और वास्तविक projects में Conan या vcpkg जैसे आधुनिक package managers का सफलतापूर्वक उपयोग भी किया जाता है.
  • तकनीक अपनाते समय project की प्रकृति और टीम के skill level को ध्यान में रखना चाहिए, और यह लेख ऐसे फैसले लेने के लिए एक अच्छा शुरुआती बिंदु दे सकता है.

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

1 टिप्पणियां

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

  • कुछ Hacker News टिप्पणियों में C++ प्रोजेक्ट विरासत में मिलने पर यह सलाह दी गई है:

    • पुनरुत्पादित किए जा सकने वाले build: Docker जैसे टूल का उपयोग करके build environment को encapsulate करने की सिफारिश की गई है, ताकि tools और dependencies स्पष्ट और reproducible हों.
    • -Wall विकल्प के साथ clean build करना: warnings को ठीक करके code की समस्याओं को सुधारें, और कभी-कभी उन्हें समझने के बाद warning को ignore करना भी संभव है.
    • Valgrind जैसे टूल से शुरुआती testing करके read/write errors की जांच करने का सुझाव दिया गया है.
    • refactoring को शुरुआत में सीमित, स्थानीय दायरे में रखें, और पूरी संरचना समझे बिना बड़े पैमाने के redesign से बचें.

  • दूसरी टिप्पणियों में यह तर्क दिया गया है कि पहले CI, linting, auto-formatting आदि लागू करना महत्वपूर्ण है:

    • code से अनावश्यक हिस्से हटाने से पहले यह समझें कि program कैसे काम करता है, और static analysis tools के जरिए यह insight मिल सकती है कि program में कहाँ काम की ज़रूरत है.

  • एक उपयोगकर्ता ने नई टीम या कंपनी में जाने का सुझाव दिया.

  • कुछ टिप्पणियों में code understanding tools और तकनीकों के महत्व का भी ज़िक्र है:

    • codebase को index करने वाले टूल का उपयोग, UML sequence diagram बनाना, और ऐसे notes लिखना जैसे आप किसी और को सिखा रहे हों, महत्वपूर्ण बताया गया है.

  • एक टिप्पणी में project को modernize करने के लिए CI, linters, fuzzing, auto-formatting आदि जोड़ने पर सलाह दी गई है:

    • CI के जरिए यह सुनिश्चित करें कि build दूसरी जगहों पर भी हो सके, और compiler warnings व static analyzers का उपयोग करके code की समस्याओं की पहचान करें.
    • code के महत्वपूर्ण हिस्सों के लिए unit tests सेट करें ताकि यह पुष्टि हो सके कि code सही काम कर रहा है.
    • auto-formatting की प्राथमिकता कम है, और मूल maintainer की शैली का पालन करने की सिफारिश की गई है.

  • एक अन्य टिप्पणी में memory-safe language में कुछ हिस्से दोबारा लिखने की सलाह की आलोचना की गई है:

    • अतिरिक्त काम के लिए ज़रूरी resources जुटाना कठिन हो सकता है, C++ के अलावा अतिरिक्त language का ज्ञान चाहिए होगा, और testing अधिक जटिल हो सकती है.

  • कुछ टिप्पणियों में यह दावा भी किया गया है कि git submodules और source compilation का तरीका package manager से बेहतर है:

    • यह इंगित किया गया कि vcpkg जैसे टूल आज़माने से पहले ऐसी आलोचना करना अजीब है.

ये टिप्पणियाँ C++ प्रोजेक्ट विरासत में मिलने पर अलग-अलग approaches और सलाह देती हैं, और project management, code understanding, refactoring, तथा modernization strategy पर विभिन्न दृष्टिकोण दिखाती हैं.