सॉफ्टवेयर आर्किटेक्चर ओवररेटेड है, सरल डिजाइन को कम करके आंका गया है

हम आपको गबरेल ओरोस के पद का अनुवाद प्रदान करते हैं, जो उबेर में इंजीनियरिंग प्रबंधक का पद संभाल रहे हैं। इसमें, वह उबेर और माइक्रोसॉफ्ट में अपने स्वयं के व्यावहारिक अनुभव के आधार पर, बड़े पैमाने पर प्रणालियों के डिजाइन पर अपना विचार साझा करता है। हैकर समाचार पर टिप्पणियों के साथ संयुक्त, जो कि वजनदार प्रति-तर्क जोड़ते हैं और लेखक के दृष्टिकोण को पूरक करते हैं, उनका लेख सप्ताह के सबसे दिलचस्प पदों में से एक बन गया है। शब्द "कोड डिज़ाइन" का उपयोग लेख में पारंपरिक "वास्तुकला" के साथ तुलना करने के लिए किया जाता है - इसके बारे में और अधिक यहां पाया जा सकता है ।

मुझे बड़े पैमाने पर सिस्टम तैयार करने और बनाने का पर्याप्त अनुभव है। मैंने Uber में वितरित भुगतान प्रणाली को फिर से लिखने, Xbox One पर स्काइप को डिज़ाइन करने और जारी करने और सार्वजनिक रूप से उपलब्ध RIBs को जारी करने में भाग लिया, जो उबर द्वारा बनाई गई एक मोबाइल वास्तुकला संरचना है। इन सभी प्रणालियों में एक सावधानीपूर्वक सोचा गया डिज़ाइन था, कई पुनरावृत्तियों के माध्यम से चला गया, और कई बैठकें व्हाइटबोर्ड, और अन्य चर्चाओं में आयोजित की गईं। फिर डिज़ाइन एक डिज़ाइन दस्तावेज़ के साथ आया, जिसे अतिरिक्त प्रतिक्रिया एकत्र करने के लिए अन्य डेवलपर्स के बीच वितरित किया गया था, जो तब तक जारी रहा जब तक हम विकास पर नहीं चले गए।

ये सभी प्रणालियां बड़े पैमाने पर थीं: सैकड़ों डेवलपर्स ने उन्हें बनाया - या उन्होंने अपने डिजाइनों में उनका उपयोग किया - और आज वे उन प्रणालियों के दिलों में धड़कते हैं जिन्हें हर दिन लाखों लोग उपयोग करते हैं। इसके अलावा, इन परियोजनाओं को खरोंच से नहीं बनाया गया था। भुगतान प्रणाली को दो अन्य मौजूदा भुगतान प्रणालियों को बदलने के लिए इस्तेमाल किया गया था जो दर्जनों अन्य प्रणालियों और दर्जनों टीमों द्वारा उपयोग की जाती थीं, सभी बिना किसी नुकसान के। उबेर आवेदन को फिर से लिखना एक परियोजना थी जिसमें कई सैकड़ों इंजीनियरों ने एक ही समय पर काम किया था - इसमें नई वास्तुकला के लिए सभी मौजूदा कार्यक्षमता को पोर्ट करना शामिल था।

मुझे कुछ ऐसी चीज से शुरू करते हैं जो अप्रत्याशित लग सकती है। सबसे पहले, हमने इन प्रणालियों के डिजाइनों पर काम करने के लिए मानक सॉफ्टवेयर आर्किटेक्चर प्लानिंग टूल्स का इस्तेमाल कभी नहीं किया। हमने न तो यूएमएल का इस्तेमाल किया, न ही 4 + 1 मॉडल का, न एडीआर का , न ही सी 4 का , न ही निर्भरता आरेखों का । हमने कई चित्र बनाए, लेकिन उनमें से किसी ने भी किसी भी सख्त नियम का पालन नहीं किया। केवल अच्छे पुराने आयतों और तीरों की ज़रूरत थी - और हमें इस के समान आकृतियाँ मिलीं, जो सूचना प्रवाह , या किसी अन्य का वर्णन करती हैं , जो वर्ग की संरचना और घटकों के बीच संबंध को दर्शाती है । एक ही डिजाइन दस्तावेज़ में दो चार्ट में अक्सर एक अलग शैली होती थी, क्योंकि उन्हें अक्सर अलग-अलग लोगों द्वारा जोड़ा या संपादित किया जाता था।

