क्या एक अच्छे प्रोग्रामर के लिए कभी संस्करण नियंत्रण का उपयोग नहीं किया जा सकता है? [बन्द है]

Question

मैं एक कठिन परिस्थिति को हल करने में मदद करने के लिए एक विशेषज्ञ प्रोग्रामर की तलाश कर रहा हूं।

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

अपने आप में समस्या बहुत गंभीर नहीं हो सकती है क्योंकि यह एक ऐसी चीज है जिसे थोड़े समय में सीखा जा सकता है।

लेकिन एक गहरा पहलू है, जो मुझे चिंतित करता है:

कभी-कभी संस्करण नियंत्रण की आवश्यकता के बिना 10-15 वर्षों के लिए सॉफ़्टवेयर को सक्रिय रूप से विकसित करना कैसे संभव है?

क्या वास्तव में ट्रैकिंग की समस्या के समाधान की तलाश न करना ही प्रोग्रामिंग में गलत रवैये का संकेत है?

Comments

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

— डॉक्टर ब्राउन

@ ई-एमईई निर्भर करता है, आप 30-60 मिनट में अपडेट / हल / कमिट सीख सकते हैं लेकिन कोई यह नहीं सीखता है कि एक (डी) वीकेएस एक घंटे में कैसे काम करता है। अधिकांश पीपीएल जो वर्षों से इसका उपयोग करते हैं वे अभी भी वास्तव में इसे प्राप्त नहीं करते हैं।

— atamanroman

@ConradFrix गाजर का केक :)

— चाड हैरिसन

यह संभव है के लिए एक अच्छा प्रोग्रामर संस्करण नियंत्रण इस्तेमाल नहीं किया है करने के लिए करता है, तो कैलेंडर का कहना है कि आज 1981 है

— Kaz

यह किसी ऐसे व्यक्ति के क्लासिक मामले जैसा लगता है जिसके पास 10 साल का अनुभव नहीं है, बल्कि 1 साल के अनुभव को 10 बार दोहराया गया है।

— जेनी पिंडर

Answer 1

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

हां, इंटरनेट से पहले प्रोग्रामिंग थी।

मैं यह देखने के लिए संघर्ष करता हूं कि आप उद्योग में 10+ वर्ष कैसे खर्च कर सकते हैं, बिना स्रोत नियंत्रण के। लेकिन, मुझे कुछ सहानुभूति होगी, मेरा मानना ​​है कि यह संभव था और मैं उस एक विवरण पर उम्मीदवार को अस्वीकार नहीं करूंगा। मैं जांच कर पता लगाऊंगा कि उम्मीदवार ने इसे कैसे प्रबंधित किया है।

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

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

Comments

+1, यह एक दिलचस्प जवाब है। हालांकि, मैं "उन दिनों में, स्रोत नियंत्रण लागत अच्छे पैसे" से बिल्कुल सहमत नहीं हूं । आरसीएस को लगभग 30 साल हो गए, सीवीएस - 21 साल; दोनों ओपन सोर्स हैं।

— vartec

+1: मैं अब भी यहां काम करता हूं । हम आखिरकार इस वर्ष (मुख्यतः मेरे कारण) प्रबंधित स्रोत नियंत्रण प्राप्त कर रहे हैं। मुझे नहीं लगता कि हम अब तक नहीं होने के परिणामस्वरूप सभी भयानक डेवलपर्स हैं, लेकिन मुझे बहुत खुशी हो रही है कि यह बहुत खुश है

— जैतून-क्लेयर

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

— 13

सही सवाल पूछने के बारे में बात के लिए +1। मैंने सोचा कि उसे सबसे अच्छा उम्मीदवार भी बनाया जाए।

— शमूलेटर

@ रामहुड: और आप मानते हैं कि स्रोत नियंत्रण करते समय मैन्युअल रूप से बैकअप के लिए आपको कम हार्डवेयर और कम समय की आवश्यकता होती है? मेरे अनुभव के विपरीत, बिल्कुल सच है।

— डॉक्टर ब्राउन

Answer 2

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

• अच्छा

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

• खराब

  संस्करण नियंत्रण केवल एक चर्चा है जो धीरे-धीरे उद्योग में मर रहा है। मैं संस्करण नियंत्रण से ऊपर हूं।

Comments

मैं मानूंगा कि यह 10 साल पहले वैध हो सकता था, लेकिन आजकल? मैं इसे "गुड / बैड" नहीं बल्कि "बैड / भयानक"

