अनुवादक से:के बारे में जब KISS करने के लिए उपयुक्त है, और जब सूखी, जब बेहतर जितनी जल्दी हो सके और आसान के रूप में किसी भी तरह से समस्या को हल करने, और जरूरत पड़ने पर एक सुंदर और सार्वभौमिक अमूर्त बनाने के लिए बहस में प्रतियां का एक बहुत टूटे। ट्विटर पर इस्तेमाल किए जाने वाले लोकप्रिय स्टॉर्म फ्रेमवर्क के लेखक नाथन मार्त्ज अपना स्वयं का संस्करण प्रदान करते हैं। अमूर्त सार्वभौमिकता की खातिर टन बेकार कोड बनाने के लिए और एक ही समय में सिस्टम को बैसाखी में बदलने की अनुमति नहीं देने के लिए, वह "दुख के माध्यम से विकास" (पीड़ित उन्मुख प्रोग्रामिंग) का उपयोग करता है।
एक बार मुझसे पूछा गया था: "आपने इतना भयानक जोखिम लेने का फैसला कैसे किया -
स्टार्टअप शुरू करने के साथ ही स्टॉर्म लिखिए?" (
स्टॉर्म वास्तविक समय में वितरित कंप्यूटिंग के लिए एक रूपरेखा है)। हां, शायद, एक स्टार्टअप के लिए इतने बड़े प्रोजेक्ट का निर्माण बेहद जोखिम भरा है। हालांकि, मेरे दृष्टिकोण से, यह बिल्कुल भी जोखिम भरा व्यवसाय नहीं था। मुश्किल है, लेकिन जोखिम भरा नहीं है।
मैं एक विकास शैली का उपयोग करता हूं जो स्टॉर्म जैसी बड़ी परियोजनाओं के जोखिम को कम करता है। मैं इस शैली को "दुख के माध्यम से विकास" कहता हूं। संक्षेप में: उन तकनीकों को लागू न करें जिन्हें आप की कमी से ग्रस्त नहीं हैं। यह सलाह बड़े, वास्तु समाधान और छोटे रोजमर्रा के कार्यों दोनों पर लागू होती है। पीड़ितों के माध्यम से विकास करना जोखिम को कम करता है, यह सुनिश्चित करता है कि आप हमेशा कुछ महत्वपूर्ण काम कर रहे हैं और समाधान में बहुत प्रयास करने से पहले आप विषय क्षेत्र में अच्छी तरह से वाकिफ हैं।
मैं इस विकास मंत्र के साथ आया: “पहले, इसे पूरा करो। फिर - सुंदर होने के लिए। फिर - जल्दी होने के लिए। ”
बनवा लो
एक नए विषय क्षेत्र के साथ सामना करना, "सामान्य" या "एक्स्टेंसिबल" समाधान बनाने की कोशिश करना शुरू से ही असंभव है। आप बस इस समस्या को अच्छी तरह से समझ नहीं पाते हैं कि आपको भविष्य में क्या चाहिए। आप सामान्यीकरण करते हैं जहां यह आवश्यक नहीं है, जटिलता और समय बर्बाद कर रहा है।
सभी समस्याओं को "सिर पर" हल करना बेहतर है, संभवतः बैसाखी और गंदे हैक के साथ, केवल आज की देखभाल करना। यह आपको जल्दी से परिणाम प्राप्त करने और व्यर्थ में समय बर्बाद नहीं करने की अनुमति देता है। और इस प्रक्रिया में, आप विषय क्षेत्र की जटिलताओं के बारे में अधिक से अधिक सीखेंगे।
स्टॉर्म के लिए डू-इट-ही चरण लगभग एक वर्ष तक चला। परीक्षण और त्रुटि से, हमने कतार और प्रक्रियाओं के साथ संदेश प्रवाह के प्रसंस्करण के लिए एक प्रणाली बनाई। हमने गारंटी डेटा प्रोसेसिंग के लिए पुष्टिकरण तंत्र का उपयोग करना सीखा। हमने सीखा है कि कतारों और प्रक्रियाओं के समूहों पर वास्तविक समय की गणना कैसे की जाए। हमने सीखा कि अलग-अलग मामलों में संदेश प्रवाह को अलग-अलग तरीकों से विभाजित करना बेहतर होता है, कभी-कभी दुर्घटना से, और कभी-कभी हैश द्वारा, ताकि एक ही प्रक्रिया द्वारा समान संस्थाओं को संसाधित किया जा सके।
हमें यह भी एहसास नहीं था कि हम "यह स्वयं करें" चरण के बीच में थे। हमने सिर्फ अपना प्रोडक्ट लिखा। हालांकि, दर्द जो लाइनों और प्रक्रियाओं ने हमें जल्दी से भड़काया, तीव्र हो गया। स्केलिंग एक भयानक परेशानी थी, और विश्वसनीयता सही स्तर से बहुत दूर थी। यह स्पष्ट हो गया कि कतारों और प्रक्रियाओं का हमारा प्रतिमान गलत था और अमूर्तता के गलत स्तर का इस्तेमाल किया। हमारे अधिकांश कोड व्यावसायिक तर्क के बजाय संदेश मार्ग और क्रमांकन पर केंद्रित हैं।
उसी समय, विकास प्रक्रिया के दौरान, हमने विषय क्षेत्र में नए कार्यों की खोज की। हमें एक फ़ंक्शन की आवश्यकता थी, जिसने ट्विटर पर URL की पहुंच की गणना की, अर्थात्, इस URL को देखने वाले अद्वितीय उपयोगकर्ताओं की संख्या। यह एक जटिल कार्य है जिसमें सैकड़ों डेटाबेस एक्सेस और लाखों ऑपरेशन की आवश्यकता हो सकती है। एक ही मशीन पर चलने वाला एक प्रारंभिक कार्यान्वयन एकल URL को संसाधित करने में एक मिनट से अधिक समय ले सकता है। यह स्पष्ट हो गया कि आपको जल्दी से काम करने के लिए एक वितरित वातावरण में कंप्यूटिंग को समानांतर करने की आवश्यकता है।
तूफान के पीछे एक महत्वपूर्ण विचार यह था कि "कवरेज समस्या"
और "संदेश प्रवाह प्रसंस्करण" की समस्या को एक साधारण अमूर्तता में जोड़ा जा सकता है।
इसे सुंदर बनाओ
विषय क्षेत्र में "युद्ध में सामंजस्य" आपको इसका नक्शा बनाने की अनुमति देता है। समय के साथ, बारीकियों और वास्तविक उपयोग के मामलों की एक गहरी समझ आती है। यह समझ मौजूदा "बैसाखी" के बजाय एक सुंदर समाधान के निर्माण का कारण बन सकती है, जो पीड़ा को बुझाएगी और नए कार्यों या प्रणालियों को बनाने के लिए संभव बनाती है जो पहले नहीं पहुंच सकती थीं।
एक सुंदर प्रणाली की खोज करने के लिए महत्वपूर्ण सार
का सबसे सरल सेट निर्धारित
करना है जो आपके साथ काम कर रहे सभी विशिष्ट समस्याओं को हल करने के लिए पर्याप्त है। आपके द्वारा सामना नहीं किए गए काल्पनिक मामलों की भविष्यवाणी करने की कोशिश करना एक त्रुटि है जो ओवर-इंजीनियरिंग के लिए अग्रणी है। सामान्य तौर पर, बड़ी प्रणाली, विषय क्षेत्र को समझने के लिए जितनी अधिक गहराई से आवश्यक है और उपयोग के मामलों का सेट उतना ही बहुमुखी होना चाहिए। अन्यथा, आप
दूसरी प्रणाली के
प्रभाव के संपर्क में आ सकते हैं।
यह "मेक इट ब्यूटीफुल" चरण में है कि आप अपने अमूर्त और डिजाइन कौशल पर मुफ्त लगाम दे सकते हैं ताकि सामंजस्यपूर्ण सरल संयोजनों के संयोजन को उजागर किया जा सके। यह एक ग्राफ पर अंकों के एक सेट (आपके उपयोग के मामलों) को सरलतम गणितीय फ़ंक्शन (आपके सार का सेट) के साथ अनुमानित करने के समान है।
ग्राफ़ पर जितने अधिक बिंदु हैं, उतनी ही अधिक संभावना है कि आप इष्टतम वक्र पाएंगे। यदि बहुत कम बिंदु हैं, तो जोखिम यह है कि आपका वक्र या तो वास्तविक डेटा का बहुत खराब वर्णन करेगा या इसका सूत्र बहुत जटिल होगा। और यह समय और प्रयास का अनावश्यक नुकसान है।
एक सुंदर समाधान के लिए एक बहुत महत्वपूर्ण शर्त प्रदर्शन और संसाधन आवश्यकताओं को याद रखना है। इसके लिए आवश्यक ज्ञान पहले चरण के दौरान ठीक दिखाई देता है।
स्टॉर्म पर काम करते हुए, मैंने मुख्य सार के एक छोटे से सेट पर प्रकाश डाला: धाराएँ, टोंटी, बोल्ट और टोपोलॉजी। मैं एक नया गारंटीकृत डेटा प्रोसेसिंग एल्गोरिथ्म विकसित करने में सक्षम था जिसने मध्यवर्ती संदेश दलालों को बचाया - उस प्रणाली का हिस्सा जो सबसे अधिक पीड़ित था। तथ्य यह है कि दो समस्याएं जो पहली नज़र में इतनी अलग थीं, जैसे कि कवरेज की समस्या और संदेश प्रवाह के प्रसंस्करण को एक तरह से इतनी आसानी से हल किया गया था, कि मुझे कुछ उत्कृष्ट लगा।
मैंने डिजाइन का परीक्षण करने के लिए कुछ और उपयोग के मामलों की तलाश की। मैंने कुछ परिचित प्रोग्रामरों से पूछा और ट्वीट किया कि मैं एक नए रीयल-टाइम सिस्टम पर काम कर रहा था और वास्तविक दुनिया के उपयोग के मामलों में रुचि रखता था। बहुत सारी दिलचस्प चर्चाएँ हुईं, मुझे बहुत सारी बहुमूल्य जानकारी मिली और यह सुनिश्चित किया कि मेरा विचार काम करे।
इसे जल्दी करो
आपके द्वारा एक सुंदर समाधान बनाने में कामयाब होने के बाद, आप प्रोफाइलिंग और अनुकूलन के साथ आगे बढ़ सकते हैं।
"इसे तेज़ बनाओ" चरण गहरी वास्तु प्रदर्शन के मुद्दों को संबोधित नहीं करता है। पहले चरण के दौरान उनके बारे में सीखना और दूसरे के दौरान उनके साथ व्यवहार करना आवश्यक था। अब हम माइक्रो-ऑप्टिमाइज़ेशन और कोड को "चाट" करने के बारे में बात कर रहे हैं। पहले दो चरणों के दौरान एल्गोरिदम की असममित जटिलता को कम करना आवश्यक है, तीसरे के दौरान - गति को प्रभावित करने वाले स्थिरांक को कम करने के लिए।
कुल्ला और दोहराएँ
दुख के माध्यम से विकास एक सतत प्रक्रिया है। एक सुंदर और प्रभावी प्रणाली नई संभावनाओं को खोलती है और नए कार्यों को प्रस्तुत करती है, जिसका अर्थ है कि आपको नए क्षेत्रों में फिर से "सुनिश्चित" करना होगा और चार्ट पर नए बिंदुओं के अनुरूप करने के लिए प्राप्त जानकारी के आधार पर डिजाइन को बदलना होगा।
तूफान ऐसे कई पुनरावृत्तियों से गुजरा। जब हमने इसका उपयोग करना शुरू किया, तो एक घटक से कई स्वतंत्र थ्रेड उत्पन्न करने की आवश्यकता थी। यह पता चला कि यदि आप एक विशेष प्रकार की धारा "डायरेक्ट स्ट्रीम" जोड़ते हैं, तो स्टॉर्म एक पूरे के रूप में रिकॉर्ड पैकेट को संसाधित करने में सक्षम होगा। हाल ही में, मैंने "ट्रांसेक्शनल टोपोलॉजीज़" विकसित किया है जो व्यावहारिक रूप से मनमाने ढंग से गणना में संदेशों की एक सख्ती से प्रसंस्करण की गारंटी देता है।
विषय क्षेत्र में परीक्षण और त्रुटि की विधि, जिसे आप बहुत अच्छी तरह से नहीं समझते हैं, परिभाषा के अनुसार कोड में गड़बड़ होती है। इसलिए, पीड़ित के माध्यम से विकास की सबसे महत्वपूर्ण विशेषता रिफ्लेक्टरिंग पर निरंतर ध्यान केंद्रित करना है। यह
आकस्मिक जटिलता को कोड
को बाढ़ने
से रोकने के लिए महत्वपूर्ण है।
निष्कर्ष
दुख के माध्यम से विकास में, उपयोग के मामले सभी हैं। वे सोने में इसके वजन के लायक हैं। और उन्हें प्राप्त करने का एकमात्र तरीका कोड लिखना शुरू करना है, और कोई फर्क नहीं पड़ता कि यह पहले से कितना सुंदर है।
सभी प्रोग्रामर विकास के कई चरणों से गुजरते हैं। सबसे पहले, हम प्रोग्राम को किसी तरह काम करते हैं। कोड किसी भी संरचना से रहित है और कॉपी-पेस्ट से भरा है। समय के साथ, हम एक अधिक संरचित दृष्टिकोण के लाभों को समझते हैं, इनकैप्सुलेशन और तेजी से अमूर्त और सामान्यीकृत निर्माणों में महारत हासिल करते हैं। और फिर हम भविष्य के लिए सुरक्षित होने के नाते, सबसे सामान्य और एक्स्टेंसिबल कोड को लिखने की इच्छा से ग्रस्त हो जाते हैं।
पीड़ित के माध्यम से विकास पद्धति उन समस्याओं का अनुमान लगाने का प्रयास करती है, जिनका आप अभी तक सामना नहीं कर पाए हैं। वह स्वीकार करती है कि विषय क्षेत्र की गहरी समझ के बिना सामान्यीकरण अत्यधिक जटिलता और खोए हुए प्रयास को जन्म देता है। आर्किटेक्चर को हमेशा वास्तविक, आविष्कार नहीं, आवश्यकताओं के अधीन होना चाहिए।