एक स्थिति लेने से पहले आप एक संभावित नियोक्ता के कोड की गुणवत्ता का पता कैसे लगाते हैं? [बन्द है]

Question

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

अद्यतन करें:

एक चेक-लिस्ट: पूछें;

• वे कोडबेस के बारे में क्या सोचते हैं। और जब आप ऐसा करते हैं, तो चेहरे के भावों पर ध्यान दें और उनके जवाब देने में समय लगता है। [Anon]
• कंपनी का सीएमएम स्तर [डीपीडी] क्या है (और यदि आप सुनते हैं कि स्तर 5 दूसरे तरीके से चलता है [डग टी])
• वे किस जीवनचक्र का उपयोग करते हैं [DPD] (और यदि आप "फुर्तीली" सुनते हैं, तो जब आप "Agile" द्वारा यह पता लगाने की कोशिश करने के लिए कुछ मर्मज्ञ प्रश्न पूछना शुरू करते हैं कि उनका अर्थ "Agile" या "चरवाहा कोडिंग" [CarsB63000] है)
• कोड गुणवत्ता के लिए वे किस उपकरण का उपयोग करते हैं? [डीपीडी]
• वे विकास के लिए किन उपकरणों का उपयोग करते हैं? [DPD] (उपकरण और निरंतर निर्माण सर्वरों को फिर से देखने के लिए देखें)
• वे कौन से स्रोत कोड (संस्करण नियंत्रण) प्रणाली का उपयोग करते हैं, और एक अच्छा अनुवर्ती यह पूछना है कि वे इसका उपयोग क्यों करते हैं। [ज़चारी का]।
• उनकी परीक्षण प्रक्रियाएँ क्या हैं? [कार्ल Bielefeldt] (विशेष रूप से उन टीमों के लिए देखें जो मॉकिंग फ़्रेमवर्क का उपयोग करती हैं और NUnit / JUnit जैसे स्थापित फ्रेमवर्क के माध्यम से पूरी तरह से स्वचालित इकाई परीक्षण पर जोर देती हैं; उन टीमों द्वारा बंद नहीं किया जाना चाहिए जो परीक्षण संचालित विकास जेडडी का उपयोग नहीं करते हैं, लेकिन हो; अगर वे परीक्षण को अभिन्न और ठोस सॉफ्टवेयर विकास की आधारशिला नहीं मानते हैं, तो समर्पित परीक्षणकर्ताओं वाली टीमों की तलाश करें।)
• नए डेवलपर्स को किस प्रकार के असाइनमेंट दिए जाते हैं? अनुभवी डेवलपर्स के लिए? [कार्ल बेवफेल्ड]
• एक परियोजना पर कितने लोग काम करते हैं? [कार्ल बेवफेल्ड]
• क्या रीफैक्टरिंग की अनुमति है? प्रोत्साहित? [कार्ल बेवफेल्ड]
• गुणवत्ता-संबंधी प्रक्रिया या वास्तुकला में बदलाव पर विचार चल रहा है या हाल ही में किया गया है? [कार्ल बेवफेल्ड]
• व्यक्तियों को अपने मॉड्यूल पर कितना स्वायत्तता है? [कार्ल बेवफेल्ड]
• क्या आप नए प्रोजेक्ट्स (ग्रीनफील्ड डेवलपमेंट) या लीगेसी प्रोजेक्ट्स (ब्राउनफील्ड डेवलपमेंट) विकसित कर रहे हैं? (ग्रीनफ़ील्ड विकास आम तौर पर अधिक मज़ेदार होता है और इसमें समस्याएं कम होती हैं क्योंकि आप किसी और की गलतियों से साफ नहीं होते हैं)।
• क्या संगठन या टीम में कर्मचारी की टर्नओवर दर अधिक है? (यह अक्सर कोड की निम्न गुणवत्ता को इंगित करता है) [M.Sameer]
• अपनी खुद की कुछ प्रोग्रामिंग समस्याएं; लेकिन एक झटके की तरह लगने से बचें। [स्पार्की]
• डेवलपर्स कैसे सहयोग करते हैं और टीम के बीच ज्ञान कैसे साझा किया जाता है? (यह आपके व्यक्तित्व से मेल खाना चाहिए; मैं कहूंगा कि एकल और जोड़ी के काम का मिश्रण संभवतः सबसे अच्छा है, आपकी सामाजिक आवश्यकताओं के अनुरूप अनुपात के साथ)
• उनका डेटाबेस 3 नॉर्मल फॉर्म (3NF) के कितना करीब है, और अगर यह कहां और क्यों विचलित होता है? (यदि वे कहते हैं "3NF ???", छोड़ दें। यदि नहीं, और इसके अच्छे कारण नहीं हो सकते हैं, तो पता करें कि वे क्या हैं)।

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