— कहूंगा

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

— १०:३६ पर

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

— एंडी बूट

इस उत्तर के लिए +1। यह एक अच्छे प्रोग्रामर की निशानी नहीं है कि उसके पास हर हुनर ​​है। यह है कि वह / वह आवश्यक कौशल उठा सकता है।

— स्टीवन

@ उत्तर: नहीं, बिल्कुल नहीं। उस तर्क से, एक 8 वर्षीय व्यक्ति को काम पर रखा जा सकता था क्योंकि वे प्रोग्रामिंग उठा सकते थे। IMO प्रोग्रामर माने जाने के लिए आवश्यक आधार कौशल हैं या होना चाहिए। एक प्रोग्रामिंग भाषा में प्रवीणता एक है, किसी भी VCS का ज्ञान और उपयोग दूसरा है। और भी हैं।

— स्टीवन एवर्स

Answer 3

मुझे आपको 20 वर्षों के लिए डॉस और विंडोज में सॉफ्टवेयर विकास करने से कुछ परिप्रेक्ष्य देना चाहिए।

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

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

कई मामलों में, 90 के दशक के उत्तरार्ध में, प्रारंभिक 00 के दशक में, अगर एक Windows टीम ने VSS का उपयोग नहीं किया, तो वे इन-हाउस सम्मेलनों से अलग स्रोत नियंत्रण के लिए कुछ भी उपयोग नहीं करते थे। उनमें से कई अभी भी टीम फाउंडेशन सर्वर (टीएफएस) के परिष्कार और जीआईटी और एसवीएन जैसे महान मुफ्त विकल्पों के बावजूद वीसीएस का उपयोग नहीं करते हैं।

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

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

Comments

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

— alroc

@alroc - मानो या ना मानो, वहाँ कुछ कम विश्वसनीय और अधिक quirky वाले थे। मुझे 1995 के एक सर्का का उपयोग करने का दुर्भाग्य था। मुझे वीएसएस विश्वसनीयता के साथ कोई गंभीर समस्या नहीं थी लेकिन मैंने दूसरों से शोक की दास्तां सुनी। मैं कुछ संगठनों को जानता हूं जिन्होंने वीएसएस के साथ बुरे अनुभवों के बाद किसी भी वीसीएस का उपयोग बंद कर दिया।

— jfrankcarr

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

— ग्रैंडमास्टरबी

मैंने एक दुकान पर 1.5 साल तक काम किया जिसमें विजुअल सोर्स सेफ का इस्तेमाल किया गया था। सबसे अच्छे प्रोग्रामर्स में से एक रिपॉजिटरी को हर बार फोन पर अपने कोड में जांचने की कोशिश करने के बारे में बर्बाद कर देगा (हाँ, यह कुछ समय पहले था)। मेरी सबसे कम पसंदीदा VCS प्रणालियों में से एक।

— GlenPeterson

हमने DOS के वातावरण में एक नौकरी पर tlib ( burtonsys.com/index.html ) का उपयोग किया । यह 2005 में था, लेकिन ऐसा लग रहा था कि वे कुछ समय के लिए इसका इस्तेमाल कर रहे थे।

— डग टी।

Answer 4

क्या आपके पास संस्करण नियंत्रण सॉफ़्टवेयर के बिना संस्करण नियंत्रण नहीं हो सकता है? पूछें कि उन्होंने अपना कोड कैसे प्रबंधित किया। शायद पहले से ही घर में रहने वाली प्रणाली थी।

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

प्रतिभा को खोजने की कोशिश करते समय, आपको बीच का अंतर बताने में सक्षम होना चाहिए: नहीं, नहीं और नहीं।

Comments

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

— orlp

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

— फिलिप

Answer 5

संस्करण नियंत्रण का उपयोग नहीं करने के लिए कोई बहाना नहीं है, यहां तक ​​कि एकल डेवलपर द्वारा विकसित एक छोटी परियोजना के लिए भी। स्थानीय संस्करण नियंत्रण स्थापित करना तुच्छ से परे है, बहुत बड़ा लाभ है। कोई भी डेवलपर यह नहीं जानता कि उसे अच्छा नहीं माना जा सकता है और न ही अनुभवी।

संस्करण नियंत्रण को "नवीनता" मानने वाली कंपनियों के लिए, जिसे वे शुरू करने के लिए तैयार नहीं हैं:

