अच्छी सॉफ़्टवेयर डेवलपमेंट आदतें

• यह लेख सलाह नहीं है, बल्कि उन डेवलपमेंट आदतों के बारे में है जिन्हें लेखक इस समय अपनाता है
• बुरी आदतों से बचने और अच्छी आदतें बनाने की कोशिश के अनुभवों को संकलित करते हुए, उत्पादकता बढ़ाने और गुणवत्ता बनाए रखने में मददगार 10 आदतों पर चर्चा की गई है

1. छोटे कमिट बनाए रखें

• कमिट को जितना संभव हो उतना छोटा रखना चाहिए। छोटे कमिट से बग आने पर सिर्फ़ किसी एक खास कमिट को revert किया जा सकता है, जिससे जटिल merge conflict से बचा जा सकता है
• इसे नियम बनाया गया है कि "जब सॉफ़्टवेयर compile हो सके, तब कमिट किया जा सके"

2. लगातार refactoring

• Kent Beck की सलाह: "जब आप बदलाव चाहते हैं, तो पहले बदलाव को आसान बनाइए, फिर आसानी से बदलाव कीजिए।"
• कोशिश रहती है कि कम-से-कम आधे कमिट में refactoring शामिल हो। छोटे refactoring बाद में बड़े requirements आने पर बहुत मदद करते हैं
• बड़े refactoring से बचना चाहिए। इसके बजाय 10 मिनट के भीतर होने वाले छोटे-छोटे सुधार लगातार करते रहना बेहतर है

3. कोड deploy करने का महत्व

• कोड खुद में संभावित debt है, और जो कोड deploy नहीं हुआ है वही सबसे बड़ा debt है
• test भरोसा देते हैं, लेकिन वास्तविक deploy ही असली approval का मतलब रखता है
• deploy की frequency बढ़ने पर hosting cost बढ़ सकती है, लेकिन यह पुष्टि कर पाना कि ताज़ा काम वास्तव में चल रहा है, एक महत्वपूर्ण फ़ायदा है

4. framework की functionality को test न करना

• framework की functionality को test नहीं किया जाता। framework पहले से ही काफ़ी verify किए जा चुके होते हैं
• component छोटे रखने पर framework ज़्यादातर काम खुद संभाल लेता है, जिससे test कम करने पड़ते हैं
• बड़े component जटिलता बढ़ाते हैं, और उसके साथ बहुत सारे test की ज़रूरत भी बढ़ती है

5. नया module बनाना

• अगर कोई खास functionality मौजूदा module में फिट नहीं बैठती, तो नया module बनाना बेहतर है
• मौजूदा module में ज़बरदस्ती functionality जोड़ने की बजाय उसे एक स्वतंत्र module के रूप में रखना बेहतर है

6. test-driven development (TDD) का लचीला उपयोग

• अगर API design स्पष्ट न हो, तो पहले test लिखकर "customer" के नज़रिए से सोचा जाता है
• TDD को किसी धार्मिक सिद्धांत की तरह नहीं अपनाया जाता। ज़रूरत होने पर पहले बड़े unit पर काम करके बाद में test लिखे जा सकते हैं
• कोड के छोटे unit को असफल स्थिति में छोड़े बिना भी काम किया जा सकता है, और उत्पादकता घटाने वाले कट्टरपन से बंधना ज़रूरी नहीं है

7. copy-paste सिर्फ़ एक बार स्वीकार्य

• एक बार copy करना ठीक है, लेकिन दूसरी बार से duplication शुरू हो जाता है
• इस बिंदु पर सही abstraction के ज़रिए duplication हटाना चाहिए। parameterization थोड़ा अजीब लगे तब भी, कई implementations को जोड़ने से यह बेहतर है

8. design में बदलाव को स्वीकार करना

• design समय के साथ पुराना पड़ता है। refactoring से इसकी उम्र बढ़ाई जा सकती है, लेकिन अंततः बदलाव अपरिहार्य है
• पुराने design से बहुत ज़्यादा चिपके नहीं रहना चाहिए, बल्कि बदलाव को स्वीकार करना चाहिए
• कोई perfect design नहीं होता, और बदलावों से अच्छी तरह निपटने की क्षमता ही सॉफ़्टवेयर डेवलपमेंट का मूल है

9. technical debt के तीन प्रकार

• technical debt को तीन प्रकारों में बाँटा जा सकता है:
  1. जो मौजूदा काम में बाधा डालता है
  2. जो भविष्य के काम में बाधा डाल सकता है
  3. जो शायद कभी बाधा डाले, शायद नहीं
• पहले प्रकार के debt को न्यूनतम रखना चाहिए, दूसरे प्रकार पर ध्यान देना चाहिए, और तीसरे प्रकार को नज़रअंदाज़ करना चाहिए

10. testability और अच्छे design का संबंध

