wawasan atau pertanyaan apa yang akan menuntun Anda untuk menentukan keterampilan OOAD seseorang.
Jawaban:
Anda dapat menunjukkan beberapa desain OO setengah-setengah dari masalah sederhana, dan mendiskusikan apa yang dilakukannya, apa yang baik dan buruk tentang itu, apakah itu cukup fleksibel, apa yang bisa diperbaiki, dan bagaimana.
Jika Anda perlu memulai diskusi, tanyakan pendapat orang tersebut tentang beberapa aspek kode, tetapi tidak dengan pertanyaan utama.
Penting untuk diingat bahwa diskusi itu penting, bukan karena Anda tahu jawabannya sebelumnya. Setiap pengembang yang layak harus dapat menunjukkan sesuatu tentang kode yang bahkan tidak Anda pikirkan sebelumnya.
Diskusikan masalah desain ujung terbuka dengan orang tersebut. Lihat bagaimana dia mulai membangun model sistem, pertanyaan apa yang ditanyakan, bagaimana desain berubah sebagai respons terhadap informasi baru.
Contoh yang bagus - disebutkan oleh Steve Yegge di salah satu posting blognya - adalah meminta orang tersebut untuk membuat model objek untuk XML.
Memiliki pengetahuan yang baik tentang semua pola desain paling populer dapat membuktikan kandidat benar-benar mencari solusi untuk masalah desainnya.
Mampu mendiskusikannya dan tahu kapan harus menerapkannya atau tidak adalah indikasi yang baik bahwa ia mengerti mereka.
Meminta dia misalnya, penggunaan dalam pengalaman masa lalunya juga dapat membantu.
Jangan berikan kuis kosakata. "Define Inheritance" atau "name 3 features of OO design" adalah pertanyaan yang tidak akan memberi tahu Anda apa pun tentang keterampilan individu, hanya berapa lama sejak ia terakhir membaca buku teks. Saya telah bertemu beberapa programmer hebat yang menggunakan keterampilan ini setiap hari, tetapi akan tersedak jika diminta untuk memberikan definisi formal.
Jika memungkinkan, mintalah kode sampel.
Jika tidak, temukan beberapa kode prosedural untuk digunakan sebagai contoh (atau kode OO yang dirancang dengan buruk), dan kemudian tanyakan kepada mereka bagaimana mereka akan mendesain ulang, menggeneralisasi dan memperbaikinya. Pastikan program memiliki konteks ekstra, sehingga pendesainan ulang bisa bermakna.
Pada akhirnya apa yang Anda uji-- desain-- subjektif. Dengan demikian, evaluasi Anda harus terbuka untuk memungkinkan beberapa solusi yang baik, dan bukan hanya satu. Lalu, pikirkan kemungkinan perubahan pada persyaratan yang akan memaksa perubahan antarmuka: Bagaimana mereka menanganinya?
Baca buku Head First Design Patterns. Semua contoh dalam buku mulai dengan masalah Berorientasi Objek dan kemudian berakhir dalam pola Desain. Mereka juga mengatakan mengapa konsep OOP tertentu akan mencapai hasil yang terbatas dan mengapa tertentu lebih baik daripada yang lain.
Meskipun buku Pola Desain buku ini penuh dengan masalah OOP :-)
Mulai dari yang sederhana: tentang apa OOP?
Anda bisa memulai dengan bertanya tentang premis dasar OOP: abstraksi, polimorfisme, pewarisan dan enkapsulasi. Makanan yang baik untuk dipikirkan untuk menghangatkan mereka.
Beri mereka masalah
Selanjutnya, berikan mereka masalah yang kemungkinan melibatkan pola. Tidak perlu menyebutkan atau menggunakan pola, tetapi pendekatan mereka kemungkinan akan menghasilkan beberapa jika mereka memiliki pengalaman di bidang tersebut.
Mungkin validasi input teks dinamis. Anda ingin dapat memvalidasi karakter input oleh karakter untuk melihat apakah itu tanggal, waktu atau tanggal dan waktu yang valid dalam format ISO8601. Anda mendapatkan salinan string input setiap kali tombol ditekan dan Anda dapat mengembalikan boolean untuk menunjukkan apakah teks tetap bagus setidaknya dalam salah satu format. Minta mereka untuk berbicara dan membuat sketsa desain menggunakan prinsip-prinsip desain OO.
Pada saat Anda selesai mengobrol tentang
maka Anda akan memiliki ide yang cukup bagus jika mereka memahami OOD.
Beri mereka masalah yang sama lagi, tapi kali ini minta desain yang berbeda
Sekarang, minta mereka untuk mendesain ulang sistem tanpa menggunakan pola Pengamat (jika mereka menyebutkannya) - mereka dapat memilih untuk pergi untuk pendekatan Rantai Tanggung Jawab atau mungkin pola Komando. Anda tidak benar-benar peduli yang mana, Anda tahu bahwa mereka memahami prinsip-prinsip yang terlibat.
Bahkan jika mereka tidak menggunakan pendekatan berbasis pola, hanya dengan mendengarkan cara mereka berusaha memecah masalah menjadi fungsi yang terkait akan menghasilkan hasil yang Anda cari.
Saya cenderung memilih skenario dunia nyata, sesuatu yang diketahui oleh siapa pun † dan meminta mereka untuk mengidentifikasi entitas; para aktor yang terlibat; interaksi apa yang ada di antara mereka; di mana fitur-fitur umum dapat diabstraksi; properti apa yang perlu dipertimbangkan.
Ya, Anda bisa meminta mereka untuk duduk dan menggambar UML, ya Anda bisa meminta mereka mencari pertanyaan pada beberapa implementasi implementasi OOP untuk melihat apakah mereka dapat "mencapai landasan".
Tetapi apa yang benar-benar dibutuhkan majikan dalam tim mereka adalah pikiran yang memahami konsep-konsep yang terlibat dan dapat menerapkannya pada apa pun yang muncul. Spesifik dapat dipelajari dengan cepat, ketika konsep tertanam.
Familiar Keakraban mendalam dan tidak adanya koneksi dengan bantuan kode: Penggunaan kamar mandi oleh keluarga di pagi hari; memasak makan malam; rute bus ke tempat kerja; perakitan mobil.
Sesuatu yang tampaknya bekerja dengan baik, dan sebenarnya hanya membutuhkan waktu beberapa detik: minta mereka untuk merancang model objek. Tidak masalah untuk apa. Ini bisa sangat sepele. Bahkan, itu mungkin sepele, untuk tidak menarik tes yang tidak perlu.
Jika hal pertama yang mereka tulis adalah sebuah objek, mereka sudah unggul 99% dari rekan-rekan mereka dalam pemahaman mereka tentang OO. Jika hal pertama yang mereka tulis adalah kelas, silakan minta mereka pergi dan mengirim kandidat berikutnya, dan renungkan mengapa itu disebut OOP dan bukan COP.