Bagaimana cara mengevaluasi kualitas kode ketika Anda tidak terbiasa dengan bahasa tersebut? [Tutup]


10

Sebagai hipotesis, jika saya akan mewawancarai seseorang untuk posisi pengembang PHP baru ketika pengalaman saya di. NET, bagaimana saya bisa menentukan apakah sampel kode yang mereka berikan kepada saya efisien dan berkualitas baik?

Dengan kata lain, apa cara terbaik untuk mengevaluasi kode programmer jika Anda tidak terbiasa dengan bahasa tersebut?


1
Saya benci menyampaikannya kepada Anda, tetapi Anda tidak :-) Sertakan seseorang dalam wawancara yang tahu bahasa atau mempelajarinya sendiri.
Joppe

2
Inilah sebabnya mengapa wawancara adalah upaya tim. Anda mengevaluasi apa yang dapat Anda evaluasi, dan menunda hal-hal semacam ini kepada beberapa pimpinan tim teknis yang mengenalnya.
Kaz

Bagi saya, metrik terbaik adalah ukuran fungsi (termasuk kedalaman penyatuan di sini) diikuti oleh ukuran kelas / file.
m3th0dman

Jawaban:


20

bagaimana saya bisa menentukan apakah sampel kode yang mereka berikan kepada saya efisien dan berkualitas baik?

Hal-hal yang Anda tidak akan dapat mengevaluasi adalah penggunaan idiom bahasa dan penggunaan perpustakaan yang benar. Jadi, ini bukan hal yang harus Anda coba lihat.

Yang dapat Anda evaluasi adalah:

  • Seberapa baik kode terstruktur terlihat seperti
  • Variabel yang dinamai dengan baik (dapatkah Anda memahami banyak hal)
  • Fungsi / unit kode yang tersusun dengan baik
  • Konsistensi dalam basis kode

Poin di atas (meskipun tidak lengkap) akan menunjukkan apakah kode berbau atau tidak dan harus menjadi sesuatu yang dapat diidentifikasi oleh programmer berpengalaman sebagai baik atau buruk.

Singkatnya - cari hal-hal yang menunjukkan kode yang baik terlepas dari bahasa.


5
Satu lagi yang penting: "Apakah komentarnya jelas, bermakna, dan mudah dimengerti?" Bisakah Anda belajar sedikit tentang apa yang dilakukan sepotong kode dari komentar, bahkan jika Anda memiliki sedikit paparan bahasa?
FrustratedWithFormsDesigner

2
@FrustratedWithFormsDesigner - Komentar? Apa itu? Serius meskipun, kode harus berkomentar sendiri. Komentar hanya boleh ada di sana untuk menjelaskan alasannya atau memberikan alasan untuk kode yang buruk.
Oded

6
Saya mendesak sangat hati-hati: sangat mudah untuk akhirnya memilih berdasarkan siapa yang menulis kode yang paling Anda terbiasa, yang mungkin relatif kurang baik menggunakan bahasa itu.
Jerry Coffin

@FrustratedWithFormsDesigner Oded mungkin berpikir Anda harus membaca elegantcode.com/2010/04/18/…
Joel

4

Mintalah mereka membuat bagan alur atau memandu Anda melewatinya sebagai bagian dari wawancara. Anda memiliki alasan yang sempurna untuk bertanya dan itu memberi tahu sedikit tentang bagaimana mereka berpikir untuk melihat bagaimana mereka menjelaskan.

Jika mereka akan melompat ke bahasa pilihan Anda, Anda tahu Anda memiliki banyak mentoring yang datang sehingga Anda harus mencari logika / kemampuan berpikir yang baik di atas segalanya.

Jika mereka akan tetap bekerja dalam bahasa pilihan mereka, Anda harus menerima bahwa mereka akan mengatur diri saya sendiri pada detail spesifik bahasa yang lebih halus sampai orang lain tetap mempercepat, jadi Anda semua harus berinteraksi dengan adalah sisi desain di sana juga.


1
Jika kandidat dapat menjelaskan kode mereka sehingga maksud dan tujuan di baliknya jelas, dan secara visual, organisasi dan struktur umum terlihat masuk akal, mereka mungkin memiliki pemahaman yang masuk akal tentang apa yang diwakilkan kode tersebut. Dan kemungkinan bisa mengulangi reproduksi bersih yang serupa. Bahkan jika bagian-bagian tertentu dijelaskan dengan sesedikit 'karena itulah yang ditunjukkan bahan referensi tertentu bagaimana melakukannya', saat menamai materi referensi, Anda setidaknya memiliki representasi sederhana dari kemampuan untuk tidak hanya 'kode' tetapi untuk menemukan dan menerapkan solusi untuk masalah yang tidak mereka hadapi secara rutin.
JustinC

1

