आसानी से हटाए जा सकने वाले कोड लिखना, बढ़ाना मुश्किल कोड (2016)

ऐसा कोड लिखना जिसे हटाना आसान हो

• कोड की हर लाइन अपने साथ maintenance cost लाती है। कोड reuse बदलाव को कठिन बना देता है।
• जितने अधिक API consumers होंगे, बदलाव के समय उतना अधिक कोड फिर से लिखना पड़ेगा।
• कोड की dependencies को manage करना बड़े सिस्टमों में एक महत्वपूर्ण समस्या है।

चरण 0: कोड न लिखना

• कोड लाइनों की संख्या अपने आप में बहुत अधिक जानकारी नहीं देती।
• जो कोड लिखा ही नहीं गया, उसे हटाना सबसे आसान होता है।

चरण 1: कोड copy-paste करना

• reusable code को बाद में examples के ज़रिए और आसानी से लिखा जा सकता है।
• कोड copy-paste करना dependencies से बचने और flexibility पाने का एक तरीका है।

चरण 2: कोड copy-paste न करना

• अगर कोड को पर्याप्त बार copy-paste किया जा चुका है, तो अब उसे function में extract करने का समय है।
• util directory बनाकर अलग-अलग utilities को दूसरी files में रखना अच्छा है।

चरण 3: और अधिक boilerplate लिखना

• boilerplate, code copy-paste जैसा ही है, लेकिन इसमें अलग-अलग जगहों पर कोड बदला जाता है।
• boilerplate dependencies को कम करता है और flexibility देता है।

चरण 4: boilerplate न लिखना

• अगर boilerplate बहुत ज़्यादा हो जाए, तो उसे ऐसी library से wrap करना चाहिए जो policy, workflow और state के बारे में opinion रखती हो।
• requests और urllib3 का संबंध इसका अच्छा उदाहरण है।

चरण 5: कोड के बड़े टुकड़े लिखना

• business logic की पहचान अंतहीन exception cases और तेज़ लेकिन अस्त-व्यस्त hacks से होती है।
• एक बड़ी गलती को हटाना, कई छोटी गलतियों को हटाने से आसान होता है।

चरण 6: कोड को टुकड़ों में बाँटना

• कोड के बड़े टुकड़ों की maintenance cost अधिक होती है।
• कोड की responsibilities को अलग करना चाहिए, और बदलाव की संभावना को ध्यान में रखकर modules डिज़ाइन करने चाहिए।

चरण 7: लगातार कोड लिखते रहना

• नए ideas को experiment करने के लिए, मौजूदा कोड से स्वतंत्र नया कोड लिखा जा सकना चाहिए।
• feature flags बाद में अपना मन बदलने का एक तरीका हैं।

GN⁺ का सार

• यह लेख समझाता है कि कोड लिखते समय ऐसा कोड कैसे बनाया जाए जिसे हटाना आसान हो।
• कोड की dependencies कम करना, flexibility बढ़ाना और maintenance cost घटाना ही मुख्य बात है।
• मिलती-जुलती भूमिका वाले projects में requests और urllib3 शामिल हैं।
• यह लेख software developers को code management और maintenance की अहमियत याद दिलाता है।

[GN⁺]

Hacker News राय

• "Simple is robust" वाली बात पसंद आई। इसका मतलब है कि सिस्टम जितना कम जटिल होगा, उसमें बदलाव करना उतना ही आसान होगा। भविष्य की योजना scalable code की बजाय सहज और intuitive code के साथ बनानी चाहिए। उदाहरण के लिए, abstraction तभी करें जब स्थिति वास्तव में उसकी मांग करे, साधारण duplication को स्वीकार करें, शुरुआत में monolith का उपयोग करें, और horizontal scaling से पहले vertical scaling को प्राथमिकता दें। कई 0-1 systems बनाते समय ये समानताएँ दिखीं।

