2009-03-31 5 views
21

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

  1. त्रुटि और अपवाद हैंडलिंग रणनीति तैयार करते समय एप्लिकेशन डिज़ाइनर को किन मुद्दों पर विचार करना चाहिए?

  2. सॉफ़्टवेयर प्रकार (सीओटीएस, इन-हाउस बिजनेस ऐप, कंसल्टवेयर, गेम, होस्टेड वेब ऐप, एम्बेडेड इत्यादि) के आधार पर रणनीति कैसे भिन्न होगी? क्या सॉफ़्टवेयर का प्रकार महत्वपूर्ण है?

  3. नैतिक, राजनीतिक और कानूनी मुद्दों?

  4. त्रुटि प्रबंधन (उपयोगकर्ता, डेवलपर, व्यवसाय समर्थन, प्रबंधन) पर विभिन्न दृष्टिकोण।

कुछ विचार है कि मैं का पता लगाया है होगा:

  • विभिन्न त्रुटि रिपोर्टिंग मार्गों (अर्थात यूआई, प्रवेश, स्वत: व्यवस्थापक अधिसूचना)।

  • Defence in depth और मजबूती (विफलता आकस्मिकता और असफल-सुरक्षित तंत्र, उन समस्याओं के खिलाफ वसूली जो अभी तक ज्ञात नहीं हैं)।

  • उपयोगकर्ताओं और ग्राहकों को काफी हद तक इलाज करना (यानी सॉफ़्टवेयर उपयोगकर्ताओं और सॉफ़्टवेयर द्वारा सेवा प्राप्त अन्य लोगों पर प्रभाव को कम करना)।

मैं विचारों और अवधारणाओं की एक समान सूची की तलाश में हूं।

कृपया मुझे यह इंगित करने के लिए टिप्पणियों का उपयोग करें कि मुझे प्रश्न को और स्पष्ट करने की आवश्यकता है और सभी को योगदान देने के लिए धन्यवाद!


पूछे जाने वाले प्रश्न

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

मूर्ख दिवस यह निश्चित रूप से नहीं है। अधिकांश विरासत प्रणालियों पर मुझे काम करने के लिए कहा गया था, उनमें स्पष्ट त्रुटि प्रबंधन रणनीति नहीं थी।

क्या इसे एक समुदाय विकी बनाया जा सकता है? नहीं। यह एक अच्छा सवाल प्रतीत होता है और अच्छे प्रश्नों के साथ आने में मुश्किल होती है।

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

यह डुप्लिकेट प्रश्न हो रहा है (देखें Best practices for exception management in Java or C और Which and why do you prefer exceptions or return codes) इन सवालों से निपटने त्रुटि (ज्यादातर डेवलपर) पर एक निश्चित परिप्रेक्ष्य के साथ सौदा है, मैं अन्य दृष्टिकोण के बारे में अधिक जानकारी चाहते हैं और कैसे वे समग्र के लिए योगदान रणनीति।

+1

"यह निर्भर करता है"। क्या मंच? जावा, .NET? वेब, डेस्कटॉप, मोबाइल? –

+0

क्या यह आपकी जगह पर 1 अप्रैल है? इस एक के लिए – Sergey

+0

समुदाय विकी, मुझे लगता है –

उत्तर

6

यहां बहुत सारे संभावित उत्तर हैं, लेकिन मैं इसमें एक दरार ले जाऊंगा।

त्रुटि और अपवाद हैंडलिंग रणनीति तैयार करते समय एप्लिकेशन डिज़ाइनर को किन मुद्दों पर विचार करना चाहिए?

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

कैसे रणनीति अलग होगा सॉफ्टवेयर प्रकार के आधार पर (, घर में व्यापार अनुप्रयोग, consultingware, खेल, तख्त वेब अनुप्रयोग, एम्बेडेड आदि मेजबानी)? क्या सॉफ़्टवेयर का प्रकार महत्वपूर्ण है? जब त्रुटि रिपोर्ट की जांच

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

नैतिक, राजनीतिक और कानूनी मुद्दों?

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

