अमूर्त (जैसे LINQ) का उपयोग इतना वर्जित क्यों है? [बन्द है]

Question

मैं एक स्वतंत्र ठेकेदार हूं और इस तरह, मैं नए गिग्स के लिए वर्ष में 3-4 बार साक्षात्कार करता हूं। मैं अब उस चक्र के बीच में हूं और एक अवसर के लिए ठुकरा दिया, हालांकि मुझे लगा कि जैसे साक्षात्कार अच्छा गया। इस साल भी ऐसा ही हुआ है।

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

साक्षात्कारकर्ता के अनुसार, मुख्य बात यह थी कि मुझे निचले-स्तर, व्यवस्थित रूप से विकसित किए गए एल्गोरिदम की बजाय अमूर्त (जैसे LINQ) के उपयोग की ओर बहुत अधिक झुकाव था।

सतह पर, यह समझ में आता है - वास्तव में, इसने अन्य अस्वीकारों को भी समझ में आता है क्योंकि मैं LINQ के बारे में उन साक्षात्कारों में भी दोष देता था और ऐसा नहीं लगता था कि साक्षात्कारकर्ता LINQ के बारे में ज्यादा जानते थे (भले ही वे .NET थे। लोग)।

तो अब मैं इस सवाल से बच गया हूं: यदि हमें "दिग्गजों के कंधों पर खड़ा होना" और हमारे लिए उपलब्ध अमूर्त (जैसे LINQ) का उपयोग करना चाहिए, तो कुछ लोग इसे इतना वर्जित क्यों मानते हैं? अगर यह अतिरिक्त लागत के बिना समान लक्ष्यों को पूरा करता है तो "शेल्फ से कोड" को खींचने का कोई मतलब नहीं है?

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

मैं यहाँ LINQ पर ध्यान केंद्रित करने का मतलब नहीं है। मुझे यकीन है कि जेएवीए दुनिया में कुछ तुलनीय है, मैं सिर्फ यह जानना चाहूंगा कि कुछ लोग अमूर्त का उपयोग करने के विचार से इतने असहज क्यों हो जाते हैं कि वे खुद नहीं लिखते।

अपडेट करें

जैसा कि यूफोरिक ने बताया, जावा दुनिया में LINQ की तुलना में कुछ भी नहीं है। इसलिए, यदि आप .NET स्टैक पर विकास कर रहे हैं, तो हमेशा इसका उपयोग करने का प्रयास क्यों न करें? क्या यह संभव है कि लोग पूरी तरह से यह नहीं समझते कि यह क्या करता है?

Comments

मुझे लगता है कि आपको नहीं पता कि "अमूर्त" क्या है, क्योंकि LINQ का इससे कोई लेना-देना नहीं है।

— व्योम

"मुझे यकीन है कि जावा दुनिया में कुछ तुलनीय है" वास्तव में, LINQ कुछ चीजों में से एक है, जो .NET है और जावा है।

— व्योम

@ जश्न - LINQ नहीं करता है सार ऐसे छंटाई और उदाहरण के लिए छानने के रूप में कार्य के निचले स्तर काम दूर? मुझे पूरा यकीन है कि objectCollection.Where(oc=>oc.price > 100)उदाहरण के लिए कुछ अतिरिक्त कोड होगा । यह एक अमूर्त का उपयोग नहीं होगा? शायद आप मुझे बता सकते हैं कि मैं यहां क्या याद कर रहा हूं। । ।

— मैट कैसहैट

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

यदि आप LINQ को समझते हैं लेकिन आपके साक्षात्कारकर्ता नहीं हैं, तो आप उनसे बेहतर हैं। अपनी जगहें अधिक सेट करें।

— २३:२० बजे जे बाज़ुजी

Answer 1

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

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

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

Comments

@MatthewPatrickCashatt आप linq स्टेटमेंट वाले तरीकों के अंदर डीबगर को संपादित और जारी नहीं रख सकते। यह एक टर्नऑफ के लिए पर्याप्त नहीं है कि मैं इसका उपयोग नहीं करता हूं; लेकिन यह मुख्य कारण था कि मैं थोड़ी देर के लिए ऐसा करने में हिचकिचाया।