दूसरे, हमारे पास आर्किटेक्ट नहीं थे जो डिजाइन के मालिक होंगे। यहां न तो आईटी आर्किटेक्ट था और न ही एंटरप्राइज आर्किटेक्ट । यह सच है - सॉफ्टवेयर आर्किटेक्ट के लिए न तो उबेर, न ही Skype / Mircrosoft में पूर्णकालिक स्थिति है। उच्च स्तर के इंजीनियरों, जैसे कि स्टाफ इंजीनियर की स्थिति में, अभी भी नियमित रूप से कोड लिखने की उम्मीद है। हमारी सभी परियोजनाओं में अनुभवी इंजीनियर हैं - हालांकि, एक भी व्यक्ति अकेले वास्तुकला या डिजाइन का मालिक नहीं है। जबकि अनुभवी इंजीनियर डिजाइन प्रक्रिया के पीछे प्रेरक बल थे, अन्य डेवलपर्स चर्चा में शामिल थे, यहां तक ​​कि हरे "जून" सहित - इसके अलावा, उन्होंने अक्सर दूसरों के फैसलों को चुनौती दी और चर्चा के लिए वैकल्पिक विकल्प लाए।

तीसरा, हमने लगभग कभी भी सामान्य वास्तुशिल्प पैटर्न और अन्य आम तौर पर स्वीकार किए गए शब्दजाल का उल्लेख नहीं किया है, जो कि मार्टिन फाउलर के मैनुअल जैसे सॉफ्टवेयर आर्किटेक्चर पर लोकप्रिय साहित्य में उपयोग किया जाता है। माइक्रोसर्विस, सर्वरलेस आर्किटेक्चर, एप्लिकेशन बाउंड्रीज़ , इवेंट-संचालित आर्किटेक्चर, या कुछ और का कोई संदर्भ नहीं था। इनमें से कुछ शब्द बुद्धिशीलता सत्र के दौरान सामने आए; हालाँकि, हमें डिज़ाइन डॉक्यूमेंटेशन में स्वयं उन्हें संदर्भित करने की कोई आवश्यकता नहीं थी।

प्रौद्योगिकी कंपनियों और स्टार्टअप में सॉफ्टवेयर डिजाइन

तो हमने सब कुछ कैसे निपटाया? और क्यों हम सॉफ्टवेयर वास्तुकला के लिए सामान्य दृष्टिकोण का पालन नहीं करते हैं?

मैंने अन्य प्रौद्योगिकी कंपनियों में काम करने वाले साथी इंजीनियरों के साथ इस मुद्दे पर चर्चा की - दोनों एफएजी आकार (फेसबुक, अमेज़ॅन, नेटफ्लिक्स, गूगल) और छोटे स्टार्टअप। अधिकांश टीमों और परियोजनाओं - चाहे वे बड़े या छोटे थे - डिजाइन और कार्यान्वयन के लिए एक समान दृष्टिकोण संयुक्त:

1. एक व्यवसाय कार्य के साथ शुरू करो। हम किस समस्या को हल करने की कोशिश कर रहे हैं? हम किस उत्पाद को बनाने की कोशिश कर रहे हैं और क्यों? हम इसकी सफलता को कैसे माप सकते हैं?
2. चुने हुए "दृष्टिकोण" के लिए मंथन। टीम के साथ मिलें और कुछ सत्रों में काम करने का हल निकालें। इस चरण के साथ अधिक विलंब न करें। शीर्ष स्तर से शुरू करें और धीरे-धीरे अपने आप को नीचे के स्तरों तक कम करें।
3. बोर्ड पर अपना दृष्टिकोण बनाएं। टीम को एक साथ इकट्ठा करें, और आप में से एक को उस दृष्टिकोण का चित्रण करने दें जिससे टीम झुक रही है। आपको एक बोर्ड की मदद से अपने सिस्टम / एप्लिकेशन की वास्तुकला को स्पष्ट रूप से समझाने में सक्षम होना चाहिए - उच्चतम स्तर से शुरू करना और, यदि आवश्यक हो, तो कम और कम होना। यदि आपको किसी स्पष्टीकरण के साथ कठिनाई होती है या यह सहयोगियों के लिए पर्याप्त रूप से स्पष्ट नहीं है, तो आपको अपने निर्णय के विवरण को बेहतर ढंग से समझने की आवश्यकता है।
4. इसे सरल दस्तावेज़ के रूप में सरल आरेखों के साथ ठीक करें जो आपने पहले व्हाइटबोर्डिंग के साथ समझाया था। शब्दजाल को न्यूनतम रखें: आप चाहते हैं कि जूनियर्स भी समझ सकें कि क्या कहा जा रहा है। अपने विवरण में स्पष्ट और आसान भाषा का उपयोग करें । उबेर में, हम एक साधारण टेम्पलेट के आधार पर एक आरएफसी-जैसे दस्तावेज़ का उपयोग करते हैं।
5. ट्रेडऑफ़ और विकल्पों पर चर्चा करें । अच्छा सॉफ्टवेयर डिजाइन और अच्छी वास्तुकला व्यापार-नापसंद के लिए सही विकल्प हैं। अपने आप में, कोई भी डिज़ाइन विकल्प खराब या अच्छा नहीं है: यह सब संदर्भ और लक्ष्यों पर निर्भर करता है। क्या आपकी वास्तुकला विभिन्न सेवाओं में विभाजित है? उल्लेख करें कि आपने एक बड़ी सेवा नहीं करने का फैसला क्यों किया, जिसमें एक सरल और तेज तैनाती की तरह अन्य फायदे हो सकते हैं। क्या आपने नई कार्यक्षमता के साथ मॉड्यूल या सेवा का विस्तार करने का निर्णय लिया है? इसके बजाय, एक अलग सेवा या मॉड्यूल विकसित करने की संभावना को तौलना, और इस दृष्टिकोण के पेशेवरों और विपक्ष क्या हैं।
6. टीम / संगठन के भीतर डिज़ाइन दस्तावेज़ वितरित करें और प्रतिक्रिया एकत्र करें। पहले, उबेर में, हमने अपने सभी इंजीनियरों को सॉफ्टवेयर के लिए सभी डिज़ाइन दस्तावेज़ भेजे - जब तक हमारा स्टाफ 2,000 लोगों तक नहीं बढ़ गया। अब जब हम इस तरह बढ़ गए हैं, तब भी हम सबसे बड़े संभावित दर्शकों तक पहुँचने की कोशिश कर रहे हैं - लेकिन साथ ही हमने यह सुनिश्चित करना शुरू कर दिया है कि सूचना शोर का स्तर अनुमेय सीमा से अधिक न हो। दूसरों को प्रश्न पूछने और विकल्प सुझाने के लिए प्रोत्साहित करें। फीडबैक पर चर्चा के लिए समय सीमा के बारे में व्यावहारिक रहें और इसे आवश्यक दस्तावेज में शामिल करें। विशिष्ट इच्छाओं को तुरंत और जल्दी से लागू किया जा सकता है, जबकि विस्तृत प्रतिक्रिया व्यक्ति में एक व्यक्ति के साथ जुदा करना बेहतर है।

