Bir röportajda neden “C # hakkında nefret ettiğin beş şeyi ver” sorusunun yanıtlanması bu kadar zor? [kapalı]

In podcast 73 Joel Spolsky ve Jeff Atwood, diğer konular arasında, "Herkesin kendi favori programlama dili hakkında nefret etmelidir beş şeyi" tartışmak:

Mevcut takım zincirinizden memnunsanız, geçiş yapmanız gerekmiyor. Ancak, en sevdiğiniz programlama dili hakkında nefret ettiğiniz beş şeyi listeleyemiyorsanız, o zaman henüz yargılamak için yeterince iyi bilmediğinizi savunuyorum. Alternatiflerin farkında olmak ve ne kullanıyorsanız kullanın sağlıklı ve eleştirel bir göze sahip olmak iyidir.

Meraklı olmakla, bu soruyu röportaj yaptığım adaylara sordum. Hiçbiri C # about hakkında nefret ettikleri en az bir şeyden alıntı yapamadı.

Niye ya? Bu soruda bu kadar zor olan ne? Görüşmenin stresli bağlamı nedeniyle, bu sorunun görüşülen kişiler tarafından cevaplandırılması imkansız mı?

Bu soru hakkında görüşmeyi kötüleştiren bir şey var mı?

Açıkçası, bu C # mükemmel olduğu anlamına gelmez. Kendime C # hakkında nefret ettiğim beş şeyin bir listesini yaptım:

• Jeneriklerde değişken sayı türlerinin eksikliği ( paramsargümanlara benzer ).
  Action<T>,
  Action<T1, T2>,
  Action<T1, T2, T3>,
        ⁞ Ciddi ?!
  Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>
  

• F # 'daki gibi ölçü birimleri için destek eksikliği.

• Salt okunur özelliklerin eksikliği. private readonlyHer zaman salt okunur bir özellik istemek için bir destek alanı yazmak çok sıkıcı.

• Varsayılan değerlere sahip özelliklerin olmaması. Ve evet, onları parametresiz kurucuda başlatabileceğimi ve diğer tüm kuruculardan arayabileceğimi biliyorum. Ama istemiyorum.

