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

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

मैंने एक अग्रणी प्रोग्रामर के बगल में एक साल बिताया। यही मैंने सीखा है।

सामग्री

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

कोड लेखन

कोड में चीजों को कैसे नाम दें

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


कोड का प्रत्येक टुकड़ा जिसे मैंने नाम दिया है, एक निहित उद्देश्य प्राप्त किया है। GodComponent यह वह घटक है जिसे सभी बकवास मिलते हैं जो मैं सही जगह पर नहीं रखना चाहता। इसमें सब कुछ समाहित है। इसे LayoutComponent नाम LayoutComponent , और भविष्य में मैं तय करूंगा कि यह घटक एक लेआउट प्रदान करता है। कि इसमें राज्य नहीं है।

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

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

यही बात फ़ंक्शंस पर लागू होती है। doEverything() कई परिणामों के साथ एक भयानक नाम है। यदि फ़ंक्शन सब कुछ करता है, तो इसके व्यक्तिगत भागों का परीक्षण करना मुश्किल होगा। यह फ़ंक्शन कितना भी बड़ा हो जाए, यह आपको कभी भी अजीब नहीं लगेगा, क्योंकि इसे सब कुछ करना चाहिए। इसलिए नाम बदलो। Otrefaktorte।

एक सार्थक नाम का एक नकारात्मक पहलू है। अचानक नाम बहुत सार्थक हो जाएगा और किसी तरह की बारीकियों को छिपाएगा? उदाहरण के लिए, सत्र बंद करने पर डेटाबेस कनेक्शन बंद नहीं होता है जब session.close() SQLAlchemy में कहा जाता है। मुझे दस्तावेज़ को पढ़ना चाहिए और इस बग को रोकना चाहिए, बाइक अनुभाग में इसके बारे में अधिक।

इस दृष्टिकोण से, count() , close() , insertIntoDB() बजाय x , y , z रूप में नामकरण फ़ंक्शन हमें उन में एक निश्चित अर्थ लगाने की अनुमति नहीं देता है और मुझे ध्यान से निगरानी करता है कि ये कार्य क्या करते हैं। ²

मैंने कभी नहीं सोचा था कि मैं एक पंक्ति से अधिक पाठ के नामकरण के सिद्धांतों के बारे में लिखूंगा।

इनहेरिटेड कोड और अगले डेवलपर

क्या आपने कभी कोड को देखा है और यह आपको अजीब लगता है? आपने ऐसा क्यों लिखा? इसका कोई मतलब नहीं है।

मुझे विरासत में मिले कोड बेस के साथ काम करने का मौका मिला। यह, आप जानते हैं कि "मोहम्मद की स्थिति को समझने पर कोड को रद्द करें" जैसी टिप्पणियों के साथ। आप यहाँ क्या कर रहे हैं? कौन है मुहम्मद?

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

यदि मैं इस कोड को भूल जाता हूं, तो बाद में वापस आ जाता हूं और संदर्भ को बहाल नहीं कर सकता, मैं कहूंगा: “उन्होंने क्या किया? यह बेवकूफी है ... आह, रुको, मैंने यह किया। "

और यहाँ कोड में प्रलेखन और टिप्पणियां खेलने में आती हैं।

प्रलेखन और कोड में टिप्पणी

वे संदर्भ और ज्ञान को बनाए रखने में मदद करते हैं। जैसा कि ली ने कहा कि कैसे अच्छा सॉफ्टवेयर बनाने के लिए :

सॉफ्टवेयर का मुख्य मूल्य निर्मित कोड में नहीं है, बल्कि इस सॉफ़्टवेयर को बनाने वाले लोगों द्वारा संचित ज्ञान में है

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

जहां तक ​​मुझे पता है, प्रत्येक टीम प्रलेखन के साथ लड़ रही है। और प्रलेखन के साथ, न केवल कोड द्वारा, बल्कि इसके साथ जुड़ी प्रक्रियाओं द्वारा भी।

हम अभी तक सही समाधान के साथ नहीं आए हैं। व्यक्तिगत रूप से, मुझे जिस तरह से एंटीरेज़ ने टिप्पणियों को विभिन्न प्रकार के मूल्यों में कोड में विभाजित किया है ।