Comments

बे उनके उत्पाद, यह जुदा है, और कुछ पढ़ें।

— जॉब

@Job - भले ही खरीदने के लिए एक सार्वजनिक कार्यक्रम हो, असम्बद्ध कोड isnt संभवत: गैर-संकलित कोड से मिलता जुलता है।

— पी। ब्रायन। मैके

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

— मार्टिन माट

Answer 1

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

फिर अपनी संस्कृति के गैर-मौखिक इशारों पर अपने ज्ञान को लागू करने के लिए यह व्याख्या करें कि वे वास्तव में क्या कह रहे हैं। उत्तर अमेरिकी कंपनी के लिए, निम्नलिखित सटीक होना चाहिए:

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

बेशक, यदि आप अंतर-व्यक्तिगत संचार से परेशान हैं, तो यह आपके लिए काम नहीं कर सकता है।

Comments

लोल .......... :)

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

— जेम्स

मैं किसी ऐसे व्यक्ति से साक्षात्कार करने की उम्मीद करूंगा जो सॉफ्टवेयर को सक्रिय रूप से विकसित कर रहा था; यहां तक ​​कि अगर वे पूरी तरह से एक वास्तुकार थे, तो मुझे उम्मीद थी कि उन्हें लिखा गया कोड पढ़ना होगा।

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

— मेसन व्हीलर

@ नाम - अगर आपको अपने संभावित साथियों द्वारा साक्षात्कार का मौका नहीं मिलता है, तो वह आपको कुछ बताता है, है न? यह निश्चित रूप से मुझे कुछ बताएगा।

— Anon

Answer 2

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

यहाँ आप क्या पता लगाने के लिए कह सकते हैं।

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

Comments

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

और अगर आप ऐसा सुना है "फुर्तीली", है कि जब आप की कोशिश करने के लिए कुछ मर्मज्ञ सवाल पूछ शुरू यह पता लगाने की अगर "फुर्तीली" द्वारा उनका अर्थ "फुर्तीली या" काउबॉय कोडिंग "।

— Carson63000

यूजी, अगर मैंने सीएमएम स्तर 5 सुना, तो मैं दूसरे तरीके से चलूंगा।

— डग टी।