• SCCS 1972 ( 40 साल पहले ) में जारी किया गया था
• आरसीएस 1982 ( 30 साल पहले ) में जारी किया गया था , और यह पूरी तरह से खुला स्रोत और मुफ्त है
• सीवीएस 1990 ( 21 साल पहले ) में जारी किया गया था , यह भी पूरी तरह से खुला स्रोत और मुफ्त

Comments

यकीन नहीं है कि SVN "तुच्छ से परे" सेटअप के लिए सबसे अच्छा उदाहरण है। उन फाइलों में से कुछ जिन्हें आपको एडिट करना है, रेपो में डायरेक्ट करना है, फिडली हो सकता है। एक स्थानीय डीवीसीएस स्थापित करना तुच्छ से परे है। और BitBucket / GitHub खाता सेट करना और इससे रिपॉजिट करना अधिक जटिल नहीं है

— pdr

@vartec: क्या तुच्छ से परे है git init। जुड़ा हुआ पेज मुझे काफी जटिल लग रहा है क्योंकि मैं भाग सकता हूं।

— Maaartinus

@vartec: मैं तर्क दूंगा कि git और hg को VCS नौसिखिया द्वारा समझने में आसान है, जो किसी व्यक्ति ने वर्षों से केंद्रीकृत VCS का उपयोग किया है, और नौसिखिया के लिए CVCS की तुलना में आसान है। बस उस पृष्ठ पर रिपॉजिटरी लेआउट अनुभाग को देखें जैसे कि आप इसे पहले से ही नहीं समझ पाए हैं। फिर सोचें "मेरे पास यहां एक भंडार है, मैं इसे यहां क्लोन करना चाहता हूं।"

— पीडीआर

@vartec: हम्म। सहमत नहीं हो सकते। जब मैं अकेले काम कर रहा होता हूं, तब भी मैं शाखा लगाना और क्लोन करना पसंद करता हूं। कभी-कभी मेरे पास विचार आते हैं। और कभी-कभी वे बुरे होते हैं :)।

— पीडीआर

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

— पिकारस

Answer 6

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

Comments

मैं असहमत हूं। स्रोत नियंत्रण का उपयोग नहीं करने के लिए सामान्य की तुलना में अन्य प्रोग्रामर के साथ उच्च स्तर के सहयोग की आवश्यकता होगी। मैं यहां तक ​​कह सकता हूं कि यदि आप ऐसे वातावरण से आए हैं जहां कोई स्रोत नियंत्रण नहीं है, तो आप वास्तव में सहकारिता के महत्व को जानते हैं

— जैतून-क्लेयर

यह एक शानदार व्यापक बयान है और वर्तमान में असत्य है।

— मर्फ़

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

— जेसपेरे

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

— ग्योर्गी एंड्रेसेक

इतने सारे लोगों को देखने के लिए डरावना वास्तव में स्रोत नियंत्रण की कमी को सामान्य या स्वीकार्य के रूप में पाते हैं।

— JesperE

Answer 7

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

Comments

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

— होऊंगा

@LordScree - एक उच्च-वॉल्यूम वेबसाइट पर काम करना आपके लिए मुश्किल हो सकता है, लेकिन आप अभी भी अपनी नौकरी के बाहर स्रोत नियंत्रण का उपयोग करना सीख सकते हैं।

— जेएफओ 12

Answer 8

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

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

आपको जो प्रश्न पूछना चाहिए, वह यह है कि स्रोत नियंत्रण के अभाव में उन्होंने कैसे प्रबंधन किया? यह आपको उसके बारे में कुछ बता सकता है और वह अपने काम का प्रबंधन कैसे करता है।

Comments

निश्चित रूप से पता लगाने के लिए वह अपडेट प्रबंधित की जरूरत है, विज्ञप्ति आदि संस्करण नियंत्रण के बिना

— ChrisF

Answer 9

आप उसके अनुभव के बारे में बहुत सारी जानकारी छोड़ देते हैं।

मूल रूप से, मैं कहूंगा कि यह बहुत संभव है कि एक प्रोग्रामर को संस्करण नियंत्रण के बारे में जानने के बिना 10-15 साल का अनुभव हो सकता है। 10 वर्षों के लिए कोडिंग लगातार 10 वर्षों तक नई प्रोग्रामिंग तकनीकों को सीखने के बराबर नहीं है।

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

सौभाग्य।

Answer 10

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

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

Answer 11

मैं यहाँ कुछ न्यायिक उत्तर देख रहा हूँ जो वास्तव में उस व्यक्ति को ध्यान में नहीं रखते हैं।

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

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