• हैरानी है कि testing या observability का कोई ज़िक्र नहीं है। tests को maintain करने की लागत होती है, लेकिन वे code हटाते समय समस्या आने के जोखिम को कम करते हैं। जब किसी service को external callers के लिए expose किया जाता है, तो कुछ calls को deprecated के रूप में चिह्नित करना और यह देखने का एक मज़बूत तरीका होना चाहिए कि क्या वे अब भी call हो रही हैं। हाल ही में GraphQL resolvers को अर्ध-स्वचालित तरीके से हटाया गया, और usage metrics के ज़रिए यह पता लगाया गया कि कौन से resolvers हटाए नहीं जा सकते। GraphQL में deprecation annotation है, लेकिन service में उसे विशेष रूप से handle नहीं किया गया था। observability जोड़कर deprecated functions के call होने पर flag सेट किया जा सकता है, और production में पर्याप्त लंबे समय तक चलाने के बाद externally exposed code को सुरक्षित रूप से हटाया जा सकता है।

• मैं "deletion के लिए design" का समर्थक बन गया हूँ। पहले लगता था कि हर स्थिति की योजना बनाई जा सकती है और हर ज़रूरत पूरी करने वाली कोई रचना बनाई जा सकती है, लेकिन भविष्य की ज़रूरतों का अनुमान लगाना कठिन है। एक दिन ऐसा आएगा जब मैंने जो बनाया है वह किसी के लिए बेकार हो जाएगा, और उसका उसे हटाना उचित होगा। इसलिए चीज़ों को आसानी से हटाया जा सके, इस पर मेहनत करनी चाहिए। इससे अक्सर coupling कम होती है, लेकिन यह उस युवा डेवलपर वाली सोच से अलग है जो हर चीज़ को meta-configurable framework में बाँटना चाहता है। कभी-कभी, जब तर्क की दृष्टि से समझना आसान हो, तो tight coupling बेहतर होती है।

• अगर code को आसानी से delete करने लायक लिखना है, तो dependencies से बचने के लिए duplication करें, manage करने के लिए नहीं। code की layers बाँटें, और ऐसे हिस्सों पर simple APIs बनाएँ जिन्हें implement करना आसान हो लेकिन इस्तेमाल करना थोड़ा असुविधाजनक हो। code को अलग करें, और जो हिस्से लिखना कठिन हैं तथा जिनमें बदलाव की संभावना अधिक है, उन्हें बाकी code से एक-दूसरे से भी अलग रखें। हर विकल्प को hardcode न करें; कुछ चीज़ें runtime पर बदली जा सकें, ऐसा होना चाहिए। मेरे अनुभव में, जिसे हटाना आसान होता है, वह layered और modular भी होता है, इसलिए उसे extend करना भी आसान होता है।

• मैं computational physics के छात्रों से कहता आया हूँ कि सबसे अच्छी computation वही है जिसकी आपको चिंता ही न करनी पड़े।

• व्यक्तिगत रूप से, मैं code को business logic और actual implementation में बाँटता हूँ। business logic अपनी प्रकृति के कारण duplicate हो सकती है, लेकिन बहुत अधिक technical details duplicate नहीं होनी चाहिए। जब तक business logic को सीधे handle नहीं किया जाता और उसे application-independent रखा जाता है, तब तक business logic जितनी चाहे उतनी बिखरी हुई हो सकती है। अगर समस्या आती है और चीज़ें सही नहीं चलतीं, तो पूरी implementation को delete करने का विकल्प होता है, और फिर उसे ठीक किया जा सकता है, बिना इस मजबूरी के कि असली specification implementation में ही ढूँढनी पड़े।

• पहले पैराग्राफ की साफ़ गलती: code reuse की समस्या यह बताई गई है कि वह बाद में राय बदलने में बाधा बनती है। यह आम तौर पर गलत दावा है। अगर आपने राय बदली और code दस जगह copy-paste किया हुआ है, तो दसों जगह बदलना पड़ेगा। दूसरी ओर, अगर code किसी function में है, तो केवल एक बार बदलना होगा। अगर दस calls में से एक को वैसा नहीं बदलना चाहिए, तो तब भी उसे copy-paste किया जा सकता है, या function को और general बनाया जा सकता है। जैसे सड़क पार करते समय इधर-उधर न देखना गलत है, वैसे ही copy-paste भी लगभग हमेशा बुरा विचार है।

• एक मज़बूत संबंध यह है कि खराब code लंबे समय तक इसलिए बना रहता है क्योंकि उसे हटाना कठिन होता है।

• सोच रहा हूँ कि क्या इसका मतलब यह है कि software को जितना संभव हो default state में इस्तेमाल करना चाहिए और customization को बहुत गहराई तक नहीं ले जाना चाहिए।