Bagaimana Anda mengevaluasi keterampilan desain berorientasi objek? [Tutup]


11

wawasan atau pertanyaan apa yang akan menuntun Anda untuk menentukan keterampilan OOAD seseorang.


Tanyakan kepada mereka apakah mereka memberi titik pada i mereka.
Ayub

Jawaban:


10

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.


Saya suka metode wawancara di mana ini adalah diskusi daripada tanya jawab.
Rohan Monga

5

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.


Bisakah Anda memberi saya tautan :)
Rohan Monga

1
@bronzebeard - Ini dia - sites.google.com/site/steveyegge2/… . Dia benar-benar berbicara tentang pemodelan OO HTML - tapi saya pikir XML bisa menjadi versi yang lebih sulit dari pertanyaan itu :)
talonx

4

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.


Itu adalah tes untuk mengetahui bagaimana kelebihan beban bekerja di C #, tetapi bukan ujian untuk keterampilan desain OOAD.
user281377

Anda benar sekali. Saya membaca pertanyaan Anda terlalu cepat, saya mengubahnya.

4
Namun, Anda dapat memiliki pengetahuan tentang pola desain dan tidak pernah mendengar konsepnya. Saya telah menggunakan hal-hal seperti rantai tanggung jawab, pengamat, dan pengontrol jauh sebelum saya tahu bahwa mereka memiliki nama. Berhati-hatilah untuk tidak berasumsi bahwa karena seseorang tidak mengetahui nama suatu pola, ia tidak dapat menggunakannya dengan kompeten.
Michael K

@Michael: ya itu sebabnya mengapa lebih baik untuk pertama kali bertanya bagaimana menyelesaikan masalah tertentu, kemudian berbicara tentang nama sebenarnya dari polanya. Saya tahu banyak orang menggunakan pola strategi setiap hari dan yang tidak tahu itu disebut seperti itu. Mereka hanya "menciptakan" dengan hanya berpikir, seperti kelompok empat yang asli lakukan. Perbedaannya adalah bahwa yang terakhir menulis buku tentang subjek tersebut.

Catatan, Geng Empat mendapatkan pola dari melihat kode OO yang digunakan dalam proyek lain. Mereka tidak pernah mengambil kredit untuk salah satu desain, hanya dalam mengenali mereka dan menggambarkannya secara konsisten.
Macneil

3

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.


2

Akan memintanya untuk menuliskan objek bisnis, kelas, dan antarmuka / metode untuk ruangan atau entitas virtual lainnya


2

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?


1

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 :-)


Saya tidak tahu tentang ini, karena semua contoh dalam buku ini secara khusus menuju satu Pola Desain atau yang lainnya. Jika Anda memiliki cukup pengetahuan teoretis, Anda akan dapat mengetahuinya dan itu tidak mencerminkan aplikasi pragmatis
Rohan Monga

1

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

  1. Pengendali (hal yang memicu perubahan acara dan mengevaluasi respons),
  2. Pengamat (validator merespons perubahan acara),
  3. Strategi (setiap validator mewakili cara yang berbeda untuk menentukan apakah input tersebut valid),

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.


1

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.


0

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.


Sementara saya mengerti maksud Anda, saya pikir saya mungkin sedikit berhati-hati dalam mengambil ini secara harfiah. Ketika saya solusi desain 'berpikir bebas' saya cenderung menggunakan notasi kelas UML bahkan jika itu bukan yang saya maksudkan dengan diagram saya.
Ken Henderson
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.