एक सॉफ्टवेयर वास्तुकार के रूप में, क्या मुझे लॉग्स का विश्लेषण करने और अन्य कीड़ों को ठीक करने पर ध्यान केंद्रित करना चाहिए?

Question

अपने स्नातक स्तर की पढ़ाई (2005 के अंत तक) के बाद से मैं उसी कंपनी के लिए काम कर रहा था जो सी ++ सॉफ्टवेयर इंजीनियर के रूप में थी। एक साल पहले मुझे एक सॉफ्टवेयर आर्किटेक्ट के रूप में पदोन्नत किया गया था, लेकिन मैंने खुद को योग्यता और फिक्सिंग बग्स, लेवल 2 के समर्थन में अधिक से अधिक शामिल पाया है।

नोटपैड ++ में बिताए गए मेरे समय का 50% सॉफ्टवेयर लॉग का विश्लेषण करता है और यह पता लगाने की कोशिश करता है कि क्या गलत हुआ। डेवलपर्स के स्पेगेटी कोड की समीक्षा करने वाले अन्य कीड़ों और शेष (यदि कोई हो) को 30% तय करना।

मैं इस उत्पाद से नफरत करने लगा और इस कंपनी से बाहर निकलने की रणनीति के बारे में सोचने लगा।

आपको क्या लगता है कि मैं इस स्थिति में क्या कर सकता हूं? क्या आप अन्य सॉफ़्टवेयर आर्किटेक्ट अभी भी कोड में कीड़े को ठीक कर रहे हैं?

Comments

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

— मैक्स

नाह - एक "वास्तुकार" का कर्तव्य बग बनाना है, उन्हें ठीक नहीं करना है।

— नागेज़ा ट्रिफ़ुनोविक

आप जो भी वर्णन करते हैं वह सॉफ्टवेयर आर्किटेक्ट नहीं है - यह एक समर्थन इंजीनियर है।

— ओडेड

एक "स्तर 2 का समर्थन" क्या है .. खेल की तरह लग रहा है अहा

— थॉमस बोनिनी

@ क्राल्प बहुत बड़े सॉफ्टवेयर उत्पाद संचालन 2 रूपों में टूट जाते हैं: 1. रिलीज़ 2. रखरखाव। रिलीज़ गतिविधियों में कुछ प्रमुख विशेषता को शामिल करना, अनुकूलन के दायरे की खोज, सॉफ्टवेयर का वैश्वीकरण, नए प्लेटफार्मों के लिए समर्थन जोड़ना आदि शामिल हैं। अब, रखरखाव भाग 3 भागों में टूट गया है: L1, L2 और L3। L1 एक ग्राहक सहायता कॉल सेंटर है। L2 लोग उत्पाद के विस्तृत ज्ञान से लैस हैं। जब L1 ग्राहक समस्या को हल करने में विफल रहता है, तो वे समस्या या L2 पास करते हैं। और अगर L2 समस्या को हल नहीं कर सकता है, तो वे L3 कहते हैं। L3 कोड परिवर्तन करने में सक्षम है।

— चनी

Answer 1

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

हालांकि वास्तविकता यह है कि शीर्षक अक्सर एक डेवलपर के लिए एक राजनीतिक नियुक्ति हो सकता है, एक विशेष शीर्षक परियोजनाओं के डेवलपर्स का नेतृत्व करने के लिए दिया जाता है, या यहां तक ​​कि एक प्रबंधन-एचआर वर्कअराउंड के रूप में सरल कुछ ऐसा है जो वेतन या दर पर बुरी तरह से आवश्यक डेवलपर को नियुक्त करने के लिए है एचआर या ऊपरी प्रबंधन सॉफ्टवेयर डेवलपर या सॉफ्टवेयर इंजीनियर शीर्षक के लिए अस्वीकार्य होगा।

दूसरे शब्दों में, शीर्षक ज्यादातर अर्थहीन होते हैं।

