- तकनीकी taste तकनीकी skill से अलग अवधारणा है; बेहतरीन क्षमता होने पर भी taste खराब हो सकती है, और क्षमता कम होने पर भी taste अच्छी हो सकती है
- सॉफ्टवेयर इंजीनियर की taste का मतलब है प्रोजेक्ट के लिए उपयुक्त engineering values चुनने की क्षमता
- यह इस बात में दिखती है कि कौन-सा code अच्छा/खराब दिखता है, कौन-सा design decision संतोषजनक लगता है, और किस समस्या पर कोई व्यक्ति अटका रहता है; यह सीधे उन engineering values को दर्शाता है जिन्हें वह सबसे अधिक महत्व देता है
- सॉफ्टवेयर इंजीनियरिंग के सभी निर्णय लगातार trade-off का हिस्सा होते हैं; अपरिपक्व इंजीनियर किसी एक approach को पूर्ण सत्य मान लेते हैं, जबकि परिपक्व इंजीनियर context के अनुसार values को लचीले ढंग से संतुलित करते हैं
- अच्छी taste वह क्षमता है जिससे किसी खास प्रोजेक्ट के लिए values की प्राथमिकता तय की जा सके, जबकि खराब taste अक्सर "best practice" जैसे पूर्ण मानकों से चिपके रहने वाली कठोरता में दिखती है
- taste विविध प्रोजेक्ट अनुभवों और खुले विचार से बनती है, और अंततः अच्छी taste है या नहीं, यह प्रोजेक्ट की सफलता से सामने आता है
तकनीकी taste और skill का अंतर
- तकनीकी taste हमेशा बेहतरीन skill के साथ मेल नहीं खाती
- जैसे कोई भी व्यक्ति खाना बनाने की skill से अलग अच्छे और खराब भोजन में फर्क कर सकता है, वैसे ही सॉफ्टवेयर में भी क्षमता से पहले taste बन जाती है
- कौन-सा code "अच्छा दिखता है" या "कमज़ोर लगता है", इससे इंजीनियर की taste झलकती है
- कौन-से design decision से संतोष मिलता है, और किन समस्याओं पर अधिक ध्यान जाता है, यह सब taste का हिस्सा है
- तकनीकी क्षमता अभ्यास और सीखने से बढ़ सकती है, लेकिन taste उससे कहीं अधिक अस्पष्ट और intuitive तरीके से विकसित होती है
-
engineering taste के संकेत
- "यह code अच्छा/खराब दिखता है" जैसा महसूस होना
- कुछ design decisions पर गहरा संतोष या पूरी उदासीनता
- वे सॉफ्टवेयर समस्याएँ जो दफ्तर के बाद भी दिमाग में बनी रहती हैं, और वे जो नहीं रहतीं
- taste को मौजूदा प्रोजेक्ट के अनुकूल engineering values अपनाने की क्षमता के रूप में देखा जा सकता है
skill और taste का विभाजन
- यह सवाल उठता है कि क्या "अच्छा दिखने वाला code" वास्तव में बेहतर code होना ही चाहिए
- उदाहरण: जो लोग
map/filter पसंद करते हैं, वे code readability और pure functions को महत्व दे सकते हैं; जबकि for loop पसंद करने वाले performance और सरल extensibility को महत्व दे सकते हैं
- यह सही या गलत का प्रश्न नहीं, बल्कि प्राथमिक values के अंतर का मामला है
- भाषा और context के अनुसार हर विकल्प के अपने फायदे और नुकसान होते हैं, इसलिए कोई भी चुनाव हर बार बेहतर नहीं होता
- हर इंजीनियर की महत्वपूर्ण values अलग होती हैं, और उसी के अनुसार उसकी पसंद बदलती है
engineering taste क्या है
- सॉफ्टवेयर इंजीनियरिंग के लगभग सभी निर्णय एक-दूसरे से टकराती values के बीच संतुलन (trade-off) होते हैं
- अपरिपक्व इंजीनियर अपनी पसंद पर ज़रूरत से ज़्यादा अड़े रहते हैं
- परिपक्व इंजीनियर अलग-अलग दृष्टिकोणों के फायदे समझते हैं और मौजूदा परिस्थिति के अनुरूप चुनाव को महत्व देते हैं
- अहम बात यह नहीं कि X (तकनीक) और Y (तकनीक) में कौन बेहतर है, बल्कि यह कि मौजूदा प्रोजेक्ट में X के फायदे Y से अधिक ज़रूरी हैं या नहीं
-
engineering values के उदाहरण
- Resiliency: क्या सिस्टम failure या network समस्याओं के दौरान भी ठीक से काम करता है
- Speed: क्या performance सैद्धांतिक सीमा के करीब है, या उसमें अनावश्यक काम बहुत अधिक है
- Readability: क्या नया इंजीनियर इसे जल्दी समझकर काम शुरू कर सकता है, क्या functions छोटे और स्पष्ट हैं
- Correctness: क्या गलत state को model किया जा रहा है, क्या tests, types,
assert आदि पर्याप्त हैं, यहाँ तक कि क्या formal verification लागू है
- Flexibility: क्या सिस्टम का विस्तार आसान है, क्या बदलाव सरलता से लागू किए जा सकते हैं
- Portability: क्या सिस्टम किसी खास environment पर निर्भर है, क्या deployment environment बदलना आसान है
- Scalability: 10x, 100x traffic बढ़ने पर क्या सिस्टम का विस्तार या auto-scaling संभव है, bottleneck कहाँ है
- Development speed: सिस्टम का विस्तार कितनी तेजी से किया जा सकता है, क्या अधिकतर इंजीनियर उस पर काम कर सकते हैं
- इसके अलावा elegance, modern-ness, open source का उपयोग, maintenance cost जैसी कई values भी होती हैं
- हर इंजीनियर हर value को समान महत्व नहीं देता
- व्यक्ति किन values को सबसे ऊपर रखता है, इसी से उसकी language, framework और design pattern की पसंद बदलती है
खराब taste की विशेषताएँ
- खराब taste तब दिखती है जब किसी व्यक्ति की पसंदीदा values मौजूदा प्रोजेक्ट के लिए उपयुक्त नहीं होतीं
- समस्या तब होती है जब कोई खास technology या methodology के फायदों को हर प्रोजेक्ट पर एक जैसा थोप दिया जाता है
- जो दावे हमेशा सिर्फ "best practice" पर टिके हों, उनमें अक्सर स्थिति-विशेष के अनुसार निर्णय लेने की कमी होती है
- अलचीला इंजीनियर किसी खास प्रोजेक्ट में फिट बैठ सकता है, लेकिन environment या काम बदलते ही गंभीर समस्याएँ पैदा कर सकता है
अच्छी taste की विशेषताएँ
- अच्छी taste वह क्षमता है जिसमें समस्या की स्थिति के अनुसार सही engineering values चुनी जाएँ
- यह सिर्फ तकनीकी skill से अलग है, और इसका परीक्षण केवल जटिल वास्तविक प्रोजेक्ट context में ही संभव है
- यदि किसी प्रोजेक्ट में आपके सहमत design decisions अपनाए गए हों और वह प्रोजेक्ट अच्छा चले, तो उससे आपकी taste की उपयुक्तता का अंदाज़ा लगाया जा सकता है
- विविध प्रोजेक्ट अनुभव, और सही समय पर नई values के प्रति खुला रवैया, सीखने के महत्वपूर्ण तत्व हैं
- लचीलापन बनाए रखना, और किसी खास technology या method को लेकर स्थिर धारणाओं से बचना, अच्छी taste विकसित करने में मदद करता है
निष्कर्ष
- अच्छी taste skill जितनी ही महत्वपूर्ण है, और विकास की प्रक्रिया में विविधता, लचीलापन, और आत्मचिंतन के जरिए विकसित की जा सकती है
- कुछ लोग अनुभव से भी बढ़कर असाधारण taste दिखाते हैं (जैसे programming या अन्य क्षेत्रों के प्रतिभाशाली लोग)
अतिरिक्त चर्चा
- Hacker News की टिप्पणियों में "taste" के अस्तित्व पर ही संदेह जताने वाली राय भी थीं
- कुछ लोगों ने कहा कि हर समस्या का सिर्फ एक सही समाधान होता है, लेकिन लेखक ने इसका विरोध करते हुए कहा कि वास्तविक दुनिया में कई समाधान संभव होते हैं, और अंततः व्यक्तिगत values और context ही चुनाव तय करते हैं
- एक अन्य राय यह भी थी कि ग्राहक और business context भी taste का हिस्सा हैं
7 टिप्पणियां
इसे सिर्फ खराब taste कहकर टालना मुश्किल है; यह टीम और प्रोजेक्ट, दोनों के लिए ज़हरीली हो सकने वाली एक बुरी प्रवृत्ति लगती है.
Hacker News राय
मेरा अनुभव है कि अपरिपक्व इंजीनियर अपनी पसंद को लेकर बहुत ज़्यादा अड़े रहते हैं, और ऐसी अपरिपक्वता अनुभवी इंजीनियरों में भी हो सकती है। पहले जब मैं दोस्तों के कंप्यूटर असाइनमेंट के कोड में मदद करता था, तो सिर्फ़ इसलिए पूरा कोड फिर से लिख देने का मन होता था क्योंकि मुझे वह पसंद नहीं था। लेकिन अंत में समझ आया कि ऐसा करने में बहुत समय लगेगा और दोस्त अपने ही परिणाम को समझ नहीं पाएँगे। इसलिए मैंने उनके अप्रोच में बस थोड़े-बहुत सुधार करके मदद की, और वे उससे ज़्यादा संतुष्ट थे। इस अनुभव की वजह से मुझे अलग-अलग नज़रिए समझ में आए और मेरा अपना कोड भी बेहतर हुआ। उल्टा मुझे लगा कि मुझे अपने दोस्तों का आभारी होना चाहिए। आज भी मेरे लिए पूर्वधारणाएँ छोड़ना आसान नहीं है, लेकिन मैं जहाँ तक संभव हो सामने वाले के नज़रिए को गंभीरता से समझने की कोशिश करता हूँ, और कभी-कभी यह मानने की भी कि उनका तरीका बेहतर हो सकता है। सिद्धांत काफ़ी हद तक व्यक्तिपरक होते हैं, इसलिए हमेशा सिर्फ़ सिद्धांतों पर टिके रहना अक्सर बिना गंभीरता से सोचे एक आलसी रवैया होता है
अगर कोई जूनियर इंजीनियर कुछ अक्षम तरीके से कर रहा हो, तब भी मैं कभी यह नहीं कहता कि वह कम optimized तरीका इस्तेमाल कर रहा है। उसकी जगह मैं हमेशा पूछता हूँ कि उसने ऐसा क्यों किया। हर बातचीत के अंत तक हम दोनों में से कोई न कोई कुछ सीखता है। या तो मुझे कोई नया तरीका या उनका कारण समझ में आता है, या फिर उन्हें पता चलता है कि लंबी अवधि में वह तरीका क्यों काम नहीं करेगा। किसी भी हालत में, ऐसी बातचीत कभी टकराव में खत्म नहीं होती
मुझे लगता है कि "अच्छी पसंद" बेहतरीन API और अच्छे कोड का अनुभव करने से बनती है। अच्छा कोड देखते ही पहचाना जा सकता है, और समय के साथ मुझे भी वैसा लिख पाना चाहिए। लेकिन इस क्षेत्र में नए आने पर अच्छी coding taste विकसित करना कठिन होता है, और अनुभव होने से भी यह अपने-आप नहीं आता, इसलिए अच्छी पसंद को खोजने, पहचानने और उसकी नकल करने की लगातार कोशिश ज़रूरी है
पूर्वाग्रह, पक्षपात और जड़ सोच से बाहर निकलने का समाधान शिक्षा और अपनी व्यक्तिगत दृष्टि से बाहर के विविध अनुभव जुटाना है। दूसरे लोगों की नज़र से दुनिया को समझने की सक्रिय कोशिश करनी चाहिए; तभी इंसान और प्रोफेशनल, दोनों रूपों में विकास होता है और दृष्टि व्यापक होती है। मेरी तरह जो इंजीनियर कई क्षेत्रों में रुचि रखते हैं, उनके लिए सिर्फ़ यह जान लेना भी कि दूसरे समाधान या दूसरे नज़रिए मौजूद हैं, समस्या हल करने का तरीका बदल देता है और पहली सहज प्रतिक्रिया से बेहतर समाधान तक ले जाता है
यही वजह है कि कई तरह की programming languages के साथ प्रयोग करना अच्छा होता है। नई भाषाओं को अपनाते हुए, जो हमारी अब तक की सोच को लगातार चुनौती देती हैं, बार-बार "आहा" वाले क्षण आते हैं। शुरुआत में कुछ अटपटा या ग़लत लग सकता है, लेकिन जब तक उसके कारण और तरीके को पूरी तरह न समझ लें, तब तक यह मानकर चलने की ज़रूरत होती है कि शायद उसके पीछे कोई वजह है
बढ़िया राय है। यही सोच मैं उन टीम सदस्यों पर लागू करता हूँ जिन्हें मैं खुद hire करता हूँ या जिनके साथ काम करता हूँ। अगर लक्ष्य या परिणाम हासिल हो रहा है, तो ज़रूरी नहीं कि प्रक्रिया और बारीकियाँ बिल्कुल मेरे तरीके से ही हों। अलग-अलग तरीके हो सकते हैं, यह मानना चाहिए
फैशन में "अच्छी पसंद" शायद किसी एक कपड़े में नहीं, बल्कि ऐसे कपड़ों को मिलाकर एक ताक़तवर और सामंजस्यपूर्ण एहसास बनाने में होती है जो अपने-आप में शायद बहुत अर्थपूर्ण न लगें। मुझे उम्मीद थी कि यह लेख उसी दिशा में जाएगा। मैं यह और जानना चाहता हूँ कि software engineer जिन चीज़ों को पसंद के आधार पर तय करते हैं, उनमें वास्तव में कौन-सी चीज़ें सिर्फ़ तकनीकी trade-off नहीं बल्कि सचमुच taste के दायरे में आती हैं। वैसे, यह लेख खुद मुझे खराब taste का एक उदाहरण लगता है। सामग्री के स्तर पर हर हिस्सा ठीक-ठाक लिखा है, लेकिन पूरा मिलकर कोई समग्र "look" नहीं बनाता, इसलिए लेख कुछ बिखरा हुआ लगता है। यह लेखक पर हमला नहीं है; मुझे विषय शानदार लगता है, इसलिए और बेहतर करने की इच्छा से यह बात कह रहा हूँ
मैं इस बात से सहमत नहीं हूँ कि कोई कपड़ा अपने-आप में अर्थहीन होता है। कपड़ों का संयोजन होने से पहले भी उनका सांस्कृतिक, ऐतिहासिक और प्रतीकात्मक अर्थ होता है। फैशन सिर्फ़ संयोजन से कहीं ज़्यादा है। और फैशन में भी उत्पादन, पहनना, matching आदि जैसे कई trade-off होते हैं
जिस बात को लेकर तुम उत्सुक हो—"हम सुंदरता और elegance को कैसे पहचानते हैं"—वह प्राचीन काल से दार्शनिकों का विषय रही है, और एक ही लेख में उसका निष्कर्ष निकालना बहुत विशाल काम है। आर्किटेक्चर के क्षेत्र में Christopher Alexander ने इसे गहराई से खोजा, और उनके विचारों का software architecture पर भी बड़ा प्रभाव पड़ा। Alexander का दावा था कि वस्तुनिष्ठ सुंदरता जैसी चीज़ होती है। उनका OOPSLA keynote या Roy Fielding की PhD dissertation देखने लायक हैं। इस लेख में जिन "values" का ज़िक्र है, उन्हें Fielding की thesis में "architectural properties" के रूप में ज़्यादा व्यवस्थित ढंग से रखा गया है
मज़ेदार बात यह है कि मुझे यह लेख विषय को गहराई और व्यवस्थित तरीके से पेश करने वाला, बहुत दुर्लभ और उम्दा लेखन का उदाहरण लगता है
मैं यह पूछना चाहता हूँ कि आख़िर किस बिंदु पर किसी engineer के लिए कोई चुनाव सच में "taste" का मामला बनता है, और वह सिर्फ़ तकनीकी trade-off से अलग कैसे पहचाना जाए। मेरी नज़र में बहुत-से फैसलों को हम इस तरह टाल देते हैं कि "यह तकनीकी trade-off है लेकिन इसे निर्णायक रूप से साबित नहीं किया जा सकता, या फ़र्क इतना मामूली है कि व्यावहारिक तौर पर मायने नहीं रखता"। यानी जहाँ बहस साफ़ न बने, वहाँ उसे taste कहकर छोड़ दिया जाता है
ज़्यादातर developers में आम तौर पर fashion sense की कमी होती है, इसलिए वे अच्छे taste जैसी चीज़ को कुल मिलाकर ठीक से समझते भी नहीं। और tech दुनिया की अधिकतर चीज़ें non-tech लोगों को बिल्कुल भी stylish या cool नहीं लगतीं। programming languages cool नहीं हैं। developer दुनिया में शुरुआती बिंदु ही "cool नहीं" से शुरू होता है और वहाँ से और नीचे जाता है। उदाहरण के लिए Rust, C++ वगैरह "cool नहीं" श्रेणी में आते हैं, और अनजानी functional languages या Bash, Linux जैसी चीज़ें "बिल्कुल भी cool नहीं" वाली श्रेणी में पड़ती हैं
अच्छी पसंद वह है जिसमें ऐसा बेहद सरल लेकिन शक्तिशाली कोड लिखा जाए जिसे देखकर लगे कि यह तो कोई भी लिख सकता था
एक और उदाहरण साझा करता हूँ। जब मैं 1972 Dodge Challenger को खोलकर फिर जोड़ रहा था, तो मैं बार-बार हैरान हुआ कि यह कार कितनी सरल, सीधी और सस्ती होते हुए भी कितनी शानदार ढंग से बनाई गई थी। उदाहरण के लिए, instrument cluster को पूरी कार के voltage (10~18V) से अलग 5V चाहिए, और इसके लिए एक तरह का buzzer (electromagnet का इस्तेमाल करके) लगाया गया है जो 5V से ऊपर होने पर circuit तोड़ता है और नीचे होने पर उसे बंद करता है, जिससे बहुत तेज़ on/off के जरिए औसतन 5V बनता है। ज़्यादातर लोग इसे electronic voltage regulator से बदल देते हैं, लेकिन फिर gauges काम नहीं करते। असल में gauges mechanical हैं, इसलिए अगर 5V में हल्का-सा noise न हो तो needle अक्सर अटक जाती है; उल्टा यही "rough" 5V उसे अटकने से बचाता है। अगर electronic replacement लगाएँ, तो उसमें जान-बूझकर कुछ "noise" जोड़ना पड़ता है। ऐसे सरल mechanical device की प्रभावशीलता और सादगी देखकर मैं प्रभावित हुए बिना नहीं रह पाता
ऐसे सरल कोड की असली क़ीमत—कि वह code maintenance या काम करने वालों का समय बचाता है—अक्सर ठीक से पहचानी ही नहीं जाती। KISS (Keep It Simple, Stupid) सिद्धांत पर बने कोड को कई बार यह कहकर कमतर आँका जाता है कि उसमें कोई दिखने वाली value नहीं है। इसलिए ऐसी teams/organizations भी मिलती हैं जो असल में सिर्फ़ अनावश्यक जटिलता को manage करने का ही काम करती हैं
कभी-कभी अच्छा लगता है जब engineer कुछ असाधारण कर सके, लेकिन सच में महत्वपूर्ण engineer वह है जो शुरुआत में मुश्किल दिखने वाली समस्या में भी अंततः साधारण और सरल समाधान ढूँढ लेता है
बैले को देखकर लोग कहते हैं, "यह तो बहुत आसान लग रहा है!" लेकिन हक़ीक़त यह है कि वे उसे आसान दिखाने के लिए हज़ारों-हज़ार बार अभ्यास करते हैं
मैं हमेशा उन लोगों का सबसे ज़्यादा सम्मान करता हूँ जो किसी जटिल चीज़ को सचमुच बहुत सरल रूप में संक्षेपित कर देते हैं। K&R C examples जैसी स्पष्टता हो, बस comments थोड़े और ध्यान से लिखे जाएँ, यही चाहूँगा
"क्या कोड एक नज़र में समझ आता है और नए engineers की onboarding आसान बनाता है"—यह सवाल जितना लगता है उतना आसान नहीं है। नया engineer से मतलब 0 साल अनुभव वाला, 10 साल वाला, या 30 साल वाला कौन है, यह स्पष्ट नहीं होता। "readability" भी किसी को बहुत स्पष्ट विचार लग सकता है, लेकिन वास्तव में यह 0 से अनंत तक फैला एक spectrum है। Maxwell's equations किसी के लिए बहुत साफ़ हो सकती हैं, और किसी दूसरे के लिए बिल्कुल अपारदर्शी। इसलिए मैं हमेशा सोचता हूँ कि "कोड पढ़ने में आसान होना चाहिए"—लेकिन किसके लिए?
पढ़ने में आसान कोड का मतलब ऐसा कोड है जो पाठक का ध्यान रखे और cognitive load को न्यूनतम करे। layered abstractions और design patterns का उद्देश्य भी यही है। हाँ, यह target reader की expertise और codebase से परिचित होने पर निर्भर करता है, इसलिए यह व्यक्तिपरक है। लेकिन सिर्फ़ व्यक्तिपरक होने के कारण readability की अवधारणा को ही नकार देना कुछ ज़्यादा होगा। आखिर Joyce की 'Ulysses' और Seuss की 'The Cat in the Hat' दोनों को एक बराबर पढ़ने में आसान तो नहीं कहा जा सकता
मैं इस दावे से सहमत नहीं हूँ कि "readability कोई अवधारणा ही नहीं है"। जो कोड पढ़ा ही नहीं जा सकता, उसे लेखक खुद (या AI) भी नहीं पढ़ सकता, तो कोई और कैसे पढ़ेगा। और जो कोड सिर्फ़ लेखक ही पढ़ सकता है, वह भी पढ़ने में आसान नहीं है
Maxwell की equations अपने समय में सचमुच कठिन थीं, लेकिन आज जो रूप हम जानते हैं वह Heaviside वगैरह के उन्हें और सँवारने का परिणाम है, जिससे उनकी readability बेहतर हुई
मुझे लगता है कि कोड के किसी छोटे हिस्से की "local readability" का बहुत ज़्यादा मतलब नहीं है। अगर codebase में एक pattern लगातार और एकसमान तरीके से लागू हो, तो भले वह pattern थोड़ा जटिल हो, पूरा codebase फिर भी काफ़ी readable हो सकता है। अस्थायी जटिलता तब तक ठीक है जब तक वह संपूर्ण कोड गुणवत्ता को प्रभावित नहीं करती
readability का उद्देश्य अक्सर 'accidental complexity' को कम करना होता है। चाहे वह फिल्म screenplay जैसी notation हो, कोई complex algorithm हो, या कुछ और—अगर उसकी notation खराब है, तो उसे समझना ही मुश्किल हो जाता है। आख़िर "कोड किसके लिए पढ़ने में आसान होना चाहिए" का जवाब यह है: उस क्षेत्र को अच्छी तरह जानने वाला engineer, जो समस्या से परिचित हो लेकिन इस खास कोड को पहले न देखा हो, वह उसे पढ़ सके। यह research paper जैसा है; वह अपने संबंधित researchers के समूह के लिए readable होना चाहिए। No Silver Bullet summary
मुझे लगता है कि "खराब taste वाला engineer टूटी हुई compass की तरह आखिरकार ग़लत दिशा बताता है"—यह उपमा बात की जड़ पकड़ती है। ऐसे लोगों को, जो इस तरह "पूर्वानुमेय रूप से खराब" होते हैं, interview में पहचाना जा सकता है। असल में ज़्यादा ख़तरनाक वे होते हैं जो "आंशिक रूप से टूटी हुई compass" जैसे हों। ऊपर-ऊपर से लगता है कि थोड़ा-बहुत घूम रही है, लेकिन असल में वह हमेशा ठीक 127 डिग्री ग़लत दिशा दिखा रही होती है
ऐसे लेख अक्सर दो मुद्दों को गड़बड़ा देते हैं। पहला, कुछ फैसले taste या principles से अलग, वस्तुनिष्ठ रूप से खराब होते हैं—जैसे list में O(n) search बनाम dictionary में O(1) search। कुछ चीज़ें तकनीकी रूप से साफ़ तौर पर बेहतर या बदतर होती हैं। दूसरा, बाकी सब trade-off हैं। map-reduce इस्तेमाल करना है या साधारण loop, यह performance, readability, compatibility वगैरह देखकर तय किया जा सकता है। अगर कई विकल्पों में किसी के पास कारण है, तो वह मेरे विचार से अलग होने पर भी ठीक है। समस्या तब है जब जवाब ग़लत हो या trade-off पर विचार ही न किया गया हो। तब बात maintenance के दायरे में आती है, और performance या frequency जैसी परिस्थिति के अनुसार हो सकता है कि उसे छेड़ना भी न पड़े। जब तक उस निर्णय का "why" साफ़ है, मैं उसे स्वीकार करता हूँ। हालांकि, इसे सच में "taste" कहना चाहिए या नहीं, इस पर मुझे संदेह है
इस लेख की समस्या यह है कि यह "लोग अलग-अलग values को महत्व देते हैं" वाली बात को बहुत ही संदर्भहीन तरीके से पेश करता है। असल में किसी engineer को मोटे तौर पर यह पहचानना आना चाहिए कि किसी समस्या में कौन-सी value सबसे महत्वपूर्ण है, यानी hard constraint क्या है। उस hard constraint को हटाने के बाद जो बाकी स्वतंत्रता बचती है, उसे "taste" कहना ज़्यादा उचित है। अगर कलाकार की भाषा में कहें, तो तय materials और specifications के अलावा जहाँ उसकी अपनी अतिरिक्त सीमाएँ या स्वतंत्रता बचती है, वही हिस्सा है। software engineer की अच्छी taste मुझे उस दिशा जैसी लगती है जहाँ "सौंदर्य की दृष्टि से minimalism" और "self-restraint की अधिकतम मात्रा" हो। मेरे हिसाब से सचमुच "खराब taste" का मामला वह है जब कोई बिना किसी कारण principle तोड़ दे। यानी कई बार लोग simplicity को गलती से familiarity समझ बैठते हैं
लेख में "values" वाला हिस्सा Roy Fielding की PhD dissertation में software architecture की properties से जुड़ता है। Fielding की thesis REST के लिए ज़्यादा मशहूर है, लेकिन वास्तव में यह उससे कहीं व्यापक और मज़बूत software architecture discussion है। यह अलग-अलग "architectural properties"—जैसे scalability, readability, maintainability आदि—के संदर्भ में सोचने में मदद करती है, और मैं व्यक्तिगत रूप से यह ज़ोर देना चाहूँगा कि इन properties के अलावा 'architectural constraints' को समझना भी उतना ही महत्वपूर्ण है
सही engineering (Principled engineering) तो बुनियादी अपेक्षा होनी चाहिए। उसके ऊपर taste अच्छा भी हो सकता है और खराब भी। लेकिन उल्टा सही नहीं है। अगर engineering ही अच्छी नहीं है, तो taste का कोई मतलब नहीं। खराब taste engineering की efficiency को कम कर सकता है, लेकिन engineering को असंभव नहीं बनाता। engineering मूल रूप से taste को सहारा देने का काम करती है। उदाहरण के लिए, कोई चीज़ पूरी तरह engineered हो सकती है, लेकिन अगर उसकी ज़रूरत ही न हो और कोई उसे चाहता ही न हो, तो उसका कोई अर्थ नहीं
खराब taste अंततः हमें उसी अनिश्चित परिस्थिति (X) की ओर ले जाती है जिससे हम बचना चाहते हैं। मेरी नज़र में अच्छी taste का मतलब है भविष्य में आने वाली अनिश्चितताओं के लिए codebase में मज़बूत नींव और सुरक्षा-तंत्र पहले से तैयार रखना। तभी जोखिम से बचा जा सकता है
वाकई अच्छा है
मूल लेख अच्छा है, लेकिन टिप्पणियों की सामग्री भी वाकई बहुत अच्छी है।
"रुचि" की बात आए तो मुझे Torvalds का TED वीडियो याद आता है:
https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux
14:20 से, linked list की entry हटाने वाले कोड के implementation के ज़रिए दिखने वाली अच्छी रुचि
Hacker News की राय में उल्लेख किए गए "वस्तुनिष्ठ रूप से बुरे फ़ैसले (जैसे, list में O(n) search बनाम dictionary से O(1) search)" भी संदर्भ के अनुसार अलग तरह से तय करने पड़ सकते हैं।
अगर lookup सिर्फ़ एक बार करना हो, तो hash table बनाने की लागत list में O(n) search करने से ज़्यादा हो सकती है।
अच्छी टिप्पणी है।