— डैन नीली

+1, विशेष रूप से दूसरे पैराग्राफ के लिए। यह पूरी तरह से मुझ पर लागू होता है, क्योंकि मैं LINQ का उपयोग किए बिना C # कोड पर काम करने के लिए पूरी तरह से दुखी हो जाएगा।

— आर्सेनी मूरज़ेंको 20

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

— jmoreno

+1 लेकिन यह दूसरे तरीके से भी काम कर सकता है। अगर कोई मुझे बताता है कि उन्होंने मुझे नौकरी नहीं दी क्योंकि मैं अपने रोल को बनाने के बजाय पार्सर्स बनाने के लिए Yacc का उपयोग करता हूं, तो यह कहीं और नहीं है, मैं वैसे भी काम करना चाहता हूं।

— स्पेंसर रथबुन

@MatthewPatrickCashatt: यह उत्तर (और इस पर मेरी टिप्पणी) LINQ के लिए विशिष्ट नहीं है, लेकिन सामान्य कथन हैं। लेकिन LINQ के लिए, यहाँ संक्षेप में C # 4.0 / 5.0 का एक अंश है, LINQ के साथ प्रदर्शन समस्याओं के बारे में बात कर रहा है। सामान्यताओं पर वापस: बहुत सारे मामलों में प्रदर्शन हिट अच्छी तरह से लायक होगा, 5% +/- अप्रासंगिक होने के कारण। लेकिन कभी-कभी यह बड़ा होगा और कभी-कभी .1% भी अस्वीकार्य है। अगर आपको नहीं लगता कि कभी कोई मुद्दा हो सकता है, या यह प्रदर्शन केवल Google जैसी कंपनियों के लिए ही है ....

— jmoreno

Answer 2

कुछ .NET प्रोग्रामर, विशेष रूप से जो कि एक क्लासिक VB / ASP या C ++ बैकग्राउंड से आते हैं, को LINQ, MVC और Entity फ्रेमवर्क जैसे नए सामान पसंद नहीं हैं।

मैंने जो देखा है उसके आधार पर, इस समूह में पूर्व VB'ers अभी भी एक डेटा एक्सेस लेयर्स और अन्य कोड का उपयोग कर सकते हैं जो मूल रूप से 10+ साल पहले लिखे गए थे। वे "n-tier" और जैसे पुराने buzzwords का उपयोग करेंगे और .NET .NET 2.0 से परे किसी भी चीज़ के बारे में वास्तव में कुछ भी नहीं समझेंगे और न ही वे इसके बारे में कुछ भी सीखना चाहते हैं।

C ++ 'ers शैक्षणिक रूप से उन्मुख प्रोग्रामर होते हैं, जो कूल एल्गोरिदम को कोडिंग से प्यार करते हैं, भले ही इसका मतलब पहिया का फिर से आविष्कार करना हो। वे किसी भी चीज़ के आधार पर घृणा करते हैं जो उन्होंने खुद कोड नहीं किया था। इनमें से कुछ लोग साक्षात्कारकर्ताओं को हीन महसूस करने में भी प्रसन्न होते हैं, विशेष रूप से कम पारंपरिक पृष्ठभूमि वाले।

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

Comments

धन्यवाद jfrankcarr मुझे संदेह था कि यह मामला हो सकता है - खोलने और बंद करने के बारे में सवाल थे datareaders!

— मैट कैसहैट

MVC "नया सामान" कॉल करने के लिए +1। मुझे जोर से हंसाया। यह लगभग 70 के दशक से है। आपका मतलब एमवीवीएम हो सकता है जो अनिवार्य रूप से एमवीपी (एमवीसी संस्करण) है जो बाइंडिंग का उपयोग करता है।

@ GlenH7 मुझे लगता है कि यह संदर्भ से बहुत स्पष्ट था कि वह उत्पाद "ASP.NET MVC" था, न कि मॉडल-व्यू-कंट्रोलर की मूल अवधारणा।

— Carson63000

@ GlenH7 - मैं पूरी तरह से .NET और विज़ुअल स्टूडियो उत्पाद लाइन और Microsoft के उत्पाद buzzwords के संदर्भ में बोल रहा था।