अंत में, आपके प्रश्न का उत्तर यह है: इस प्रोग्रामर को उसके कौशल, उसके दर्शन और उसके निर्णयों से जज करें, न कि (पूर्व में भ्रामक) निर्णय लोगों द्वारा उसकी पूर्व नौकरियों में किए गए।

Comments

यदि आपने केवल 15 वर्षों के लिए बेवकूफों के साथ काम किया है, और पक्ष में कोई भी बुद्धिमान खुला स्रोत नहीं किया है, तो संभवतः यह आपके कौशल सेट और दृष्टिकोण पर प्रतिबिंबित करेगा। लोग अपने वातावरण से आकार लेते हैं। अगर ऐसा नहीं होता, तो हम किसी के रोजगार इतिहास को भी क्यों देखेंगे।

— काज़

@ काज़ हम उनके रोजगार इतिहास को उनके सहकर्मियों के इनपुट के लिए नहीं बल्कि उनके स्वयं के इतिहास पर देखते हैं। वे जिस क्षेत्र में पले-बढ़े हैं उस पर किसी का न्याय नहीं कर सकते हैं अन्यथा हम पड़ोसियों का भी साक्षात्कार लेना शुरू कर सकते हैं।

— जेम्स खूर्नी

हमारे वातावरण के अनुसार, हां, लेकिन हम अपने वातावरण से परिभाषित नहीं हैं। मैं सिर्फ सुझाव दे रहा हूं कि ओपी प्रोग्रामर का पूरा ध्यान रखें और एक मापदंड के आधार पर कठोर निर्णय न लें।

— cdkMoose 15

Answer 12

मैंने खुद को कभी भी "प्रोग्रामर" नहीं माना, जब तक कि मैंने इसे पेशेवर रूप से करने के लिए पैसा नहीं बनाया।

मैंने काफी पैसा बनाने वाली प्रणाली बनाई है जिसने ग्राहकों को और अधिक पैसा दिया है। चाहे मैं एक "अच्छा" डेवलपर व्यक्तिपरक हूं या नहीं।

मैं तेजी से जीएसडी (गेट समथिंग डन) प्राप्त कर सकता हूं, जो वेब विकास के लिए आमतौर पर मेरे ग्राहकों को प्रसन्न करता है। वे पर्दे के पीछे कुछ बदसूरत कोड, टिप्पणियों की कमी आदि नहीं देख सकते हैं।

मैंने इस वर्ष तक Git का उपयोग नहीं किया था और एक Github प्रोफ़ाइल नहीं थी, जो मुझे लगता है कि आधुनिक प्रोग्रामर मानकों के संदर्भ में "समय के पीछे" है। मैंने भी केवल पिछले दिनों PHP, Flash और iOS करने के बाद रेल और Django प्रोजेक्ट्स करना शुरू किया है। जब से मैंने ग्राहकों और मेरे लिए दोनों में विकासशील स्थलों को अनुबंधित किया है, 30 साल की उम्र में कुछ नया सीखना और कुछ साल प्रोग्रामिंग से बाहर रखना बहुत दर्दनाक नहीं है।

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

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

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

Answer 13

मुझे यह अविश्वसनीय लगता है कि एक सॉफ्टवेयर पेशेवर ने कभी भी स्रोत नियंत्रण का उपयोग नहीं किया है, और मैं उसे काम पर रखने के बारे में बहुत परेशान हूं।

उसके पास क्या अनुभव है। मुझे आश्चर्य होगा कि वह और क्या नहीं जानता है कि आपको अभी तक पता नहीं चला है।

आपके सॉफ्टवेयर विकास का अनुभव क्या है? क्या आप उनसे आर्किटेक्चर, डिज़ाइन पैटर्न, सामान्य सॉफ़्टवेयर डेवलपमेंट समस्याओं, सिस्टम प्रदर्शन प्रश्नों, सिस्टम सुरक्षा प्रश्नों आदि के बारे में पूछने की स्थिति में हैं?

यदि वह उस प्रकार के सामान पर मजबूत निकला, तो शायद मैं स्रोत नियंत्रण ज्ञान की कमी को नजरअंदाज कर सकता हूं।

Answer 14

क्या एक अच्छे प्रोग्रामर के लिए कभी संस्करण नियंत्रण का उपयोग नहीं किया जा सकता है?

हाँ। स्वयं सिखाया प्रोग्रामर के साथ कई छोटी कंपनियां इसका उपयोग नहीं करती हैं।

