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

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

1. कोई शुक्रवार जमा नहीं

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

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

2. नियमित बैकअप

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

संभवतः आपको 10 में से 9 बैकअप की आवश्यकता नहीं होगी। लेकिन एक दिन, जैसा कि मैं आज हूं, आप अतीत में लौटना चाहेंगे और यह पता लगाना चाहेंगे कि हमने यह असंगत लेकिन पूरी तरह से घातक गलती कैसे की है, जिस पर किसी का ध्यान नहीं गया! तब आपको खुशी होगी कि आपने बैकअप के लिए समय लिया। या, आप जानते हैं, जब एक नया कर्मचारी गलती से कोड की 100,000 लाइनों को हटा देता है। ऐसा होता है। हम लोगों के खिलाफ शिकायत नहीं रखते हैं, लेकिन गलतियों से सीखते हैं। यह कठिन है, भले ही बैकअप बनाओ!

3. विकास शुरू करने से पहले पूर्ण विनिर्देश प्राप्त करें

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

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

4. यदि आप महत्वहीन बकवास देखते हैं, तो ऐसा कहें

हाथ से निकलने से पहले अनुत्पादक चर्चाओं को धीरे से रोकने या रोकने की कोशिश करें। हमारे कार्यालय का समय लगभग उतना ही मूल्यवान है जितना कि 3-8 घंटे हम हर रात बेहोशी में बिताते हैं - यानी यह बहुत महत्वपूर्ण है! व्यापारिक दृष्टिकोण से, जितने अधिक लोग हैं, बैठक उतनी ही प्रभावी होनी चाहिए, क्योंकि प्रति घंटा वेतन एक कमरे / सम्मेलन कक्ष / आदि में 20-500 डेवलपर्स द्वारा गुणा किया जाता है। यह पागल पैसा है, विशेष रूप से धूप में कैलिफोर्निया में अपने वेतन के साथ। समय पैसा है! और हम इस पैसे को टेंटेकल के साथ राक्षसों के चारों ओर बौद्धिक चाल का आविष्कार करके काम कर रहे हैं जो प्रत्येक कोड बेस के पीछे छिपे हुए हैं और बस क्रूर कीड़े और दुर्घटनाओं के साथ निर्दोष उम्मीदों को तोड़ने का इंतजार करते हैं।

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

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

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