@ Carson63000 '' फुर्तीली '' या '' काउबॉय कोडिंग '' (मुझे लगा कि वे एक ही चीज से बहुत ज्यादा

@ बी टायलर: ज़िंग! लेकिन गंभीरता से, मैंने कई साक्षात्कारकर्ताओं को जाना है जिन्होंने सोचा था कि "एजाइल" की परिभाषा "झरना नहीं" थी; उन्होंने महसूस नहीं किया कि जलप्रपात मॉडल को फेंकने के बाद आपको वास्तव में इसे किसी अन्य प्रक्रिया से बदलने की आवश्यकता थी।

— कार्सन 63000 21

Answer 3

1. उनसे पूछें कि क्या वे स्रोत नियंत्रण का उपयोग करते हैं।
   • कोई स्रोत नियंत्रण? -> कोड सबसे अधिक संभावना है
2. उनसे पूछें कि कोड समीक्षा कितनी बार करते हैं।
   • कोई कोड समीक्षा नहीं? -> कोड संदिग्ध हो सकता है (लेकिन जरूरी नहीं कि, विशेष रूप से अगर यह एक छोटी टीम है जो सभ्य डेवलपर्स से बना है।)
3. उनसे पूछें कि उत्पादन में जाने से पहले वे परीक्षण और तैनाती कैसे करते हैं?
   • कोई परीक्षा का माहौल नहीं? उत्पादन में प्रत्यक्ष तैनाती? -> कोड सबसे अधिक संभावना है।
4. उनसे पूछें कि क्या वे निरंतर एकीकरण (.ie चल रहा है हडसन के साथ)
   • कोई निरंतर एकीकरण नहीं? -> कोड संदिग्ध हो सकता है, लेकिन जरूरी नहीं कि ऐसा हो।
5. (# 3 से संबंधित), उनसे पूछें कि क्या उनका परीक्षण वातावरण आपके विकास के वातावरण से अलग है?
   • टेस्ट देव है? -> एक अच्छा संकेत नहीं, तब तक नहीं जब तक कि वे वास्तव में नकदी-तंगी न हों, लेकिन एक अतिरिक्त बॉक्स कितना महंगा होगा?
6. उनसे पूछें कि क्या वे उत्पादन में तैनात करने से पहले एक कार्रवाई सूची की समीक्षा करते हैं।
   • उत्पादन परिनियोजन से पहले क्रियाओं की समीक्षा नहीं? -> बुरा जूजू।
7. उनसे पूछें कि उन्हें एक निर्माण करने के लिए कितने कदम उठाने होंगे।
   • 3 से अधिक? -> आमतौर पर बुरा जूजू।
8. क्या वे साइक्लोमैटिक जटिलता या LCOM (वर्ग सामंजस्य का एक उपाय) जैसे कोड मेट्रिक्स लेते हैं (या गुप्तचर)।
   • हाँ? -> शायद (लेकिन निश्चित रूप से नहीं) उनकी कोड गुणवत्ता के बारे में एक अच्छा संकेत।
   • नहीं, लेकिन वे अवधारणाओं को समझते हैं (कम से कम चक्रीय जटिलता)? -> कहना मुश्किल है
   • उन्हें लगता है कि साइक्लोमैटिक जटिलता टिम्बकटू से एक विदेशी व्यंजन या कामोद्दीपक है (दूसरे शब्दों में, वे नहीं जानते कि वह क्या है)? -> संभव बुरा जूजू।
   • उन्हें लगता है कि यह अप्रासंगिक बकवास है (या किसी अन्य प्रकार का डिमॉनर)? -> भाग जाते हैं।
9. उनसे पूछें कि वे बग्स पर नज़र कैसे रखते हैं।
   • वे कुछ मीट्रिक (.ie प्रति प्रोजेक्ट, बदले हुए मॉड्यूल की संख्या, या आवश्यकता / परिवर्तन अनुरोधों की संख्या, कुछ!) के खिलाफ # बगों का पता लगाते हैं। -> उनके कोड (और उनकी सॉफ़्टवेयर प्रक्रिया) के बारे में अच्छा संकेत।
   • वे ऊपर एक करते हैं और एक संभावित मीट्रिक (परिवर्तन अनुरोधों, परियोजना आकार, आदि के आधार पर) भविष्य में (या चल रहे) प्रोजेक्ट में आने वाले संभावित बगों की संख्या का अनुमान लगाने का प्रयास कर सकते हैं? -> बहुत अच्छा संकेत।
   • वे बग रिज़ॉल्यूशन के लिए बग का ट्रैक रखते हैं? -> बताना मुश्किल है
   • कोई संगत ट्रैकिंग? -> मैं भाग जाता हूं।

यह मेरे सिर के ऊपर से होगा। आप देखेंगे कि मेरे कुछ प्रश्न सॉफ़्टवेयर डेवलपमेंट प्रक्रिया से संबंधित हैं, न कि केवल कोडिंग पर कड़ाई से। बाद की गुणवत्ता पूर्व की गुणवत्ता का प्रत्यक्ष कार्य है।

इसके साथ ही कहा कि जब आप ये प्रश्न पूछें तो सावधानी के साथ आगे बढ़ें। उनका अध्ययन करें और साक्षात्कार के समय कुछ का चयन करें।

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

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

• btw, मैं पूरे दिल से मानता हूं कि यह एक सॉफ्टवेयर डेवलपर के लिए जरूरी है कि वह कम से कम एक बार किसी प्रकार के परे-आशा (या परे-आशा-पास) कोड के साथ काम करे। आप जीवित रहते हैं और एक अच्छे काम के लिए करते हैं, यह एक मूल्यवान सबक है।

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

जब ऐसा होता है, तो आपको खुद से पूछना होगा कि क्या आपको इस नौकरी की जरूरत है जो खराब है। कभी-कभी आप करते हैं, और आपको स्पेगेटी गंदगी के ढेर में डुबकी लगानी होती है। कभी-कभी आप (मतलब नहीं है, आप बर्दाश्त नहीं कर सकते।)

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

Answer 4

वास्तविक कोड गुणवत्ता के बजाय, मैं ऐसी कंपनी की तलाश करूंगा जहां कोड गुणवत्ता का महत्व अच्छी तरह से समझा जाए।

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

दूसरी ओर, कहते हैं कि कंपनी बी का एक बुरा कोड आधार है, लेकिन प्रबंधन समझता है कि कोड की गुणवत्ता उन सभी बगों और देरी का कारण बन रही है, वे परिवर्तन की आवश्यकता देखते हैं, और वे इसके बारे में कुछ करने को तैयार हैं (जैसे बड़े पैमाने पर) refactoring या यहां तक ​​कि फिर से लिखना)। वह कंपनी अपने कोड आधार में सुधार करेगी, और आप उन्हें ऐसा करने में मदद कर सकते हैं।

मुझे पता है कि मैं कहां काम करना चाहूंगा।

Comments

इससे सिर पर कील लग गई।

— वेन मोलिना

Answer 5

99.9% संभावना है कि आप शुरू करने से पहले कोड नहीं देख पाएंगे। (जब तक कि वे निश्चित रूप से मुफ्त सॉफ्टवेयर उत्पाद नहीं डालते)

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

Comments

... या जब तक वे अपने मालिकाना उत्पाद के साथ स्रोत कोड की आपूर्ति नहीं करते। व्यवसाय की मेरी लाइन (एनएलपी) में, लिंगपाइप को इस तरह से वितरित किया जाता है, और अन्य उत्पादों को स्रोतों के साथ भेजना चाहिए।

— फ्रेड फू

Answer 6

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

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

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

इसलिए, कोड गुणवत्ता का आकलन करने के लिए मैं जो प्रश्न पूछूंगा:

• आपकी परीक्षण प्रक्रियाएँ क्या हैं?
• नए डेवलपर्स को किस प्रकार के असाइनमेंट दिए जाते हैं? अनुभवी डेवलपर्स के लिए?
• एक परियोजना पर कितने लोग काम करते हैं?
• क्या रीफैक्टरिंग की अनुमति है? प्रोत्साहित?
• गुणवत्ता-संबंधी प्रक्रिया या वास्तुकला में बदलाव पर विचार चल रहा है या हाल ही में किया गया है?
• व्यक्तियों को अपने मॉड्यूल पर कितना स्वायत्तता है?

Comments

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

— gnasher729

Answer 7

जैसा कि @DPD और @Zachary ने कहा, प्रक्रिया और एसडीएलसी बहुत महत्वपूर्ण कारक हैं लेकिन मैं कुछ अन्य कारकों को जोड़ना चाहता हूं जो मेरे अनुभव के अनुसार कोड की गुणवत्ता पर महत्वपूर्ण प्रभाव डालते हैं:

• यह पूछें कि क्या आप अपेक्षाकृत नए प्रोजेक्ट में विकास में काम करने जा रहे हैं या विरासत आवेदन को बनाए रखने में। लीगेसी एप्लिकेशन नए प्रोजेक्ट की तुलना में कम साफ होते हैं।
• यह जानने की कोशिश करें कि कर्मचारी की टर्नओवर दर संगठन या टीम में अधिक है या नहीं। इससे कोड की गुणवत्ता भी कम होगी।

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

Comments

मुझे लगता है कि उच्च कारोबार दर की प्रतिक्रिया एक बहुत अच्छा संकेतक है ... असफल परियोजना के पीछे आना आमतौर पर किसी के स्वास्थ्य के लिए अच्छा नहीं है ...

— वेबदाद 3

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

— M.Sameer

Answer 8

मेरा दृष्टिकोण यह है, कोड कोड है, अगर यह बुरा है, तो यह बेहतर बनाने के लिए एक चुनौती है। यदि यह अच्छा है, तो इसे बेहतर बनाने के लिए और भी कठिन चुनौती है!

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

Comments

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

— क्रिस पिटमैन

@ क्रिस, वह पराजित है! ;) खराब कोड के कई कारण हैं, लेकिन अगर वहाँ लोगों का रवैया एक है जो बदलाव के लिए प्रयास करता है, तो क्यों नहीं ??

