Proses pemikiran umum untuk pertanyaan wawancara "Bagaimana Anda membangun situs web / aplikasi ini"


14

Saya telah mengumpulkan banyak pertanyaan wawancara seperti "Jelaskan bagaimana Anda akan merancang aplikasi album foto", "Jelaskan bagaimana Anda akan merancang fitur khusus ini dari situs web khusus ini" (misalnya suka di Facebook, rekomendasi di Amazon, keranjang belanja, permainan jack hitam). Lalu, bagaimana jika ada jutaan benda ini? Apa yang akan Anda ubah?

Sepertinya ini mengharapkan skema database atau sekelompok definisi kelas (atau keduanya?). Saya telah belajar tentang database di sekolah tetapi saya belum pernah benar-benar merancang aplikasi sebelumnya dan saya mengalami kesulitan mengetahui di mana harus memulai, apakah desain yang saya buat adalah "baik" dan apa yang dapat saya ubah untuk membuatnya dapat diskalakan.

Apakah ada pendekatan umum atau proses pemikiran ketika merancang sistem ini? Dan masalah umum / masalah yang sepertinya banyak muncul dalam desain yang harus saya coba hindari? Dapatkah seseorang mungkin menuntun saya melalui satu (atau lebih disukai semua, sambil membandingkan kebutuhan masing-masing) dan menjelaskan:

1) Bagaimana Anda menemukan entitas apa yang dibutuhkan? 2) Bagaimana Anda memutuskan hubungan apa yang akan dimiliki semuanya? 3) Bagaimana Anda memasukkan optimasi kinerja ke dalam desain Anda? 4) Apakah saya melakukan ini menggunakan kelas atau database? Apakah itu membuat perbedaan (yaitu apakah saya memiliki kelas yang tidak dapat benar-benar diterjemahkan ke tabel database, misalnya?)

Alasan utama saya bertanya adalah karena saya sedang melalui "Cracking the Coding Wawancara" dan jawaban saya benar-benar berbeda dari yang penulis - saya punya ide yang sangat berbeda tentang kelas apa yang penting.

PERHATIAN SAYA: Dengan aplikasi berbagi foto, saya akan memiliki kelas / tabel: Foto dan Pengguna pasti.

Lalu, saya pikir jika kita mencoba membuat skema, akan ada tabel yang menghubungkan foto dan pengguna jika kita menganggap setiap orang di foto tersebut terhubung ke foto (apakah tabel ini diperlukan? Jika tidak, apakah masih praktik umum untuk memiliki tabel terpisah untuk hubungan banyak ke banyak atau tidak?).

Tetapi jika kita mencoba mengambil pendekatan berorientasi objek, mungkin sebaliknya kita akan memiliki kelas yang disebut album yang melakukan semua pekerjaan dan memiliki semua info dari dua tabel / kelas lainnya. Ini adalah satu hal yang saya perhatikan dalam buku - ada banyak kelas dan kemudian satu kelas yang pada dasarnya memiliki semua info dan menghubungkan kelas-kelas lain - apakah ini biasa? Misalnya, dalam contoh saya di atas, apakah ini tampaknya akan berlaku?

Saya hanya berharap beberapa aturan / pedoman umum untuk diikuti karena saat ini saya tidak tahu bagaimana mengatakan seperti apa arsitektur yang bagus untuk sistem besar.


1
Misalkan Anda mengkodekan album foto sebagai proyek hobi. Alih-alih bertanya, "Apakah saya di jalur yang benar?" (well, tentu saja, karena semua persyaratan berada di jalur yang harus dipenuhi, dalam beberapa cara), Anda mungkin akan bertanya "rasanya aspek desain ini membuat hal-hal yang tidak perlu menjadi canggung; bisakah kita mengubah hal-hal di sekitar untuk membuat semuanya lebih sederhana? " Tapi bagaimana Anda tahu bahwa ada beberapa aspek desain yang jelek? Dengan bekerja melalui eksperimen pemikiran seperti kasus penggunaan dan kasus terburuk. Juga: "persyaratan masuk ini cukup umum; bisakah kita menemukan perpustakaan alih-alih menciptakannya sendiri?"
Evgeni Sergeev

Jawaban:


19

Inti dari pertanyaan tersebut adalah untuk menilai apakah Anda memiliki keterampilan dunia nyata dalam menulis aplikasi perangkat lunak. Anda telah belajar beberapa teori, tetapi pengetahuan teoretis hanya bisa sejauh ini. Satu-satunya cara untuk benar-benar memahami pengembangan perangkat lunak adalah dengan melakukannya.

Tidak ada jalan pintas untuk ini, karena tidak ada stok jawaban untuk pertanyaan seperti "entitas apa yang dibutuhkan?" Sebaliknya, Anda harus menerapkan pengalaman Anda tentang berbagai alat dan paradigma, dan bagaimana mereka bekerja bersama, untuk menghasilkan solusi praktis untuk masalah yang dihadapi.