Comments

यह हास्यास्पद है कि आर्किटेक्ट हमारे क्षेत्र में इंजीनियर के रूप में उन्नत शीर्षक बन गया है। अन्य क्षेत्रों में इंजीनियर आर्किटेक्ट्स को देखते हैं। सहमत हैं कि शीर्षक ज्यादातर अर्थहीन हैं।

— माइक

यह बहुत पसंद है कि कैसे मुझे कॉलेज से दो साल पहले "सीनियर सॉफ्टवेयर इंजीनियर" के रूप में पदोन्नत किया गया था। मैं शायद कम से कम एक दशक से अधिक समय तक उस खिताब के लायक नहीं था।

— रोबोट डिक

आर्किटेक्ट्स की तुलना में सिटी प्लानर शायद एक बेहतर रूपक है जो आमतौर पर सॉफ्टवेयर आर्किटेक्ट करते हैं।

— रॉय टिंकर

यह सच है, शीर्षक निरर्थक हैं

— srk

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

— कार्सन 63000

Answer 2

विकिपीडिया लेख सॉफ्टवेयर वास्तुकार को परिभाषित करता है :

एक कंप्यूटर प्रोग्रामर जो उच्च-स्तरीय डिज़ाइन विकल्प बनाता है और तकनीकी मानकों को निर्धारित करता है , जिसमें सॉफ्टवेयर कोडिंग मानक, उपकरण या प्लेटफ़ॉर्म शामिल हैं ...

इसके बाद के संस्करण को देखते हुए, अपने अनुमानों "अपने समय के 50% खर्च ... सॉफ्टवेयर लॉग का विश्लेषण ... 30% अन्य के बगों" आप दूर कर दिया अब तक बंद सॉफ्टवेयर वास्तुकार सामान्य रूप से करते रहने की उम्मीद है क्या की।

• मैं कहूंगा कि ऊपर शीर्षक आपको 50+30=80%नकली के बारे में देता है ।

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

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

---

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

Answer 3

एक सॉफ्टवेयर वास्तुकार के रूप में, क्या मुझे लॉग्स का विश्लेषण करने और अन्य कीड़ों को ठीक करने पर ध्यान केंद्रित करना चाहिए?

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

आप सक्रिय होना चाहिए:

1. शिक्षा की पहल करें ताकि अन्य लोग (देव / सहायता) भार उठा सकें। "एक आदमी को मछली सिखाना" और वह सब जाज।
2. तेजी से और आसान दोष विश्लेषण और मूल कारण अलगाव का समर्थन करने के तरीकों को विकसित करें और उपकरण विकसित करें। यदि आपको यह उबाऊ लगता है, तो अन्य, संभवतः कम प्रतिभाशाली या अनुभवी डेवलपर्स को यह न केवल उबाऊ लगता है, बल्कि कठिन और शायद चुनौतीपूर्ण भी लगता है। उन्हें तकनीक से दूर करने में मदद करें।
3. उत्पाद की गुणवत्ता बढ़ाने के लिए एक प्रयास शुरू करें - सरल करें, संशोधित करें, परीक्षण ढांचे बनाएं - उदाहरण के लिए नेतृत्व करें, न कि रोना और छोड़ने की धमकी देकर।
4. सुनिश्चित करें कि डेवलपर्स जानते हैं कि आप क्या कर रहे हैं - लेकिन आपके प्रबंधक भी। एक वास्तुकार की भूमिका अन्य लोगों के साथ संबंधों के बारे में बहुत अधिक है फिर यह कोडिंग और विश्लेषण के बारे में है। जितना आप इस से नफरत कर सकते हैं, राजनीति यहाँ एक महत्वपूर्ण भूमिका निभाती है। यह सुनिश्चित करना कि आपके साथी आपकी उपलब्धियों को देखते हैं, बाद में उन्हें आश्वस्त करना आसान हो जाता है कि आप सही हैं। यदि आप अभी तक वहां नहीं हैं, तो शोध और पीओसी द्वारा अपने दावों को वापस लें।
5. यदि बाकी सब विफल हो जाता है, और केवल चीजों को बेहतर बनाने की कोशिश करने के लिए समय बिताने के बाद, अपने प्रबंधक से बात करें। यह कहें कि आपके कौशल का नियोजन और चरणों के डिजाइन में बेहतर उपयोग किया जाता है और देखें कि वर्तमान स्थिति को बदलने के लिए क्या किया जा सकता है। आपका उत्पाद एक चुटकी में हो सकता है और आपके प्रबंधक का जवाब "हमें इस चीज़ के लिए आपको अभी यहीं चाहिए," हो सकता है। मैं एक दीर्घकालिक योजना पर जोर दूंगा - हालांकि हम वर्तमान स्थिति को कैसे बदलने जा रहे हैं।

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