— निम

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

— क्रिस पिटमैन

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

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

— वेन मोलिना

Answer 9

थोड़ा मजाक में कहता हूं, मेरे साथ साक्षात्कार करो ।

मैं आमतौर पर साक्षात्कार कोड के रूप में हमारे कोड-बेस में एक वास्तविक बग (पहले से तय) का उपयोग करता हूं, इसलिए आप कुछ वास्तविक कोड देखते हैं। आम तौर पर थोड़ा जटिल कोड, और इसमें एक बग है।

मैं इस तकनीक का उपयोग करने के लिए सभी को प्रोत्साहित करता हूं, जैसा कि आप पहले से ही जानते हैं कि बग वास्तविक है, समस्या वास्तविक है, और आप जानते हैं कि इसे खोजने और ठीक करने में कितना समय लगा।

बड़ी बात यह है कि आपको एक मुश्किल से मुश्किल समस्या हो सकती है।

विशेषज्ञों को बहुत अच्छे से अलग करने के लिए मैंने अंतिम साक्षात्कार प्रश्न के रूप में एक बहुत कठिन समस्या का उपयोग किया है।

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

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

बेशक, मानक "यह सब एक कंपनी गुप्त है" जवाब कुल घोड़ा-पक्की है।
मेरा प्रमाण: मेरे पिछले नियोक्ता में, एक सैन्य उत्पाद का एक गैर गोपनीय हिस्सा साक्षात्कार प्रश्न के लिए कोड नमूना था। [सौभाग्य से अवर्गीकृत]