— jfrankcarr

अच्छा भगवान, क्या वास्तव में दुकानें हैं जो लिनक को "नया" मानते हैं? यह लगभग 4 साल से अधिक समय से है। मैं awaiters कार्य करने के लिए पकड़ा नहीं समझ सकता है, या का उपयोग करने के dynamic/ ExpandoObject/ आदि।, या Azure और अन्य क्लाउड सामान के सभी के बारे में देखभाल नहीं करने के लिए ... मैं भी कर सकते हैं समझने के ओल्ड-स्कूल WebForms देखने का उपयोग जारी रखने MVC या वेब फॉर्म में इंजन, या MVVM के बिना WPF / WinRT कोड लिखना ... लेकिन Linq? यदि आपने अभी तक इसका पता नहीं लगाया है, तो यह एक .NET डेवलपर के रूप में अपनी नौकरी छोड़ने का समय है।

— हारून

Answer 3

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

Comments

ईमानदारी से, जब मैं मूल बिंदु देखता हूं, तो मुझे नहीं लगता कि लिनक जल्द ही कभी भी दूर जा रहा है। Linq2SQL, हाँ, उन्होंने इसे अधिक शक्तिशाली EF के पक्ष में चित्रित किया। लेकिन लिनक ही पिछले 3 .NET रिलीज में इतने अन्य चमकदार नएपन की नींव है कि अगर उन्होंने इसे अपदस्थ कर दिया, तो वे अपने नए दृढ़ता-परत तकनीक के आधे हिस्से को पूर्ववत कर लेंगे जैसे एज़्योर और ईएफ, व्यावहारिक रूप से हर ORM को अपंग करने के लिए कुछ भी नहीं कहना। वहाँ और स्मृति सूची प्रसंस्करण के अलावा बहुत कुछ है।

— कीथ्स

प्रतीक्षा करें ... "पुराने, आउटकमोडेड टेक से दूर जाने के लिए घबराहट, क्योंकि यह काम करता है" ... डब्ल्यूटीएफ। क्या हम उस बिंदु पर आ गए हैं जहाँ काम करने वाले सामान की कोशिश की जाती है, परीक्षण किया जाता है, समझने योग्य और बनाए रखा जाता है, और परिपक्व नहीं होता है।

— gbjbaanb

@ gbjbaanb - कोई। लेकिन - एक उपाख्यान के रूप में - क्या आप चाहते हैं कि कोई डॉक्टर आपके सीने के दर्द का निदान छाती के एक्स-रे से करे क्योंकि यह तरीका 'आजमाया हुआ, परखा हुआ, समझने योग्य' है या आप ऐसा fMRI चाहते हैं जो नया हो, लेकिन उच्च संकल्प के साथ आता है , बेहतर रोग का निदान और अधिक जानकारी? यहाँ कोई भी क्लासिक सिद्धांतों से दूर होने के लिए नहीं कह रहा है; काफी विपरीत। आप देखते हैं, LINQ (एक उदाहरण के रूप में) उन सिद्धांतों पर बनाया गया है। मुझे लगता है, जैसा कि अन्य लोगों ने उल्लेख किया है, यह उन भागों का सीखना है जो LINQ बनाते हैं और यह उचित उपयोग है जो आपके जैसे 'डब्ल्यूटीएफ' क्षणों का कारण बनता है।

— मैट कैसहैट

@MatthewPatrickCashatt: निर्भर करता है, अगर डॉक्टर को fMRI के परिणामों को पढ़ने के लिए प्रशिक्षित नहीं किया गया है, तो मैं निदान के बारे में अनुमान लगाने के बजाय एक्स-रे ले जाऊंगा। यदि मैं एक बैकवाटर में बीमार हो गया, तो मेरे पास एक डॉक्टर होगा जो स्टेथोस्कोप के अलावा और कुछ भी नहीं कर सकता है जो कि नवीनतम उपकरणों में परम के बिना सामना करने में असमर्थ है।

— gbjbaanb