Comments

मेरी राय में सबसे अच्छा जवाब। इस तरह से मेरी ... मुझे अभिनय करने की उम्मीद होगी।

— रिंकीपिंकू

Answer 4

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

यह देखते हुए कि आपने क्या कहा:

नोटपैड ++ में बिताए गए मेरे समय का 50% सॉफ्टवेयर लॉग का विश्लेषण करता है और यह पता लगाने की कोशिश करता है कि क्या गलत हुआ। डेवलपर्स के स्पेगेटी कोड की समीक्षा करने वाले अन्य कीड़ों और शेष (यदि कोई हो) को 30% तय करना।

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

Answer 5

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

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

इसे हल करना एक कठिन समस्या है, लेकिन मेरी सलाह है:

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

2. अपने प्रबंधक से बात करें कि कितना समय नष्ट हो रहा है और किन समूहों या परियोजनाओं के लिए। आपका प्रबंधक आपको बता सकता है कि आप उनकी मदद न करें, और उनकी परियोजनाओं पर ध्यान केंद्रित करें। यदि ऐसा है, तो दूसरा समूह आता है और मदद मांगता है, आप उन्हें बताएं कि आपके बॉस ने भी नहीं कहा।

3. अपने काम को व्यवस्थित करें, अपनी प्राथमिकताओं को स्पष्ट रखते हुए, और अपने आर्किटेक्चर प्रोजेक्ट्स के बाहर इतने उत्तरदायी न हों।

4. एक वास्तुकार की तरह कार्य करें, अपने साथियों को आपको एक वास्तुकार के रूप में देखने के लिए प्राप्त करें, न कि उसी डेवलपर के रूप में जो आप इन सभी वर्षों से हैं। आपके पास सिर्फ डेवलपर के रूप में व्यवहार करने की आदत है।

सौभाग्य।

Answer 6

नहीं, आप यहाँ हैं बड़ी तस्वीर का प्रबंधन करने के लिए।

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

हालांकि, आप कोर आर्किटेक्चर पर बग्स को लागू और ठीक कर सकते हैं।

उदाहरण: आप WPF / C # प्रोजेक्ट में PRISM, MEF आदि पर काम करेंगे, लेकिन आप स्पलैश को प्रदर्शित करने के लिए XAML पर काम नहीं करेंगे।

आप DB डिज़ाइन पर काम करेंगे, लेकिन आप CRUD संचालन के लिए संग्रहीत कार्यविधियाँ नहीं लिखेंगे।

आदि।

Answer 7

जवाब का हिस्सा एक इंजीनियर को ढूंढना होगा जो इस भार को लेने के लिए तैयार है।

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

मुझे दो संभावनाएँ दिखती हैं।

1. आपको आर्किटेक्ट का पद दिया गया था ताकि आप बड़े पिक्चर आइटम पर काम कर सकें।
   इस मामले में, आपको प्रबंधन का उल्लेख करना चाहिए कि आप इन बड़े चित्र वस्तुओं पर काम करने में असमर्थ हैं क्योंकि निचले स्तर की समर्थन भूमिका लेने के लिए किसी ने भी कदम नहीं उठाया है। तब उनकी समस्या को हल करना है।

