Mengapa penggunaan abstraksi (seperti LINQ) sangat tabu? [Tutup]


60

Saya seorang kontraktor independen dan, dengan demikian, saya mewawancarai 3-4 kali setahun untuk pertunjukan baru. Saya berada di tengah-tengah siklus itu sekarang dan ditolak untuk kesempatan meskipun saya merasa seperti wawancara berjalan dengan baik. Hal yang sama terjadi pada saya beberapa kali tahun ini.

Sekarang, saya bukan orang yang sempurna dan saya tidak berharap menjadi orang yang cocok untuk setiap organisasi. Yang mengatakan, rata-rata pukulan saya lebih rendah dari biasanya jadi saya dengan sopan meminta pewawancara terakhir saya untuk umpan balik yang membangun, dan dia menyampaikan!

Hal utama, menurut pewawancara, adalah bahwa saya tampaknya terlalu condong ke arah penggunaan abstraksi (seperti LINQ) daripada ke arah yang lebih rendah, algoritma yang dikembangkan secara organik.

Pada permukaan, ini masuk akal - pada kenyataannya, itu membuat penolakan lain juga masuk akal karena saya mengoceh tentang LINQ dalam wawancara itu juga dan sepertinya pewawancara tidak tahu banyak tentang LINQ (meskipun mereka. NET teman-teman).

Jadi sekarang saya dibiarkan dengan pertanyaan ini: Jika kita seharusnya "berdiri di atas bahu raksasa" dan menggunakan abstraksi yang tersedia untuk kita (seperti LINQ), lalu mengapa beberapa orang menganggapnya sangat tabu? Tidakkah masuk akal untuk menarik kode "dari rak" jika mencapai tujuan yang sama tanpa biaya tambahan?

Tampaknya bagi saya bahwa LINQ, bahkan jika itu adalah abstraksi, hanyalah abstraksi dari semua algoritma yang sama yang akan ditulis untuk mencapai akhir yang sama persis. Hanya tes kinerja yang bisa memberi tahu Anda jika pendekatan khusus Anda lebih baik, tetapi jika sesuatu seperti LINQ memenuhi persyaratan, mengapa repot-repot menulis kelas Anda sendiri?

Saya tidak bermaksud fokus pada LINQ di sini. Saya yakin bahwa dunia JAWA memiliki sesuatu yang sebanding, saya hanya ingin tahu mengapa beberapa orang menjadi sangat tidak nyaman dengan gagasan menggunakan abstraksi yang mereka sendiri tidak tulis.

MEMPERBARUI

Seperti yang Euphoric tunjukkan, tidak ada yang sebanding dengan LINQ di dunia Java. Jadi, jika Anda mengembangkan pada .NET stack, mengapa tidak selalu mencoba dan memanfaatkannya? Mungkinkah orang tidak sepenuhnya memahami apa fungsinya?


8
Saya pikir Anda tidak tahu apa itu "abstraksi", karena LINQ tidak ada hubungannya dengan itu.
Euforia

8
"Saya yakin bahwa dunia JAWA memiliki sesuatu yang sebanding" Sebenarnya, LINQ adalah salah satu dari beberapa hal, yang dimiliki .NET dan Java tidak.
Euforia

42
@ Euforia - Apakah LINQ tidak mengabstraksikan pekerjaan tingkat bawah dari tugas-tugas seperti menyortir dan memfilter misalnya? Saya cukup yakin bahwa akan ada beberapa kode tambahan di belakang objectCollection.Where(oc=>oc.price > 100)misalnya. Apakah itu bukan penggunaan abstraksi? Mungkin Anda bisa memberi tahu saya apa yang saya lewatkan di sini. . .
Matt Cashatt

37
Selalu ada kemungkinan bahwa mereka tidak mengerti LINQ dan tidak melihat nilai dalam mempelajarinya. Aspek fungsional penulisan ini sangat sangat berbeda dengan pemrograman imperatif. Sebagai seorang kontraktor, saya baru-baru ini pada tahun 2009 melihat pengembang Java "senior" yang tidak cukup memahami SQL untuk menulis pertanyaan tingkat lanjut sehingga mereka menghabiskan waktu berminggu-minggu untuk mengoptimalkan kode yang membawa semua data ke sisi Java dan memfilternya dengan kode Java alih-alih memiliki database yang melakukannya. Ketidaktahuan merajalela di industri pengembangan perangkat lunak.

18
Jika Anda mengerti LINQ tetapi pewawancara Anda tidak, Anda lebih baik dari mereka. Atur pandangan Anda lebih tinggi.
Jay Bazuzi

Jawaban:


74

Saya tidak berpikir itu penggunaan abstraksi per se yang tidak menyenangkan. Ada dua penjelasan lain yang mungkin. Salah satunya adalah bahwa semua abstraksi bocor pada satu waktu atau yang lain. Jika Anda memberi kesan, benar atau tidak, bahwa Anda tidak memahami dasar-dasarnya yang mendasarinya, yang mungkin mencerminkan buruk dalam sebuah wawancara.

Penjelasan lain yang mungkin adalah efek fanboy. Jika Anda berbicara dengan bersemangat tentang LINQ, dan berulang kali memunculkannya dalam sebuah wawancara dengan perusahaan yang tidak menggunakannya dan tidak memiliki rencana saat ini untuk melakukannya, itu memberi kesan bahwa Anda akan merasa tidak puas atau bahkan tidak puas bekerja dengan teknologi yang lebih tua. Itu juga dapat memberi kesan bahwa antusiasme Anda terhadap satu produk telah membutakan Anda terhadap berbagai alternatif.