परमाणु करता है

यदि आपको वापस रोल करने की आवश्यकता है (और आपको इसकी आवश्यकता है। परीक्षण अध्याय देखें), क्या यह एकल मॉड्यूल के रूप में समझ में आएगा?

कैसे आसानी से घटिया कोड को हटाने के लिए

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

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

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

कोड समीक्षा

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

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

मेरे अनुभव में, आपको कोड को तब तक मंजूर नहीं करना है जब तक मैं यह नहीं समझता कि यह कैसे काम करता है।


मेरे गितुब आँकड़े।

परीक्षण

मुझे परीक्षण से इतना प्यार हो गया कि बिना किसी परीक्षण के कोड बेस में लिखना मेरे लिए अप्रिय है।

यदि आपका आवेदन केवल एक ही काम करता है (जैसे मेरे सभी स्कूल प्रोजेक्ट), तो आप अभी भी मैन्युअल रूप से परीक्षण कर सकते हैं। ⁴ यही मैंने किया है। लेकिन क्या होता है अगर कोई एप्लिकेशन 100 अलग-अलग कार्य करता है? मैं आधे घंटे का परीक्षण नहीं करना चाहता, और कभी-कभी मुझे किसी चीज़ की दृष्टि खोनी पड़ती है। एक बुरा सपना।

टेस्ट और टेस्ट ऑटोमेशन यहां मदद करते हैं।

मैं परीक्षण को प्रलेखन के रूप में मानता हूं। यह कोड के बारे में मेरे विचारों का प्रलेखन है। टेस्ट मुझे बताते हैं कि मैं (या मुझसे पहले कोई और) कैसे कोड के काम की कल्पना करता है और जहां कुछ गलत होने की उम्मीद करनी चाहिए।

आज, जब मैं परीक्षण लिखता हूं, तो मैं कोशिश करता हूं:

1. टेस्ट क्लास, फ़ंक्शन या सिस्टम का उपयोग करने का तरीका दिखाएं।
   
2. मेरे विचार से, गलत हो सकता है।
   

नतीजतन, सबसे अधिक बार मैं व्यवहार का परीक्षण करता हूं, लेकिन कार्यान्वयन नहीं ( यहां एक उदाहरण है जिसे मैंने Google पर ब्रेक के दौरान चुना था)।

पैराग्राफ 2 में, मैंने बग के स्रोतों का उल्लेख नहीं किया है।

जब मैं एक बग को नोटिस करता हूं, तो मैं यह सुनिश्चित करता हूं कि जानकारी को दस्तावेज करने के लिए फिक्स का एक उपयुक्त परीक्षण (इसे प्रतिगमन परीक्षण कहा जाता है)। यह एक और कारण है कि कुछ गलत हो सकता है। ⁵

बेशक, मेरे कोड की गुणवत्ता में सुधार होता है क्योंकि मैं परीक्षण लिखता हूं, लेकिन इसलिए कि मैं कोड लिखता हूं। लेकिन परीक्षणों को पढ़ने से मुझे बेहतर परिस्थितियों को समझने और बेहतर कोड लिखने में मदद मिलती है।

परीक्षण के साथ यह सामान्य स्थिति है।

लेकिन यह एकमात्र ऐसा परीक्षण नहीं है जो मैं लागू करता हूं। मैं तैनाती के वातावरण के बारे में बात कर रहा हूं। आपके पास आदर्श इकाई परीक्षण हो सकते हैं, लेकिन यदि आपके पास सिस्टम परीक्षण नहीं हैं, तो ऐसा कुछ हो सकता है:



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

• ऐसी मशीनें हैं जिन्हें आप विकसित कर रहे हैं ("मेरे कंप्यूटर पर काम किया!" जैसे सभी मेमों का स्रोत)।
  
• ऐसी मशीनें हैं जिन पर आप परीक्षण कर रहे हैं (पिछले वाले के साथ मेल खा सकते हैं)।
  
• अंत में, ऐसी मशीनें हैं जिन पर आप तैनाती कर रहे हैं (उन्हें उन मशीनों के साथ मेल नहीं खाना चाहिए, जिन पर आपने विकास किया था)।
  