कभी-कभी संस्करण नियंत्रण की आवश्यकता के बिना 10-15 वर्षों के लिए सॉफ़्टवेयर को सक्रिय रूप से विकसित करना कैसे संभव है?

मैंने व्यक्तिगत रूप से 2 छोटी कंपनियों के लिए संस्करण नियंत्रण पेश किया है, 1 मध्यम कंपनी को कुछ भगवान से भयानक SVN (उस समय सबसे अच्छा विकल्प) में उन्नत किया है और एक और छोटी कंपनी में काम किया है जिसमें केवल कुछ VC थे, कुछ कोड के लिए अपना स्वयं का VC समाधान लिखा था और बहुत सारे कोड थे किसी भी VC में नहीं।

क्या वास्तव में ट्रैकिंग की समस्या के समाधान की तलाश न करना ही प्रोग्रामिंग में गलत रवैये का संकेत है?

वैसे यह एक त्वरित विफल नहीं है, लेकिन मैं निश्चित रूप से बहुत से अनुवर्ती प्रश्न पूछ रहा हूं। इस तरह की चीजें:

क्या आपने कभी किसी वीसी सॉफ्टवेयर की कोशिश की है? क्या? तुम इसके बारे में क्या सोचते हो? क्या कोई कारण है कि आप इसका उपयोग नहीं करेंगे? कोड को प्रबंधित करने से पहले आपने क्या उपयोग किया है? क्या आपने समान कोड आधार पर पहले किसी के साथ काम किया है, और झड़पों से बचने के लिए आपने किन तरीकों का इस्तेमाल किया?

Comments

इस जवाब में कुछ भी नया नहीं है।

— पीडीआर

स्मार्ट स्व-सिखाया प्रोग्रामर आज सभी संस्करण नियंत्रण के बारे में जानते हैं और इसका उपयोग करते हैं। बाकी उनके सिर कहीं अटक गए हैं।

— काज़

@ काज असहमत। मुझे लगता है कि हम जैसा सोचते हैं, वैसा ही होता है, लेकिन मैं उन प्रोग्रामर्स से मिलूंगा जिन्हें मैं स्मार्ट समझूंगा, जैसा कि मेरा व्यक्तिगत अनुभव कहता है। संस्करण नियंत्रण का उपयोग नहीं करना एक बड़ा चेतावनी संकेत है कि वे अपना सिर कहीं अटक सकते हैं [आकर्षक वाक्यांश :-)] लेकिन यह हमेशा मामला नहीं होता है।

— जेम्स

Answer 15

मैं विस्फोट गोलियों से सहमत होना चाहता हूं (लेकिन मेरे प्रतिनिधि बहुत कम, एटीएम ...) ... रवैया कहीं अधिक महत्वपूर्ण है।

देखने के लिए कुछ चीजें हैं, जो मेरा मानना ​​है कि प्रोग्रामिंग उत्कृष्टता के लिए बनाते हैं:

1. संचार
2. रचनात्मकता
3. करुणा (कहो क्या?)

और, अक्सर, थोड़ा ओसीडी से अधिक।

आप प्रकार जानते हैं ... जो एक समस्या पर हथौड़ा मारते हैं, वे पूरी तरह से अपने कोड में खुद को खो देते हैं क्योंकि वे विकल्प तलाशते हैं। ये वे हैं जो नोट लेते हैं जैसे वे साथ जाते हैं, अपने कोड में टिप्पणी छोड़ देते हैं ताकि यह सुनिश्चित हो सके कि वे अपने स्वयं के तार्किक पथों को समझते हैं (और अपने या अन्य प्रोग्रामर के लिए रास्ता तय करने के लिए जिन्हें भविष्य में कोड से निपटना पड़ सकता है। .. इस प्रकार, ऊपर मेरी सूची में "करुणा"!), और जल्दी से और स्पष्ट रूप से स्पष्ट रूप से जटिल विचार श्रृंखला निर्माताओं को निर्णय लेते हैं ताकि समस्याओं को कुशलता से संबोधित किया जा सके।

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

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

Answer 16

कभी-कभी संस्करण नियंत्रण की आवश्यकता के बिना 10-15 वर्षों के लिए सॉफ़्टवेयर को सक्रिय रूप से विकसित करना कैसे संभव है?

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

क्या वास्तव में ट्रैकिंग की समस्या के समाधान की तलाश न करना ही प्रोग्रामिंग में गलत रवैये का संकेत है?