Jika Anda benar-benar berpikir Anda akan senang di toko non-LINQ, cobalah bertanya tentang apa yang mereka lakukan menggunakan, dan menyesuaikan jawaban Anda sesuai. Tunjukkan pada mereka bahwa sementara Anda lebih suka LINQ, Anda kompeten menggunakan alat apa pun yang ada.


4
@MatthewPatrickCashatt Anda tidak dapat melakukan edit dan melanjutkan metode debugger di dalam yang berisi pernyataan linq. Tidak cukup hanya belokan yang tidak saya gunakan; tetapi itu adalah alasan utama saya ragu-ragu melakukannya untuk sementara waktu.
Dan Neely

3
+1, terutama untuk paragraf kedua. Ini benar-benar berlaku untuk saya, karena saya akan benar-benar tidak senang bekerja pada kode C # tanpa bisa menggunakan LINQ.
Arseni Mourzenko

5
Ada juga fakta bahwa sering ada hit kinerja selain abstraksi yang bocor. Anda bertukar kemudahan penggunaan untuk presisi, dan kehilangan presisi sering menyertakan detail yang akan membuat segalanya lebih cepat. Dan semakin jauh Anda dihapus dari sumbernya, semakin detail Anda lepas dan semakin besar kemungkinan detail itu penting bagi kinerja.
jmoreno

6
+1 tetapi juga bisa bekerja dengan cara lain. Jika seseorang mengatakan kepada saya bahwa mereka tidak mempekerjakan saya karena saya menggunakan Yacc untuk membuat parser alih-alih menggulirkan parser saya, maka itu bukanlah suatu tempat yang ingin saya gunakan untuk bekerja.
Spencer Rathbun

5
@ MatthewPatrickCashatt: jawaban ini (dan komentar saya tentang itu) tidak spesifik untuk LINQ, tetapi pernyataan umum. Tetapi untuk LINQ, inilah kutipan dari C # 4.0 / 5.0 secara singkat, berbicara tentang masalah kinerja dengan LINQ. Kembali ke generalisasi: dalam banyak kasus, pencapaian kinerja akan sepadan, 5% +/- tidak relevan. Tapi kadang-kadang akan lebih besar dan kadang-kadang bahkan 0,1% tidak dapat diterima. Jika Anda tidak berpikir akan ada masalah, atau kinerja itu hanya untuk perusahaan seperti google ....
jmoreno

29

Beberapa pemrogram .NET, terutama yang berasal dari latar belakang VB / ASP klasik atau C ++, tidak menyukai hal-hal baru seperti LINQ, MVC dan Entity Framework.

Berdasarkan apa yang saya amati, mantan VBer dalam grup ini kemungkinan masih menggunakan lapisan akses data dan kode lain yang aslinya ditulis 10+ tahun yang lalu. Mereka juga akan menggunakan kata kunci lama seperti "n-tier" dan sejenisnya dan tidak benar-benar memahami apa pun tentang apa pun di luar .NET Framework 2.0 juga tidak ingin mempelajari apa pun tentang itu.

Para C + + cenderung pemrogram berorientasi akademis yang suka coding algoritma keren, bahkan jika itu berarti menciptakan kembali roda. Mereka benci tergantung pada apa pun yang tidak mereka berikan kode sendiri Beberapa dari orang-orang ini juga senang membuat orang yang diwawancarai merasa rendah diri, terutama mereka yang memiliki latar belakang yang kurang tradisional.

Anda kemungkinan akan bertemu dengan organisasi seperti ini ketika Anda mewawancarai. Tapi, Anda juga akan bertemu dengan beberapa yang menggunakan metode yang lebih baru. Jangan biarkan beberapa wawancara buruk membuat Anda marah.


2
Terima kasih jfrankcarr. Saya menduga ini mungkin - ada pertanyaan tentang membuka dan menutup datareaders!
Matt Cashatt

2
+1 untuk memanggil MVC "hal baru." Membuatku tertawa terbahak-bahak. Sudah ada sejak 70-an. Anda mungkin bermaksud MVVM yang pada dasarnya adalah MVP (varian MVC) yang menggunakan binding.

14
@ GlenH7 Saya pikir cukup jelas dari konteksnya bahwa yang ia maksud adalah produk "ASP.NET MVC", bukan konsep dasar Model-View-Controller.
Carson63000

4
@ GlenH7 - Saya berbicara sepenuhnya dalam konteks lini produk .NET dan Visual Studio dan kata kunci produk Microsoft.
jfrankcarr

6
Ya Tuhan, apakah benar-benar ada toko yang menganggap Linq sebagai "baru"? Sudah ada selama lebih dari 4 tahun. Saya dapat memahami bahwa saya tidak mengejar tugas penunggu, atau menggunakan dynamic/ ExpandoObject/ etc., Atau tidak peduli tentang Azure dan semua hal cloud lainnya ... Saya bahkan dapat memahami terus menggunakan tampilan WebForms sekolah lama mesin di MVC atau Formulir Web itu sendiri, atau menulis kode WPF / WinRT tanpa MVVM ... tapi Linq? Jika Anda belum mengetahuinya, saatnya untuk berhenti dari pekerjaan Anda sebagai pengembang .NET.
Aaronaught