2. शीर्षक काफी हद तक औपचारिक है - आपके आसपास रखने के लिए आपके द्वारा फेंकी गई हड्डी।

इस मामले में, प्रबंधन को आपके समर्थन भार को कम करने में बहुत रुचि नहीं हो सकती है।

-

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

Answer 8

नोटपैड ++ में बिताए गए मेरे समय का 50% सॉफ्टवेयर लॉग का विश्लेषण करता है और यह पता लगाने की कोशिश करता है कि क्या गलत हुआ। डेवलपर्स के स्पेगेटी कोड की समीक्षा करने वाले अन्य कीड़ों और शेष (यदि कोई हो) को 30% तय करना।

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

दूसरे शब्दों में, मेरी बात # 1 है - आर्किटेक्ट उच्च स्तर के डिजाइनर और सिस्टम इंटीग्रेटर्स हैं, जो हाथों से अनुभव करते हैं कि किस तरह से टेक्नॉलॉजी काम के आंतरिक-कार्य / उपयोग और उपयोग की आवश्यकता है।

यदि आपके पास कोड गुणवत्ता को असाइन करने और प्रबंधित करने का अवसर है, तो आपके कार्य प्रबंधन कौशल को सुधारने की आवश्यकता है। इस प्रकार, "कैसे काम करना है" दृष्टिकोण पर नियोजन कार्य आपकी प्राथमिकता होनी चाहिए।

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

Answer 9

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

Answer 10

एक सॉफ्टवेयर आर्किटेक्ट के रूप में, क्या मुझे लॉग्स का विश्लेषण करने और अन्य बग्स को ठीक करने पर ध्यान केंद्रित करना चाहिए?

बोलने के मामले में, 'हाँ'।

यहां बताया गया है कि मैं अपना उत्तर कैसे प्राप्त करूंगा:

1. डिफ़ॉल्ट रूप से, आपको सॉफ़्टवेयर डेवलपर्स को लॉग का विश्लेषण करने और बग्स को ठीक करने देना चाहिए।
2. हालाँकि ... आपको उन दोषों के बारे में पता होना चाहिए जो डेटा हानि के कारण होते हैं, इसके लिए एक डेटाबेस डेटाबेस रोलबैक की आवश्यकता होती है, डेवलपर्स को हल करने या ग्राहक माफी की आवश्यकता के लिए लंबा समय लगता है।
   1. एक नियम के रूप में, आपकी प्रत्यक्ष रिपोर्ट आपको ऐसे दोषों के बारे में बताएगी।
   2. आपको एक ऐसी संस्कृति का निर्माण करना चाहिए जिसमें आपकी प्रत्यक्ष रिपोर्ट आपको ऐसे दोषों के बारे में बताने के लिए सशक्त महसूस करे , लेकिन आपको तुच्छ लोगों के बारे में बताने के लिए मजबूर न करें ।

---

# 2 पर अधिक:

1. इस प्रकार के दोष आमतौर पर एक आर्किटेक्चरल असफलता है। जब वे करते हैं, तो आपको दोष और वास्तुविद् के सटीक स्वरूप को ठीक करना चाहिए।
   1. इसलिए विस्तार से, आपको लॉग के माध्यम से तैयार होना चाहिए, तैयार होना चाहिए, और अन्य लोगों के कीड़े को ठीक करने में सक्षम होना चाहिए (भले ही आप सीधे स्रोत कोड रिपॉजिटरी में कोड नहीं करते हैं)।

Answer 11

जवाब शायद नहीं है। आप डिबगिंग और समर्थन मुद्दों पर इतना समय क्यों दे रहे हैं? क्या कोई आपको यह काम सौंप रहा है?

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