यदि आपका उम्मीदवार टीम विकास (कम से कम 4 या अधिक प्रोग्रामर) वातावरण में रहा है तो यह एक तुच्छ प्रश्न है। हालांकि, प्रोग्रामर के बीच एक कार्य विभाजन हो सकता है, पूरी तरह से उन्हें सौंपे गए मॉड्यूल पर काम किया जाता है, जो कोड को स्रोत नियंत्रण की आवश्यकता को कम कर सकता है।

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

Comments

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

— डैन नीली

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

— काज़

Answer 17

मामलों का अनुभव करें और आप सही हैं कि स्रोत नियंत्रण उपकरण का उपयोग करने वाले यांत्रिकी को बहुत जल्दी सीखा जा सकता है। लेकिन आपको लाल झंडा देखना सही है।

• क्या आपका उम्मीदवार पेशे और उसकी प्रवृत्तियों से अलग है?
• क्या एक टीम में काम करने के कई अन्य पहलुओं को भी सीखने की जरूरत होगी?

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

हालांकि, वह वहां पहुंच गया, अगर वह एक दशक या उससे अधिक समय तक अकेला भेड़िया रहा है, तो यह मुश्किल से लोगों के साथ रह सकता है।

यह पूछने लायक हो सकता है कि क्या आपका उम्मीदवार कुछ अधिक संभावित प्रश्न कर रहा है।

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

वह अपने तरीकों, प्रक्रियाओं और लगभग एकमात्र सॉफ्टवेयर विशेषज्ञ की भूमिका में होने के कारण लगभग पूर्ण नियंत्रण रखने के आदी हो सकते हैं। आप किसी ऐसे व्यक्ति को चाहते हैं जो चीजों को करने के नए तरीके के लिए खुला होगा। और सवाल:

• मुझे उस समय के बारे में बताएं जब आपने कोडिंग मानक बनाने या उपयोग करने में मदद की थी?
• कोडिंग मानक में आप किस प्रकार की चीजों को देखना चाहते हैं?
• आपको किसी और के कोड को फिर से लिखने के बारे में कैसा महसूस होता है?
• मुझे उस समय के बारे में बताएं जब आप सॉफ़्टवेयर या प्रलेखन की सहकर्मी समीक्षाओं में शामिल थे?
• क्या आप मुझे किसी सॉफ्टवेयर विकास के प्रस्ताव या अनुबंध के बारे में बता सकते हैं जो आप लेखन में शामिल थे?
• मुझे अपने पसंदीदा सॉफ़्टवेयर प्रबंधक या पर्यवेक्षक के बारे में बताएं?
• मुझे अपने पसंदीदा सहकर्मी या अधीनस्थ के बारे में बताएं?

Answer 18

वर्ष 2012 में, 15 साल के उद्योग के अनुभव वाले किसी व्यक्ति के लिए कभी भी संस्करण नियंत्रण का उपयोग नहीं किया गया लाल झंडा है। हो सकता है कि ऐसा कोई लाल झंडा न हो अगर वर्ष 1982, या 1992 भी था। लेकिन आज, उस डेवलपर की पृष्ठभूमि में इस गूढ़ अंतराल के लिए एक उत्कृष्ट स्पष्टीकरण था।

असाधारण स्थितियों में असाधारण स्पष्टीकरण की आवश्यकता होती है।

यह कुछ हद तक एक कार मैकेनिक की तरह है जो दावा करता है कि वह 15 वर्षों से कारों को ठीक कर रहा है, लेकिन कभी भी खुद पर ग्रीस का एक निशान नहीं मिला।

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

यदि आप किसी ऐसे अनुभवी व्यक्ति का साक्षात्कार कर रहे हैं जो मानता है कि उसके पास कोई संस्करण नियंत्रण अनुभव नहीं है, तो वह शायद अपने अनुभव में से कुछ को अतिरंजना या गढ़ रहा है (और यह भी नहीं जानता कि संस्करण नियंत्रण व्यापक रूप से उपयोग किया जाता है और महत्वपूर्ण है, और कुछ उसे झूठ भी बोलना चाहिए! )

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

यहां तक ​​कि कंप्यूटर विज्ञान से भी नई ग्रेड्स को संस्करण नियंत्रण के साथ निष्क्रिय परिचित होने की उम्मीद की जा सकती है, भले ही उन्होंने अभी तक इसका व्यापक उपयोग न किया हो।

Comments

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

— इज़काता