Mengesampingkan kode yang jelas / salah, efisien sebagian besar akan bergantung pada kompiler / juru bahasa yang bersangkutan, dan Anda tidak akan benar-benar dapat melihatnya dari sampel kode. Contoh kode dapat ditulis dengan indah dan elegan seperti porselen halus pada doilies tetapi berjalan lambat jika dikompilasi / diinterpretasikan dengan buruk.

Anda tidak akan dapat mengevaluasi penggunaan fitur bahasa / gula sintaksis / konvensi secara idiomatis tanpa keakraban.

Anda harus dapat mengetahui apakah itu ditulis dengan baik secara umum berdasarkan pertimbangan universal seperti kerapian, aliran kontrol, penamaan variabel, urutan operasi, dan sebagainya.

Namun, lebih praktisnya, jika Anda tahu bahasa apa yang akan digunakan dalam proses, Anda dapat mencoba menemukan satu atau lebih panduan gaya untuk bahasa itu, pergi ke toko buku dan balik melalui beberapa buku untuk bahasa itu dan membaca sekilas contoh kode yang mencari analog dengan sesuatu yang Anda kenal dengan bahasa pilihan Anda, periksa satu atau lebih proyek sumber terbuka yang menggunakan bahasa itu, dan sebagainya.

Jika Anda punya waktu dan jika tidak ada penghalang biaya, Anda mungkin bahkan melangkah lebih jauh untuk mengatur lingkungan pengembangan untuk bahasa itu dan mengeluarkan aplikasi Hello World, melakukan kata sandi, atau menulis aplikasi kecil sederhana di dalamnya. Anda akan mengembangkan kerangka referensi yang belum sempurna dengan cepat dan tidak hanya akan memberi Anda dukungan untuk tujuan khusus meninjau kode yang dimaksud, Anda mungkin akan terdorong oleh bahasa dan sedikit bercabang.


1

Terlepas dari bahasa:

  • Adakah pemisahan kekhawatiran yang jelas, penggunaan kelas yang tepat (untuk bahasa OO), atau indikasi upaya yang disengaja untuk memecah kode menjadi 'potongan' modular yang dapat digunakan kembali?
  • Demikian pula, ada bukti pengujian - pengujian unit atau sebaliknya?
  • Jika itu kode produksi, apakah itu dipenuhi dengan string debug yang mungkin menyarankan sedikit pemisahan antara pengembangan dan penyebaran?
  • Apakah kode mengikuti konvensi penamaan apa pun (apakah Anda suka konvensi itu atau tidak, tidak penting!)?
  • Jika Anda memiliki file, daripada hasil cetak, apakah setiap fungsi / kelas dalam file berhubungan dengan (jadi jika itu file yang disebut data_access_layer , bukti fungsi yang memproses gambar mungkin tidak pada tempatnya).
  • Indikasi kurangnya kepercayaan terhadap input pengguna juga bagus, terutama untuk bahasa berbasis web seperti PHP. Jadi struktur seperti input = melarikan diri (input) setidaknya menunjukkan kepada Anda bahwa mereka mengetahui masalah ini.
  • Komentar atau kode yang menggambarkan diri sendiri selalu baik. Ada beberapa aliran pemikiran tentang jumlah komentar yang harus ada, tetapi tidak ada komentar sama sekali
  • Dengan biaya menjadi sinis, saya juga akan google beberapa kode sebelum wawancara. Sayangnya, ini bisa dengan mudah menjadi pekerjaan salin dan tempel.

Tidak mengatakan bahwa kode apa pun yang tidak memiliki semua ini secara otomatis buruk, tetapi saya menganggap ini sebagai indikator seseorang yang telah merenungkan dan mempertimbangkan praktik mereka.

Namun, untuk semua indikator ini, Anda harus bertanya seperti apa rasionya menjadi seperti itu. Mungkin ada alasan bagus, khusus bahasa untuk pilihan mereka ... dan setelah itu, google adalah teman Anda ketika mereka dan kandidat lainnya pergi, karena Anda dapat memeriksa apakah apa yang mereka katakan terdengar masuk akal ...!

Semoga beruntung, karena mempekerjakan orang baik adalah salah satu peran paling penting dalam organisasi Anda;)


Di belakang, ini duplikat banyak dari apa yang @Oded (dan komentar) katakan.
frackham

0

Anda harus bertanya kepada seseorang yang tahu bahasa yang dimaksud untuk datang ke wawancara atau melihat sampel. Orang seperti itu akan lebih mungkin menemukan titik-titik buruk jika ada.

Apakah kandidat akan bekerja dalam tim? Biarkan anggota tim menemuinya dan mengajukan pertanyaan tentang keahliannya.


-2

Tanyakan kepada mereka tentang batasan yang mereka temui saat menggunakan bahasa. Minta mereka untuk menunjukkan kepada Anda permintaan SQL sederhana. Dev Php apa pun yang patut dicoba harus dapat mengeluarkan kueri pemilihan / pembaruan / penghapusan dasar tanpa terlalu banyak usaha.

doug

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.