सॉफ्टवेयर आर्किटेक्चर पर साहित्य में आमतौर पर उल्लिखित हमारा दृष्टिकोण अलग क्यों है? वास्तव में, हमारा दृष्टिकोण मौलिक रूप से इतना अलग नहीं है जो वास्तुकला के मैनुअल में वर्णित है। लगभग सभी मैनुअल एक व्यवसाय कार्य के साथ शुरू करने का सुझाव देते हैं, साथ ही समाधान और व्यापार-बंद का वर्णन करते हैं - हम यह भी करते हैं। हम जो नहीं कर रहे हैं वह अधिक परिष्कृत उपकरणों का उपयोग नहीं कर रहा है जो कि कई आर्किटेक्ट और आर्किटेक्चर बुक्स की वकालत करते हैं। हम यथासंभव सरल और सबसे स्पष्ट टूल, जैसे कि Google डॉक्स या ऑफिस 365 का उपयोग करके डिज़ाइन को सरल बनाते हैं।

मेरा मानना ​​है कि हमारे दृष्टिकोण में मुख्य अंतर विभिन्न कंपनियों की इंजीनियरिंग संस्कृति के लिए नीचे आता है। स्वायत्तता और न्यूनतम पदानुक्रम की एक उच्च डिग्री एक विशेषता है जो आधुनिक प्रौद्योगिकी कंपनियों और स्टार्टअप्स के बीच आम है; अधिक परंपरागत कंपनियों के मामले में, यह हमेशा सच है। यही कारण है कि इन जगहों पर वे अक्सर सख्त नियमों के साथ प्रक्रिया के आधार पर डिजाइन के बजाय "सामान्य ज्ञान पर आधारित डिजाइन" का सहारा लेते हैं।

मुझे पता है कि बैंक और कार कंपनियां जहां डेवलपर्स को सक्रिय रूप से चेन के ऊपर जाने और वास्तुकारों से कई स्तरों पर स्वीकृति प्राप्त करने के लिए बिना किसी वास्तु निर्णय लेने से हतोत्साहित किया जाता है, जो कई टीमों की देखरेख करते हैं। इससे प्रक्रिया धीमी हो जाती है, और बड़ी संख्या में अनुरोध के साथ, आर्किटेक्ट अतिभारित हो जाते हैं। इसलिए, ये आर्किटेक्ट और भी अधिक औपचारिक दस्तावेज बनाते हैं, इस उम्मीद में कि सिस्टम अधिक समझ में आएगा - उन सभी साधनों का उपयोग करना जो आपके परिचित साहित्य का वर्णन करता है। इन दस्तावेजों को एक टॉप-डाउन दृष्टिकोण द्वारा समर्थित किया जाता है, क्योंकि यह इंजीनियरों पर एक डराने वाले तरीके से काम करता है - आखिरकार, वे आर्किटेक्ट नहीं हैं, और निर्णय पर संदेह या विवाद नहीं करना चाहिए, क्योंकि उन्हें पहले से ही औपचारिक तरीकों का उपयोग करके दस्तावेज किया गया है जिसमें वे खराब तरीके से वाकिफ हैं। इसलिए, वे आमतौर पर ऐसा नहीं करते हैं। ईमानदारी से, ये कंपनियां डेवलपर्स को एक विनिमेय संसाधन बनाने के लिए ऐसा ही करती हैं - क्योंकि इससे उन्हें थोड़े समय में लोगों को एक परियोजना से दूसरी परियोजना में स्थानांतरित करने की अनुमति मिलती है। यह शायद आपके लिए आश्चर्य की बात नहीं होगी कि विभिन्न उपकरण विभिन्न वातावरणों के लिए बेहतर अनुकूल हैं।

वास्तु पैटर्न के बजाय शब्दजाल के बिना सरल सॉफ्टवेयर डिजाइन

सिस्टम डिजाइन का लक्ष्य सादगी होना चाहिए। सिस्टम जितना सरल है, समझने में उतना ही आसान है - और जितना आसान है उसमें समस्याओं को ढूंढना, और साथ ही इसे लागू करना भी है। जिस भाषा में यह वर्णित किया गया है, वह जितनी स्पष्ट है, उसकी डिज़ाइन उतनी ही सुलभ है। शब्दजाल का उपयोग करने से बचें जो टीम के प्रत्येक सदस्य को समझ में नहीं आएगा - यहां तक ​​कि आपके सहयोगियों के सबसे अनुभवहीन को यह समझने में सक्षम होना चाहिए कि दूसरों के स्तर पर क्या दांव पर है।