16

Microsoft memiliki sejarah panjang dalam menghasilkan teknologi baru yang panas dan kemudian melupakannya 5, 10, atau 20 tahun ke depan. LINQ mungkin terlihat seperti yang lain bagi sebagian orang. Mereka akan mencatat bahwa Microsoft tidak dapat menolak SQL, tetapi LINQ bisa mengikuti Silverlight . Jadi Anda bisa melihat paranoia yang dihasilkan dari pengalaman yang sulit, atau hanya orang-orang yang tertinggal oleh teknologi modern dan yang membencinya.


12
Sejujurnya, ketika saya melihat poin dasarnya, saya tidak berpikir Linq akan pergi dalam waktu dekat. Linq2SQL, ya, mereka menolaknya demi EF yang jauh lebih kuat. Tapi Linq sendiri adalah fondasi bagi begitu banyak kebaruan baru mengkilap dalam 3 .NET rilis terakhir yang jika mereka tidak gunakan lagi mereka akan membatalkan setengah dari teknologi lapisan-ketekunan baru mereka seperti Azure dan EF, untuk mengatakan tidak ada yang melumpuhkan hampir setiap ORM di luar sana dan BANYAK pemrosesan dalam memori di samping.
KeithS

6
tunggu ... "takut untuk menjauh dari teknologi yang sudah ketinggalan zaman, karena berhasil" ... WTF. Sudahkah kita sampai pada titik di mana hal-hal yang dapat dicoba, diuji, dapat dimengerti, dan dipelihara, serta matang tidak baik.
gbjbaanb

7
@ gbjbaanb - Tidak. Tetapi - sebagai anekdot - apakah Anda ingin dokter mendiagnosis nyeri dada Anda dengan rontgen dada karena metode itu 'dicoba, diuji, dapat dimengerti' atau Anda ingin fMRI yang lebih baru, tetapi hadir dengan resolusi lebih tinggi , prognosis yang lebih baik dan lebih banyak informasi? Tidak ada yang mengatakan untuk berpaling dari prinsip-prinsip klasik di sini; justru sebaliknya. Anda lihat, LINQ (sebagai contoh) dibangun di atas prinsip-prinsip tersebut. Saya pikir, seperti yang telah disebutkan orang lain, itu adalah pembelajaran dari bagian-bagian yang membuat LINQ dan penggunaan yang tepat yang menyebabkan momen 'WTF' seperti milik Anda.
Matt Cashatt

2
@MatthewPatrickCashatt: tergantung, jika dokter belum dilatih untuk membaca hasil fMRI, saya akan mengambil x-ray daripada membuatnya menebak diagnosis. Jika saya sakit di daerah terpencil, saya lebih suka memiliki dokter yang dapat mendiagnosis dengan stetoskop tidak lebih daripada tidak dapat mengatasi tanpa alat terbaru yang canggih.
gbjbaanb

2
@MatthewPatrickCashatt Saya mengerti maksud Anda, tetapi faktor penyeimbang adalah Anda tidak ingin mengikuti setiap tren hanya karena itu lebih baru. Saya akan dengan senang hati mengikuti teknologi baru yang sesuai dengan salah satu dari dua kategori. 1. Ini menggairahkan saya dan saya bersedia menghabiskan waktu luang saya untuk itu. 2. Ini membuktikan dirinya benar-benar menjadi lebih baik dan sepertinya itu akan bertahan cukup lama untuk membuatnya bernilai investasi. Tren yang tidak sesuai dengan salah satu dari dua kategori adalah pertaruhan terbaik.
TimothyAWiseman

15

Tidakkah masuk akal untuk menarik kode "dari rak" jika mencapai tujuan yang sama tanpa biaya tambahan?

Selalu ada biaya tambahan.

Kurva belajar untuk barang-barang di luar rak selalu ada. Rasa sakit mendapatkan pembaruan (dan dependensi) selalu ada. Ketidakmampuan untuk bermain-main dengan nyali selalu ada.

Untuk LINQ, yang pertama hanya berlaku. Banyak orang menganggap kode 'aneh' itu sulit dibaca dan sulit di-debug. Sintaks seperti sql cukup banyak persona-non-grata setiap pertunjukan profesional saya telah bekerja sejak keluar. LINQ ke SQL (dan sumber data lainnya) memiliki sejumlah gotcha dan opsi pengoptimalan terbatas.

Ini adalah argumen umum terhadap alat pihak ke-3 dan LINQ secara khusus. Semua yang dikatakan, LINQ adalah alat yang sangat berguna dan harus lebih disukai dalam kebanyakan situasi. Menangis Tidak Diciptakan Di Sini, dan abstraksi tidak boleh disukai sangat disonansi Kognatif .

Mereka tidak tahu / tidak bisa belajar LINQ, tapi mereka "jelas" adalah pengembang yang baik, jadi LINQ pasti tidak berharga. Ini jebakan yang umum.


1
Poin bagus. Setuju dengan biaya yang Anda sebutkan dan itu adalah klarifikasi yang baik. Lebih luas, bagaimanapun, mengembangkan kelas homegrown dengan yang ada karyawan baru bisa akrab karena mereka tidak ada di luar organisasi menyajikan tantangan yang sama di samping biaya pengembangan utama.
Matt Cashatt

