चीजें जो हम बाद में करना चाहते हैं

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



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

यदि आप मेरी रेक पर नहीं चलना चाहते हैं, तो बिल्ली का स्वागत करें।

डेटाबेस

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

सूचकांक और बाधाएं

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

समय-समय पर, डेटाबेस में JSON या XML छड़ी करने की इच्छा होती है ताकि दृश्य को परत में जल्दी से स्थानांतरित किया जा सके। विचार अपने तरीके से अच्छा है, लेकिन इस तरह से शास्त्रीय एसक्यूएल समाधान की मुख्य ताकत खो गई है। जल्दी या बाद में आपको इस मुद्दे को हल करने के लिए कहा जाएगा और यह अप्रिय होगा। मुझे JSON चाहिए - आसानी से। मोंगा या कुछ और न लें- sql'e और चुनें कि आप डेटा अखंडता या पहुंच की गति को क्या महत्व देते हैं।

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

एप्लिकेशन परतें और यूनिट टेस्ट

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

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

अशक्त संदर्भ या रक्षात्मक प्रोग्रामिंग

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

आवेदन टांके और एसआरपी

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

वेब सर्वर स्केलिंग

सर्वर क्षमता को लगातार बढ़ाना संभव नहीं है। जल्दी या बाद में आप चैनल क्षमताओं में चलेंगे। और यहाँ अचानक सभी स्टैटिक वैरिएबल जो आपने सीधे इस्तेमाल किए थे, पॉप अप होंगे। सामान्य तौर पर, सभी स्तरों पर सिस्टम की क्षैतिज स्केलिंग एक ऐसी चीज है जिसके बारे में आपको पहले से सोचने की जरूरत है। और यहां फिर से, आप अभी भी स्टीम बाथ नहीं ले सकते हैं और स्टैटिक वैरिएबल पर तब तक लिख सकते हैं जब तक कि आप दूसरा सर्वर न डालें। एक दिया लेकिन इन सभी गंदी चीजों को अपने IDataProvier या IProblemResolver के अंदर करें। फिर आपको केवल एक वर्ग बदलना होगा, और पूरे कोड में परिवर्तन नहीं एकत्र करना होगा।

DevOps

और हम इसे कैसे तैनात करेंगे? ठीक है, मैं सभी को तैनात कर रहा हूं, लेकिन मैंने कंप्यूटर को नहीं बदला, ओएस को फिर से स्थापित किया और अन्य बकवास किया। और नए डेवलपर्स के बारे में क्या? खैर, वे प्रोग्रामर हैं, यह उनका काम है, उन्हें इसका पता लगाना होगा। इसमें से किसी को भी प्रलेखित करने की आवश्यकता नहीं है, और इससे भी अधिक, इसे लागू करने के लिए कोई अतिरिक्त प्रयास करने की आवश्यकता नहीं है।

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

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

मल्टीथ्रेडेड प्रोग्रामिंग

क्या आप वाकई मल्टी-थ्रेडेड कोड लिख सकते हैं? क्या आप सुनिश्चित हैं कि आपको इसकी आवश्यकता है? जहां भी आप मल्टी-थ्रेडेड कोड नहीं लिख सकते हैं, कृपया इसे न लिखें। दिलचस्प कूल हाँ। और यहां तक ​​कि, शायद, आपके मशीन पर कुछ डेटा सेट पर, यह सही ढंग से काम करता है। मल्टी-थ्रेडेड प्रोग्रामिंग ज्ञान का एक पूरी तरह से अलग क्षेत्र है, और बहु-थ्रेडेड एप्लिकेशन लिखना एकल-थ्रेडेड लोगों की तुलना में बहुत अधिक कठिन है। बिल्कुल सही कैसे डिबग करने के लिए। अपने आप को और अपने सहयोगियों को बचाने के लिए।

ऐसा लगता है कि चीजें सरल हैं। उन्होंने इस सब के बारे में बात की। हालांकि, यह वह है जो मुझे अपने दैनिक कार्यों में सबसे अधिक समस्याएं देता है।