• Çoklu kalıtım Evet, karışıklığa neden olur ve çoğu durumda buna ihtiyaç duymazsınız. Bazı (çok nadir) durumlarda hala yararlıdır ve karışıklık aynı adı taşıyan yöntemleri içeren çeşitli arayüzleri miras alan sınıfa da uygulanır (ve C # 'da çözülmüştür).

Bu listenin tamamlanmaktan çok uzak olduğundan eminim ve vurgulamak için daha çok nokta var, özellikle de benimkinden çok daha iyi olanlar var.

^{People Birkaç kişi, .NET Framework'teki bazı meclisleri veya çerçeve içindeki bazı kütüphanelerin bulunmamasını eleştirdi veya CLR'yi eleştirdi. Bu soru hakkında olduğu için, sayılmaz dilin Potansiyel olarak hiçbir ortak arayüz olmadığı gerçeğini gibi örnek bir şey için .NET Framework (özünde bir şey negatif ilgili bir cevap kabul edebileceğini ederken kendisi ve TryParseeğer öyleyse, Bir dize birkaç tür ayrıştırmak istiyorsanız, her tür için kendinizi tekrarlamanız gerekir), JSON veya WCF hakkında bir cevap tamamen konu dışı.}

Tahmin etmek zorunda kalırsam:

1. Bazı programcılar farklı dillere maruz kalmıyorlar. Daha iyi şeylerin olduğunu bilmediğinizde, dilde yanlış olan şeyleri görmek zordur.

2. Bazı programcılar sadece kod maymunlarıdır. Programlama dillerinin nasıl daha iyi olabileceği gibi bir şey olsa bile, önlerindeki sorunları zar zor analiz ederler.

3. Çok az insan özellikle kritiktir. Eksiklikleri değil faydaları ve özellikleri görürler. Eğer görüşme böyle gitmezse, bu düşünme tarzına geçmeleri zor.

4. En azından buralarda, aşırı derecede kritik olmak ölümcül bir kişilik hatası olarak görülüyor. 'Her zaman daha iyi şeyler yapmanın yollarını arayan anlayışlı geliştirici' olmak yerine (yaşadığım bazı bölgeler gibi), onlar 'her şeyden nefret eden o aşağılık' tır. Dilde nefret ettikleri şeyleri düşünebilen insanlar bile röportajda daha az acerici görünebilir.

Görüşme sırasında sorunun cevaplanmasının çok zor olduğunu hayal ediyorum, çünkü:

1. Gerçekten beklenmedik,

2. Görüşme sırasında kullanılandan çok fazla düşünme ve çok farklı bir şekilde düşünme gerektiren,

3. Genel olarak kısa sürede cevap vermek zordur (görüşmeden önce hazırlanmadıysa).

1. Beklenmedik

Beklenmeyen sorular, özellikle stresli bir bağlamda gerçekten zor. Bir görüşme sırasında aşağıdaki diyaloğu hayal edin:

- HashSet<T>ve arasındaki fark nedir List<T>?
- Hashset, element araması çok hızlı olacak şekilde optimize edilmiştir. Örneğin set.Contains(), çok setsık bir döngü içinde kullanıyorsanız , listeden karmaşaya geçiş yapmak işleri daha hızlı yapabilir.
- Salt okunur bir özellik nasıl oluşturulur?
- readonlySadece alıcı olan bir mülk için destek alanı olarak işaretlenmiş bir alan kullanıyorum .
- Kullanımı nedir sealed?
- Miras almaması gereken sınıflar için kullanıyorsunuz.
- En son ne zaman dişçi gördün?
- Ne?!

2. Çok fazla farklı düşünce gerektirir

Genel mülakat tipi sorular sorulduğunda, hafızanızı kitaplardan veya uygulamadan dil ve çerçeve ile ilgili öğrendiklerinizi hatırlamak için kullanırsınız. Bir cevap bulmak için biraz düşünebilirsiniz ama çok fazla değil.

Öte yandan, nefret ettiğiniz beş şeyle ilgili soru daha derin düşünmeyi gerektirir. Kitaplardan öğrendiğin bir şeyi hatırlayamazsın ve analojiyle hiçbir şey bulamazsın. Pasif olmak yerine eleştirel olmak ve kullandığınız dilde neyin hoş görünmeyeceğini bulmak zorundasınız.

3. Zaman gerektirir

Açıkçası, C # hakkında nefret ettiğim beş (aslında daha fazla) şeyden oluşan bir listem var ama uzun zamandır düşündüm. .NET Framework 2 döneminden bir kaç şey var; .NET Framework 2 için listelediğim sorunların çoğu artık geçerli değil, çünkü bazıları LINQ ve tüm bu işlevsel programlama öğelerini, diğerleri dinamik programlamayı da kaldırdılar. Bu soruyu hazırlamadan bir röportaj sırasında beş öğeyi de bulabilecek miyim, emin değilim.

Beş kelimeden dolayı zor olduğunu düşünüyorum . Ve daha az derecede, nefret kelimesinden dolayı .

Beş mi? Ya sadece dört tane bulursan? Soruya cevap vermedin mi? Ya beşten fazla varsa ? Şimdi, yerinde, hangisinin kullanılacak en iyi beş olduğunu bulmak zorundasınız.

Nefret çok olumsuz bir kelimedir. İnsanlara röportajlarda kaçınmaları söylenen bir tür olumsuzluk. Üstelik bunun o kadar çok şey onlar bütün gün programlama harcama olacak bir dil hakkında onlar "nefret" olması bir çok insan için tuhaf olacağını düşünüyorum Bazı insanlar hileli bir soru düşünmek bile olabilir. Aslında Eğer do come Beş şeyden önce, C # 'dan nefret etmek için iyi programlayamayacak kadar çok diskalifiye olurlar. Ne yazık ki, bu tür bir sapkın hile sorusu röportajlarda duyulmamış değildir.

Bunun yerine, size kalmış olsaydı C # konusunda neleri geliştirirdiniz? Bu, görüşmecinin istediği sayıda yanıt vermesini sağlar. Bu kelime öbeği aynı zamanda "nefret" kelimesinin göreceli olarak olumlu "iyileşme" için olumsuzluğunu da işlemektedir.

• Adayların çoğu, kontrast oluşturmak için birden fazla dil veya paradigma ile yakından ilişkili değildir . 5 yıldır başka bir nesne yönelimli dille çalışmadım ve çalıştığım dilde (PowerBuilder) çok şey vardıile Üniversiteden yeni çıkmış erkeklerin çoğu bir veya belki iki dilde sıcak şeylerdir (veya öyle olduğunu düşünürler) ve üç veya dört kişiye daha fazla "maruz kalma" (yani, en az bir ev ödevini tamamladılar ancak bir yarıyıldan daha az sürede tamamladılar) ders çalışıyorum. Dilde neyin yanlış olduğunu gerçekten bilmek için bu yeterli bilgi ya da deneyim değil. Gerçek dünyada bir iş bulun ve bu odak önemli ölçüde daralır; size maaş çekini diğerlerinden daha fazla kazandıran dil hakkında çok şey öğrenirsiniz ve bu süreçte dilin ne yapmayacağını ya da garip bir şekilde ne hatırlayamadığınızı kabul edersiniz. farklı yapıyorum.

• Java / C / C ++ ile karşılaştıran çoğu C # -savvy adayı oldukça memnun . C #, Java'dan daha iyi şeyler yapmak için sıfırdan tasarlandı (olaylar, geri çağrılar, grafik kütüphanesi, veritabanı çalışması). Java da kullanımı daha kolay olacak şekilde tasarlandı ve C ++ 'dan ziyade doğru koda odaklandı. Kabarcıklı performansın ve devreye yakın seviye kontrolün kritik öneme sahip olmadığı herhangi bir ortamda C ++ 'a geri dönmek isteyen bir C # programcısıyla henüz tanışmadım.

Başka bir deyişle, See-Sharpers, her şeyi göz önünde bulundurarak oldukça iyi bir duruma sahip.

İşte listem:

• Lambda ifadeleri izlenemez / değerlendirilebilir değildir . Adlandırılmış yöntemlere yapılan çağrılar VS'nin QuickWatch'una takılabilir. Yani ifadeler olabilir. Fakat kuzu eti? Hayır (en azından VS2010'da değil). Hata ayıklama Linq zincirleri gerçek bir angarya yapar.

• Dize dışındaki referans türleri için isteğe bağlı parametre değerleri yalnızca boş olabilir . bir aşırı yük yığını oluşturuyor olsaydım, diğer varsayılanları kullanmak isteyebilirdim. Bir özelliği temel alan bir değeri veya başka bir parametreyi temel alan basit ifadeyi ayarlayabilirim. Ama yapamam. Bu nedenle, isteğe bağlı parametreler için seçenekler çok kısıtlı olduğunda bir aşırı yük yığını oluşturmak zorunda kalmama değeri (kazan plakasını kullanmak için ReSharper gibi yeniden ateşleme asistanı ile küçük olan) azalır.

• C # ciddi eski kod sorunları için yeterince yaşlanıyor . Orijinal olarak 1.1 için yazılmış olan kod, eskiden 4.0'a korku içinde tıkanmaya neden olan herhangi birisine neden olacaktır. 2.0 kodu bile çok fazla özlüyor. Aynı zamanda, ADO.NET gibi şeylerin son derece ilkel görünmesini sağlayan üçüncü parti kütüphaneleri de ortaya çıktı (ve ADO.NET'in "bağlı modeli" artık büyük bir anti-kalıptır). Yine de, geriye dönük uyumluluk için, .NET, bu eski, kötü kodun desteğini bir araya getirdi, "ArrayList bunu yapmak için berbat bir yoluydu, asla koyduğumuz için üzgünüz ve alıp götürüyoruz. Bunun yerine Liste kullanın ve kesinlikle farklı türlerden oluşan bir listeye ihtiyacınız varsa, bunu olarak bildirin List<Object>.

• Ciddi sınırlı anahtar deyimi kuralları . Muhtemelen PowerBuilder hakkında söyleyebileceğim en iyi şeylerden biri, Select Case deyiminin (değişime eşdeğer) değişkene dayalı Boolean ifadelerine izin vermesidir. Ayrıca, kod ifadeleri olsa bile anahtar ifadelerinin düşmesine izin verdi. İkincisinin izinsiz bırakılma nedenlerini anlıyorum (istemeden kasıtlı olarak yapılması daha olasıdır) ancak zaman zaman şöyle bir ifade yazmak yine de iyi olurdu:

  switch(someInt)
  {
      case < 0: //all negative values enter here
         //...
         break;
      case 0: 
         //...
         break;
      case 1:
         //...
         //no break; continue through to the code for > 1
      case > 1 // all positive values enter here (including 1)
         //...
         break;
  }

• Nümerik arayüz yok . Bu bir sayıysa, onunla matematik yapabilirsiniz. Çoğu durumda, gerçek yöntem tam olarak hangi tiplerin takılı olduğu ile ilgilenmek zorunda değildir; hassasiyet, arayanın sorumluluğundadır. Ancak, GTP olarak yalnızca sayı türlerini kabul edebilecek genel bir yöntem veya sınıf oluşturmak mümkün değildir.

Sorunun bir kısmının kötü bir cevap verme korkusu olduğunu öneriyorum - X'ten nefret ettiğini söylüyorsun, görüşmeci X'i seviyor ya da X'in nefret sebebinin aptalca olduğunu düşünüyor, bunun iyi olduğunu düşünmenin daha az tartışmalı bir seçenek olarak görünebileceğini düşünüyor.

Aynı zamanda muhtemelen çoğu insanın gerçekten çok fazla düşünemediği bir şeydir; şu anki problemleri var ve geçmiş problemleri var, geçmişin neden olduğu geçmiş problemler sona erdi ve bu yüzden insanlar esas olarak çözümü düşünüyor ve daha önemli olan problemi değil, çok azının dilin neden olduğu güncel bir problemi olacak.

Bir röportaj için sadece 1 veya 2 isteyeceğim, ancak kabul ediyorum, kullandığınız aracın sınırlarını belirleyemiyorsanız, muhtemelen çok iyi bilmiyorsunuz demektir. SSIS hakkında bu kesin soruyu soruyoruz ve buğdayı samandan ayırmaya gerçekten yardımcı oluyor; Bu soruyu iyi cevaplayan, işe aldığımız herkes iyi bir çalışan oldu. Birkaç kez bakmış biri değil, bilgiliğe sahip insanlara ihtiyacımız var. Ve iddiaya girerim istediğin de budur.

Bunun geçerli bir soru olduğunu ve bu kadar çok kişinin cevap veremeyeceği gerçeği, iş için adayların pek çoğunun gerçekte ne kadar zayıf olduğunun bir örneği. Birisi aracın bazı kısıtlamalarını anlayabilecek kadar analitik değilse, zor programlama problemlerini çözmek için nasıl analitik olarak yeterli olacaklar?

Sizin de C # ile ilgili derinlemesine bir deneyim eksikliği ve / veya diğer dillere maruz kalmama dediğiniz gibi geliyor. C # yüzeyindeki hafif çiziklerin bile ortaya çıkarması gereken bazı soruları cevaplayamayan, kendilerini kıdemli düşünen birkaç geliştiriciyle görüştüm.

Yeterince kazma olmadan, dilin sınırlarına ulaşamayacak ve onların gitmesini dilemeyeceksiniz. Kimsenin merak etmesi durumunda ilk beşim

1. Değiştirilemeyen nesneler oluşturmak için çok sayıda tören gerektirir (nesnelerin varsayılan olarak değiştirilemez olduğu işlevsel bir dilin aksine).
2. Metaprogramming yapmak zor. Lisp makroları ile emit türünü karşılaştırın. (Derleyici Servisleri, bu ilerlemeye çok yardımcı olacaktır).
3. Uzatma yöntemleri harika ... uzatma özellikleri ve uzatma operatörleri (özellikle açık ve açık operatörler) daha iyi olurdu.
4. Açık Yayınlar çalışma zamanı yerine derleme zamanında çözümlenir.
5. Sıra yok Eşleştirme, fonksiyon aşırı yüklenmesinden çok daha temiz.

Ben onun turunda söylediği gibi düşünüyorum; Kırıldığını düşünüyorsanız, neden olduğunu anlamıyorsunuzdur. Bilginizde bir delik olabilir.

İronik olarak, bir mülakat sorusu olarak kullanarak "büyük Joel" ten alıntı yaptıklarını düşünen görüşmeciler muhtemelen noktayı kaçırıyorlar.

Onlar eğer izlenimi altında olabilir çünkü cevap isteksiz olabilir olabilir onlar görüşmeyi yuvarlak dönüp diyebilirsiniz dile nefret 5 şeylerin listesini ninjalar 'Ah, biz C # arıyoruz '' ve görünmüyor Dilini beğenmek için 'veya' Dili sevmiyorsanız neden işe başvurdunuz? '.

Görüşülen kişiler görüşmeler sırasında olumlu kalmaları için büyük bir baskı altındadır.

Çünkü diller düşündüğümüz şekli veriyor . Her gün C # kullanarak kodunuzu, dilin sorunları etrafında doğal olarak çalışacak şekilde düşünme ve tasarlama alışkanlığını edindiniz.

Şimdi düşünmeden, hatta yaptığını bile bilmeden yapıyorsun. Bu yüzden kötü şeylerin ne olduğunu belirtmek çok zor. Hiç şüphe yok ki, C # öğrenmeye başladığınız gün, çok fazla sorun buldunuz, ancak şimdi onları artık göremiyorsunuz. Alışkanlıklar güçlü şeylerdir. Düşünce alışkanlıkları, daha da fazlası .

Bunun olumlu yanı, C # 'daki kusurları listelemeyi zor buluyorsanız, iyi bir C # programcısı olduğunuzdan, dili sevdiğinizden ve diğer dillerden daha fazla kullandığınızdan kaynaklanıyor olmalı.

Fakat C # 'daki kusurları daha iyi görebilmek istiyorsanız, düşünme şeklinizi değiştirmek zorundasınız. Daha fazla programlama dili öğrenin ve bunlara alışın. Mümkün olan en farklı dilleri hedefleyin. Statik yazmaya alışkın mısınız? Python veya Ruby'i deneyin. Nesne yönelimli ve zorunlu olanlara alışkın mısınız? Haskell tamamen başka bir dünya.

Ve C # 'ya geri döndüğünde, "Haskell'de sadece bir satır olan bu basit şeyi yapmak için neden yüz satır C #' a ihtiyacım var?" Gibi olacaksın. C # hakkında bir çok şeyden nefret edeceksin.

• C #, geri çevrilemez referans türlerine sahip değil.
• Cebirsel veri türü yok.
• Dize enterpolasyonu yok.
• Sözdizimi her yerde aşırı ayrıntılı.
• Makro sistemi yok.
• Tür çıkarımı sınırlıdır.
• Regexp değişmezleri yok.
• Yapısal yazım yok.
• Değişmezlik için zayıf destek.
• C # yapıları hataya açık.
• Standart koleksiyon kütüphanesi çok sınırlıdır.
• Yapıcıların parametreleri üzerindeki kısıtlamaları tanımlayamaz.
• Matematik operatörleri üzerindeki kısıtlamalar ile genel olarak programlanamaz.
• 'Yeni tip' yok.
• Dizi dilimleme yok, değişmez aralık yok.
• İşlevler, türlerinin bir parçası olarak yapabilecekleri yan etkileri listelemez. :)

(Elbette hiçbir dil her şeye sahip olamaz. Dil tasarımı son derece zordur ve her bir özelliği aynı dile eklemek işe yaramaz. Farklı amaçlar için farklı araçlar.)

Evet, özellikle röportajda soruyu iyi cevaplamak zor. Ancak cevap verebilecek insanlar, bunun hakkında düşündüklerini, bazı bakış açılarına sahip olduklarını kanıtladılar.