मेरे पुरातन सहकर्मी को संभालना


28

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

बात यह है, हम एक टीम के साथ काम कर रहे हैं, और उनकी कार्यशैली पूरी तरह से पुरातन है। वह सॉफ्टवेयर के संस्करण में विश्वास नहीं करता है (यदि आप सुनिश्चित करते हैं कि आपका कोड सही है, तो आपको उस सभी बकवास की आवश्यकता नहीं है)। परिनियोजन में विश्वास नहीं करता है (मैं एक कार्य निष्पादन योग्य वितरित कर सकता हूं। यह कैसे तैनात किया गया है यह सिस्मडिन्स को पता लगाने के लिए है)। अमूर्तता में विश्वास नहीं करता। ('यदि आप एक सबरूटीन बनाना चाहते हैं, तो आगे बढ़ें, लेकिन उस सबरूटीन से किसी भी सबरूटीन्स को कॉल न करें। यह उस तरह से गड़बड़ हो जाता है, और कोड का पालन करना कठिन है। इस तरह से हर एक को हर कदम पर अनुसरण किया जा सकता है। 'या' हाँ, सुनिश्चित करें कि आप उस लाइब्रेरी का उपयोग आपके लिए कर सकते हैं, लेकिन इस तरह से आपको वास्तव में समझ नहीं आ रहा है कि क्या चल रहा है ') और निश्चित रूप से ओओपी में विश्वास नहीं करता है। (हम VB.net में काम करते हैं)

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

मेरे पास उनके द्वारा लिखे गए कार्यक्रमों को बनाए रखने के लिए बहुत कठिन समय है, और यह एक अच्छी टीम के माहौल के लिए नहीं है। आपको क्या लगता है कि मेरे लिए सबसे अच्छी बात क्या है?


2
"हाँ, यकीन है कि आप उस लाइब्रेरी का उपयोग आपके लिए कर सकते हैं, लेकिन इस तरह से आप वास्तव में नहीं समझ पाएंगे कि क्या चल रहा है" "। वह यहाँ क्या मतलब है कि वह समझ नहीं पा रहा है कि क्या हो रहा है। हम करते हैं :) लगता है कि वह अपनी उत्पादकता में सुधार करने के लिए कुछ और सीखने से डरता है।
डेमियन रोश

7
आपका सहकर्मी पुरातन नहीं है, वह सिर्फ कुछ महत्वपूर्ण प्रोग्रामिंग 101 पाठों को याद करता है। वर्जनिंग, एब्सट्रैक्शन आदि ये सब 20 साल पहले के साथ-साथ आज भी बहुत महत्वपूर्ण हैं।
जस

7
शब्द "पुरातन" एक बल्कि भरा हुआ और अप्रकाशित शब्द है। मेरे पास कोई ऐसा व्यक्ति है जिसके साथ आपके द्वारा उपयोग किए गए समान शब्दों में वर्णित किया जा सकता है। हालाँकि वह मुझसे बहुत अधिक युवा है।
बिल

1
पुस्तकालयों के बारे में बात काफी मान्य है। आपको वास्तव में यह समझने की आवश्यकता है कि वे क्या करते हैं - उदाहरण के लिए पुस्तकालयों में चीजें जो थ्रेड या थ्रो अपवाद बनाते हैं, वे आपके जीवन को बहुत दुखी कर सकते हैं। उनके डोको या स्रोत कोड पर एक त्वरित झांकना आमतौर पर जिज्ञासा को संतुष्ट करने के लिए पर्याप्त है। यह पुस्तकालयों में चीजों का उपयोग नहीं करने का तर्क नहीं है, इसका सिर्फ एक तर्क है कि वे क्या करते हैं (और फिर अज्ञानता के बजाय खुशी से उनका उपयोग करें)।
जल्‍दी से जल्‍दी से

जवाबों:


25

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

