- बड़े systems में वास्तविक डिज़ाइन में भागीदारी केवल वही engineers कर सकते हैं जो उस code को सीधे संभालते हैं; abstract सलाह ज़्यादातर बेकार होती है
- सामान्य design सलाह (generic design) अक्सर codebase को जाने बिना, सिर्फ domain समझकर दी जाती है
- वास्तविक काम में ठोस constraints और consistency बनाए रखना design principles से कहीं ज़्यादा महत्वपूर्ण होता है, और code की मौजूदा स्थिति को समझना सबसे अहम है
- नए system की design या पूरी company की technical direction तय करने में सामान्य design principles कुछ हद तक उपयोगी हो सकते हैं
- लेकिन मैदान से कटे हुए architect-केंद्रित design ढाँचे आसानी से विफल होते हैं, और design सुझाने वाले व्यक्ति को उसके परिणाम की ज़िम्मेदारी लेनी चाहिए
सामान्य software design की सीमाएँ
- बड़े systems की design के लिए code की ठोस बारीकियों की गहरी समझ अनिवार्य है
- abstract सलाह वास्तविक समस्याएँ सुलझाने में लगभग कोई मदद नहीं करती
- व्यवहारिक काम में consistency ‘अच्छे design’ से भी अधिक महत्वपूर्ण होती है
- वास्तविक codebase जटिल होती है और अप्रत्याशित परिणाम पैदा करती है, इसलिए सुरक्षित बदलाव के लिए चुने जा सकने वाले implementation तरीके सीमित होते हैं
- बड़े shared codebase हमेशा कई designs के मिले-जुले बीच के state में होते हैं; आदर्श लक्ष्य से अधिक महत्वपूर्ण code की मौजूदा coupling की स्थिति होती है
- अधिकांश systems का पूरा rewrite संभव नहीं होता, इसलिए आंतरिक consistency और engineers की बारीकी पर निर्भर रहना पड़ता है
ठोस software design की विशेषताएँ
- प्रभावी design discussion उन कुछ engineers की बातचीत में होती है जो system के साथ रोज़ काम करते हैं
- discussion का विषय सामान्य principles नहीं, बल्कि system की संरचना, data flow जैसे ठोस context होते हैं
- उदाहरण के लिए, “क्या DRY अच्छा है?” की जगह “क्या यह feature A subsystem में रखा जा सकता है, क्या B जानकारी C context में accessible है” जैसी सूक्ष्म technical चर्चा होती है
- महत्वपूर्ण योगदान अक्सर छोटी गलतफहमियों या code change के सूक्ष्म प्रभावों को ठीक करने से आता है
जब सामान्य design सलाह उपयोगी होती है
- नए project को पहली बार design करते समय ठोस constraints नहीं होते, इसलिए सामान्य principles उपयोगी होते हैं
- जब कई implementation विकल्पों में से चुनना कठिन हो, तब सामान्य principles decision के tie-breaker की भूमिका निभा सकते हैं
- पूरी company स्तर पर consistency बनाए रखने में भी मदद मिलती है, और यह औपचारिक software architect की भूमिका में से एक है
- cloud vs on-premise, AWS vs Azure जैसे व्यापक technical चुनावों में भी सामान्य principles संदर्भ बन सकते हैं, लेकिन तब भी ठोस constraints को नज़रअंदाज़ नहीं किया जा सकता
architect और ‘local minima’ समस्या
- कई कंपनियाँ मैदान के अनुभव के बिना architect-केंद्रित abstract design structure में फँस जाती हैं
- यह तरीका ऊपर से efficient दिखता है, लेकिन व्यवहार में ऐसी design पैदा करता है जिसे field engineers लागू ही नहीं कर पाते
- architect खुद implementation नहीं करते, इसलिए नतीजों के प्रति ज़िम्मेदारी (skin in the game) कम होती है
- design सफल हो तो श्रेय ले सकते हैं, और विफल हो तो execution team को दोष दे सकते हैं
- ऐसी संरचना वास्तविक value से अधिक औपचारिक design गतिविधियों को बढ़ावा देने की ओर झुकती है
निष्कर्ष और सुझाव
- उपयोगी design discussion code-level की ठोस बातचीत में होती है, और designer को codebase से भली-भाँति परिचित होना चाहिए
- सामान्य architecture principles को नए system की design, मौजूदा system में सूक्ष्म निर्णयों की सहायता, और company-स्तरीय technical दिशा तय करने तक सीमित रखना चाहिए
- जो व्यक्ति project design का प्रस्ताव रखता है, उसे उसकी सफलता और विफलता दोनों की ज़िम्मेदारी लेनी चाहिए, और वास्तव में code संभालने वाले engineers ही design के मुख्य पात्र होने चाहिए
- इससे वही व्यक्ति सच्चा designer माना जा सकेगा जो वास्तविक system को समझता हो और उसे deploy कर सकता हो
अभी कोई टिप्पणी नहीं है.