अद्यतन
मैं देवों की एक छोटी टीम पर काम करता हूं, 4 लोग। उनके पास सभी स्रोत नियंत्रण का उपयोग किया गया है। उनमें से ज्यादातर स्रोत नियंत्रण नहीं रख सकते हैं और इसके बजाय इसका उपयोग नहीं करना चुनते हैं। मेरा मानना है कि स्रोत नियंत्रण पेशेवर विकास का एक आवश्यक हिस्सा है। कई मुद्दों को स्रोत नियंत्रण का उपयोग करने के लिए उन्हें समझाना बहुत मुश्किल है:
- टीएफएस का उपयोग करने के लिए टीम का उपयोग नहीं किया जाता है । मेरे पास 2 प्रशिक्षण सत्र हैं, लेकिन केवल 1 घंटे आवंटित किया गया था जो अपर्याप्त है।
- टीम के सदस्य सर्वर पर कोड को सीधे संशोधित करते हैं। यह कोड को सिंक से बाहर रखता है। तुलना की आवश्यकता सिर्फ यह सुनिश्चित करने के लिए है कि आप नवीनतम कोड के साथ काम कर रहे हैं। और जटिल मर्ज की समस्या उत्पन्न होती है
- इन समस्याओं में से किसी को भी ठीक करने के लिए डेवलपर्स द्वारा प्रस्तावित समय अनुमानों को समय की आवश्यकता होती है। इसलिए, अगर मैं कहता हूं कि इसे नॉन 10 गुना अधिक समय लगेगा ... मुझे लगातार इन मुद्दों को समझाना होगा और खुद को जोखिम में डालना होगा क्योंकि अब प्रबंधन मुझे "धीमा" समझ सकता है।
- सर्वर पर भौतिक फाइलें अज्ञात तरीकों से ~ 100 फाइलों से अधिक भिन्न होती हैं। विलय से परियोजना के ज्ञान की आवश्यकता होती है और इसलिए, डेवलपर सहयोग जिसे मैं प्राप्त करने में सक्षम नहीं हूं।
- अन्य परियोजनाएं सिंक से बाहर हो रही हैं। डेवलपर्स के पास स्रोत नियंत्रण का अविश्वास जारी रहता है और इसलिए स्रोत नियंत्रण का उपयोग न करके समस्या को जटिल करता है।
- डेवलपर्स का तर्क है कि स्रोत नियंत्रण का उपयोग करना बेकार है क्योंकि विलय त्रुटि प्रवण और कठिन है। यह बहस करने के लिए एक कठिन बिंदु है, क्योंकि जब स्रोत नियंत्रण इतनी बुरी तरह से गलत इस्तेमाल किया जा रहा है और स्रोत नियंत्रण लगातार बायपास किया जाता है, तो यह वास्तव में त्रुटि प्रवण है। इसलिए, साक्ष्य उनके विचार में "खुद के लिए बोलता है"।
- डेवलपर्स का तर्क है कि TFS को दरकिनार करते हुए सीधे सर्वर कोड को संशोधित किया जाता है। यह बहस करना भी मुश्किल है। क्योंकि समय के साथ शुरू करने के लिए कोड को सिंक्रनाइज़ करने के लिए आवश्यक मर्ज । इसे 10 + परियोजनाओं द्वारा गुणा करें जिन्हें हम प्रबंधित करते हैं।
- स्थायी फ़ाइलों को अक्सर वेब प्रोजेक्ट के समान निर्देशिका में संग्रहीत किया जाता है। इसलिए प्रकाशन (पूर्ण प्रकाशित) इन फ़ाइलों को मिटा देता है जो स्रोत नियंत्रण में नहीं हैं। यह स्रोत नियंत्रण के लिए अविश्वास भी चलाता है। क्योंकि "प्रकाशन परियोजना को तोड़ता है"। इसे ठीक करना (सॉल्यूशन फ़ाइलों को सॉल्यूशन सबफ़ोल्डर्स से बाहर ले जाना) बहुत समय लेता है और डिबगिंग करता है क्योंकि ये स्थान web.config में सेट नहीं होते हैं और अक्सर कई कोड बिंदुओं पर मौजूद होते हैं।
तो, संस्कृति अपने आप बनी रहती है। बुरा अभ्यास अधिक बुरे अभ्यास को भूल जाता है। खराब समाधान नई हैक को बहुत अधिक समय लेने वाली समस्याओं को और अधिक गहरा, "ठीक" करने के लिए ड्राइव करते हैं। सर्वर, हार्ड ड्राइव स्पेस द्वारा आना बेहद मुश्किल है। फिर भी, उपयोगकर्ता की उम्मीदें बढ़ रही हैं।
इस स्थिति में क्या किया जा सकता है?
24
लापता जानकारी का मुख्य अंश: टीम में आपकी भूमिका क्या है?
—
मोरों
क्या जीवन वास्तव में इतना समय बर्बाद करने के लिए पर्याप्त है जैसे कहीं काम कर रहा है? आपके पास सहकर्मियों की एक टीम है जो एक सक्षम और पेशेवर तरीके से काम करने की इच्छा नहीं रखते हैं, और प्रबंधन जो परवाह नहीं करते हैं। आप इससे बेहतर कर सकते हैं।
—
कार्सन 63000 22
स्रोत नियंत्रण के लिए उपयोग नहीं किए जाने के बारे में: यदि यह एक वास्तविक दुनिया की परियोजना है, तो यह स्रोत नियंत्रण के आदी होने का समय है।
—
कॉम्पैन
या तो अपने कार्यस्थल को बदलें, या अपने कार्यस्थल को बदलें । जो भी आप तय करते हैं, संकोच न करें।
—
गोरान जकोव
एक डेवलपर का विचार जो पहले स्रोत नियंत्रण का उपयोग करता था और उसे प्यार नहीं करता था वह मेरी समझ से लगभग परे है। शायद उन्होंने इसका गलत इस्तेमाल किया?
—
jhocking