एक साफ डिजाइन साफ ​​कोड की तरह है: यह पढ़ने में आसान है और समझने में आसान है। क्लीन कोड लिखने के कई बेहतरीन तरीके हैं। हालाँकि, आपने अक्सर सुना होगा कि कोई व्यक्ति आपके कोड में "चार" के डिजाइन पैटर्न को लागू करने से शुरू होता है। स्वच्छ कोड एकमात्र जिम्मेदारी, स्पष्ट नाम और आसानी से समझने वाले सम्मेलनों के सिद्धांत से शुरू होता है। ये सिद्धांत समान रूप से शुद्ध वास्तुकला पर लागू होते हैं।

तो वास्तु पैटर्न की भूमिका क्या है? मुझे उन्हें उपयोगी लगता है - कोड डिज़ाइन पैटर्न के समान ही उपयोगी। वे आपको इस बारे में विचार दे सकते हैं कि आप अपने कोड या आर्किटेक्चर को कैसे सुधार सकते हैं। कोड डिज़ाइन पैटर्न लें: जब मैं कोड में एक सिंगलटन को नोटिस करता हूं, तो मैं खुद के लिए नोटिस करता हूं - और मैं अपनी भौहें बढ़ाता हूं और जब मैं एक वर्ग की तरह व्यवहार करता हूं, तो मुझे गहरी खुदाई होती है, लेकिन वास्तव में यह सिर्फ कॉल करता है। लेकिन वह दिन अभी तक नहीं आया है जब मैंने सोचा होगा, "एक अमूर्त फैक्ट्री बस यहीं मांग रही है।" सच में, मुझे यह पता लगाने में काफी समय लगा कि यह पैटर्न क्या करता है और इससे पहले कि यह मुझ पर हावी हो जाए; समझ निर्भरता इंजेक्शन के साथ कड़ी मेहनत के परिणामस्वरूप आई, उन कुछ क्षेत्रों में से एक जहां यह पैटर्न व्यापक और बेहद उपयोगी है । मैं यह भी स्वीकार करता हूं कि भले ही मैंने "चार" डिजाइन पैटर्न के गिरोह को पढ़ने और समझने में बहुत समय बिताया हो, लेकिन उनके पास मेरे कोड के बारे में अन्य डेवलपर्स से मिली प्रतिक्रिया की तुलना में प्रोग्रामर के रूप में मेरे पेशेवर विकास पर बहुत कम प्रभाव था।

इसी तरह, सामान्य वास्तुशिल्प पैटर्न को जानना एक अच्छी बात है: यह उन लोगों के साथ चर्चा में बिताए गए समय को कम करने में मदद करता है, जो उन्हें उसी तरह से समझते हैं जो आप करते हैं। लेकिन वास्तुशिल्प पैटर्न लक्ष्य नहीं हैं, और वे सरल सिस्टम डिज़ाइन विकल्पों के विकल्प नहीं होंगे। जब आप एक सिस्टम डिज़ाइन करते हैं, तो आपको अचानक महसूस हो सकता है कि आपने गलती से कुछ सामान्य पैटर्न लागू किया है - और यह अच्छा है, क्योंकि बाद में आपके लिए उपयोग किए गए दृष्टिकोण को संदर्भित करना आसान होगा। लेकिन आपको कभी भी एक या अधिक पैटर्न नहीं लेना चाहिए और उन्हें एक हथौड़ा के रूप में उपयोग करना चाहिए, जिसके लिए आप हमेशा नाखून देखेंगे।