@MatthewPatrickCashatt मैं आपकी बात देखता हूं, लेकिन एक संतुलन कारक यह है कि आप हर प्रवृत्ति का पालन नहीं करना चाहते हैं क्योंकि यह नया है। मैं खुशी से एक नई तकनीक का पालन करूंगा जो दो श्रेणियों में से एक में फिट होती है। 1. यह मुझे उत्तेजित करता है और मैं इस पर अपना खाली समय बिताने को तैयार हूं। 2. यह खुद को वास्तव में बेहतर साबित करता है और ऐसा लगता है कि यह निवेश के लायक बनाने के लिए काफी समय तक चलेगा। दो श्रेणियों में से एक में फिट नहीं होने वाले रुझान सबसे अच्छे हैं।

— टिमोथीविज़मैन

Answer 4

अगर यह अतिरिक्त लागत के बिना समान लक्ष्यों को पूरा करता है तो "शेल्फ से कोड" को खींचने का कोई मतलब नहीं है?

हमेशा एक अतिरिक्त लागत होती है।

शेल्फ सामान को बंद करने के लिए सीखने की अवस्था हमेशा होती है। अपडेट (और निर्भरता) प्राप्त करने का दर्द हमेशा रहता है। हिम्मत के साथ चारों ओर पेंच करने में असमर्थता हमेशा रहती है।

LINQ के लिए, पहले केवल वास्तव में लागू होता है। बहुत से लोग 'अजीब' दिखने वाले कोड को पढ़ने में कठिन और डिबग के लिए कठिन मानते हैं। एसक्यूएल की तरह सिंटैक्स बहुत अधिक व्यक्ति-गैर-ग्राम है जो मैंने बाहर आने के बाद से काम किया है। LINQ to SQL (और अन्य डेटा स्रोत) में कई गोच और सीमित अनुकूलन विकल्प हैं।

ये विशेष रूप से 3rd पार्टी टूल्स और LINQ के खिलाफ सामान्य तर्क हैं। सभी ने कहा, LINQ एक शापित उपयोगी उपकरण है और इसे अधिकांश स्थितियों में पसंद किया जाना चाहिए। यहाँ रोना नहीं आविष्कार किया गया है, और अमूर्त को संज्ञानात्मक विसंगति का दृढ़ता से पक्षधर नहीं होना चाहिए ।

वे LINQ नहीं जानते / सीख नहीं सकते, लेकिन वे "स्पष्ट रूप से" अच्छे डेवलपर्स हैं, इसलिए LINQ सार्थक नहीं होना चाहिए। यह एक आम जाल है।

Comments

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

— मैट Cashatt

@MatthewPatrickCashatt - ओह बिल्कुल। इस तरह घर में रहने वाले कोड को लगभग हमेशा एक ही जीत के लिए अधिक प्रयास करना चाहिए , लेकिन जरूरी नहीं है। कई अन्य चीजों की तरह, लागत / इनाम का अनुमान किया जाना चाहिए और सबसे अच्छा अभ्यास को प्राथमिकता दी , आँख बंद करके पालन नहीं किया।

— तेलेस्टिन

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

— Hawken

Answer 5

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

आप एक दृष्टिकोण प्रस्तुत करना चाहते हैं जो कहता है, "आप जो कुछ भी कर रहे हैं, मैं उसे प्राप्त करने में आपकी मदद करना चाहता हूं", बजाय यह कहने के कि कोई सबटैक्स देता है, "आप बुरे तरीके से काम कर रहे होंगे, और मेरे आसपास होने से साबित होगा यह। "

Comments

+1 - साथ ही उन्हें यह बताने से कि आप उनके बारे में क्या जानते हैं, उनसे पूछें कि वे क्या कर रहे हैं और वे क्या विशेषज्ञ हैं।

— Kirk Broadhurst

Answer 6

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

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

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

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

Comments

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

— वेन मोलिना

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

— gbjbaanb

