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

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?

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.

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.

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.

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.

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."

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.

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.

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. ;)

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" ¹ , 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.

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.

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.