वास्तुशिल्प पैटर्न तब अस्तित्व में आया जब इंजीनियरों ने इस तथ्य पर ध्यान आकर्षित किया कि कुछ स्थितियों में यह डिजाइन और इसके कार्यान्वयन के बारे में समान निर्णय लेने के लिए समझ में आता है। समय के साथ, इन फैसलों को नाम प्राप्त हुए, आम जनता द्वारा रिकॉर्ड और चर्चा की गई। वास्तुशिल्प पैटर्न ऐसे उपकरण हैं जो समाधानों के बाद दिखाई देते हैं, इस उम्मीद में कि यह दूसरों के लिए जीवन को आसान बनाने में मदद करेगा। एक इंजीनियर के रूप में, आपको अपने लक्ष्य के रूप में अपनी समस्याओं के समाधान के लिए एक स्वतंत्र खोज के रूप में सेट करना चाहिए और इस प्रक्रिया के दौरान सीखना चाहिए - इस उम्मीद में कि "हाइप" वास्तुशिल्प पैटर्न लेने के बजाय यह आपकी समस्या का समाधान करेगा।

कैसे बेहतर डिजाइन सिस्टम सीखने के लिए

लोग अक्सर मुझसे सलाह मांगते हैं: सिस्टम की वास्तुकला और डिजाइन में "पंप" कैसे करें? अनुभवी इंजीनियर आमतौर पर आर्किटेक्चरल पैटर्न के साथ-साथ सॉफ्टवेयर आर्किटेक्चर पर किताबें पढ़ने की सलाह देते हैं। मैं यथासंभव अधिक - विशेष रूप से पुस्तकों को पढ़ने की सिफारिश का पूरी तरह से समर्थन करता हूं, क्योंकि वे आपको इस विषय में कम पदों की तुलना में अधिक गहराई से गोता लगाने की अनुमति देते हैं - हालांकि, मेरे पास कुछ और व्यावहारिक सिफारिशें हैं।

• टीम के सदस्यों में से एक को संलग्न करें और एक साथ व्हाइटबोर्डिंग करें। बोर्ड पर ड्रा करें जो आप काम कर रहे हैं और छवि का अर्थ समझाएं। सुनिश्चित करें कि आपके सहकर्मी समझ रहे हैं कि क्या कहा जा रहा है। और जब आप अंततः समझ जाते हैं, तो प्रतिक्रिया के लिए पूछें।
• एक सरल दस्तावेज़ में अपने डिजाइन का वर्णन करें और अपनी टीम के साथ साझा करें, उनसे प्रतिक्रिया पूछें। इससे कोई फर्क नहीं पड़ता है कि आप जिस कार्य को सरल या जटिल कर रहे हैं - यह या तो एक छोटी रीफैक्टरिंग या बड़े पैमाने पर परियोजना हो सकती है - आपको इसे संक्षेप में संक्षेप में प्रस्तुत करना चाहिए। इसे इस तरह से करें कि आपके लिए यह दस्तावेज़ समझ में आता है, और बाकी के लिए यह समझ में आता है; प्रेरणा के लिए - यहाँ एक उदाहरण है कि यह उबेर में कैसे किया जाता है । इस दस्तावेज़ को अपनी टीम के साथ एक प्रारूप में साझा करें जो टिप्पणी करने की अनुमति देता है - उदाहरण के लिए, Google डॉक्स, ऑफिस 365 या कुछ इसी तरह का उपयोग करके। दूसरों से अपने विचारों और सवालों के साथ इसे पूरक करने के लिए कहें।
• दो अलग-अलग डिज़ाइन बनाएं और उनके विपरीत। जब हम में से अधिकांश वास्तुकला डिजाइन करते हैं, तो वे आमतौर पर एक ही रास्ता तय करते हैं: वह जो उनके सिर में पॉप अप करता है। हालांकि, वास्तुकला कुछ काला और सफेद नहीं है। एक दूसरे आर्किटेक्चर डिज़ाइन विकल्प के साथ आओ जो आपकी स्थिति में भी काम कर सकता है। दोनों डिज़ाइनों का विरोध करें और समझाएं कि एक दूसरे से बेहतर क्यों है। संकेत दें कि आपने विकल्प के रूप में कुछ समय के लिए दूसरा विकल्प माना है, और समझाएं कि आपने उसके पक्ष में निर्णय क्यों नहीं लिया।
• उन समझौतों पर निर्णय लें, जिन्हें आप करने के लिए तैयार हैं - पता करें कि आप उन्हें क्यों स्वीकार करते हैं और उनकी मदद से आप क्या हासिल करना चाहते हैं। मौजूदा प्रतिबंधों को स्पष्ट रूप से स्थापित करें जिन्हें आपको ध्यान में रखने के लिए मजबूर किया गया था।
• अन्य लोगों के डिजाइनों की समीक्षा का संचालन करें। और समझदारी से करें। यदि आपकी कंपनी में डिज़ाइन साझा करने की संस्कृति है, जिसे लोग व्हाइटबोर्डिंग, मीटिंग या दस्तावेज़ों का उपयोग करके साझा करते हैं - तो उनसे अधिक प्राप्त करें। आमतौर पर एक समीक्षा के दौरान, लोग किसी और के कोड डिजाइन को पर्यवेक्षकों के रूप में देखते हैं; इसके बजाय, उन भागों के लिए स्पष्ट प्रश्न पूछें, जिन्हें आप काफी समझते नहीं हैं। पूछें कि उन्होंने किन विकल्पों पर विचार किया। पूछें कि उन्होंने क्या समझौता किया और उन्होंने किन सीमाओं को माना। शैतान के वकील बनें और एक और सुझाव दें, संभवतः सरल विकल्प - भले ही यह उनके समाधान से बेहतर न हो - और पूछें कि वे आपके प्रस्ताव के बारे में क्या सोचते हैं। भले ही आपने इसे प्रस्तुत करने वाले की तुलना में अपने डिज़ाइन को इतनी अच्छी तरह से सोचा नहीं है, फिर भी आपकी चर्चा कुछ नया ला सकती है और आपको उस कार्य को बेहतर ढंग से समझने में मदद करेगी जो आप कर रहे हैं।