इसलिए, ऐसा कहा जा रहा है, ऐसा लगता है कि आपके हाथों में एक समस्या है। आपके लिए जो बुरा है वह यह है कि वह सिद्ध है और शायद उसके तरीकों में निर्धारित है। तो आप क्या कर सकते हैं?

  • उसके आसपास काम करें।
  • अपनी परियोजनाओं का उत्पादन करने के लिए एक कार्यक्रम के रूप में तंग अनुसूची के रूप में वह करता है।
  • और यदि आप नहीं कर सकते, तो बेहतर परिणाम दें।
  • समय के साथ उन सिद्ध अवधारणाओं को, जिन्हें वह खारिज करता है, आपके लिए भुगतान करना शुरू कर देंगे।

दूसरी ओर, यदि आप अपने तरीके से काम करने के लिए मजबूर हैं, तो छोड़ दें।


मैं इस बात से सहमत हूँ कि जितना @pierre 303 का जवाब है। वह अंधेरे साइट को छोड़ देगा जब वह सुंदर उपकरण लगता है कि अच्छे लोगों के पास है।
कोर्तुक

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

अच्छा टीम-वर्क प्रथाओं का उपयोग करके प्रदर्शन के लिए +1।
बजे

11

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

तो आपके पास दो विकल्प हैं:

  • खुद को एडाप्ट करें। शायद समय के साथ आप उसे एक स्रोत नियंत्रण प्रणाली की उपयोगिता के लिए मना पाएंगे? आपको अपना प्रभाव क्षेत्र बढ़ाना होगा । जितना अधिक वह बदलने के लिए प्रतिरोधी होगा, उतना ही अधिक समय आपको चाहिए होगा।

  • अपने आप को दूर करो team। इसे सही ठहराने के लिए आपके पास बहुत से बिंदु हैं। हो सकता है कि आपको इसे छोड़ देना चाहिए और अपने स्वयं के अनुप्रयोगों को बनाए रखना चाहिए, और अपने आप को नए सामान पर समर्पित करना चाहिए।

  • अपने आप को दूर करो company। कभी-कभी, यह एकमात्र समाधान है।


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

3
दुनिया में 3 तरह के लोग हैं - वे जो बाइनरी को समझते हैं, और यह जो नहीं करते हैं ...
माइकल के

ट्रिक का उपयोग करना आसान है, और यह दिखाने के लिए पर्याप्त लाभ हैं कि यह वास्तव में मायने रखता है। बहुत कुछ सीट बेल्ट की तरह ...

मैं इससे सहमत नहीं हूँ। कुछ अभ्यास केवल तभी अच्छे होते हैं जब आप अकेले काम करते हैं, और यह लड़का उनसे भरा हुआ लगता है।
बोरिस यांकोव

इस सवाल पर वापस आ रहे हैं और इस जवाब के बाद, एक वर्ष से अधिक समय के बाद, विकल्प 3 उचित समाधान निकला
मार्टिजेन

6

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

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

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

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

इन सबसे ऊपर, यह उसके लिए जितना संभव हो उतना सरल बनाएं (इसे इट्स सिंपल स्टूपिड)। उसे अपनी शर्तों पर इन प्रथाओं का पालन शुरू करने की अनुमति दें। लेकिन इसे आप नीचे खींचें मत।


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

4

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

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

.. उसके बारे में .. हाँ, उसके साथ काम नहीं करने का एक तरीका खोजें और उसके काम के साथ संबद्ध न हों। ऐसा लगता है जैसे वह अपने काम के प्रति एक विशिष्ट स्वार्थी दृष्टिकोण रखता है। आप उस तरह से किसी के साथ काम नहीं कर सकते हैं, आप केवल उन्हें काम करने के लिए तैयार कर सकते हैं और उनके बाद साफ कर सकते हैं (जैसे आप वर्तमान में हैं)।


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

