Bagaimana Anda memastikan kualitas kode calon majikan sebelum Anda mengambil posisi? [Tutup]

Dalam pengalaman saya sebelum Anda mulai bekerja untuk perusahaan Anda tidak memiliki kesempatan untuk melihat basis kode (saya sudah bertanya dan untuk alasan kerahasiaan setiap orang selalu mengatakan tidak, saya pikir itu adil), jadi selama proses wawancara apa Menurut Anda, apakah pertanyaan-pertanyaan paling penting untuk ditanyakan untuk mengetahui seperti apa keadaan kode itu (toh, jika itu seekor anjing, maka Anda akan berada pada orang-orang malang yang harus berjalan setiap hari)?

MEMPERBARUI:

Daftar periksa: Tanyakan;

• Apa yang mereka pikirkan tentang basis kode. Dan ketika Anda melakukannya, perhatikan baik-baik ekspresi wajah dan waktu yang diperlukan bagi mereka untuk merespons. [Segera]
• Berapakah level CMM perusahaan [DPD] (dan jika Anda mendengar Level 5 jalankan sebaliknya [Doug T])
• Siklus hidup apa yang mereka gunakan [DPD] (Dan jika Anda mendengar "Agile", saat itulah Anda mulai mengajukan beberapa pertanyaan tajam untuk mencoba mencari tahu apakah dengan "Agile" itu berarti "Agile atau" koboi pengkodean "[Carson63000])
• Alat apa yang mereka gunakan untuk menilai kualitas kode? [DPD]
• Alat apa yang mereka gunakan untuk pengembangan? [DPD] (Cari alat refactoring dan server build berkelanjutan)
• Sistem kode sumber (kontrol versi) apa yang mereka gunakan, dan tindak lanjut yang baik adalah menanyakan mengapa mereka menggunakannya. [Zachary K].
• Seperti apa prosedur pengujian mereka? [Karl Bielefeldt] (Cari terutama untuk tim yang menggunakan kerangka kerja mengejek dan memberi penekanan pada pengujian unit otomatis menyeluruh melalui kerangka kerja yang sudah ada seperti NUnit / JUnit; jangan ditunda oleh tim yang tidak menggunakan TDD pengembangan yang digerakkan oleh pengujian, tetapi waspada jika mereka tidak menganggap pengujian sebagai bagian integral dan landasan pengembangan perangkat lunak yang solid. Carilah tim dengan penguji khusus.)
• Jenis tugas apa yang diberikan kepada pengembang baru? Untuk pengembang berpengalaman? [Karl Bielefeldt]
• Berapa banyak orang yang mengerjakan proyek? [Karl Bielefeldt]
• Apakah refactoring diperbolehkan? Didorong? [Karl Bielefeldt]
• Apa proses terkait perubahan arsitektur atau yang sedang dipertimbangkan atau telah dibuat baru-baru ini? [Karl Bielefeldt]
• Berapa banyak otonomi yang dimiliki individu atas modul mereka? [Karl Bielefeldt]
• Apakah Anda akan mengembangkan proyek baru (pengembangan greenfield) atau proyek lama (pengembangan brownfield)? (Pengembangan Greenfield umumnya lebih menyenangkan dan memiliki lebih sedikit masalah karena Anda tidak membersihkan kesalahan orang lain).
• Apakah tingkat turnover karyawan tinggi di organisasi atau tim? (Ini sering menunjukkan kualitas kode yang lebih rendah) [M.Sameer]
• Beberapa masalah pemrograman Anda sendiri; tapi hindari terlihat seperti orang brengsek. [Sparky]
• Bagaimana para pengembang berkolaborasi dan bagaimana pengetahuan dibagikan di antara tim? (Ini harus sesuai dengan kepribadian Anda; Saya akan mengatakan campuran pekerjaan solo dan pasangan mungkin yang terbaik, dengan rasio yang sesuai dengan kebutuhan sosial Anda)
• Seberapa dekat database mereka dengan 3 Normal Form (3NF), dan jika menyimpang di mana dan mengapa? (Jika mereka mengatakan "3NF ???", pergi. Jika tidak, dan mungkin tidak ada alasan bagus untuk itu, maka cari tahu apa itu).

CATATAN: Saya telah menerima jawaban Anon karena setelah sekitar satu minggu komunitas berpikir bahwa itu adalah yang terbaik - saya pikir ini menunjukkan bahwa itu adalah sesuatu yang Anda butuhkan untuk mengembangkan indra keenam. Tapi, saya pikir semua orang memiliki sesuatu yang berharga untuk dikatakan.

Daripada meminta untuk melihat kode mereka, tanyakan apa yang mereka pikirkan tentang basis kode. Dan ketika Anda melakukannya, perhatikan baik-baik ekspresi wajah dan waktu yang diperlukan bagi mereka untuk merespons.

Kemudian terapkan pengetahuan Anda tentang gerakan non-verbal budaya Anda untuk menafsirkan apa yang sebenarnya mereka katakan. Untuk perusahaan Amerika Utara, berikut ini harus akurat:

• Sebuah mengangkat bahu kecil, dan respon cepat "itu bisa lebih baik": itu mungkin cukup bagus.
• Jeda panjang, napas panjang, mungkin tawa kecil: itu tidak menyenangkan, dan orang-orang yang Anda wawancarai merasa tidak nyaman untuk mengatakan itu.
• Mata memutar, respons cepat "itu menyebalkan": mungkin baik, mungkin buruk, tetapi ada permainan politik yang terjadi. Kecuali Anda siap untuk memainkan game itu atau menjadi orang yang pendiam, menjauhlah.
• Alis terangkat atau dikontrak: mereka tidak mengerti pertanyaan, dan basis kode hampir pasti busuk.

Tentu saja, jika Anda memiliki masalah dengan komunikasi antar-pribadi, ini mungkin tidak cocok untuk Anda.

Saya terkejut bahwa Anda bahkan bertanya. Tidak ada perusahaan yang akan menunjukkan kode sebelum Anda bergabung. Bahkan kepada konsultan yang dipanggil untuk proses tersebut, kecuali mereka telah menandatangani perjanjian kerahasiaan.

Inilah yang dapat Anda minta untuk mengetahuinya.

• Apa tingkat CMM perusahaan (idealnya 5)
• Apa proses yang diikuti dalam proyek prospektif Anda (BTW, menanyakan ini bagus karena itu menunjukkan Anda tertarik pada pekerjaan "ini" dan bukan sembarang pekerjaan)
• Siklus hidup apa yang mereka gunakan (Jangan menghakimi jika Anda tidak mendengar "Agile". Mereka mungkin memiliki alasan yang sah untuk menggunakan model sekolah lama)
• Tanyakan apakah mereka menggunakan alat dan metrik apa pun untuk memeriksa kualitas kode. Dan jika ya yang mana (jika mereka menggunakan setidaknya satu alat untuk metrik dan yang lainnya untuk kualitas, itu adalah pertanda baik.)
• Perhatikan juga alat apa yang mereka gunakan. Jika itu adalah alat yang mahal seperti Resharper alih-alih beberapa alat freeware maka mereka sangat serius dengan kualitas.

1. Tanyakan apakah mereka menggunakan kontrol sumber.
   • Tidak ada kontrol sumber? -> kode yang paling mungkin menyebalkan
2. Tanyakan kepada mereka seberapa sering ulasan kode.
   • Tidak ada review kode? -> kode mungkin dicurigai (tetapi tidak harus demikian, khususnya jika itu adalah tim kecil yang terdiri dari pengembang yang layak.)
3. Tanyakan kepada mereka apakah cara mereka menguji dan menggunakan sebelum mulai berproduksi?
   • Tidak ada lingkungan pengujian? Penempatan langsung ke dalam produksi? -> kode yang paling mungkin menyebalkan.
4. Tanyakan kepada mereka apakah mereka melakukan integrasi terus menerus (mis. Berjalan membangun dengan Hudson)
   • Tidak ada integrasi berkelanjutan? -> kode mungkin dicurigai, tetapi tidak harus demikian.
5. (Terkait dengan # 3), tanyakan kepada mereka apakah lingkungan pengujian mereka terpisah dari lingkungan pengembangan Anda?
   • Tes itu dev? -> bukan pertanda baik, tidak kecuali mereka benar-benar kekurangan uang, tapi seberapa mahal sebuah kotak tambahan?
6. Tanyakan kepada mereka apakah mereka meninjau daftar tindakan sebelum digunakan untuk produksi.
   • Tidak ada ulasan tindakan sebelum penyebaran produksi? -> Bad Juju.
7. Tanyakan kepada mereka berapa banyak langkah yang diperlukan bagi mereka untuk membangun.
   • Lebih dari 3? -> juju biasanya buruk.
8. Apakah mereka mengambil metrik kode (atau perkiraan) seperti kompleksitas siklomatik atau LCOM (ukuran kohesi kelas).
   • Iya nih? -> mungkin (tetapi tidak tentu) pertanda baik mengenai kualitas kode mereka.
   • Tidak, tetapi mereka memahami konsepnya (setidaknya kompleksitas siklomatik)? -> sulit dikatakan
   • Mereka berpikir kompleksitas siklomatik adalah hidangan eksotis atau afrodisiak dari Timbuktu (dengan kata lain, mereka tidak tahu apa itu)? -> kemungkinan juju buruk.
   • Mereka pikir itu omong kosong yang tidak relevan (atau sikap semacam itu)? -> lari.
9. Tanyakan kepada mereka bagaimana mereka melacak bug.
   • Mereka melacak # bug terhadap beberapa metrik (mis. Per proyek, jumlah modul yang diubah, atau jumlah permintaan / permintaan perubahan, sesuatu!)? -> pertanda baik tentang kode mereka (dan proses perangkat lunak mereka).
   • Mereka melakukan hal di atas dan mencoba memprediksi jumlah bug yang mungkin mereka temui di proyek masa depan (atau yang sedang berlangsung) berdasarkan metrik yang diharapkan (# permintaan perubahan, ukuran proyek, dll)? -> pertanda sangat baik.
   • Mereka melacak bug hanya untuk resolusi bug? -> sulit diceritakan
   • Tidak ada pelacakan yang konsisten? -> lari.

Itu dari atas kepala saya. Anda akan melihat bahwa beberapa pertanyaan saya berkaitan dengan proses pengembangan perangkat lunak, dan tidak hanya pada pengkodean. Kualitas yang belakangan merupakan fungsi langsung dari kualitas yang sebelumnya.

Dengan itu, ketika Anda mengajukan pertanyaan ini, lanjutkan dengan hati-hati. Pelajarilah mereka dan pilih beberapa saat wawancara.

Beberapa hal yang harus Anda ingat. Tim pengembang yang baik akan senang mendengar orang yang diwawancarai menanyakan pertanyaan-pertanyaan ini ... asalkan mereka diminta dengan bijaksana. Lakukan salah, dan Anda akan memberi pewawancara kesan arogansi dan perfeksionisme. Tidak peduli seberapa bagus tim dev, tidak ada grup yang sempurna dan mereka semua memiliki masalah untuk dipecahkan, kompromi dalam kualitas dan semacamnya. Mereka menginginkan pemain tim yang memiliki kecenderungan untuk kualitas, bukan perfeksionis yang mengganggu. Jadi berhati-hatilah.

Juga, mungkin ada kasus di mana Anda memiliki tim yang terdiri dari orang-orang baik yang secara eksternal harus bekerja dalam kode yang berkualitas di bawah standar (mereka mungkin pengembang junior, atau mereka hanya mewarisi tumpukan sampah yang sekarang harus mereka kerjakan dengan terbatas sumber daya yang dikhususkan untuk meningkatkan kualitas.) Anda dapat bekerja dengan kode menyebalkan dan masih memiliki pengalaman kerja yang baik jika orang-orang di sekitar Anda juga orang baik (baik secara pribadi maupun profesional). Beri mereka kesan yang salah ketika Anda mengajukan pertanyaan, dan mereka mungkin menghindari mempekerjakan Anda sama sekali (merampas kesempatan Anda untuk bekerja dengan orang-orang baik dalam situasi yang sangat sulit dan menantang.)

• Namun, saya sepenuh hati percaya bahwa adalah suatu keharusan bagi pengembang perangkat lunak untuk bekerja setidaknya satu kali dengan beberapa jenis kode di luar harapan (atau hampir di luar harapan). Anda selamat dari itu dan melakukan pekerjaan yang baik, itu pelajaran yang berharga.

Anda mungkin juga menemukan grup pengembangan yang buruk dengan orang-orang yang menyebalkan. Jelas kemudian, kode mereka akan menyebalkan, dan mereka akan gagal di salah satu dari pertanyaan ini. Mereka mungkin membenci Anda karena mengajukan pertanyaan-pertanyaan sulit kepada mereka (dan dengan demikian mungkin membantu Anda), atau mereka akan mempekerjakan Anda karena mereka membutuhkan Anda (bahkan jika mereka / tidak akan mampu bekerja dengan Anda.)

Ketika itu terjadi, maka Anda harus bertanya pada diri sendiri apakah Anda memerlukan ini pekerjaan yang buruk. Kadang-kadang Anda melakukannya, dan Anda harus terjun ke tumpukan kotoran spaghetti. Kadang-kadang Anda tidak melakukannya (artinya, Anda tidak mampu melakukannya.)

Itulah hal-hal yang perlu Anda pertimbangkan ketika / jika Anda memilih untuk bertanya kepada pewawancara tentang kualitas kode dan proses perangkat lunak mereka.

Alih-alih kualitas kode aktual, saya lebih suka mencari perusahaan di mana pentingnya kualitas kode dipahami dengan baik.

Sebagai contoh, katakanlah perusahaan A memiliki manajer yang percaya bahwa "perencanaan adalah waktu yang terbuang" dan "kita dapat memperbaiki masalah desain nanti (misal ketika neraka membeku. Kita akan punya waktu kemudian)". Bahkan jika perusahaan itu memiliki basis kode yang baik sekarang, mereka tidak akan lama memilikinya. Dan Anda akan menjadi orang yang (terpaksa) membuatnya lebih buruk.

Di sisi lain, katakanlah perusahaan B memiliki basis kode yang buruk, tetapi manajemen memahami bahwa kualitas kode menyebabkan semua bug dan keterlambatan, mereka melihat perlunya perubahan, dan mereka bersedia melakukan sesuatu tentang hal itu (misalnya skala besar refactoring atau bahkan menulis ulang). Perusahaan itu akan meningkatkan basis kode-nya, dan Anda dapat membantu mereka mewujudkannya.

Saya tahu di mana saya ingin bekerja.

Ada kemungkinan 99,9% Anda tidak akan dapat melihat kode sebelum memulai. (Kecuali mereka mengeluarkan produk perangkat lunak gratis tentu saja)

Jadi apa yang bisa Anda lakukan, saya akan bertanya tentang proses, secara umum proses yang baik akan menghasilkan kode yang baik. Saya akan mulai dengan tes Joel, dan bertanya tentang metode pengembangan. Juga melampaui dasar-dasar. Sebagai contoh, saya selalu bertanya sistem kode sumber apa yang mereka gunakan, jadi tindak lanjut yang baik adalah menanyakan mengapa mereka menggunakannya.

Tempat saya bekerja dengan kode berkualitas sangat tinggi pada dasarnya tidak memungkinkan dua pertiga pengembang menyentuh kode. Yang lain menulis skrip tes kotak hitam otomatis sebagai gantinya. Jika Anda membuktikan diri Anda layak untuk mengubah kode yang sebenarnya, persyaratannya sangat sangat ditentukan sehingga pada dasarnya tidak lebih dari transkripsi ke dalam kode sumber. Script tes sebenarnya lebih menyenangkan untuk ditulis.

Tempat-tempat yang pernah saya lihat kode kualitas terendah justru kebalikannya: hanya programmer yang relatif tidak terlatih atau tidak dimentor yang pernah menyentuh kode tersebut, biasanya karena itu adalah alat yang tidak terkait langsung dengan produk perusahaan, atau dianggap eksperimental.

Tempat paling menyenangkan untuk bekerja memiliki keseimbangan. Pengembang baru diberi tugas nyata, tetapi dibimbing. Ada proses QA departemen dan peer review yang bagus untuk menangkap kesalahan Anda. Anda tidak dihukum karena melakukan kesalahan, tetapi diharapkan untuk memperbaikinya dan belajar darinya. Kadang-kadang, modul yang ditulis dengan buruk jatuh ke celah-celah, tetapi Anda tidak dikritik karena menghabiskan waktu meningkatkan kualitas kode ketika Anda menemukan itu. Perusahaan secara keseluruhan terus berupaya untuk menemukan cara-cara baru untuk membuat kode lebih baik.

Oleh karena itu, pertanyaan yang akan saya tanyakan untuk menilai kualitas kode adalah:

• Seperti apa prosedur pengujian Anda?
• Jenis tugas apa yang diberikan kepada pengembang baru? Untuk pengembang berpengalaman?
• Berapa banyak orang yang mengerjakan proyek?
• Apakah refactoring diperbolehkan? Didorong?
• Apa proses terkait perubahan arsitektur atau yang sedang dipertimbangkan atau telah dibuat baru-baru ini?
• Berapa banyak otonomi yang dimiliki individu atas modul mereka?

Seperti yang dikatakan @DPD dan @Zachary, proses dan SDLC adalah faktor yang sangat penting, tetapi saya ingin menambahkan beberapa faktor lain yang menurut pengalaman saya berdampak signifikan pada kualitas kode:

• Tanyakan apakah Anda akan bekerja dalam pengembangan dalam proyek yang relatif baru atau dalam mempertahankan aplikasi warisan. Aplikasi lama cenderung kurang bersih daripada proyek yang lebih baru.
• Cobalah untuk mengetahui apakah tingkat turnover karyawan tinggi di organisasi atau tim. Ini kemungkinan besar akan menurunkan kualitas kode juga.

Perhatikan bahwa suatu proses memang banyak membantu tetapi tidak akan memberikan kekebalan total terhadap faktor-faktor di atas. Ketika banyak pengembang meneruskan suatu proyek, setiap orang datang dengan pola pikir yang berbeda. Arsitek dan pengembang tidak akan mengikuti cara persis yang dilakukan pendahulu mereka yang akan menyebabkan beberapa inkonsistensi.

Sikap saya adalah ini, kode adalah kode, jika buruk, ya itu tantangan untuk membuatnya lebih baik. Jika itu baik, maka itu adalah tantangan yang bahkan lebih sulit untuk membuatnya lebih baik!

Yang paling penting bagi saya adalah apakah saya ingin bekerja untuk perusahaan dan orang-orang yang memiliki kesempatan untuk berinteraksi dengan saya. Kode dapat diubah, orang tidak dapat ...

Sedikit bercanda kukatakan, wawancara denganku .

Saya biasanya menggunakan bug aktual (sudah diperbaiki) di basis kode kami sebagai tes wawancara, sehingga Anda melihat beberapa kode aktual. Umumnya kode sedikit rumit, dan ada bug di dalamnya.

Saya mendorong semua orang untuk menggunakan teknik ini, karena Anda sudah tahu bug itu nyata, masalahnya nyata, dan Anda tahu berapa lama waktu yang diperlukan untuk menemukan dan memperbaikinya.

Yang hebat adalah Anda bisa memiliki masalah yang sulit terukur.

Saya telah menggunakan masalah yang sangat sulit sebagai pertanyaan wawancara terakhir untuk memisahkan para ahli dari yang cukup bagus.

Relevansi dengan pertanyaan OP adalah bahwa setiap orang yang melakukan wawancara fisik dapat melihat beberapa kode. (Tidak apa-apa dengan konten rahasia perusahaan)

Jika Anda tidak dapat menggunakan teknik ini, karena, kata-kata yang tidak senonoh dalam basis kode, maka tes akan berhasil, karena calon karyawan akan bertanya "bisakah saya melihat kode" dan jawabannya adalah "oh, Anda tidak dapat melakukannya penuh dengan kata-kata kotor ".

Tentu saja, standar "itu semua rahasia perusahaan" jawabannya adalah kuda puckey total.
Bukti saya: di perusahaan saya sebelumnya, bagian non-rahasia dari produk militer adalah contoh kode untuk pertanyaan wawancara. [Untungnya tidak diklasifikasikan]

Saya meninggalkan masalah menentukan kualitas desain rahasia sebelum bekerja di sana untuk seseorang yang lebih pintar dari saya. Saya sarankan mungkin umum bahwa diklasifikasikan identik dengan bebas pengawasan.

Sangat diragukan bahwa mereka akan membiarkan Anda melihat kode mereka, tetapi Anda mungkin bisa mendapatkan ide seperti apa jika Anda memberi mereka tugas pekerjaan rumah pemrograman. Banyak tempat memberi orang yang diwawancarai tugas untuk dibawa pulang yang dapat mereka gunakan untuk mengukur Anda. Kembalikan bantuan - perkirakan salah satu dari mereka sehingga Anda dapat mengukur dengan lebih baik apa yang bisa Anda dapatkan.

Tanyakan kode apa yang diperlukan untuk membuatnya menjadi bagian produksi. Jika Anda mendapatkan 'uhh ... dev melakukan itu ...' maka itu hampir pasti sampah.

Ada beberapa hal yang cenderung meningkatkan kualitas kode (jelas, tidak ada jaminan).

• Analisis statis (dalam. NET ini adalah hal-hal seperti fxcop / stylecop)
• Subset (atau set lengkap) dari test suite - unit / integrasi / regresi / manual dll.
• Buddy build (pengembang lain di tim membuat perubahan untuk melihat apakah ada masalah yang bergantung pada mesin / pengguna - terkadang menjalankan kewarasan yang cepat juga)
• Ulasan kode

Ini dapat membantu meningkatkan, tidak hanya kekuatan kode, tetapi kualitas kode.

Tanyakan kepada mereka tentang pengujian unit. Jika mereka menganggapnya serius, maka pewawancara mungkin akan memiliki beberapa pendapat yang pasti tentang masalah ini, dan akan dengan senang hati membagikannya. Jika jawabannya tidak jelas, itu pertanda peringatan besar.

Jika itu adalah toko Java, tanyakan kepada mereka perpustakaan ORM apa yang mereka gunakan. Jika mereka menggulung sendiri, maka itu bisa jadi jalan lain - bisa payah, atau bisa baik-baik saja. Jika mereka tidak menggunakan apapun, lari ke pintu segera.

Ini adalah tugas yang sulit karena ada begitu banyak praktik pengkodean buruk yang berbeda, sehingga Anda tidak akan pernah bisa memprediksi semuanya.

Kamu tidak bisa, sayangnya. Tidak ada perusahaan yang akan membiarkan Anda melihat kode mereka (tetapi mereka akan meminta untuk melihat kode ANDA ...), dan kemungkinan besar jika Anda mengajukan pertanyaan kepada mereka tentang lingkungan, Anda akan langsung dibohongi ("Kontrol versi? Tentu .. kami menggunakan .. uhh .. berpikir Sub .. Sub-sesuatu ") atau menyesatkan tentang kualitas (" Kami menggunakan .NET 4 terbaru dan terhebat hanya untuk mengetahui bahwa mereka menggunakan .NET 4 mereka ' sedang menulis itu seperti .NET 1.1).

Saya telah dibakar olehnya berkali-kali di masa lalu, dan saya belum menemukan cara yang baik untuk mengukur kualitasnya. Biasanya cara terbaik adalah dengan menggunakan penilaian Anda sendiri dan jika itu turun ke sana, segera pergi jika itu lebih buruk daripada yang Anda pikirkan; Anda mungkin berakhir sebagai hopper pekerjaan tetapi Anda akan menjaga kewarasan Anda.