Sebuah pertanyaan seperti "Apakah saya melakukan ini menggunakan kelas atau database?" menunjukkan bahwa Anda tidak memiliki pengetahuan dasar tentang hal-hal apa dan bagaimana cara kerjanya. Kelas adalah paradigma untuk mengatur kode Anda; database adalah metode penyimpanan data. Mereka adalah dua konsep yang secara inheren tidak berhubungan (meskipun mereka dapat bekerja bersama). Ini bukan pertanyaan salah satu atau dua.

Saya tidak bermaksud keras, tetapi saya pikir Anda perlu mengembangkan pengalaman pengkodean Anda agar berhasil dalam wawancara kerja seperti itu. Anda tentu memiliki potensi - diskusi Anda tentang aplikasi berbagi foto memiliki beberapa ide yang tepat dan menuju ke arah yang benar. Tetapi Anda perlu belajar bagaimana ini bekerja secara langsung. Cara terbaik untuk mempersiapkan wawancara Anda adalah dengan benar-benar membuat aplikasi dari awal hingga selesai. Aplikasi berbagi foto akan menjadi proyek berukuran tepat, atau Anda bisa memilih yang lain. Pengetahuan Anda akan benar-benar berkembang ketika Anda melihat bagaimana semua bagian dapat bekerja bersama untuk membuat aplikasi yang berfungsi.


8

Sepertinya ini mengharapkan skema database atau sekelompok definisi kelas (atau keduanya?)

Saya pikir Anda terlalu fokus pada detail di sini. Dengan pertanyaan itu, perekrut tidak mengharapkan deskripsi lengkap dari semua kelas yang akan Anda tulis (jika tidak mereka akan meminta Anda untuk membuat kode, bukan membicarakannya).

Jawaban Anda pertama-tama harus tentang gambaran besar - arsitektur, tingkatan, lapisan, bahkan siklus hidup proyek dan proses pengembangan yang akan Anda lakukan. Jangan ragu untuk bertanya tentang persyaratan dan lingkungan aplikasi yang seharusnya dijalankan untuk menyesuaikan jawaban Anda. Seperti yang ditunjukkan dan1111, tidak ada resep umum untuk desain aplikasi yang benar. Semua desain tergantung pada konteks.

Hanya jika perekrut mulai mengajukan pertanyaan yang sangat spesifik, Anda dapat masuk ke detail tentang kelas, entitas atau tabel database apa yang akan Anda gunakan di bawah tenda.

Juga, jika Anda memiliki sedikit pengalaman, itu hanya normal untuk mengatakan "Saya akan menunjukkan kepada Anda solusi menggunakan jenis desain aplikasi yang saya telah diajarkan dan digunakan sampai sekarang. Saya tahu ini dan itu pendekatan lain yang saya bisa menggambarkan Anda dalam ukuran besar tetapi tidak pernah benar - benar menerapkannya. Saya juga terbuka untuk menemukan dan menerapkan orang lain ".

Tidak ada yang salah dengan mengakui bahwa hanya ada begitu banyak alat di kotak alat Anda sehingga pengalaman Anda memungkinkan Anda untuk memiliki - pada kenyataannya, itu lebih baik daripada melontarkan jawaban yang telah Anda latih yang Anda tidak tahu cara kerjanya dalam praktik.


2

Saya pikir saya akan membuat komentar cepat pada pertanyaan pertama Anda:

1) Bagaimana Anda menemukan entitas apa yang dibutuhkan?

Hal pertama yang saya lakukan untuk proyek baru adalah, baik di papan tulis atau selembar kertas kosong, tuliskan semua hal-hal fisik dan konseptual tentang proyek tertentu yang dapat saya dan tim saya pikirkan. Ini adalah sesi curah pendapat.

Kata benda cenderung menjadi objek, kata kerja cenderung menggunakan kasus atau metode.

Fisik: foto (jelas!), Jenis tampilan, sistem, file foto, format file, pengguna, tanggal ....
Konseptual: menambah, menghapus, menyimpan / menyimpan, mengambil, menyortir, memodifikasi, melihat / menampilkan foto ....

Buat koneksi antara kata benda dan kata kerja. Pengguna Menambahkan Foto. (Yah - ada kasus penggunaan!)

Saya juga menyarankan melihat UML dan Pola Desain dan bagaimana mereka dapat digunakan dalam OOD generik. (Perhatikan - Saya tidak menyebutkan bahasa atau database di mana pun di atas. Jangan memilih bahasa dan kemudian lakukan OOD Anda. Lakukan OOD Anda dengan cara yang desain dapat diimplementasikan oleh OOL.

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.