• अगर किसी चीज़ को test करना मुश्किल है, तो संभव है कि design में समस्या हो
• test design भी सुधार का विषय हो सकता है। उदाहरण के लिए, अगर em.getRepository(User).findOneOrFail({id}) का mock लिखना मुश्किल लगे, तो उसे अलग function में बाँटना या test utility का उपयोग करना बेहतर है
• test न लिखे जाने की वजह अक्सर यह होती है कि उन्हें लिखना मुश्किल है, और यह design की समस्या हो सकती है

[yangeok]

ऐसा लगता है कि DRY से ज़्यादा SRP हासिल होना चाहिए; तभी AI को सौंपने पर भी वह बकवास नहीं करता।

[progdesigner]

मुझे लगता है कि सबसे महत्वपूर्ण बात यह है कि आपने ऐसा कोड और environment बनाया है जो बदलावों के साथ कितनी तेजी से adapt कर सकता है।

और उपयुक्त abstraction के ज़रिए कोड की reusability और scalability बढ़ाई जा सकती है, और AI tools का उपयोग करके development speed को अधिकतम किया जा सकता है।

[pcj9024]

यह वाकई बहुत अच्छा लेख है। इसे जगह-जगह recommend करने का मन करता है।

[tsboard]

बदलाव को अपनाएँ, copy-paste सिर्फ एक बार करें, testing को और बेहतर बनाएँ, commits को और छोटा रखें...!

[aer0700]

अच्छा लेख है।

[puersum]

मुझे लगता है कि इस लेख का मूल संस्करण ज़रूर देखना अच्छा रहेगा.
आमतौर पर भी अगर कोई खबर दिलचस्प लगे तो मैं उसका मूल लेख देख लेता हूँ, लेकिन इस मामले में तो खास तौर पर ऐसा करना अच्छा होगा. पहला बिंदु देखें तो मूल लेख में
Keep commits small enough that you wonder if you're taking this "keep commits small" thing a little too far. ऐसा लिखा है, लेकिन यहाँ उसे संक्षेप में "commit को जितना हो सके छोटा रखना चाहिए" कर दिया गया है..

[ilbanin00]

यह वाकई बहुत अच्छा लेख है।

[joon14]

7वाँ बिंदु वाकई बहुत अच्छा है।

[GN⁺]

Hacker News की राय

• कई implementations से बचने के लिए parameters का उपयोग करना अच्छा है। parameters को बेहतर बनाना, कई implementations को एकीकृत करने से आसान होता है.

  • अगर "अजीब parameters" से बचा नहीं जा सकता, तो code को अलग करना बेहतर है। boolean flags और कई enum parameters से बचना चाहिए.
  • complex function signatures maintenance को कठिन बना देती हैं.

• code copy एक बार तक ठीक है, लेकिन दूसरी बार से duplication से बचना चाहिए। जब पर्याप्त data points हों, तभी अच्छा abstraction बनाना चाहिए.

  • भले ही code शुरुआत में एक जैसा लगे, बदलाव की ज़रूरत पड़ने पर इस बात पर ध्यान देना चाहिए कि क्या उन्हें साथ में बदलना चाहिए.
  • code duplication से बचना लक्ष्य नहीं है; लक्ष्य यह है कि जो code साथ में evolve होना चाहिए, उसे साथ में रखा जाए.

• DRY (खुद को दोहराओ मत) या WET (सब कुछ दो बार लिखो) कोई पूर्ण नियम नहीं हैं। code duplication और consolidation का सही समय समझना ही कठिन समस्या है.

• छोटे commits के विकल्प के रूप में, बड़े commit को revert किए बिना bug fix करने के लिए नया commit जोड़ा जा सकता है.

  • यह स्पष्ट नहीं है कि बड़े refactoring क्यों बुरे हैं.
  • स्वतंत्र structure बनाना, उसे किसी मौजूदा module में ज़बरदस्ती ठूँसने से बेहतर है.
  • API design करते समय, unit tests की जगह design sessions किए जा सकते हैं.

• testability का संबंध अच्छे design से है। जिसे आसानी से test नहीं किया जा सकता, वह इस बात का संकेत हो सकता है कि design बदलने की ज़रूरत है.

  • test code की भी अन्य तरीकों से समीक्षा की जानी चाहिए.

• framework की functionality को test करते समय सावधानी रखनी चाहिए। framework समय के साथ बदल सकता है.

  • dependencies को upgrade करते समय यह सुनिश्चित करना कि सब सुरक्षित है, testing की एक महत्वपूर्ण भूमिका है.

• commit size के बारे में, लक्ष्य ऐसे commits होने चाहिए जिन्हें किसी खास बदलाव को वापस लेना पड़े तो आसानी से revert किया जा सके.

• कंपनियाँ स्थिर codebase चाहती हैं, लेकिन लगातार refactoring की ज़रूरत होती है। यह स्थिरता के साथ टकराव में हो सकता है.