आशावादी प्रोग्रामर

हम प्रोग्रामर आशावादी हैं। यह पूरे सॉफ्टवेयर डेवलपमेंट चक्र में डेडलाइन के मूल्यांकन से लेकर कोड और कार्यान्वयन तक स्पष्ट है। जैसा कि मेरे अभ्यास से पता चलता है, सॉफ्टवेयर विकास में मर्फी के कानून 100% मामलों में काम करते हैं। इसके बावजूद, मैं बार-बार "आशावादी प्रोग्रामर" पर आता हूं।

शीर्ष आशावादी धारणाएँ:

हम अभी भी इस सप्ताह शुक्रवार को शाम 5:48 बजे जारी कर सकते हैं, हालांकि कोड में त्रुटियां हैं।

नहीं, आप नहीं कर सकते त्रुटियों को ठीक करने के अलावा, आपको निम्न करने की आवश्यकता है:

1. इस कोड को दबाए रखें (आप उस शाखा में विकास नहीं करते हैं जहाँ से आप उत्पादन में प्रकाशित करते हैं, ठीक है?)
2. प्रतिगमन सहित एक परीक्षण बेंच और परीक्षण पर कोड प्रकाशित करें
3. कॉन्फ़िगरेशन, डेटाबेस माइग्रेशन की जाँच करें
4. उत्पादन बचाओ
5. परिवर्तन पोस्ट करें
6. परीक्षण उत्पादन
7. अगर कुछ गलत हुआ हो तो उसे वापस करें

यहां तक ​​कि अगर सब कुछ स्वचालित मोड में होता है, तो आपके पास काम करने का दिन खत्म होने से 12 मिनट पहले ही पर्याप्त होगा। आमतौर पर, इस तरह की गणना जल्दी और अंत में उत्पादन, रात में और / या सप्ताहांत पर प्रसंस्करण, पिछली रिलीज के रोलबैक और गणना के हस्तांतरण, या इन बिंदुओं के संयोजन के साथ होती है।

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

इसमें तीन दिन लगते हैं। क्या आप इसे एक दिन में कर सकते हैं? खैर, शायद मैं कर सकता हूँ

प्रबंधकों के साथ पालन न करें। प्रबंधक, यहां तक ​​कि तकनीकी पृष्ठभूमि के साथ, सभी ins और बहिष्कार नहीं जानता है। एक साधारण और त्वरित प्रबंधक की तरह क्या लग सकता है वास्तव में बहुत अधिक समय लग सकता है। प्रबंधक हमेशा एक नई सुविधा को लागू करने की केवल श्रमशीलता का मूल्यांकन करता है। आपका कार्य इस बात पर जोर देना है कि आपको रिफैक्टिंग, परीक्षण, गणना के लिए समय चाहिए। प्रबंधन के नेतृत्व के बाद, बार-बार आप तकनीकी ऋण को स्थगित कर देंगे जब तक कि यह इतना जमा नहीं हो जाता है कि आपको पता नहीं चलेगा कि रिफैक्टिंग के लिए कौन सा तरीका है। आवश्यकताएँ बदल रही हैं, कोई भी तुरंत सही कोड नहीं लिख सकता है, कोई आवश्यकता से अधिक नहीं और कम नहीं। यदि आपको लगता है कि इस जगह में बैसाखी भविष्य में दिनों और हफ्तों के लिए आती है, तो बेहतर है कि अब कुछ घंटे बिताएं और थोड़ी देर बाद इस सुविधा को पारित करें। इसे प्रबंधक को उसकी भाषा में समझाएँ: अब इस रिफैक्टरिंग की कीमत हमें 8 बजे होगी। और अगर हम बैसाखी डालते हैं, तो एक महीने में हमारे तकनीकी ऋण में 56 घंटे लगेंगे। प्रबंधक आमतौर पर अच्छी तरह से गिनती करते हैं, और आसानी से आपकी दर पर घंटों की संख्या को गुणा करते हैं। याद रखें कि आपके अलावा कोई भी कोड को बेहतर नहीं जानता है, इसलिए आप बेहतर जानते हैं कि तकनीकी पक्ष पर बेहतर कैसे करें। आप लेख में प्रबंधन के दबाव के बारे में अधिक पढ़ सकते हैं " दो सप्ताह कैसे होते हैं!" "।

ओह, यह बहुत बेवकूफ बग है, अब मैं इसे जल्दी से ठीक कर दूंगा और यह काम करेगा। कुछ भी नहीं लिखने के लिए परीक्षण करें

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

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

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

आप इस परिवर्तन को परीक्षण स्टैंड में प्रकाशित नहीं कर सकते, यह मेरी स्थानीय मशीन पर ठीक काम करता है। रनिंग टेस्ट भी समय की बर्बादी है, यहाँ सब कुछ इतना सरल है

नहीं, हमेशा "लक्ष्य" पर्यावरण / हार्डवेयर पर, सबसे पहले परीक्षण करें। कोई भी अनुकरण सिर्फ एक मॉडल है। वास्तविक परिस्थितियों में, अप्रत्याशित परिस्थितियां उभर सकती हैं: ओएस का एक अलग संस्करण, अन्य अधिकार, एक अलग प्रोसेसर शक्ति, रैम, अन्य खुले बंदरगाह। कुछ भी।

यह जाँच बेकार है। यह इस तरह से कार्यक्रम का उपयोग करने के लिए किसी को भी कभी नहीं होगा।

अतिरिक्त जांच नहीं होती है। वास्तव में ऐसे मामलों के लिए अपवादों का आविष्कार किया गया था। आप किसी भी व्यवहार / परिदृश्य का समर्थन नहीं करते हैं? एक NotSupportedException फेंक दें। सब कुछ बहुत स्पष्ट हो जाएगा। लेकिन NullReferenceException से भी बदतर , कुछ कल्पना करना मुश्किल है। यह आपके कोड का समर्थन करने वाले व्यक्ति को कोई जानकारी प्रदान नहीं करता है। उसे स्टैक ट्रेस के माध्यम से अफवाह करने और निम्न-स्तरीय त्रुटियों की तलाश करने की आवश्यकता नहीं है। हमेशा निम्न-स्तरीय त्रुटियों को संभालें और अपने समझने योग्य अपवादों का उपयोग करें। .NET में, एक अपवाद में एक आंतरिक अपवाद गुण है जो निम्न-स्तरीय समस्या के बारे में जानकारी रखने में मदद करता है। .NET में अपवाद से निपटने के बारे में बुरा नहीं है लेख में लिखा गया है " सी # में अपवादों के साथ सुरक्षित कार्य "।

आप इस त्रुटि को संभाल सकते हैं और दिखावा कर सकते हैं कि कुछ भी नहीं हुआ।

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

यह बग नहीं है, यह एक विशेषता है, परीक्षण पर डेटाबेस खाली है, उत्पादन पर सब कुछ ठीक होगा

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

मैंने फिक्स्ड / अपडेट किया, यह काम करने लगता है

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

एफआईजी जानता है कि समस्या क्या थी, मैंने फिर से शुरू किया, यह काम किया

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

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