मुख्य भाग "छोटी परियोजनाओं पर"। मुझे बहुत संदेह है कि हम यहां छोटी परियोजनाओं के बारे में बात कर रहे हैं (पढ़ें: टीम प्रयास)।
डेमियन रोश

पूरी तरह से असहमत। यह वाल्टर के बारे में कुछ भी नहीं कहता है सिवाय इसके कि वह जानता है कि ये सभी अच्छे अभ्यास क्या हैं और वे टीम को कैसे लाभ पहुंचा सकते हैं। इन प्रथाओं का उपयोग न करना राड के बारे में है, क्योंकि वे आपको धीमा करते हैं।
रोस

4

मैंने इसे पहले देखा है ,

और मैं लगभग शर्त लगाने के लिए तैयार हूं: इस प्रकार का आदमी केवल "तेज" दिखाई देता है क्योंकि उसके सिर में कोशिश की और परीक्षण किए गए "पैटर्न" का एक सेट है। लाइन ऑफ बिज़नेस ऐप्स का 99% हिस्सा CRUD , बेसिक सामान है।

वह शायद अपने स्वयं के मौजूदा कोड से कॉपी और पेस्ट की एक टन का उपयोग करता है (इसके साथ कुछ भी गलत नहीं है)।

परंतु..

जिस क्षण वह दूर से कुछ भी जटिल का सामना करता है, वह नीचे गिर जाता है, क्यों? क्योंकि यह अब बुनियादी "पैटर्न" में से किसी को भी फिट नहीं करता है।

थोड़ी चुनौती ...

मैं ओर एक परियोजना बनाऊंगा, एक जटिल जो ओओपी और कोड री-यूज से वास्तव में लाभान्वित होगा।

फिर उसे उस परियोजना को दिखाएं और उसे फीचर के लिए इसे लागू करने के लिए कहें।

मैं तब दांव लगाऊंगा कि उसका कोड निश्चित रूप से लगभग 10 गुना बड़ा और 10x बदसूरत होगा यदि उसने इसे अपने तरीके से लागू किया था।


हाँ, सहमत हूँ, लेकिन फिर वह इसके बारे में क्या कर सकता है?
रॉस

खिलौना परियोजना को फिर से लागू करने पर समय क्यों खर्च करें?

@ एंडर्सन क्योंकि कुछ कार्यक्रम जो केवल सुनने का कारण नहीं सुनना चाहते, उनके सामने एक बार साक्ष्य स्वीकार कर लें
Darknight

@ रात, शायद नहीं, लेकिन फिर भी, क्यों खिलौना परियोजनाओं को फिर से लागू करने पर समय बिताने पर विचार करें जो वास्तविक जीवन की समस्याओं पर लागू नहीं होते हैं?

3

इसे व्यावसायिक पक्ष से देखें।

Buggier कोड तैयार करने में आपको अधिक समय लगता है। आप कम राजस्व पैदा करते हैं इसलिए आप चूसते हैं।

यदि, समय के साथ, आप इसे उल्टा कर सकते हैं तो आप इसे उल्टा कर सकते हैं।

लेकिन हो सकता है, बस हो सकता है, यह पुरातन प्रोग्रामर वास्तव में आपको कोड बनाने के बारे में कुछ चीजें सिखा सकता है जो इतनी बग मुक्त है? शायद उसकी तकनीकें इतनी पुरानी स्कूल नहीं हैं जितनी आप सोचते हैं?

मुझे यह संदेहास्पद लगता है कि कोई व्यक्ति बहुत अच्छी प्रथाओं के बिना ऐसे महान कोड का उत्पादन कर सकता है। आप उन प्रथाओं को सीखने में सक्षम हो सकते हैं और उन्हें "सर्वोत्तम प्रथाओं" और ट्रेंडी चीजों पर लागू कर सकते हैं जिन्हें आप समझते हैं।


2