सबसे अच्छा सॉफ्टवेयर डिजाइन सरल और समझने में आसान है। अगली बार जब आप एक नया प्रोजेक्ट शुरू करते हैं, तो सवाल को टटोलने के बजाय, " मैं इस प्रणाली को कैसे डिज़ाइन करूंगा, मुझे युद्ध में किन पैटर्नों का उपयोग करना चाहिए और मुझे इसे किस औपचारिक कार्यप्रणाली के साथ दस्तावेज़ करना चाहिए? ", सोचो - " मैं सबसे सरल संभव डिजाइन में कैसे आ सकता हूं - एक जिसे आसानी से किसी के द्वारा समझा जाएगा? "

सॉफ्टवेयर आर्किटेक्चर, उद्यम विकास के वास्तुशिल्प पैटर्न, सिस्टम का वर्णन करने के प्रकार के सर्वोत्तम तरीके के सर्वोत्तम अभ्यास सभी उपकरण हैं जो स्वयं के लिए उपयोगी हैं, क्योंकि एक दिन वे आपके लिए बहुत उपयोगी हो सकते हैं। लेकिन जब सिस्टम डिजाइन करते हैं, तो यह एक साधारण से शुरू होता है और जितना संभव हो उतना सरल रहने के लिए जारी रहता है। उस कार्य से बचने की कोशिश करें जो अधिक जटिल वास्तुकला और शक्तिशाली उपकरण अनिवार्य रूप से आपके सिस्टम में लाते हैं।

इस पोस्ट ने उद्योग के श्रमिकों के बीच गर्मजोशी से चर्चा की, जिन्होंने सॉफ्टवेयर वास्तुकला के बारे में अपने अनुभव और दृष्टिकोण को साझा किया। आप इन चर्चाओं को हैकर न्यूज़ , लोबेस्ट.र्स और रेडिट पर पढ़ सकते हैं ।

, , , « », « »; — 20 « », 300 IT- , — API, 5000 7000 .