हां, और क्योंकि वे नए स्नातक हैं, हम "खरीद" करते हैं और आगे बढ़ते हैं।

— काज़

"पासिंग परिचितता" (मुझे क्या लगता है कि आप उत्तर में इसका मतलब है) का मतलब है कि उन्होंने इसका इस्तेमाल किसी बिंदु पर किया है; मैं इंगित कर रहा हूँ कि आप भी उम्मीद नहीं कर सकते।

— इज़काता

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

— काज

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

— डेफेनेस्ट्रेशनडाई

Answer 19

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

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

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

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

Comments

डेटाबेस से SQL स्क्रिप्ट उत्पन्न करने के लिए DBA से पूछें और फिर वह स्क्रिप्ट को स्रोत नियंत्रण में रख सकता है।

— linquize

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

— तीमुथियुसविमेन

Answer 20

मेरा अपना 2 सी है, यह इस बात पर निर्भर करता है कि उसने वीसी के बारे में पूछे जाने पर कैसे प्रतिक्रिया दी। संभावित प्रतिक्रियाएं हो सकती हैं:

1. है ना? वह क्या है
2. इसके बजाय हमने नहीं किया
3. कोई शर्मनाक फेरबदल नहीं , प्रबंधन हमें अनुमति नहीं देगा
4. कोई शर्मिंदा फेरबदल , लेकिन मैं अपने आप को एक छोटे से जांच की और यह कुछ हम क्या करना चाहिए की तरह देखा सोचा।

4 के मामले में, लड़के को मुझसे पास मिलेगा, उसके पास सही रवैया है और शायद वह इसे ठीक कर लेगा। 3 के मामले में, उसे यह समझने का श्रेय जाता है कि यह कुछ ऐसा होना चाहिए, लेकिन उतना क्रेडिट नहीं होना चाहिए। 4. यदि वह वीसी के बारे में कुछ तथ्यों का नाम रखने में सक्षम था (वीसी के कुछ पैकेजों की सूची तैयार करें) I d कुछ जिज्ञासा के सबूत के रूप में उसे ले सकता है और उसे पास कर सकता है।

यदि उसने 1 या 2 का उत्तर दिया, अर्थात, यदि वह जानता था और वीसी के बारे में जानने की परवाह नहीं करता था, तो मैं उम्मीदवार के निर्णय पर गंभीरता से सवाल उठाऊंगा। अन्य उपकरण (बग ट्रैकिंग, क्वालिटी मेट्रिक्स, बिल्ड ऑटोमेशन आदि) होंगे, जिनके साथ उसे काम करने की आवश्यकता होगी और आप शायद इन सभी मुद्दों पर एक कठिन लड़ाई करेंगे यदि वह नई कोशिश करने के लिए तैयार नहीं है। दृष्टिकोण।

यहां ज्यादातर लोगों की तरह, मुझे लगता है कि उम्मीदवार को नुकसान पहुंचाना अनुचित होगा क्योंकि उनके नियोक्ता की गति तक नहीं थी; मेरे लिए, यह सब इस बात पर निर्भर करता है कि उन्होंने इस पर क्या प्रतिक्रिया दी।

Answer 21

जब वापस देखा जाए तो जो लिखा है वह अच्छा है। इसने मुझे बहुत बार बचाया है जब पता लगा कि क्या गलत है और समस्याओं का भार जल्दी से तय हो गया क्योंकि मैंने इसे लिखा था। मेरी राय में, एक लॉग रखना अच्छा है। खासकर अगर आप खुद से ज्यादा लोगों के साथ प्रोग्रामिंग कर रहे हैं।

यदि आप एक वेब ऐप लिख रहे हैं, तो आप नो वर्जन कंट्रोल के साथ फ़ोटोग्राफ़र जोड़ सकते हैं क्योंकि आप लगातार इसमें नई चीज़ें जोड़ रहे हैं। लेकिन हो सकता है कि आप नई चीजों के साथ एक लॉग या एक समाचार पोस्ट लिखेंगे।

यह सब आप पर प्रोग्रामिंग कर रहे हैं के बारे में है।

Answer 22

मैंने उन स्थानों पर काम किया है जहाँ सॉफ्टवेयर को मंजूरी मिलने की प्रक्रिया 12 से 18 महीने थी। यदि यह पहले से ही अनुमोदित सॉफ़्टवेयर की सूची में नहीं था, तो मशीनों पर इसे प्राप्त करने का कोई तरीका नहीं था। सीडी / डीवीडी ड्राइव को बंद कर दिया गया था, और मशीनें इंटरनेट से जुड़ी नहीं थीं।

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

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