2
@ MatthewPatrickCashatt - Oh, tentu saja. Dengan demikian, kode yang dibuat sendiri hampir selalu lebih merupakan upaya untuk kemenangan yang sama, tetapi tidak harus demikian. Seperti banyak hal lain, biaya / imbalan harus diperkirakan dan praktik terbaik yang disukai , tidak diikuti secara membabi buta.
Telastyn

@Telastyn Home-grow code juga bagus karena Anda tahu apa yang dilakukannya dan dapat memperbaikinya pada saat pemberitahuan. Selain itu, Anda dapat mengoptimalkan untuk keadaan tertentu berdasarkan penggunaan Anda sendiri, bukan rata-rata semua orang.
Hawken

13

Hal lain yang harus Anda pertimbangkan adalah bahwa antusiasme Anda terhadap teknologi baru yang keren bisa membuat orang merasa tidak nyaman dan tidak ingin Anda ada di sekitarnya. Anda tidak "memberdayakan" mereka, karena Andalah yang tahu teknologi ini, bukan mereka. Bahkan jika mereka sendiri tidak menyadarinya, mereka mungkin mencari kandidat yang memperkuat apa yang telah mereka investasikan begitu banyak waktu.

Anda ingin menunjukkan sikap yang mengatakan, "Apa pun yang Anda lakukan, saya ingin membantu Anda mencapainya", daripada memberikan subteks yang mengatakan, "Anda mungkin melakukan hal-hal dengan cara yang buruk, dan mengajak saya berkeliling akan membuktikan saya t."


+1 - dan juga memberi tahu mereka apa yang Anda ketahui, tanyakan kepada mereka apa yang mereka lakukan dan apa spesialisasi mereka.
Kirk Broadhurst

12

Pandangan saya mengenai hal ini (dan TBH saya duga karena tidak ada di antara kita yang bisa mengatakan apa yang dipikirkan pewawancara itu) adalah Anda sering pergi ke sebuah wawancara untuk menjelaskan mengapa mereka harus mempekerjakan Anda agar cocok dengan tim mereka, cara mereka bekerja .

Anda bisa menjadi pengembang yang sempurna, dewa kode permulaan rock, tetapi itu sama sekali tidak berarti apa-apa jika apa yang ingin Anda lakukan (ditekankan oleh Anda berbicara secara berlebihan dan terlalu antusias tentang beberapa gubbin teknologi keren) hanya memberi tahu mereka tentang Anda, dan bahwa Anda tidak akan cocok dengan apa yang mereka inginkan. Jika mereka memiliki sistem akses data gaya lama, yang tidak dapat di-upgrade dengan alasan apa pun, mereka tidak membutuhkan seseorang yang lupa bagaimana cara mempertahankannya. Jika mereka mengembangkan hal-hal baru, dan Anda benar-benar ingin menempatkan teknologi baru yang keren itu di mana-mana, maka jelas mereka akan memiliki masalah besar dengan pemeliharaan kode di masa depan dan / atau pelatihan staf.

Sebagai seorang freelancer, ini jauh lebih dari masalah bahwa jika mereka menyewa permie. Dengan permie, pelatihan dan pengembangan cara-cara kerja baru bukanlah hal-hal buruk, dalam lingkup kode dan praktik yang ada - Anda akan berada di sana untuk waktu yang lama untuk membuat segalanya lebih baik. Dengan freelancer, mereka benar-benar tidak peduli dengan apa yang Anda inginkan, Anda ada di sana hanya untuk melakukan pekerjaan mereka seperti yang mereka inginkan, dan itu bukan pekerjaan Anda untuk melakukan hal lain. (tidak setuju - menjadi karyawan tetap)

Mungkin tidak ada hubungannya dengan LINQ itu sendiri, saya telah menolak seorang kandidat yang muncul dan menjelaskan betapa jauh lebih baik semuanya akan ditulis dalam Haskell. Kami tidak melakukan Haskell. Hal yang sama berlaku untuk teknologi apa pun yang tidak digunakan oleh perusahaan, biasanya itu bukan masalah jika Anda menyebutnya sebagai sesuatu yang baik. Masalahnya muncul ketika Anda terlalu antusias dan tertarik padanya.


2
Saya setuju dengan ini, tetapi saya telah memperhatikan lebih banyak orang yang menggunakan sikap ini untuk menolak ide - ide bagus yang mereka tidak mengerti (misalnya pengujian, pola desain, ORM). Jadi, sementara saya setuju bahwa menjadi orang yang cocok untuk tim adalah hal yang baik, penting untuk menyadari bahwa Anda mungkin lebih baik daripada anggota tim lainnya dan harus menemukan orang-orang yang berpikiran sama di mana itu bukan hal yang buruk untuk mengetahui hal yang baik. abstraksi.
Wayne Molina

1
@WayneM yakin, tapi OP adalah freelancer, jadi itu benar-benar tidak masalah jika dia adalah dewa pengkodean, kecuali mereka siap untuk mempekerjakannya secara permanen untuk menjaga kode yang tidak dimengerti oleh tim lain (hmm) kemudian dia perlu melakukan apa yang mereka inginkan, bukan apa yang dia inginkan.
gbjbaanb

