2006 के लिए लिनुस टोरवाल्ड्स का एक उद्धरण इस प्रकार है :

मैं डेटा के आसपास कोड विकसित करने का एक बड़ा प्रस्तावक हूं, और इसके विपरीत नहीं, और मुझे लगता है कि यह एक कारण है कि गिट काफी सफल रहे थे ... वास्तव में, मैं तर्क देता हूं कि एक खराब प्रोग्रामर और एक अच्छे के बीच का अंतर यह है कि क्या वह अधिक सोचता है महत्वपूर्ण आपका कोड या आपकी डेटा संरचनाएँ। खराब प्रोग्रामर कोड के बारे में चिंता करते हैं। अच्छे प्रोग्रामर डेटा संरचनाओं और उनके संबंधों के बारे में चिंता करते हैं।

जो एरिक रेमंड के 2003 के "सबमिशन नियम" के समान है:

ज्ञान को डेटा में बदल दें ताकि प्रोग्राम लॉजिक बेवकूफ़ और विश्वसनीय हो जाए।

यहाँ पर रोब पाइक के 1989 विचार जैसे विचारों का सारांश है:

डेटा हावी है। यदि आप सही डेटा संरचनाओं का चयन करते हैं और सब कुछ अच्छी तरह से व्यवस्थित करते हैं, तो एल्गोरिदम लगभग हमेशा स्वयं स्पष्ट होगा। डेटा संरचनाएं, एल्गोरिदम नहीं, प्रोग्रामिंग में केंद्रीय भूमिका निभाती हैं।

वह 1975 से फ्रेड ब्रुक्स को उद्धृत करते हैं:

प्रस्तुति प्रोग्रामिंग का सार है

महारत के पीछे सहजता है जो बनाती है
किफायती और तेज कार्यक्रम। यह लगभग हमेशा परिणाम होता है।
सामरिक सफलता, सामरिक कौशल नहीं। कभी-कभी इतना रणनीतिक
एक सफलता एक एल्गोरिथ्म है, जैसे कि तेजी से फूरियर रूपांतरण,
Cooley और Tukey द्वारा प्रस्तावित, या n n की तुलना में n लॉग एन के साथ छँटाई करते समय।

अधिक बार, प्रस्तुति के परिणामस्वरूप एक रणनीतिक सफलता मिलती है
डेटा या टेबल। कार्यक्रम का मूल यहाँ है। टेबलों को दिखाए बिना मुझे फ्लोचार्ट दिखाओ, और मैं भटकूंगा। मुझे अपना दिखाओ
तालिकाओं और फ़्लोचार्ट्स की सबसे अधिक संभावना नहीं है: वे स्पष्ट होंगे।

तो, लगभग आधी सदी के लिए, स्मार्ट लोगों ने बार-बार कहा है: पहले डेटा पर ध्यान दें। लेकिन कभी-कभी ऐसा लगता है कि यह सबसे स्मार्ट सलाह है जिसे हर कोई भूल जाता है।

मैं कुछ वास्तविक उदाहरण दूंगा।

अत्यधिक स्केलेबल प्रणाली जो विफल रही

यह प्रणाली मूल रूप से सीपीयू पर एक बड़े भार के साथ अविश्वसनीय स्केलेबिलिटी की उम्मीद के साथ बनाई गई थी। कुछ भी समकालिक नहीं। हर जगह कॉलबैक, कतार, और काम पूल।

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

सर्विस-ओरिएंटेड आर्किटेक्चर दैट स्टिल डेटा ओरिएंटेड

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

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

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

शानदार ढंग से मॉड्यूलर और विन्यास योग्य कीचड़

यह प्रणाली एक तरह की स्वचालित तैनाती पाइपलाइन थी। मूल विकास टीम कंपनी में तैनाती के मुद्दों को हल करने के लिए एक उपकरण को पर्याप्त लचीला बनाना चाहती थी। उन्होंने कॉन्फ़िगरेशन फ़ाइल सिस्टम के साथ प्लग-इन घटकों का एक सेट लिखा, जो न केवल घटकों को कॉन्फ़िगर करता है, बल्कि यह भी प्रोग्रामिंग के लिए एक डोमेन-विशिष्ट भाषा (डीएसएल) के रूप में कार्य करता है कि घटकों को पाइपलाइन में कैसे फिट किया जाता है।

कुछ वर्षों के लिए तेजी से आगे, और उपकरण "बहुत ही कार्यक्रम" में बदल गया। ज्ञात त्रुटियों की एक लंबी सूची थी जो किसी ने भी तय नहीं की थी। कोई कुछ तोड़ने के डर से कोड को छूना नहीं चाहता था। किसी ने भी DSL के लचीलेपन का उपयोग नहीं किया है। सभी उपयोगकर्ताओं ने सभी के रूप में एक ही गारंटीकृत कार्य विन्यास की प्रतिलिपि बनाई और चिपकाई।

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

सबक

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

अद्यतन:

जाहिर है, कई अभी भी सोचते हैं कि मैं किसी का मजाक बनाने की कोशिश कर रहा हूं। मेरे वास्तविक सहयोगियों को पता है कि मैं वास्तविक समस्याओं को ठीक करने में बहुत अधिक दिलचस्पी रखता हूं, और उन लोगों को दोष नहीं दे रहा हूं जिन्होंने इन समस्याओं को उत्पन्न किया है, लेकिन, ठीक है, यह वही है जो मैं इन परियोजनाओं में शामिल डेवलपर्स के बारे में सोचता हूं।

ईमानदारी से, पहली स्थिति स्पष्ट रूप से हुई क्योंकि सिस्टम वास्तुकार एक वास्तविक समस्या को हल करने की तुलना में वैज्ञानिक कार्य को लागू करने में अधिक रुचि रखते थे। हम में से कई को इसके लिए दोषी ठहराया जा सकता है (मुझे भी), लेकिन यह वास्तव में हमारे सहयोगियों को परेशान करता है। आखिरकार, जब हम किसी खिलौने से थक जाते हैं, तो उन्हें समर्थन में मदद करनी होगी। यदि आप अपने आप को पहचानते हैं, तो नाराज मत होइए, बस रुक जाइए (हालाँकि मैं अपने "XML डेटाबेस" के किसी भी सिस्टम के साथ एक नोड पर एक वितरित सिस्टम के साथ काम करना पसंद करूंगा)।

दूसरे उदाहरण में, व्यक्तिगत कुछ भी नहीं है। कभी-कभी ऐसा लगता है कि सभी लोग कहते हैं कि सेवाओं को साझा करना कितना शानदार है, लेकिन कोई भी इस बारे में बात नहीं करता है कि ऐसा करना बेहतर नहीं है। हर समय लोग अपने स्वयं के कड़वे अनुभव से सीखते हैं।

तीसरी कहानी वास्तव में मेरे साथ काम करने वाले कुछ सबसे चतुर लोगों के साथ हुई।

(अपडेट का अंत)।

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

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

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