@WayneM इसी तरह बहुत से लोग कुछ इसी तरह का उपयोग करेंगे जो आपने अभी कहा है कि किसी और पर उनके विचारों को बढ़ावा देने के लिए कहा जाता है (विश्वास है कि जो उनकी बात बस नहीं करता है)। अंत में दोनों पक्ष पक्षपाती हैं, लेकिन ओपी को काम पर रखने के बारे में है, न कि भव्य DIY / अमूर्त युद्ध को जीतने के बारे में। हर किसी की अपनी राय होगी, लेकिन किसी को इस पर पाने के लिए मिल गया है; मुझे लगता है कि यह इस मामले में नियोक्ता नहीं होगा। :(

— हॉकेन

Answer 7

वहाँ एक वैध चिंता है जो मैंने सुना है जो Linq का उपयोग नहीं करते हैं, और यह एक है जिसे मैं दिल से लेता हूं: "सिर्फ इसलिए कि आप कार्यान्वयन को नहीं देख सकते इसका मतलब यह महंगा नहीं है"।

निम्नलिखित स्निपेट लें:

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

यहाँ LINQ- शुरू कर रहे हैं cringing। क्यों? क्योंकि सिर्फ इसलिए कि यह कोड अच्छा और सुरुचिपूर्ण दिखता है इसका मतलब यह नहीं है कि यह भयावह रूप से अक्षम नहीं है। गणना (), एक विधेय के साथ, अपने माता-पिता के हर तत्व का मूल्यांकन करता है, और उस समय को पूरा करता है जब विधेय सही लौटा। तो, न केवल यह N ^ 2 है (जब inputList और otherInputList लगभग समान रूप से समान कार्डिनैलिटी एन हैं), यह पूर्ण सबसे खराब मामला N ^ 2 है; अन्य InInList के हर तत्व इनपुट के हर तत्व के लिए है। इसके बजाय, पहला कदम गणना के बजाय किसी भी () का उपयोग करना है, क्योंकि यह वास्तव में वही है जो आप जानना चाहते हैं, और यह उत्तर के "हाँ" होने के रूप में जल्द ही छोड़ देगा। एक HashSet की स्थापना जो अलग-अलग मूल्यों को संग्रहीत otherInputListObject.OtherPropertyकरती है, आपकी सहायता भी कर सकती है; एक्सेस O (N) के बजाय O (1) हो जाता है,सबसे अच्छा मामला जटिल जटिलता के बजाय सबसे खराब स्थिति ।

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

एक और चिंता का विषय अच्छा पुराना है "जब आपका एकमात्र उपकरण एक हथौड़ा है" तर्क। इस Linq fanboy साक्षात्कारकर्ता साक्षात्कारकर्ता के स्थान पर खुद को रखें। उम्मीदवार लिनक को पसंद करते हैं, इसका उपयोग करना चाहते हैं, सोचते हैं कि यह अब तक की सबसे अच्छी बात है। यह भी प्रतीत हो सकता है कि उम्मीदवार इसके बिना कोड नहीं कर सकता था, क्योंकि दी गई हर प्रोग्रामिंग समस्या लिनक के साथ हल की गई थी। जब इसका उपयोग नहीं किया जा सकता है तो क्या होता है? .NET 2.0 के बहुत सारे कोड अभी भी वहां मौजूद हैं, अगर इसे अपग्रेड किया गया तो सर्वर, यूजर वर्कस्टेशन आदि के लिए दर्दनाक अपग्रेड की आवश्यकता होगी, इसलिए आप अपने फैंसी एक्सटेंशन के तरीकों का उपयोग कर सकते हैं। साक्षात्कारकर्ता के रूप में, मैं आपको यह दिखाने की कोशिश करूंगा कि आप एक कुशल प्रकार को कोड कर सकते हैं या यदि आप को कोई फर्क नहीं पड़ता है तो 2.0 सॉर्टिंग विधियों का उपयोग कर सकते हैं, फिर भी मैं आपसे कितना सहमत हो सकता हूं कि Linq पुस्तकालयों और इसी तरह के विस्तार के तरीके सुंदर हैं मिठाई। एक साक्षात्कारकर्ता जो बिंदु को नहीं देखता है, वह आपको किसी और चीज के लिए योग्यता दिखाने के लिए परेशान करने की कोशिश भी नहीं कर सकता है; वे मान लेंगे कि आपके पास यह नहीं है और आगे बढ़ें।

Comments

आप अपनी क्वेरी सिर्फ इसलिए नहीं लिखेंगे var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));? हो सकता है कि मैंने उस पर रोक लगा दी हो, लेकिन मेरी बात यह है कि LINQ आपके द्वारा बताई गई क्वेरी को निष्पादित करने के बेहतर तरीके हैं (.Join () एक और तरीका है)। मुझे पता है कि LINQ का उपयोग करने के तरीके हैं जो अन्य तरीकों की तरह कुशल नहीं हो सकते हैं, लेकिन इसका मतलब यह नहीं है कि आपको उन बुरे कार्यान्वयनों पर भरोसा करना होगा।