1
@WayneM juga banyak orang akan menggunakan sesuatu yang mirip dengan apa yang baru saja Anda katakan untuk mempromosikan bahwa ide-ide mereka lebih dari milik orang lain (yakin bahwa siapa yang mereka ajak bicara tidak mengerti). Pada akhirnya kedua belah pihak bias, tetapi OP adalah tentang disewa, bukan memenangkan perang besar DIY / abstraksi. Setiap orang akan memiliki pendapat mereka sendiri, tetapi seseorang harus mengatasinya; Saya kira itu bukan majikan dalam kasus ini. :(
Hawken

10

Ada satu kekhawatiran valid yang saya dengar dari mereka yang tidak menggunakan Linq, dan itu yang saya ingat: "Hanya karena Anda tidak dapat melihat implementasinya tidak berarti itu tidak mahal".

Ambil cuplikan berikut:

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

LINQ yang diinisiasi di sini cringing. Mengapa? Karena hanya karena kode ini terlihat bagus dan elegan bukan berarti kode itu tidak efisien. Hitung (), dengan predikat, mengevaluasi setiap elemen dari induknya dihitung, dan meringkas berapa kali predikat dikembalikan benar. Jadi, tidak hanya N ^ 2 ini (ketika inputList dan inputInputList lainnya kira-kira sama dengan kardinalitas N), ini adalah kasus terburuk mutlak N ^ 2; SETIAP elemen inputInputList lain dilalui untuk SETIAP elemen input. Sebagai gantinya, langkah pertama adalah menggunakan Any () alih-alih Count, karena itulah yang benar-benar ingin Anda ketahui, dan itu akan berhenti segera setelah jawabannya diketahui "ya". Menyiapkan HashSet yang menyimpan nilai berbeda otherInputListObject.OtherPropertymungkin membantu Anda juga; akses menjadi O (1) alih-alih O (N),kompleksitas kasus terburuk daripada kompleksitas kasus terbaik kuadratik .

Dengan demikian kita melihat bahwa metode elegan yang bagus ini memiliki biaya yang serius di belakangnya, dan jika Anda tidak tahu berapa biayanya, Anda dapat dengan mudah memasukkan kode algoritma kompleksitas - O (GD saya) ke dalam penyedia layanan file pusat berkinerja tinggi calon perusahaan Anda atau halaman portal pendaratan utama saat berikutnya mereka mungkin perlu mengubah. Memecat Anda setelah Anda melakukan itu tidak membatalkan apa yang Anda lakukan, tetapi tidak mempekerjakan Anda jika mereka pikir Anda akan melakukannya akan mencegahnya. Jadi, untuk menghindari ini, Anda harus membuktikan mereka salah; diskusikan apa yang dilakukan oleh metode-metode itu (artinya Anda harus tahu diri Anda sendiri) dan kompleksitasnya, dan bagaimana mencapai jawaban dalam waktu yang efisien (NlogN atau lebih baik).

Kekhawatiran lainnya adalah argumen "Ketika satu-satunya alat Anda adalah palu" yang baik. Tempatkan diri Anda di tempat pewawancara mewawancarai penggemar Linq ini. Calon suka Linq, ingin menggunakannya, berpikir itu hal terbaik yang pernah ada. Bahkan mungkin tampak bahwa kandidat tidak dapat kode tanpa itu, karena setiap masalah pemrograman yang diberikan diselesaikan dengan Linq. Nah apa yang terjadi ketika itu tidak dapat digunakan? Banyak kode .NET 2.0 masih di luar sana, bahwa jika itu ditingkatkan akan memerlukan upgrade yang menyakitkan ke server, workstation pengguna, dll, semuanya, sehingga Anda dapat menggunakan metode ekstensi mewah Anda. Sebagai pewawancara, saya akan mencoba untuk membuat Anda menunjukkan bahwa Anda dapat mengurutkan kode efisien atau menggunakan metode penyortiran 2.0 jika Anda harus, tidak peduli berapa banyak saya mungkin setuju dengan Anda bahwa perpustakaan Linq dan metode ekstensi serupa cukup manis. Pewawancara yang tidak mengerti maksudnya mungkin bahkan tidak repot-repot mencoba membuat Anda menunjukkan bakat untuk hal lain; mereka akan menganggap Anda tidak memilikinya dan terus maju.


Mengapa Anda tidak menulis permintaan saja var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));? Saya mungkin telah gagal itu, tetapi poin saya adalah bahwa LINQ memiliki cara yang lebih baik untuk mengeksekusi permintaan yang Anda sebutkan di atas (.Join () adalah cara lain). Saya menyadari bahwa ada beberapa cara untuk menggunakan LINQ yang mungkin tidak sebagus cara lain, tetapi itu tidak berarti Anda harus bergantung pada implementasi yang buruk itu.
Matt Cashatt

4
@MatthewPatrickCashatt Saya tidak berpikir maksudnya begitu banyak untuk mengklaim bahwa LINQ selalu tidak efisien - sementara Anda selalu dapat mengalahkan kueri LINQ yang diberikan, beberapa penggunaan memberikan kinerja yang lebih baik per pengembang-jam daripada banyak pendekatan non-LINQ. Sebaliknya, bisa relatif mudah untuk menulis kueri LINQ yang tidak efisien dan tidak menyadarinya, karena inefisiensi tidak begitu mencolok.
Jon Hanna