यदि आपका प्रबंधक कोई प्रोग्रामर नहीं है, तो उसे ऐसे शब्दों में समझने की कोशिश करें।

  • अगर हम नहीं करते हैं तो हमें स्मारकंट्रोल का उपयोग करना चाहिए क्योंकि हमें बड़ी समस्याएं ठीक हो सकती हैं

  • मुझे समय की x राशि अधिक लगती है क्योंकि वह कुछ काफी बुनियादी प्रक्रियाओं का पालन करने से इनकार कर देता है।

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


"पुनर्प्राप्त करना" == रोलबैक।

2

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


5
श्रृंखला की श्रृंखला के ऊपर जाने से आपके द्वारा सिर पर उठाए गए हर व्यक्ति के दुश्मन बन जाते हैं, और अक्सर इसका परिणाम अच्छा नहीं होता है।
कोर्तुक

1

अपने प्रबंधक से बात करें, जैसा कि आप यहाँ पर सादे और सरल हैं। यहां विकास की संभावनाएं हैं - यदि आपका सहकर्मी अच्छा है जैसा कि आप कहते हैं कि वह ऐसा नहीं है तो उसे स्रोत नियंत्रण और .net उचित OO अवधारणाओं के साथ परिवर्तित करने के लिए उसे शुरू करने के लिए बहुत आश्वस्त होना चाहिए।


1
अगर वह बदलना चाहता है ..
वाल्टर

3
मेरे पास पहले से मौजूद बहुत से प्रबंधक नए आदमी को कुछ ऐसा करने के लिए महत्व नहीं देते हैं जो काम करने के लिए लगता है। वे तेजी से किए गए उत्पाद को महत्व देते हैं क्योंकि वे पूरी तरह से नहीं समझते हैं कि आप क्या कर रहे हैं। ऐसा लगता है कि आपके पास एक बॉस है जो तकनीकी नहीं है जो आपके अनुभाग के लिए प्रमुख बाधा है, हो सकता है।
कोर्तुक

1
यदि वह नहीं करता है, तो यह और भी महत्वपूर्ण है कि प्रबंधक (यह मानते हुए कि एक है) इसके बारे में जानता है।
ओट्टोवियो डेसिओ

@ कोरटुक - यह एक बहुत अच्छा बिंदु है, और अगर यह सच है तो ओपी वास्तविक परेशानी में है।
ओट्टोवियो डेसियो

मुझे लगता है कि अगर ओपी इन चीजों को अचानक बदलने की कोशिश करता है और उन्हें उँगलियाँ उठाने के लिए मजबूर करता है। यह दुश्मन बनाता है और काम के माहौल को नुकसान पहुंचा सकता है जहां वह अपने सहयोगी से बहुत कुछ सीख सकता है।
कोर्तुक

1

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

आप उसके साथ बात करना चाहते हैं कि उसने किस तरह की बड़ी प्रणालियों का निर्माण किया है क्योंकि कुछ बड़े उद्यम सिस्टम हैं जो बहुत सारे बिल्डिंग ब्लॉक हैं जहां स्पेगेटी कोड भूमि में चला सकता है, "ओह, यही कारण है कि ओओपी अच्छा हो सकता है! ” हालांकि यह कभी-कभी ऐसा होता है जहां यह देखने के लिए काफी उपयोगी साबित होता है कि यह किसी के टूलबॉक्स में कैसे उपयोगी हो सकता है।

उदासीनता यह देखने के लिए एक और संदेह हो सकता है कि क्या इसीलिए वह कुछ चीजों को अस्वीकार कर देता है, जिन्हें मैं मौलिक रूप से करीब से समझाऊंगा कि मैं किस तरह से कोड डिजाइन करता हूं, लेकिन तब शायद मेरे पास बहुत अधिक कूल-सहायता थी।


1

उसे चुनौती दें (एक अच्छे तरीके से) अन्यथा आपको साबित करने के लिए, उसे साधनों और प्रथाओं का ठंडा पक्ष दिखाएं। संरक्षण मत करो।