— मैट Cashatt

@MatthewPatrickCashatt मुझे नहीं लगता कि उसकी बात यह दावा करने के लिए बहुत है कि LINQ हमेशा अक्षम है - जब आप हमेशा दिए गए LINQ क्वेरी को हरा सकते हैं, तो कुछ उपयोग कई गैर-LINQ दृष्टिकोणों की तुलना में प्रति डेवलपर-घंटे बेहतर प्रदर्शन देते हैं। बल्कि, यह एक LINQ क्वेरी लिखने के लिए अपेक्षाकृत आसान हो सकता है जो अक्षम है और इसे महसूस नहीं करता है, क्योंकि अक्षमताएं उतनी ही तेज नहीं हैं।

— जॉन हन्ना

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

— सुपरकैट

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

— कीथ्स

@KeithS: मुझे लगता है कि जावा और .net दोनों में एक बात बुरी तरह से गायब है, वस्तुओं या वस्तुओं को अपने से अलग करने के लिए पूछने का एक मानक साधन है। उदाहरण के लिए, कोड जो एक संग्रहणीय संग्रह प्राप्त करता है, यह जानने से लाभ हो सकता है कि क्या वस्तुओं की संख्या और / या मौजूदा वस्तुओं का क्रम कभी भी बदल सकता है, क्या वस्तुओं की संख्या परिमित या अनंत (या दोनों तरह से ज्ञात नहीं है), और क्या संग्रह स्वाभाविक रूप से जानता है कि उसमें कितने आइटम हैं। LINQ जैसी तकनीकों को अक्सर ऐसी चीजों के बारे में धारणा

— बनानी पड़ती है जो

Answer 8

यह एक लंबा सा है, लेकिन यह किसी के लिए उपयोगी हो सकता है तो मैं इसे होने दूँगा।

मुझे वास्तव में कुछ इसी तरह का सामना करना पड़ा, पिछले महीने 20 से अधिक साक्षात्कारों से गुजरना (फोन और आमने-सामने का मिश्रण)। वहाँ निश्चित रूप से कुछ अप्रत्याशित हो रहा था कि मैं अपनी उंगली नहीं डाल सकता था।

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

असंबंधित उद्योगों में कई साक्षात्कारों और विभिन्न असंबंधित फर्मों में, इन पंक्तियों के साथ क्या ध्यान दिया गया था:

• पुराने / आउटमोडेड सम्मेलनों और "बैक टू स्टोन एज" सीमाओं पर एक अजीब निर्धारण। VS2003 में एक आदिम वेब ऐप विकसित करने की तरह, बेतुके प्रतिबंधों की एक सूची के साथ .net के उस युग के भीतर स्पष्ट सुविधाओं के उपयोग की मनाही है ... जैसे कि वह एक आधुनिक डेवलपर्स की क्षमता का एक वास्तविक गेज है ... याद रखने की क्षमता प्रतिमान और 9 साल पहले की सीमाओं को अवास्तविक / मनमाना बाधाओं द्वारा अपंग कर दिया गया। कस्टम संग्रह के विषय पर एक और जगह बहुत ही धूमिल की गई थी, लगभग पूर्व-सामान्य संग्रह। एक अन्य स्थान पर एक क्लास मॉडल का एक कोड नमूना तैयार किया गया था जिसे मैंने बाहर निकाला था क्योंकि मैंने कैस्केड किए गए निर्माणकर्ताओं का उपयोग नहीं किया था (वे घोषणा पर संपत्ति के आरंभ के लिए समर्थन से अनजान थे, जो आवश्यकता के लिए पर्याप्त था)।