त्रुटि प्रबंधन (उपयोगकर्ता, डेवलपर, व्यवसाय समर्थन, प्रबंधन) पर विभिन्न दृष्टिकोण।

  1. एक उपयोगकर्ता के दृष्टिकोण से, इस तरह से इंटरफेस डिजाइन करने कि यह मुश्किल है उन्हें गलती करने के लिए से त्रुटियों से बचने का प्रयास करें। ऐसे प्रश्न पूछें जो उपयोगकर्ता शायद उत्तर देने में सक्षम नहीं होंगे (निरस्त करें, पुनः प्रयास करें, किसी को भी विफल करें?)

  2. डेवलपर परिप्रेक्ष्य से, आप जो भी हुआ, उसका निदान करने में सहायता के लिए जितना संभव हो उतना जानकारी चाहते हैं - स्टैक ट्रेस, पर्यावरण जानकारी, आदि

  3. एक व्यापार समर्थन से & प्रबंधन दृष्टिकोण, वे जानना चाहते हैं कि त्रुटि (ज्यादातर एंटरप्राइज़ वातावरण में) के बारे में क्या करना है - जो आवेदन के लिए ज़िम्मेदार है (जो करते हैं मैं कॉल/पेज/आदि?) साथ ही साथ गंभीरता और किसी भी संभावित दुष्प्रभाव (उदा। यदि यह बैच नौकरी विफल हो जाती है, तो कौन सी व्यावसायिक प्रक्रियाएं प्रभावित होंगी?)। लिखित दस्तावेज यहां आपका मित्र है।

4

मैं जावा पृष्ठभूमि से आ रहा हूं, लेकिन मेरी प्रतिक्रिया नेट पर भी लागू होनी चाहिए।

  1. अपने कोड लिखें तेजी से विफल: अंगूठे का

    नियम Hunt & Thomas; युक्ति 33

  2. एक पैरा चेक लाइब्रेरी के साथ अपने सभी पैरामीटर का परीक्षण करें - ये असाधारण स्थितियां नहीं हैं। वे (दस्तावेज) एपीआई का दुरुपयोग कर रहे हैं। उदाहरण: google collections Predicates
  3. असाधारण स्थितियों के लिए अपवादों का उपयोग करें: [शिकार & थॉमस]; युक्ति 34. अपवादों को रिटर्न कोड के रूप में उपयोग नहीं किया जाना चाहिए।
  4. असाधारण स्थितियों के लिए परीक्षण: अपवाद विधियों के लिए अपवाद हैं। यदि आप परीक्षण के साथ वहां नहीं जा सकते हैं, तो अपवाद घोषित नहीं किया जाना चाहिए।
  5. (जावा के लिए) Josh Bloch's advice (अध्याय 9 के सभी) का पालन करें। कुछ महत्वपूर्ण टिप्स: 5 ए। अमूर्तता के लिए उपयुक्त अपवाद फेंको। 5 बी। विफलता परमाणुता के लिए प्रयास करें। 5 सी। विस्तार संदेश में विफलता-कैप्चर जानकारी शामिल करें (या इसे अपवाद में स्वयं को समाहित करें)। 5 डी। अपवादों को अनदेखा न करें।
3

मैं काम पर इन मुद्दों में से कुछ में भाग गया - वास्तव में वहां इसका पता लगाने का मौका नहीं था। मेरे विचार:

त्रुटि और अपवाद हैंडलिंग रणनीति तैयार करते समय एप्लिकेशन डिज़ाइनर को किन मुद्दों पर विचार करना चाहिए?

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

सॉफ़्टवेयर प्रकार (सीओटीएस, इन-हाउस बिजनेस ऐप, कंसल्टवेयर, गेम, होस्टेड वेब ऐप, एम्बेडेड इत्यादि) के आधार पर रणनीति कैसे भिन्न होगी? क्या सॉफ़्टवेयर का प्रकार महत्वपूर्ण है?

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

नैतिक, राजनीतिक और कानूनी मुद्दों?

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

विभिन्न दृष्टिकोण।

एक उपयोगकर्ता के रूप में, त्रुटि हैंडलिंग पूरी तरह से अदृश्य होना चाहिए। यदि कोई सर्वर दुर्घटनाग्रस्त हो जाता है, तो भी मैं चाहता हूं कि मेरा बैंक लेनदेन बैंक को कॉल किए बिना लेनदेन को दोबारा निर्धारित किए बिना निर्धारित किया जाए।

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

व्यापार समर्थन & प्रबंधन के लिए, मुझे लगता है कि त्रुटि हैंडलिंग सॉफ्टवेयर विकास चरणों जो ग्राहकों को जो असुविधाओं या सॉफ्टवेयर विफलता की वजह से कटौती का अनुभव क्षतिपूर्ति करने के लिए होने की घटनाओं को कम करने के दौरान भुगतान किया बीमा जैसा होगा। यह सॉफ्टवेयर गुणवत्ता और जवाबदेही का एक उपाय भी है (यानी वे जानना चाहते हैं कि कौन सा विभाजन/समूह/डेवलपर जिम्मेदार था)।

3

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

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

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

