मैंने कोड लिखना क्यों बंद किया और डिज़ाइन करना क्यों शुरू किया
मैं पहले सोचता था कि सॉफ्टवेयर डेवलपमेंट का मतलब फीचर्स लिखना है। मुझे लगता था कि मेरा काम एंटिटीज (entities) बनाना, कंट्रोलर्स (controllers) बनाना और डेटाबेस को कनेक्ट करना है।
हाल ही में एक प्रोजेक्ट ने मेरा नज़रिया बदल दिया। मैंने सीखा कि कोडिंग समाधान का केवल एक हिस्सा है। असली काम कोड की एक भी लाइन लिखने से पहले ही हो जाता है।
आपको आर्किटेक्चर (architecture) पर निर्णय लेना होगा। आपको पूछना होगा कि यह क्यों उपयुक्त है, इसकी लागत क्या है, और यह किन जोखिमों को हल करता है।
यहाँ मेरे मुख्य सबक दिए गए हैं:
• आर्किटेक्चर को प्रोडक्ट के चरण (stage) के अनुरूप होना चाहिए। तुरंत microservices, Kubernetes और जटिल event queues का उपयोग करने का मन करता है। हमारे प्रोजेक्ट के लिए, हमने एक सिंगल प्रोसेस में layered architecture को चुना। इसने हमें एक distributed system के सिरदर्द के बिना जिम्मेदारियों को अलग करने की अनुमति दी। शुरुआत करते समय अक्सर सादगी ही बेहतर होती है।
• कुछ निर्णय अभी सस्ते होते हैं लेकिन बाद में महंगे पड़ते हैं। हमने पहले दिन से ही अपने डेटा मॉडल में TenantId जोड़ दिया था। भले ही हमारे पास केवल एक ही क्लाइंट था, लेकिन इससे भविष्य में SaaS मॉडल पर जाना आसान हो गया। यदि आप multi-tenancy जोड़ने में बहुत अधिक समय लगाते हैं, तो माइग्रेशन एक दुस्वप्न (nightmare) बन जाता है।
• डिज़ाइन भविष्य के बंद रास्तों (dead ends) को रोकता है। प्रोग्रामिंग एक तात्कालिक समस्या को हल करती है। डिज़ाइनिंग भविष्य के दरवाजों को बंद किए बिना समस्या को हल करती है। हमने अलग-अलग इंफ्रास्ट्रक्चर पर जाना आसान बनाने के लिए शुरुआत में ही containers का उपयोग किया। हमने प्रोवाइडर्स को बदलना आसान बनाने के लिए interfaces का उपयोग किया।
• व्यावसायिक बदलाव तकनीकी बदलावों को प्रेरित करते हैं। जब व्यवसाय बढ़ता है, तो सिस्टम microservices की ओर बढ़ता है। एक सिंगल क्लिनिक ऐप सैकड़ों क्लिनिकों के लिए एक SaaS प्लेटफॉर्म बन जाता है। यह बदलाव आपके बिलिंग, सब्सक्रिप्शन और स्केलिंग (scaling) को संभालने के तरीके को बदल देता है।
• विश्वसनीयता के लिए स्मार्ट पैटर्न्स (patterns) की आवश्यकता होती है। हम synchronous calls से event-driven architecture की ओर बढ़े। एक मेडिकल सिस्टम में, एक धीमा नोटिफिकेशन सर्विस अपॉइंटमेंट बुकिंग को क्रैश नहीं करना चाहिए। हमने Outbox pattern का उपयोग यह सुनिश्चित करने के लिए किया कि यदि मैसेज ब्रोकर विफल भी हो जाए, तो डेटा सुरक्षित रहे।
• पैटर्न्स को डोमेन (domain) के अनुरूप होना चाहिए। पैटर्न्स का अंधाधुंध उपयोग न करें। मेडिकल डायग्नोसिस के लिए मजबूत कंसिस्टेंसी (consistency) की आवश्यकता होती है। आप मरीज की सुरक्षा के लिए eventual consistency पर भरोसा नहीं कर सकते। संवेदनशील क्लिनिकल डेटा के लिए cache का उपयोग तब न करें यदि यह आपके ऑडिट ट्रेल (audit trail) को बाधित करता है।
• DevOps कोई बाद का विचार नहीं है। डिप्लॉयमेंट (deployment), हेल्थ चेक और पाइपलाइन्स शुरुआती डिज़ाइन का हिस्सा हैं। आपको लागत का अनुमान लगाना चाहिए और ऐसे कंपोनेंट्स चुनने चाहिए जो वास्तव में आपकी आवश्यकताओं को पूरा करें।
एक प्रोग्रामर और एक डिज़ाइनर के बीच का अंतर "क्यों" है।
एक प्रोग्रामर पूछता है: "मैं इसे कैसे काम कराऊं?" एक डिज़ाइनर पूछता है: "इस विशिष्ट समस्या के लिए यह सही समाधान क्यों है?"