• एक सूक्ष्म जगत और / या कॉन्फ़िगरेशन सेटिंग्स में विशिष्ट कार्यान्वयन विवरणों पर अत्यधिक ध्यान दें, यहां तक ​​कि प्रौद्योगिकियों के मामले में भी जो कि प्लेटफ़ॉर्म या प्रोटोकॉल अज्ञेयवादी होने पर ध्यान केंद्रित करते हैं (यानी..पूरे बिंदु को एक विशिष्ट कार्यान्वयन या विशेष उपयोग पर ठीक नहीं किया जाना है, बल्कि पुन: उपयोग / पुनः-प्रयोजन / विलोपन / आवश्यकतानुसार एकीकरण)।

• अटकल / पर्यवेक्षण / कोड की समीक्षा करने की इच्छा / और अन्यथा एक किनारे से काम करने के लिए और ऐसा करने से संबंधित गैर-कोडिंग कौशल से काम करना बंद कर दिया।

• उत्पादों के विशिष्ट संस्करणों / प्लेटफार्मों / मॉड्यूल / आदि का उपयोग कभी-कभी बेतुका डिग्री के लिए; "तो - आपने संस्करण 1, 2 और 4 का उपयोग किया है; लेकिन 3 नहीं, एह; हम्म् ... {आपके पुनरारंभ को" no v3 !!!! "के साथ बताता है। उपयोग की डिग्री कोई बात नहीं लगती थी; केवल आप हैं, वे या कुछ और इस्तेमाल नहीं किया है सब पर , और विशिष्ट बात यह है कि वे भी के लिए पूछ रहे हैं ... कोई प्रतिस्थापन गिनती करने के लिए, एक और अधिक व्यापक रूप से इस्तेमाल और पूरी तरह से विशेष रुप से प्रतिस्पर्धा उत्पाद की भी लग रहा था।

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

• इस समय के आसपास कंपनियों को विशेष तकनीकी समस्याओं को हल करने, नए ग्रीन-फील्ड या बिग 2.0 डेवलपमेंट प्रोजेक्ट्स शुरू करने, या एक विशिष्ट उत्पाद को बाजार में लाने के लिए एक उभरती हुई प्रवृत्ति या अवसर, या सामान्य रूप से बड़े किकऑफ्स पर ध्यान केंद्रित करने में बहुत कम लग रहा था। । एक दोहराई जाने वाली थीम जिसे मैंने कम से कम 15 स्थानों पर देखा, 3-5 डेवलपर्स का एक छोटा समूह, 08 में बाजार दुर्घटना से बचे, जो पिछले 3 वर्षों के दौरान उत्पाद को पीसने में सक्षम थे। और कुछ सफलता मिली या उनकी कंपनी पूरी तरह से फलफूल रही है और वे नए लोगों को काम पर रखने के लिए काम पर रख रही हैं ताकि बढ़ती मांग को पूरा किया जा सके या इन प्रणालियों में निर्मित डिज़ाइन खामियों को दूर किया जा सके या उन्हें मुक्त करने के लिए पूर्वोक्त प्लेटफार्मों पर काम किया जा सके। कोर टीम ने इसे "अन्य प्रोजेक्ट्स" करने के लिए बनाया था।

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

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

बेशक, मर्फी की विधि जा रहा है कि यह क्या है, आप के बाद अगले ही साक्षात्कार "मेरे वर्तमान पसंदीदा प्रौद्योगिकी पुरुष के बारे में भावुक" किया जा रहा रोकने के लिए और एक अधिक संतुलित / दाढ़ी-पथपाकर रुख अपनाने गिग है कि आप है होगा मिल गया है आप पागल हो गया था जोएलोट लड़का ;)

Answer 9