उदाहरण के लिए, शायद वह सहायता के रूप में वर्जनिंग में विश्वास नहीं करता है, लेकिन उसे यह दिखाता है कि फ़ाइलों की एक ब्लोट की आवश्यकता के बिना ब्रांचिंग / विलय और कैसे वह कई प्रयोगात्मक सुविधाओं पर काम कर सकता है।

OOP के बारे में, उसे कुछ शांत / जटिल डिज़ाइन पैटर्न दिखाएं, जैसे कमांड पैटर्न, कार्य पैटर्न और यह कैसे उसे मूल्यवान समय बचा सकता है, और आपकी टीम के सभी।

यदि आपके पास उसे थोड़ी सी भी दिलचस्पी नहीं है ... वह एक खोया हुआ मामला हो सकता है, लेकिन तब फिर से, आपके पास आपकी टीम के लिए उपकरण हैं और आप उससे आगे निकल जाएंगे। एक रिपॉजिटरी सॉफ्टवेयर का उपयोग करने की कोशिश करें जो आपके प्रबंधक द्वारा देखे गए संदेशों को दिखा / ईमेल कर सकता है, जो आपके प्रबंधक को पारदर्शिता लाएगा और आपके सहकर्मी को तस्वीर से बाहर कर देगा (bitbucket.org के पास असीमित स्थान के साथ नि: शुल्क निजी रिपॉजिटरी हैं, यदि आप नैचुरल का उपयोग करते हैं)।

अंत में, शब्दों के साथ समझाने की कोशिश मत करो, लेकिन अकाट्य कार्यों के साथ, यह जिद्दी लोगों के साथ निपटने का सबसे अच्छा तरीका है IMHO (रिवर्स मनोविज्ञान कभी-कभी काम करता है, योग्य)।


1

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

मुझे लगता है कि शुरू करने के लिए जगह संभावित पुन: उपयोग के लिए नजर रख रही है - जैसा कि परियोजनाएं गुजरती हैं, सामान्यताओं, या अधिक सामान्य रूपरेखाओं के बारे में सोचते हैं। परियोजनाओं के सामने आने की कोशिश एक शक्तिशाली कदम होगा, और हो सकता है कि आप अधिक तकनीक में काम करें ...


संस्करण नियंत्रण भी इतिहास प्रदान करता है। महत्वपूर्ण यह है कि लोग अब आसपास नहीं हैं।

0

आपको अपने पर्यवेक्षक से हर किसी के लिए एक प्रस्तुति करने के लिए कहना चाहिए कि "वर्जनिंग" सॉफ्टवेयर क्यों अच्छा है। अपने सहकर्मी को बाहर मत करो।

मैं स्वयं स्रोत नियंत्रण सॉफ़्टवेयर का संदेहवादी हूं, क्योंकि मैं लोगों को हर समय इसका दुरुपयोग करते देखता हूं - काम से बचने के तरीके के रूप में।

मेरे सहकर्मी लगातार विलय कर रहे हैं, लगातार एक दूसरे के पैर की उंगलियों पर कदम रख रहे हैं। लेकिन इसके लाभों पर एक अच्छा मैत्रीपूर्ण व्याख्यान एक अच्छी बात होगी और इस पर चर्चा होगी।


1
एक दूसरे के पैर की उंगलियों पर लगातार कदम रखना इस बात का संकेत है कि सॉफ्टवेयर बुरी तरह से आर्किटेक्चर है। इसका स्रोत नियंत्रण से कोई लेना-देना नहीं है, और इसके बिना वास्तव में बदतर हो सकता है।
deadalnix

@deadlnix यह भी कारण हो सकता है, लेकिन मुझे लगता है कि यह उचित समाधान नहीं होने पर कुछ मामलों में, कुछ मामलों में, ब्रोचिंग के अति-उत्साही उपयोग के लिए भी जिम्मेदार ठहराया जा सकता है।
निकोल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.