3
@ JonHanna: Mungkin lebih tepatnya, nilai abstraksi sangat berkurang jika seseorang harus memeriksa kode apa yang "benar-benar dilakukan" untuk menentukan apa skenario yang tidak biasa tapi masuk akal yang mungkin menyebabkan kinerja menjadi banyak urutan besarnya lebih buruk dari yang diharapkan. Jika perubahan dari satu struktur data ke yang lain akan menyebabkan kode berjalan 10.000 kali lebih lambat, kemampuan untuk melakukan perubahan seperti itu tanpa mengubah kode lain mungkin tidak selalu menjadi hal yang baik.
supercat

1
@supercat: ya dan tidak. Hanya karena pengetahuan tentang bagaimana sesuatu dilakukan dalam implementasi pihak ketiga sangat penting untuk memahami implikasi kinerja dan menghindari ketidakefisienan, tidak berarti perpustakaan yang merangkum alat-alat ini memiliki nilai lebih sedikit. Itu adalah dua sisi dari koin yang sama; mengetahui sifat implementasi, dan Anda dapat menggunakannya dengan beberapa penekanan tombol, bukan satu jam bergulir sendiri. Tapi, Anda harus tahu kedua belah pihak, dan fanboy Linq stereotip yang berpikir itu sempurna, tidak ada yang salah, gunakan untuk segala sesuatu yang sepertinya tidak.
KeithS

@KeithS: Satu hal yang saya pikir sangat hilang di Jawa dan .net adalah cara standar untuk menanyakan objek atau koleksi berbagai hal tentang diri mereka sendiri. Sebagai contoh, kode yang menerima koleksi enumerable mungkin mendapat manfaat dari mengetahui apakah jumlah item dan / atau urutan item yang ada dapat berubah, apakah jumlah item diketahui terbatas atau tidak terbatas (atau tidak diketahui), dan apakah koleksi secara inheren tahu berapa banyak item di dalamnya. Teknologi seperti LINQ sering harus membuat asumsi tentang hal-hal seperti itu yang mungkin atau mungkin tidak benar, dan ...
supercat

10

Yang ini agak lama, tapi mungkin bisa membantu seseorang jadi saya akan membiarkannya.

Saya benar-benar menemukan sesuatu yang serupa, melalui sedikit lebih dari 20 wawancara bulan lalu (campuran telepon dan tatap muka). Jelas ada sesuatu yang tidak terduga terjadi sehingga saya tidak bisa menggunakan jari saya.

Salah satu hal yang saya perhatikan adalah bahwa hal-hal yang biasanya menjadi titik pusat dari siklus wawancara selama lima atau enam tahun terakhir jelas tidak dibahas atau diberi sedikit perhatian. Hal-hal seperti dasar-dasar analisis OOP / desain, pola (desain dan arsitektur keduanya), beberapa fitur .net yang lebih maju / berorientasi abstraksi (termasuk lambdas atau LINQ khusus, generik, serialisasi / pengikatan data, dan sejenisnya), dan bahkan biasanya topik hangat metodologi disukai (tidak ada yang peduli tentang lincah vs air terjun atau apa rasa tangkas) dan alat atau pilihan ORM atau cara kolaborasi atau manajemen sumber kontrol yang disukai. Dalam beberapa kasus tidak disebutkan sama sekali, dalam hampir semua kasus tampaknya tidak menjadi perhatian.