मैं वहां किसी से होशियार होने से पहले वर्गीकृत डिजाइन की गुणवत्ता निर्धारित करने की समस्या को छोड़ देता हूं। मेरा सुझाव है कि यह सामान्य हो सकता है कि वर्गीकृत नि: शुल्क निरीक्षण का पर्याय है।

Answer 10

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

Comments

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

मैं मानता हूं कि यह इसे आगे बढ़ा सकता है, लेकिन मुझे आश्चर्य भी है कि क्या ऐसी परिस्थितियां हैं जहां भावी नियोक्ता तैयार हो सकते हैं - कहते हैं कि शायद उन्होंने एक प्रस्ताव आगे बढ़ाया है? केवल लौकिक बॉक्स के बाहर सोचने की कोशिश कर रहा है (गह, मैं उस अभिव्यक्ति से नफरत करता हूं)।

— स्पार्की

+1 जैसा कि मुझे यह विचार पसंद है, लेकिन जब तक वे वास्तव में आपको पसंद करते हैं, तब तक अधिकांश साक्षात्कारकर्ता आपको एक कूदने के लिए कहेंगे।

— परिक्रमा

Answer 11

यह पूछें कि उत्पादन के निर्माण में कोड बनाने के लिए क्या आवश्यक है। यदि आप 'उह ... देव इसे प्राप्त करते हैं ...' तो यह लगभग निश्चित रूप से कचरा है।

कई चीजें हैं जो कोड की गुणवत्ता बढ़ाने की प्रवृत्ति रखती हैं (जाहिर है, इसकी कोई गारंटी नहीं है)।

• स्थैतिक विश्लेषण (.NET में यह fxcop / stylecop जैसी चीजें हैं)
• परीक्षण सूट का एक सबसेट (या पूर्ण सेट) - यूनिट / एकीकरण / प्रतिगमन / मैनुअल आदि।
• बडी बिल्ड (टीम पर एक अन्य देव परिवर्तन देखने के लिए बनाता है कि क्या कोई मशीन / उपयोगकर्ता पर निर्भर समस्याएं हैं - कभी-कभी एक त्वरित संन्यास चलाने के साथ)
• को़ड समीक्षा

ये न केवल कोड की ताकत, बल्कि कोड की गुणवत्ता में सुधार करने में मदद कर सकते हैं।

Answer 12

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

यदि यह जावा की दुकान है, तो उनसे पूछें कि वे किस ORM लाइब्रेरी का उपयोग कर रहे हैं। यदि उन्होंने अपना रोल कर दिया है, तो यह किसी भी तरह से जा सकता है - यह चूस सकता है, या यह ठीक हो सकता है। यदि वे कोई उपयोग नहीं कर रहे हैं, तो तुरंत दरवाजे के लिए दौड़ें।

यह एक मुश्किल काम है क्योंकि बहुत सारे अलग-अलग बुरे कोडिंग प्रैक्टिस हैं, जो आप कभी भी उन सभी का अनुमान नहीं लगा पाएंगे।

Answer 13

आप दुर्भाग्य से नहीं कर सकते। कोई भी कंपनी आपको उनका कोड नहीं देखने देगी (लेकिन वे आपका कोड देखने के लिए कहेंगे ...), और संभावना है कि यदि आप उनसे पर्यावरण के बारे में सवाल पूछें तो आप या तो एकमुश्त झूठ बोलेंगे ("संस्करण नियंत्रण? जरूर ..?" हम उपयोग करते हैं .. उह .. सोच उप .. उप-कुछ ") या गुणवत्ता के बारे में गुमराह (" हम नवीनतम और सबसे बड़ी .NET 4 का उपयोग कर रहे हैं "केवल यह पता लगाने के लिए कि वे .NET 4 का उपयोग कर रहे हैं ' इसे .NET 1.1 की तरह फिर से लिखना)।

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