यदि परीक्षण और परिनियोजन वातावरण मशीनों पर मेल नहीं खाते हैं, तो आपको समस्याएँ होंगी। परिनियोजन वातावरण इससे बचने में मदद करेगा।

हम अपने कंप्यूटर पर डॉकर में स्थानीय विकास कर रहे हैं।

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

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

आप विकास और संचालन के लिए अलग-अलग समूहों को कॉन्फ़िगर कर सकते हैं। AWS ECS को तैनात करने के लिए Docker छवियों का उपयोग करता है, इसलिए विभिन्न वातावरणों में प्रक्रिया अपेक्षाकृत संगत होगी। विभिन्न AWS सेवाओं के बीच एकीकरण के संदर्भ में बारीकियाँ हैं। क्या आप सही वातावरण से सही समापन बिंदु कह रहे हैं?

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

जोखिम में कमी

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

आर्किटेक्चर

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

आर्किटेक्चर बनाते समय आपको बहुत सोचने की जरूरत है।

• नंबरों का उपयोग कैसे किया जाएगा?
  
• कितने उपयोगकर्ता होंगे? उनकी संख्या कितनी बढ़ सकती है (डेटाबेस में पंक्तियों की संख्या इस पर निर्भर करती है)?
  
• क्या रीफ्स मिल सकते हैं?
  

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

• स्थानीय विकास कैसे आगे बढ़ेगा?
  
• हम कैसे पैक और तैनात करेंगे?
  
• हम अंत-से-अंत परीक्षण कैसे करेंगे?
  
• हम नई सेवा का तनाव परीक्षण कैसे करेंगे?
  
• हम रहस्य कैसे रखेंगे?
  
• CI / सीडी एकीकरण?
  

हमने हाल ही में BNEF के लिए एक नया खोज इंजन विकसित किया है। उस पर काम करना अद्भुत था, मैंने एक स्थानीय विकास का आयोजन किया और डीपीजी (पैकेज और उनकी तैनाती) के बारे में पता लगाया, रहस्यों की तैनाती को देखते हुए।

किसने सोचा होगा कि एक ठिकाने पर रहस्य को तैनात करना इतना nontrivial हो सकता है:

1. उन्हें कोड में नहीं रखा जा सकता, क्योंकि कोई उन्हें नोटिस कर सकता है
   
2. एक पर्यावरण चर के रूप में उन्हें स्टोर करने के लिए कल्पना के रूप में 12 आवेदन कारक प्रदान करता है? एक बुरा विचार नहीं है, लेकिन उन्हें वहां कैसे रखा जाए? (हर बार कार शुरू होने पर पर्यावरण चर में भरने के लिए ठेस पर जाना एक दर्द है)
   
3. उन्हें फ़ाइलों के रूप में तैनात करें? लेकिन वे कहां से आएंगे और उन्हें कैसे भरना होगा?
   

हम सब कुछ मैन्युअल रूप से नहीं करना चाहते हैं।

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

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

हम रखरखाव नहीं भूल, वास्तुकला बनाते हैं

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

मैं गिरावट की दर को कम करने के लिए कम से कम तीन तरीके जानता हूं।

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

परिनियोजित

क्या मैं एक बार में एक साथ फीचर पैक कर सकता हूँ या उन्हें तैनात कर सकता हूँ? वर्तमान प्रक्रिया के आधार पर, यदि आप उन्हें एक साथ पैक करते हैं, तो परेशानी का इंतजार करें। अपने आप से पूछें कि आप सुविधाओं को एक साथ क्यों पैक करना चाहते हैं?

• तैनाती में बहुत समय लगता है?
  
• क्या कोड की समीक्षा बहुत मजेदार नहीं है?
  

कारण जो भी हो, इस स्थिति को ठीक करने की आवश्यकता है। मुझे पता है कि पैकेजिंग से जुड़ी दो समस्याएं हैं:

1. यदि आप उनमें से एक बग है, तो आप स्वयं सभी सुविधाओं को अवरुद्ध करते हैं।
   
2. आप समस्याओं का खतरा बढ़ाते हैं।
   