Apa yang mendapat fokus, dalam berbagai wawancara dan berbagai perusahaan yang tidak terkait dalam industri yang tidak terkait, ada di sepanjang baris ini:

  • Fiksasi aneh pada konvensi yang ketinggalan zaman / ketinggalan zaman dan batasan "kembali ke zaman batu". Seperti mengembangkan aplikasi web primitif di VS2003 dengan daftar pembatasan absurd lebih lanjut yang melarang penggunaan fitur fitur secara luas dalam era .net ... seolah-olah itu adalah ukuran nyata dari kemampuan pengembang modern ... kemampuan untuk mengingat Paradigma dan keterbatasan 9 tahun yang lalu lebih lanjut dilumpuhkan oleh kendala yang tidak realistis / sewenang-wenang. Tempat lain sangat mantap pada subjek koleksi kustom, sekitar koleksi pra-generik. Tempat lain menggunakan sampel kode model kelas yang saya buat karena saya tidak menggunakan konstruktor bertingkat (mereka tampaknya tidak mengetahui dukungan untuk inisialisasi properti pada deklarasi, yang cukup untuk kebutuhan).

  • Fokus ekstrem pada detail implementasi spesifik dalam mikrokosmos dan / atau pengaturan konfigurasi, bahkan dalam kasus teknologi yang berfokus pada platform atau protokol agnostik (mis. Keseluruhan intinya adalah TIDAK harus terpaku pada implementasi tertentu atau penggunaan tertentu melainkan pada penggunaan kembali / re-bertujuan / ekstensibilitas / sesuai kebutuhan integrasi).

  • Kesediaan untuk menentukan / mengawasi / meninjau kode / dan sebaliknya menggulung pekerjaan ke dan dari tim lepas pantai, dan keterampilan non-coding yang terkait dengan melakukannya.

  • Penggunaan versi produk / platform / modul / dll. Untuk tingkat yang terkadang tidak masuk akal; "Jadi ... kamu sudah menggunakan versi 1, 2, dan 4? Tapi bukan 3, eh? Hmmm ... {menjelaskan resume kamu dengan" no v3 !!!} ". Tingkat penggunaan sepertinya tidak masalah; hanya bahwa Anda telah atau belum menggunakan sesuatu sama sekali , dan hal spesifik yang mereka minta juga ... tidak ada penggantian yang masuk hitungan, bahkan dari produk pesaing yang lebih banyak digunakan dan berfitur lengkap.

  • Jumlah yang jauh lebih besar dari fokus pada "seberapa baik Anda akan cocok dengan tim kami" lebih "apakah Anda benar-benar baik sebagai pengembang perangkat lunak" atau "apakah Anda memiliki keterampilan dan pengalaman untuk menambah nilai bagi perusahaan dan membantu kami memberikan kualitas produk "atau bahkan" apakah Anda idiot berbahaya yang akan datang dan menghancurkan toko ". Dalam beberapa kasus, resume saya hanya dianggap sebagai hadiah, dan bahkan apa yang disebut "layar teknologi" atau wawancara teknis adalah penilaian kepribadian yang jauh lebih dari sekadar penilaian keterampilan. Bahkan untuk posisi kontrak jangka pendek di mana Anda akan berada di sana dan pergi lagi sebelum dua musim telah berubah.

  • Perusahaan kali ini tampaknya kurang fokus dalam menyelesaikan masalah teknis tertentu, memulai proyek pengembangan lapangan hijau baru atau 2.0 besar, atau membawa produk tertentu ke pasar untuk memanfaatkan tren atau peluang yang muncul, atau kickoff besar yang biasa . Tema berulang yang saya perhatikan setidaknya 15 tempat adalah bahwa sekelompok kecil 3-5 pengembang, sebagian besar yang selamat dari jatuhnya pasar di 08, mampu menggiling produk selama 3 tahun terakhir atau lebih dan menemukan beberapa keberhasilan atau perusahaan mereka secara keseluruhan sedang booming dan mereka mempekerjakan orang-orang baru untuk mengimbangi tuntutan fitur yang meningkat atau untuk mengatasi / mengatasi kekurangan desain yang mereka buat dalam sistem ini, atau untuk mengambil alih platform yang disebutkan di atas untuk membebaskan tim inti yang membangunnya untuk melakukan "proyek lain".

Tapi ... jika ada satu hal yang saya tahu tentang bisnis ini adalah bahwa itu adalah siklus. Lain kali saya mencari pertunjukan baru, saya tidak akan terkejut jika permainan telah berubah lagi. Anda hanya harus tetap fleksibel secara mental, mendengarkan dengan aktif, menghindari membuat pernyataan absolut jika tidak perlu tetapi juga tidak menjadi musang, dan jangan dianggap sebagai satu-dimensi (Anda datang sebagai idiot atau seorang fanatik, tidak diinginkan) atau karena terlalu baik (itu bisa mengancam dan merugikan Anda).

Cukup sesuaikan pendekatan Anda, dan cobalah untuk memberikan respons yang lebih terukur di lain waktu ... sebutkan beberapa cara berbeda untuk mendekati masalah ... tetapi meskipun itu adalah pengetahuan yang hafalan bagi Anda bertindak seolah-olah Anda benar-benar memikirkannya dan alasan itu di tempat. Tampaknya lebih rendah hati dan tidak mengintimidasi atau menyangkal cara itu.

Tentu saja, Hukum Murphy menjadi seperti itu, wawancara berikutnya setelah Anda berhenti menjadi "bergairah tentang orang teknologi favorit saya saat ini" dan mengadopsi sikap yang lebih seimbang / membelai jenggot adalah pertunjukan yang akan Anda dapatkan seandainya Anda menjadi gila. pria fanatik. ;)


6

Saya pikir Anda menggambar kesimpulan yang salah, karena set sampel Anda terlalu terbatas. Meskipun saya telah melihat bagian yang adil dari toko-toko TI dengan keengganan kuat terhadap apa pun yang "tidak ditemukan di sana" 1 , tidak satupun dari mereka akan mendiskualifikasi kandidat berdasarkan preferensi mereka dalam tumpukan teknologi: mereka sepantasnya yakin bahwa mereka dapat mengajarkan kandidat yang tepat untuk menggunakan perpustakaan rumah mereka sendiri.

Saya sangat ragu bahwa perusahaan itu melarang penggunaan LINQ secara langsung. Kemungkinan besar, mereka ingin Anda menunjukkan kepada mereka keterampilan Anda di tingkat yang lebih dalam.

Sebagai contoh, salah satu cara untuk mengetahui apakah Anda tahu tabel hash Anda adalah meminta Anda untuk mengimplementasikan tabel primitif di papan tulis. Latihan sederhana ini mengungkapkan sejumlah data yang mengejutkan tentang pengetahuan Anda kepada pengulas: dia langsung belajar jika Anda tahu tentang kode hash / sama dengan, dan apa yang Anda ketahui tentang tabrakan hash. Pada saat yang sama, sulit untuk membayangkan seseorang yang waras menerapkan kembali tabel hash, karena Microsoft melakukan pekerjaan dengan baik. Hal yang sama berlaku untuk banyak algoritma, seperti pengurutan dan pencarian: pewawancara sering ingin tahu apakah latar belakang Anda cukup untuk memahami interaksi tingkat rendah, daripada memeriksa apakah Anda memiliki pengetahuan tentang perpustakaan .NET.

