कुछ बुनियादी नियमों का पालन करने के लिए अपने साथियों को कैसे मनाऊं


28

मुझे अपने साथियों के साथ समस्या है। लंबी कहानी छोटी: हम एक प्रतियोगिता के लिए एक परियोजना में काम करने वाले तीन छात्र हैं। परियोजना में 2 अलग-अलग अनुप्रयोग हैं: एक विंडोज के लिए (जो मैं विकसित करता हूं) और एक एंड्रॉइड के लिए (मेरे सहयोगी इसे विकसित करने के लिए जिम्मेदार हैं)। हमारे कोड बेस कभी भी इंटरसेक्ट नहीं होंगे, ऐप्स थर्ड पार्टी टूल्स के जरिए संवाद करेंगे।

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

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

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

मेरा सवाल है: क्या मैं इस मामले पर बहुत कठोर हूं? क्या मैं कुछ बेतुके नियम लागू करता हूँ? ध्यान रखें कि यह एक छोटी परियोजना है, आवश्यकताएं बहुत स्पष्ट हैं (मैंने यह निर्दिष्ट करते हुए दस्तावेज बनाए हैं कि अनुप्रयोगों को क्या करना चाहिए), तीन कुशल डेवलपर्स 3-4 दिनों में ऐसा कर सकते हैं, इसलिए वे लेखन गुणवत्ता की अतिरिक्त जटिलता नहीं देख सकते हैं। कोड के रूप में लंबे समय के रूप में अपने वर्तमान विधि काम करता है।

क्या कोई तरीका है जिससे मैं उन्हें डॉक्यूमेंट कोड का लाभ दिखा सकूँ, git इत्यादि का उपयोग कर सकता हूँ?


37
शायद वे इसे "एक सप्ताह के ऐप" के लिए ओवरकिल के रूप में देखते हैं? शायद यह "कैसे" के कारण आप उन्हें समझाने की कोशिश करते हैं? कहानी का उनका पक्ष क्या है? उनकी राय आपके पोस्ट में भी नहीं आई, फिर भी इस या उस टूल का उपयोग करने की तुलना में IMHO अधिक महत्वपूर्ण है। ... या शायद वे परियोजना के दायरे की परवाह नहीं करते हैं? परिवर्तन लाने के लिए संचार, कौशल और धैर्य की आवश्यकता होती है।
dagnelies

2
यही परियोजना प्रबंधकों के लिए है। तय करने के लिए कुछ अधिकार होना चाहिए। "समझाने की कोशिश" हमेशा के लिए हो सकती है।
SChepurin

@ नारनौद मैंने उनसे इस मुद्दे पर बात की थी, लेकिन उन्होंने आसानी से ध्यान नहीं दिया। उन्होंने कुछ दस्तावेज लिखे लेकिन अधिकांश हिस्सा मेरे द्वारा किया गया। इसके अलावा, उनमें से एक ने एक कोड समीक्षा का अनुरोध करने के बाद हमारे परिवर्तन भंडार में कुछ बदलाव किए, लेकिन तब से 1 सप्ताह बीत गया।
razvanp

7
नई प्रथाओं का परिचय और नए उपकरण चीजों को शुरू करने में देरी करते हैं, और बाद में गति में सुधार करते हैं। प्रतियोगिता के समय क्या है?
MarkJ

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

जवाबों:


43

मेरा सवाल है: क्या मैं इस मामले पर बहुत कठोर हूं?

आप पानी के लिए एक घोड़े का नेतृत्व कर सकते हैं, लेकिन आप उसे पी नहीं सकते।

यह कहना मुश्किल है कि क्या आप "बहुत कठोर हैं", लेकिन अपने साथियों से उन सभी बुनियादी ढांचे को अपनाने की उम्मीद करना अवास्तविक हो सकता है, जिनकी आप उम्मीद करते हैं। और वास्तव में, अगर टीम एक साथ अच्छी तरह से काम कर रही है, तो तीन लोगों के बीच संवाद करने के लिए एक विकी का उपयोग करना संभवतः ओवरकिल है।

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


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

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

22

मेरा दृष्टिकोण यह है कि यदि आप इन परियोजनाओं को छोटी परियोजनाओं पर करना सीख सकते हैं, तो बड़ी परियोजनाओं के साथ आने पर आप तैयार रहेंगे।

यदि वे इस परियोजना के साथ अच्छे विकास अभ्यास का पालन करते हैं, तो उनके पास भविष्य के नियोक्ताओं को दिखाने के लिए कोड होगा, और उनके पास ऐसा अनुभव होगा जो उन्हें कर्मचारियों के लिए मूल्यवान बना देगा।

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

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