मुझे लगता है कि आप एक गलत निष्कर्ष निकाल रहे हैं, क्योंकि आपके नमूनों का सेट बहुत सीमित है। यद्यपि मैंने आईटी दुकानों की एक उचित हिस्सेदारी देखी है जिसमें कुछ भी "वहाँ का आविष्कार नहीं किया गया" ^{1 के} लिए मजबूत प्रत्यावर्तन के साथ , उनमें से कोई भी प्रौद्योगिकी स्टैक में उनकी प्राथमिकताओं के आधार पर उम्मीदवारों को अयोग्य घोषित नहीं करेगा: वे सही तरीके से आश्वस्त थे कि वे उपयोग करने के लिए सही उम्मीदवार को सिखा सकते हैं। उनके घर के पुस्तकालय।

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

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

यह निश्चित है कि वे अपनी कंपनी के लिए काम पर रखने के बजाय अपने खुद के बजाय पुस्तकालय कार्यान्वयन का उपयोग करने पर जोर देंगे । लेकिन साक्षात्कार के दौरान वे आपकी वास्तविक क्षमताओं की बेहतर समझ हासिल करने के लिए आपको निम्न स्तर के कोड की ओर धकेल देंगे।

---

¹ एक दुकान के रूप में अपने स्वयं के बल्कि आदिम निर्माण उपकरण के निर्माण के रूप में दूर चला गया!

Comments

आपके सभी बिंदुओं को अच्छी तरह से बनाया गया है, लेकिन मुझे आपको पिछले साक्षात्कार के आसपास कुछ रंग देना चाहिए: साक्षात्कारकर्ता ने जोर देकर कहा कि LINQ को "पदावनत" किया जा रहा है। मैंने पूछा, "क्या आपका मतलब यह नहीं है कि MS अब Linq-to-SQL में निवेश नहीं करेगा, लेकिन Linq-to-Entities के आसपास होगा" और उनके जवाब का मतलब था कि उनका मतलब था: LINQ "पदावनत" किया जा रहा है इसलिए, नहीं, मुझे नहीं लगता कि वह LINQ के बारे में बहुत अधिक जानता था या इसके उपयोग पर जोर देगा।

— मैट Cashatt

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

— रखें

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

— मैट कैसहेट

फिर यह तकनीक स्टैक के साथ कम और इस तथ्य के साथ अधिक प्रतीत होता है कि आपने उसे सही किया है। लोगों को सही होना पसंद नहीं है। यह सिर्फ मानव स्वभाव है। जब लोग लोगों को काम पर रखने जैसे निर्णय लेते हैं, तो 99% अपने अंतर्ज्ञान के साथ जाएंगे। वे आपके द्वारा सकारात्मक या नकारात्मक भावनाओं को महसूस करने का कारण बनते हैं या नहीं। उसे ठीक करने से उसे नकारात्मक भावनाओं का एहसास हो सकता है। और फिर वह उस नकारात्मकता को स्थिति से जोड़ देता है।

— कोडर

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

— तजार्ट

Answer 10

मुझे लगता है कि आप स्कॉटलैंड में "मैंने एक काली गाय देखी, इसलिए सभी स्कॉटिश गाय काली हैं"।

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

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

Answer 11

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

ऐसा लगता है जैसे आप एक गरीब डेवलपर के साथ साक्षात्कार करते हैं जो चीजों के साथ तारीख तक नहीं रखता है और हर चीज के लिए हथौड़ा और नाखून दृष्टिकोण लेता है। ये डेवलपर्स के प्रकार हैं जो NUnit, या NHibernate, या विभिन्न IoT कंटेनर जैसे सहायक ओपन सोर्स टूल के बारे में कुछ नहीं जानते हैं; डेटाबेस में बड़े पैमाने पर संग्रहित खरीद के साथ हर समस्या को हल करने की कोशिश करने वाले; कई वर्षों से बाहर होने के बावजूद MVC के बारे में कुछ भी नहीं पता है।

Comments

आप LINQ को Nhbernate इत्यादि वाले buzzword पूल में फेंक सकते हैं ... मैं ऐसा नहीं करूंगा। वास्तव में मुझे लगता है कि buzzwords उचित अभिव्यक्तियों में अमूर्तता की व्याख्या करने में हमारी असमर्थता का उदाहरण देता है।

— एंड्रियासचिनर्ट

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

— एंड्रियाशेचेर्ट