Hampir pasti bahwa mereka akan mendesak Anda menggunakan implementasi perpustakaan daripada Anda sendiri setelah Anda dipekerjakan untuk bekerja di perusahaan mereka. Tetapi selama wawancara mereka akan mendorong Anda ke kode tingkat rendah untuk mendapatkan pemahaman yang lebih baik tentang kemampuan Anda yang sebenarnya.


1 satu toko pergi sejauh membangun sendiri alat membangun agak primitif!


2
Semua poin Anda dibuat dengan baik, tapi saya harus memberi Anda warna di sekitar wawancara terakhir: pewawancara bersikeras bahwa LINQ sedang "usang". Saya bertanya, "bukankah maksud Anda MS tidak akan lagi berinvestasi dalam Linq-to-SQL tetapi Linq-to-Entities akan ada" dan jawabannya adalah bahwa ia memaksudkan apa yang ia katakan: LINQ sedang "ditinggalkan" jadi, tidak, saya tidak berpikir bahwa dia tahu terlalu banyak tentang LINQ atau akan bersikeras menggunakannya.
Matt Cashatt

1
@MatthewPatrickCashatt Jika seseorang bingung LINQ untuk LINQ2SQL dalam hal teknologi yang sudah usang, saya membuat alasan konyol untuk meninggalkan wawancara lebih awal, dan tidak pernah menelepon perusahaan itu kembali. Jika memang demikian, Anda harusnya senang karena mereka tidak mempekerjakan Anda :)
dasblinkenlight

1
100% yakin itu yang terjadi. Sebenarnya, saya tidak bisa menahan diri untuk tidak mengiriminya beberapa tautan untuk menempatkannya di jalan yang benar pada subjek, bukan sebagai pukulan karena saya tidak mendapatkan pekerjaan, tetapi karena saya benar-benar merasa malu untuknya dan berharap bahwa saya bisa bantu dia untuk tidak membuat kesalahan yang sama dua kali;).
Matt Cashatt

4
Maka ini tampaknya tidak ada hubungannya dengan tumpukan teknologi dan lebih berkaitan dengan fakta bahwa Anda memperbaikinya. Orang tidak suka dikoreksi. Itu hanya sifat manusia. Ketika orang membuat keputusan seperti mempekerjakan orang, 99% akan pergi dengan intuisi mereka. Mereka pergi apakah Anda menyebabkan mereka merasakan emosi positif atau negatif. Mengoreksinya mungkin telah menyebabkannya merasakan emosi negatif. Dan dia kemudian menghubungkan hal negatif itu dengan situasi.
coder

1
Saya tidak tahu bagaimana hashtables bekerja secara internal. Namun, tes teknis mendalam seperti itu membuat orang-orang dengan pelatihan yang berpikiran praktis adalah kandidat yang baik. Membutuhkan orang untuk memiliki pengetahuan tingkat rendah yang tidak akan pernah mereka gunakan tampaknya tidak perlu bagi saya. Prinsip-prinsip desain telah menjadi jauh lebih penting!
Tjaart

4

Saya pikir Anda membuat generalisasi gila di sana tentang jenis "Saya melihat sapi hitam di Skotlandia, jadi semua sapi Skotlandia hitam".

Jika saya mewawancarai Anda, saya akan kecewa jika Anda tidak bisa menjawab pertanyaan linq saya.

Linq adalah yang rumit, banyak orang melihatnya sebagai voodoo yang tidak adil karena sebenarnya sangat sederhana dan semakin pintar untuk itu.


3

Untuk berperan sebagai advokat iblis, alasannya adalah banyak pengembang tidak peduli tentang hal-hal baru dan berpikir semuanya harus diselesaikan dengan alat buatan sendiri (biasanya lebih rendah). Tidak ada yang salah dengan menggunakan abstraksi. Sial, biasanya tidak ada alasan bagus untuk tidak menggunakan abstraksi itu.

Kedengarannya seperti Anda baru saja mewawancarai pengembang yang buruk yang tidak mengikuti perkembangan hal-hal dan mengambil pendekatan palu dan kuku untuk semuanya. Ini adalah jenis pengembang yang tidak tahu apa-apa tentang alat open source yang bermanfaat seperti NUnit, atau NHibernate, atau berbagai wadah IoC; orang-orang yang mencoba menyelesaikan setiap masalah dengan proc yang tersimpan dalam database; orang-orang yang sama sekali tidak tahu tentang MVC meskipun sudah keluar selama beberapa tahun sekarang.


Anda dapat membuang LINQ ke kumpulan kata kunci yang berisi Nhibernate dll ... Saya tidak akan melakukannya. Sebenarnya saya pikir kata kunci menunjukkan ketidakmampuan kita untuk menjelaskan abstraksi menjadi ekspresi yang tepat.
AndreasScheinert

Anda berbicara tentang 'tetap up to date' baik saya pikir kebalikannya akan jauh lebih tepat. Banyak konsep yang berguna telah ditemukan dan digunakan di masa lalu, misalnya DSL. Terserah kepada kita untuk meningkatkan komunikasi dan pemahaman konsep kita sehingga kita tidak perlu menciptakan kata-kata baru untuk konsep lama.
AndreasScheinert
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.