8
यह ओपी की मदद करेगा यदि आपने एक टिप्पणी छोड़ दी है कि आपने नीचे क्यों उतारा है।
गुस्ताव बर्तराम

10

मुझे डर है कि आपके द्वारा बताए गए नियम बुनियादी नहीं हैं।

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

गिट रिपॉजिटरी का उपयोग करने के लिए क्या आता है, यह नौसिखियों के लिए दर्द हो सकता है। जब मैं एंड्रॉइड प्रोजेक्ट पर 3 लोगों की टीम में काम कर रहा था, तो हमें पहली बार अपने संस्करण नियंत्रण प्रणाली से बहुत परेशानी हुई। इसलिए मुझे उम्मीद है कि आपके साथियों को भी परेशानी होगी।

आपने उल्लेख किया है कि अनुभवी डेवलपर को परियोजना को पूरा करने में 3-4 दिन लगेंगे (मुझे लगता है कि यह आपकी टीम को 2-3 बार लंबे समय तक ले जाएगा)। यह बहुत कम समय है, इसलिए नए उपकरणों का उपयोग करने वाले तर्क लंबे समय तक काम करने में मदद करेंगे।

आप जो कर सकते हैं वह यह दिखाने के लिए कि वे उपकरण कैसे उपयोग किए जाते हैं, लघु और सरल डेमो बना सकते हैं। सबसे बुनियादी कार्यों को पहले कवर करें, उनकी तरफ से बैठें और उन्हें उपकरण का उपयोग करने में मदद करें। सभी कार्यों को करने के लिए तैयार रहें जैसे गिट को कॉन्फ़िगर करना, विकी पेज संरचना बनाना, आदि।

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


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

कृपया मेरा संपादन देखें।
10

9

मैं वास्तव में इस पर जोएल स्पोलस्की के अपने विचारों को पसंद करता हूं, जैसा कि उन्होंने गेटिंग थिंग्स होन व्हेन यू आर ओनली ए ग्रंट में रखी है । संक्षेप में:

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

अमूल्य जवाब!
वोराक

4

प्रलेखन, विकी, संस्करण सॉफ्टवेयर, कार्यप्रणाली आदि समय के साथ सीखे गए अनुभव और सबक हैं; कई परियोजनाओं के काम और शायद कई टीमों पर। और यह आमतौर पर उन लोगों के साथ रहता है जो पहले से ही कार्यरत हैं या जो अपने उद्योग को गंभीरता से लेते हैं। वे छात्र हैं, इसलिए भविष्य में जो कुछ भी होता है, उनके हित शायद सीमित हैं। :)

लेकिन कोशिश करें और अपने प्रश्न का उत्तर दें:

यदि आप उनके साथ एक टीम में हैं, तो आपको यह लागू करने की आवश्यकता होगी कि आपको क्या लगता है कि इस तरह से महत्वपूर्ण है कि उनके हितों को फायदा हो। एक उदाहरण के रूप में: जब USB इसे साझा करते हैं तो क्या उन्हें अपने कोड को तोड़ने के बारे में शिकायत करनी चाहिए? तब शायद उन्हें एक सरल उपकरण के रूप में SVN (git के बजाय) का उपयोग करने का एक सरल (गैर जटिल) तरीका दिया जाए।

मैं अरनौद की टिप्पणी से भी सहमत हूं।

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


मैं वास्तव में आश्वस्त नहीं हूं कि एसवीएन बड़े पैमाने पर गिट की तुलना में उपयोग करना आसान है। खिड़कियों पर, मैं Mercurial / TortoiseHG की वकालत करूंगा।
पेंगुइन

सच। एसवीएन और जीआईटी के अपने अनुभव में मैंने एसवीएन को उन नए लोगों को समझाने में आसान पाया है जो संस्करण की अवधारणा के लिए हैं।
डेविड 'गंजा अदरक'

2

दृष्टिकोण में समस्याएं हैं:

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

  2. सीखना कठिन है। अन्य लोगों के नियमों का कोई मतलब नहीं है क्योंकि उन नियमों में तार्किक संरचना नहीं है जो आपके प्रोग्रामर उम्मीद कर रहे हैं। उन नियमों को लागू करना जो समझ में नहीं आते हैं, उपयोगी गतिविधि नहीं है।

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

-1

मुझे विश्वविद्यालय में यह बहुत समस्या लगी है। कई लोग बस काम करने का एक अलग (और शायद अधिक पेशेवर दृष्टिकोण) सीखने के लिए तैयार नहीं हैं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.