अपवाद सीमा पर पकड़ा जाना चाहिए। सभी ईवेंट हैंडलर, सार्वजनिक घटक कार्य, और सेवा विधियों को होने वाले सभी अपवादों को पकड़ना चाहिए।कुछ मामलों में, अपवाद को फिर से फेंकना समझ में आता है; उदाहरण के लिए, जब किसी वेब सेवा विधि में अपवाद पकड़ा जाता है, तो एक SOAP अपवाद फेंक दिया जाना चाहिए। लेकिन यह एक बुरा विचार है कि एक घटक को स्वचालित रूप से एक घटक सीमा में घूमने की अनुमति दें।

इसके विपरीत, यह आम तौर पर एक बुरा विचार, या तरीकों कि एक घटक के एक जटिल आंतरिक प्रक्रिया के बीच में नेस्टेड रहते हैं में कक्षाओं के निजी तरीकों पर अपवाद को पकड़ने के लिए है। इस संदर्भ में अपवाद को संभालने के लिए यह समझ में नहीं आता है जब तक कि आप अपवाद से पुनर्प्राप्त नहीं हो जाते। यह आंतरिक कोड संरचित किया जाना चाहिए ताकि सभी संसाधन जारी किए जाएंगे और डेटाबेस लेनदेन अपवादों की उपस्थिति में वापस लुढ़क जाएंगे। प्रत्येक विधि में ब्लॉक को पकड़ना अराजकता का संकेत है, और अंततः ब्लॉक एक ध्वनि त्रुटि हैंडलिंग ढांचे का संकेत है।

बल्कि अनुमान लगाने के लिए जब त्रुटियों, हो सकता है आपके घटक सीमाओं अप शोरिंग पर ध्यान केंद्रित कोशिश कर रहा से याद रखें कि अपवाद असाधारण रहे हैं (यदि आप उन्हें उम्मीद कर रहे थे, वे अपवाद नहीं कहा जा सकता है!)। यहां तक ​​कि मामूली कोड जो संभवतः किसी त्रुटि का अनुभव नहीं कर सका, यदि वह सीमा पर बैठता है तो पकड़ने वाला ब्लॉक होना चाहिए। इस तरह जब कोड अप्रत्याशित तरीकों से बाद में संशोधित किया जाता है तो आर्किटेक्चर अभी भी पकड़ लेगा।

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

सारांश में:

  1. विस्तृत त्रुटि जानकारी वापस विकास टीम को मज़बूती से प्राप्त करें।

  2. घटक सीमाओं पर हमेशा ट्रैप त्रुटियां और केवल घटक सीमाओं पर।

  3. सभी कोड अपवाद सुरक्षित करें।

  4. त्रुटि को संभालने में त्रुटि न दें समस्या का हिस्सा बनें।

+0

महान विचारों, हालांकि मैं उपयोगकर्ता के क्लिपबोर्ड के साथ चारों ओर खिलवाड़ के खिलाफ हूँ। –

+0

स्पष्ट है कि, मैं उन्हें एक चिपकाएं बटन दे रही है, क्लिपबोर्ड पर कुछ भी मजबूर कर नहीं के बारे में बात कर रहा हूँ। –

1

मैं इनाम जीतने के लिए इरादा नहीं है, लेकिन यहाँ कुछ रणनीतियों कि मैं का इस्तेमाल किया है और अच्छी तरह से प्राप्त हुए थे हैं:

  1. उप घटकों से informatin निकाला जा रहा है और उन्हें मानचित्रण के लिए कार्यात्मक इकाइयों में मदद की हमारी व्यापार विश्लेषक और अंतिम उपयोगकर्ता त्रुटियों बेहतर

  2. एक व्यापार प्राथमिकता स्तर डोमेन आप काम कर रहे हैं पर निर्भर करता है में मदद मिलेगी नियत को समझने के लिए।

  3. एक अलग त्रुटि व्यूअर अनुप्रयोग इससे पहले कि वे तो मेरे टीमों इन्हें ठीक करना शुरू कर सकते हैं सूचित किया गया हमें त्रुटियों को देखने में मदद की। जब वे साथ गड़बड़ नहीं कर रहे हैं

  4. सिस्टम स्तर अपवाद बेहतर हैं। त्रुटियों के

  5. Async प्रवेश समग्र रणनीति और डिजाइन में एक महान सौदा मदद मिलेगी।

  6. बनाएं डोमेन चालित त्रुटि रणनीति: अर्थ त्रुटियों whould कुछ व्यापार तर्क की विफलता के अनुरूप हैं।बेशक, सबसे डेवलपर्स द्वारा संभाला जाना चाहिए, लेकिन वहाँ है कि आप में चला सकते हैं यदि आप संदेश ट्रेडिंग इंजन में विभिन्न उद्यमों के बीच मार्ग पर काम कर रहे कुछ परिदृश्यों हैं, आदि

0

<opening my mind to new concepts>

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

<closing my mind to new contepts>

संबंधित मुद्दे