5
एक आम घटक एक पुस्तकालय या कोड का कुछ अन्य टुकड़ा है जिसे एक समूह द्वारा बनाया और बनाए रखा जाता है और कई समूहों द्वारा उपयोग किया जाता है।आपका संगठन सामान्य घटकों को कैसे संभालता है?
कुछ समस्याओं हमारे पास हैं:
- उन घटकों के साथ समस्याओं की रिपोर्ट नहीं है।
- उपयोगकर्ता अपनी आवश्यकताओं के अनुरूप घटकों को कामकाज बनाते हैं।
- वे अपनी समयसीमा को पूरा करने के लिए ट्रंक संस्करण के साथ संगतता तोड़ते हैं।
- उपयोगकर्ता अपने स्वयं के (कम मजबूत) समाधान कोडिंग को समाप्त करते हैं क्योंकि उन्हें लगता है कि यह बेहतर है।
आपका संगठन सामान्य घटकों को कैसे संभालता है?
विचार मेरे पास है:
- एक ओपन सोर्स प्रोजेक्ट की तरह घटक इलाज और पैच प्रस्तुत करने के लिए टीमों की आवश्यकता है।
- कोड में कस्टम संशोधन को पूरी तरह से अस्वीकार करें।
- ...
मैं मानता हूं कि लोगों की समस्या होने की अधिक संभावना है। जिस कोण को मैं लगातार चलाता हूं, वह प्रबंधन के लिए किसी भी आम घटक की लागत को न्यायसंगत साबित कर रहा है जो केवल इसे तत्काल या दीर्घकालिक न्यायसंगत भुगतान के साथ व्यय के रूप में देखता है। –
आपके बिंदु ग्रेग के लिए, यदि प्रबंधन को मूल्य नहीं दिखता है तो आपको यह समझने की आवश्यकता है कि लंबे समय तक आपको मूल्य या चेहरे को नौकरी के नुकसान के बारे में संवाद करने की आवश्यकता है। अपने घर के बजट के बारे में सोचें, कठिन समय में आप उन सेवाओं के लिए भुगतान जारी रखते हैं जिनके पास आपके लिए कोई मूल्य नहीं है? – JonnyBoats
मेरे विशेष संगठन में, मैं पूरी तरह से एमजीएम के आरक्षण से असहमत नहीं हूं। पिछले कुछ सालों में, मैंने जो कुछ सीखा है, वह यह है कि मेरा संगठन नहीं जानता कि सॉफ्टवेयर को अच्छी तरह से कैसे लिखना है, या सॉफ्टवेयर जोखिम को अच्छी तरह से प्रबंधित करना है। वे इतने लंबे समय से इतने लंबे समय से रहे हैं कि मृत वजन "lifers" बहुत कम लोगों की तुलना में काफी अधिक है जो वास्तव में कम रखरखाव, उच्च गुणवत्ता वाले सॉफ्टवेयर बनाने की परवाह करते हैं।मेरा विशेष समूह का "वरिष्ठ डेवलपर" अपने सी # कक्षाओं में एक स्थिर "मुझे" चर बनाता है और इसे "उदाहरण" को उसके उदाहरण ctor में निर्दिष्ट करता है, उदा। अगर आप कभी दूसरा उदाहरण बनाते हैं तो यह बदसूरत है। :( –