मुझे पता है कि डेवलपर्स ने केवल इन स्थितियों में काम किया है। वे इन उपकरणों का उपयोग करना चाहते हैं, वे इन उपकरणों का उपयोग करना पसंद करेंगे, लेकिन उन्हें इन उपकरणों का उपयोग करने की अनुमति नहीं है।

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

Comments

इस जवाब में कुछ भी नया नहीं है।

— पीडीआर

Answer 23

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

Comments

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

— कज़

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

— कज़

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

— कज़

Answer 24

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

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

अगर मैं अभी भी इस बिंदु पर मेनफ्रेम पर काम कर रहा था, तो यह पूरी तरह से संभव है कि मैं अभी भी कभी भी औपचारिक संस्करण नियंत्रण प्रणाली के संपर्क में नहीं आया हूं; विकल्प जो विशेष रूप से समर्थित हैं, क्लियरकेस और तर्कसंगत हैं, जिनमें से कोई भी मुफ्त नहीं है (और वास्तव में दोनों काफी महंगे हैं)।

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

Answer 25

मान जाओ ना! हमारे समुदाय की संपूर्णता उच्च-विकसित सामाजिक समुदायों में नहीं रहती है, जहां geeky हैंगआउट और हैकी ईवेंट अत्यधिक प्रचुर मात्रा में हैं, न ही हम सभी सॉफ्टवेयर विकास कंपनियों में काम करते हैं और हम में से कुछ भी प्रासंगिक या अद्यतित संसाधन नहीं खोज सकते हैं हमारी मूल भाषाओं में, मुद्रित या ऑनलाइन, कभी भी एक साथी प्रोग्रामर का मांस में सामना करते हैं।

सभी के लिए मैं समझ सकता हूं, अगर वह एक अनुभवी सॉफ्टवेयर डेवलपर है जैसा कि आप कहते हैं, तो वह एक अकेला भेड़िया है जो छोटे व्यवसायों के लिए एक फ्रीलांसर के रूप में काम कर रहा है।

Answer 26

संस्करण नियंत्रण का उपयोग नहीं करने के कुछ संभावित कारण हैं:

1. उन कंपनियों में काम करना जो सॉफ्टवेयर विकास को अपने व्यवसाय की मुख्य पंक्ति के रूप में नहीं कर रहे हैं।
2. या अगर डेवलपर ने कुछ अन्य प्रणाली का उपयोग करने का निर्णय लिया है - केवल अनुभवी लोगों के लिए मान्य है।
3. या अगर डेवलपर ने अभी तक नहीं सीखा है कि प्रत्येक सिस्टम कैसे काम करता है
4. या यह उपकरण के खिलाफ रवैया समस्या है जो वे अपरिचित हैं

लेकिन जब आप मानने वाले लोगों से मिलते हैं तो आपको सावधान रहना चाहिए:

1. कि कुछ करने का एक ही तरीका है
2. या कि हर प्रोग्रामर को इसे उसी तरह करना चाहिए जैसे वे कर रहे हैं
3. या यह कि जिन प्रथाओं का लोग उपयोग कर रहे हैं उन्हें बदलना आसान है

Answer 27

बस के रूप में संभव के रूप में यह एक गरीब प्रोग्रामर के लिए संस्करण नियंत्रण पर एक विशेषज्ञ होने के लिए है। मेरा कहना है, मुझे नहीं पता कि आपके प्रोग्रामिंग कौशल या समस्या सुलझाने की क्षमताओं के लिए संस्करण नियंत्रण क्या करता है। यह अनुभव का सवाल है। कई छोटी दुकानें या तो इसका उपयोग नहीं करती हैं या इसे इंडवेड्यूल्स (जो अक्सर एकल काम कर रही हैं) को छोड़ देती हैं ताकि वे इसे अपने लिए समझ सकें।

Answer 28

मुझे लगता है कि यह इतना अधिक का सवाल नहीं है "कैसे यह संभव सक्रिय रूप से कभी संस्करण नियंत्रण की आवश्यकता होगी,? बिना 10-15 साल के लिए सॉफ्टवेयर विकसित करने के है", लेकिन "कैसे यह सक्रिय रूप से के लिए सॉफ्टवेयर विकसित करने के लिए संभव है पिछले कभी बिना 10-15 वर्ष संस्करण नियंत्रण की आवश्यकता है? "।

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

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