आप जो भी तैनाती प्रक्रिया चुनते हैं, आप हमेशा चाहते हैं कि आपकी कारें पशुओं की तरह रहें, पालतू जानवरों की तरह नहीं। वे अद्वितीय नहीं हैं। आपको पता है कि प्रत्येक मशीन पर क्या निष्पादित होता है, मृत्यु के मामले में उन्हें फिर से कैसे बनाया जाए। आप परेशान नहीं होंगे यदि कोई कार मर जाती है, तो आप बस एक नया उठाते हैं। तुम उन्हें चरते हो, बढ़ते नहीं।

जब कुछ गलत होता है

मामले में कुछ गलत हो जाता है - और यह है - एक सुनहरा नियम है: ग्राहकों पर प्रभाव को कम से कम। विफलताओं के मामले में, मेरी पहली इच्छा हमेशा इसे ठीक करने की थी। यह इष्टतम समाधान नहीं लगता है। फिक्सिंग के बजाय, भले ही यह एक पंक्ति में किया जा सकता है, आपको पहले वापस रोल करने की आवश्यकता है। पिछले ऑपरेटिंग स्थिति पर लौटें। यह काम करने वाले संस्करण में ग्राहकों को वापस करने का सबसे तेज़ तरीका है। तभी मुझे पता चलता है कि समस्या क्या है और इसे ठीक करें।

वही आपके क्लस्टर में "क्षतिग्रस्त" मशीन पर लागू होता है: इसे बंद करें, इसे दुर्गम के रूप में चिह्नित करें, इससे पहले कि यह क्या हुआ है। मुझे यह अजीब लगता है कि मेरी प्राकृतिक इच्छा और सहज ज्ञान कितना इष्टतम समाधान के विपरीत है।

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

तब से मैंने "पहले चौड़ाई" में खोज करना सीख लिया है, और इसलिए ऊपरी स्तर के कारणों को बाहर करने के लिए पहले से ही "गहराई में पहले"। वर्तमान संसाधनों से मैं वास्तव में क्या पुष्टि कर सकता हूं?

• कार का काम करता है?
  
• क्या कोड सही तरीके से स्थापित है?
  
• क्या कोई कॉन्फ़िगरेशन है?
  
• <कोड-विशिष्ट कॉन्फ़िगरेशन>, जैसे कि रूटिंग को सही ढंग से वर्तनी दी गई है?
  
• क्या स्कीमा संस्करण सही है?
  
• और फिर मैंने कोड में डुबकी लगाई।
  

हमने सोचा था कि नाज़िनक्स गलत तरीके से स्थापित किया गया था, लेकिन यह निकला कि कॉन्फ़िगरेशन केवल अक्षम था

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

बेज

यह लेख एक कहानी के बिना पूरा नहीं हो सकता। , . SQLAlchemy. BNEF , . . SQLAlchemy, , Solr. - .

«MYSQL server has gone away.» . , , . , . , . , ?

, ? , , . , , __exit__() session.close() .

, , . . . . .

Session.close() MySQL- SQLAlchemy , NullPool. . , , . : StackOverflow (, !) , , SQL- . , . , , (), .

«» , 1 8. , , — .

, .

निगरानी

, . , , . , .

, , , . , . , . « ?! , ? ».

, : , . , , . , , . , . — ? , , . . , -, , , , , .. .

. , , ? (, AWS CloudWatch Grafana). .

. , , 50 %, — . ? . , — (, ?).

. , , , , ? ? , ?

, . , . — - .

निष्कर्ष

. , , , . , - !

. , !

, . , — How to Build Good Software .

. : ! , .

1. ?
   
2. ? , ? , ?
   
3. . , ? ?
   
4. (utils) (, , , ) , « »?
   
5. ?
   
6. , , - ?
   
7. — API , ?
   
8. ? , .
   
9. , , . , , .
   
10. PR: « , , 52 , , , , , ». ?
    
11. . ?
    
12. ?
    
13. ?
    

1. . , ? - ? , ?
   
2. , x() , y() z(), x() , y() z() . , WYSIATI .
   
3. .
   
4. . , ?
   
5. , - , , . , .
   
6. , , Docker- AWS.
   
7. .