Bagaimana sebenarnya mencari tahu apa yang harus dilakukan dalam desain berorientasi objek?


12

Pertama penafian: Saya tidak benar-benar tahu apakah pertanyaan ini cocok dengan situs web ini, tetapi saya masih menemukan itu pertanyaan yang relevan tidak hanya untuk saya tetapi untuk orang lain yang masih pemula. Jika pertanyaan dapat ditingkatkan agar sesuai di sini, harap tunjukkan komentar int. Jika tidak cocok, beri tahu saya juga dan jika mungkin beri tahu saya di mana ini bisa dibahas karena saya tidak menemukan forum yang bagus untuk ini.

Saya telah belajar memprogram pada tahun 2009 ketika saya belajar PHP. Kemudian pada 2012, saya pindah ke C # dan .NET. Bagaimanapun, pengkodean bukanlah masalahnya, menuliskan algoritma bukanlah masalah saya. Masalah saya yang sebenarnya adalah mengetahui apa yang harus dikodekan untuk mencapai persyaratan dan di mana harus dikodekan.

Sebagian besar kursus di luar sana yang tersedia di web membahas bagaimana - cara menulis kode dalam bahasa tertentu, cara menggunakan beberapa set API, dll. Itu bukan poin saya di sini.

Pada tahun-tahun ini, saya telah membaca banyak hal tentang banyak hal: analisis dan desain berorientasi objek, pola desain, desain berbasis domain, dan sebagainya. Saya mengerti misalnya prinsip-prinsip SOLID, beberapa ide utama DDD seperti perlunya keterlibatan para ahli domain, pengembangan bahasa di mana-mana dan sebagainya. Saya berani mengatakan bahwa saya memiliki latar belakang teoritis setidaknya masuk akal.

Tetapi ketika tiba saatnya untuk berlatih, saya merasa seperti bencana. Beberapa waktu yang lalu saya perlu melanjutkan pengembangan sistem keuangan yang sudah dikembangkan oleh orang lain. Ini semacam "sistem lama" yang dikembangkan dengan C # dan WinForms. Itu adalah pertama kalinya saya memilih proyek dengan kompleksitas domain nyata, dengan banyak aturan bisnis dan sebagainya.

Saya mengaku bahwa ketika saya menerima persyaratan sebagian besar waktu saya berpikir "bagaimana mungkin ini bisa dilakukan?" - Saya tidak tahu bagaimana memulai mengerjakan persyaratan untuk mengetahui apa yang harus dilakukan. Kebingungan utama saya, saya percaya adalah apa yang harus saya kode, kelas apa, antarmuka dan di mana setiap potongan logika, di mana kelas setiap hal harus. Masalahnya adalah saya tidak tahu harus mulai dari mana.

Seringkali, dengan banyak pemikiran saya berakhir dengan beberapa ide, tetapi saya tidak pernah tahu bagaimana menilai apakah ide saya benar atau tidak.

Maksud saya, saya tidak berpikir ini kekurangan teori, seperti yang saya katakan saya sudah membaca tentang banyak hal tentang arsitektur perangkat lunak dan orientasi objek saya direkomendasikan tetapi tidak banyak membantu dalam mengidentifikasi apa yang harus dilakukan dalam praktek .

Jadi bagaimana saya bisa belajar untuk benar - benar melakukan desain berorientasi objek? Apa yang ingin saya pelajari adalah: persyaratan yang diberikan tahu bagaimana memulai mengerjakannya dalam proses yang mengarah pada mencari tahu apa yang harus dilakukan dan di mana masing-masing bagian kode berada. Bagaimana saya bisa belajar menilai apakah ide saya benar atau tidak?

Saya percaya sepenuhnya menjelaskan ini sebagai jawaban di sini tidak mungkin. Apa yang saya cari, bagaimanapun, yang mungkin sesuai dengan gaya situs adalah jawaban hanya memberikan gambaran dan menunjuk beberapa referensi (buku, kursus online, dll) yang dapat digunakan untuk memperluas ide dan benar-benar mempelajari hal-hal ini.


1. Apakah Anda sudah memahami semua konsep dasar C #, termasuk hal-hal seperti perbedaan antara overloading operator vs overriding operator, apa kelas abstrak itu dan bagaimana perbedaannya dari antarmuka, enkapsulasi, polimorfisme, dll.? Mengetahui hal-hal ini terlebih dahulu sangat penting untuk memahami OO sepenuhnya dalam C #. Lihat c-sharpcorner.com/technologies/oop-ood .
Robert Harvey

2
2. Aplikasi lama yang ditulis dalam Winforms cenderung berubah menjadi bola lumpur besar kecuali jika dirancang dengan baik. Pemisahan masalah menjadi yang terpenting. Lihat winformsmvp.codeplex.com
Robert Harvey

1
Sebenarnya tidak ada proses. Desain kebanyakan tentang mengetahui cara berorganisasi, yang disertai dengan pengalaman. Prinsip-prinsip SOLID adalah awal yang baik, tetapi itu tidak cukup, dan orang-orang cenderung tersesat di SOLID dan lupa mengapa prinsip-prinsip itu ada.
Robert Harvey

1
Mulai sedikit. Persyaratan adalah masalah. Satu masalah bisa sebesar "Kami ingin mengembangkan situs Stackexchange berikutnya" atau sesedikit "kami ingin Stackexchange berikutnya memiliki login". Ubah masalah besar menjadi banyak tetapi lebih kecil. Secara keseluruhan, beri diri Anda kesempatan untuk melakukan hal-hal yang "salah" pertama dan meningkat seiring waktu.
Laiv

1
Saya secara bersamaan ingin memperbaiki dan vtc ini ...
svidgen

Jawaban:


21

Jadi bagaimana saya bisa belajar untuk benar-benar melakukan desain berorientasi objek? Yang ingin saya pelajari adalah: persyaratan yang diberikan tahu bagaimana memulai mengerjakannya dalam proses yang mengarah untuk mengetahui apa yang harus dilakukan dan di mana masing-masing bagian kode berada. Bagaimana saya bisa belajar menilai apakah ide saya benar atau tidak?

Nah pertama-tama, berhentilah berpikir bahwa desain berorientasi objek itu benar. Itu seperti berpikir bahasa Inggris sebagai hal yang benar.

Paradigma berorientasi objek tidak benar. Ini memiliki kelebihan dan kekurangan tertentu. Ini ideal. Itu bukan satu-satunya kita. Ini lebih baik daripada tidak sama sekali tetapi tentu saja tidak semuanya.

Saya telah mengkode selama beberapa dekade sekarang. Saya telah mempelajari hal ini hampir selama idenya sudah ada. Saya masih belajar apa artinya. Para ahli masih mempelajari artinya. Seluruh bidang kami berusia kurang dari 100 tahun.

Jadi ketika Anda mengambil tumpukan persyaratan dan menghasilkan kode yang memuaskan mereka namun merasa bahwa kode yang Anda tulis adalah kekacauan yang tragis, Anda tidak sendirian. Kode kerja hanyalah langkah pertama menuju kode hebat. Kode yang tidak hanya berfungsi tetapi orang lain dapat membaca dan memahami dengan mudah. Kode yang dapat diadaptasi dengan cepat ketika persyaratan berubah. Kode yang membuat Anda ingin duduk dan berkata "Wow, itu sangat sederhana".

Masalahnya adalah kita tidak dibayar untuk melakukan semua itu. Kami melakukan semua itu karena kami profesional. Kita harus melakukan semua itu ketika bos tidak melihat karena selalu ada tenggat waktu. Tapi kami ingin kembali dalam 5 tahun dan berkata kepada para pemula: "Oh ya, saya menulis itu. Masih berfungsi ya? Keren."

Bagaimana caramu sampai kesana? Praktek. Jangan terima ide desain APA PUN atas keyakinan. Seseorang tidak akan diam tentang bagaimana desain event driven akan menyederhanakan desain ini? Tidak yakin apakah mereka benar? Bangun proyek mainan Anda sendiri di rumah yang menggunakan pola pengamat. Berantakan dengan itu. Cobalah untuk menemukan hal-hal yang TIDAK BANTU bantu.

Baca. Pertanyaan. Uji. Ulang.

Ketika Anda sampai pada titik bahwa Anda telah melakukan itu selama 80% dari hidup Anda, Anda akan sama bingungnya dengan saya.

Saya mengaku bahwa ketika saya menerima persyaratan sebagian besar waktu saya berpikir "bagaimana mungkin ini bisa dilakukan?" - Saya tidak tahu bagaimana memulai mengerjakan persyaratan untuk mengetahui apa yang harus dilakukan. Kebingungan utama saya, saya percaya adalah apa yang harus saya kode, kelas apa, antarmuka dan di mana setiap potongan logika, di mana kelas setiap hal harus. Masalahnya adalah saya tidak tahu harus mulai dari mana.

Dulu saya merasakan hal yang sama. Kemudian saya menemukan kegembiraan refactoring. Bersedialah untuk menyesuaikan desain saat Anda membuat kode. Mencoba menyelesaikan semua hal di atas kertas adalah cara yang sulit untuk melakukannya. Tulis kode yang dapat dibuktikan salah, buktikan salah, dan perbaiki.


2
Ini jawaban yang bagus. Saya telah memprogram selama 15 tahun, dan saya akan menambahkan bahwa seluruh bidang Rekayasa Perangkat Lunak (profesi saya) "tidak jelas" - ini campuran seni dan fungsi, dan tergantung pada pengembangnya lebih dari yang lain. Saya dapat memunculkan ide untuk arsitektur di atas kertas, tetapi saya tidak pernah dapat mengerjakan rincian desain OO sampai saya masuk ke dalam tanah, mencari-cari, menemukan apa yang berhasil dan yang tidak.
jropella

Terima kasih atas jawabannya! Jadi maksud Anda adalah: setelah kami memiliki setidaknya satu solusi untuk mengimplementasikan suatu persyaratan, dan itu berfungsi, kami mengimplementasikannya, dan kemudian ketika kami melihat bagaimana itu terkait dengan kode lain dan persyaratan lain, kami refactor untuk membuatnya lebih baik? Tetapi masih ada situasi di mana saya mendapatkan beberapa persyaratan dan saya tidak tahu bagaimana memulainya. Dalam hal ini, apakah Anda punya saran tentang cara memulai? Terkadang saya percaya yang terbaik adalah mendiskusikan persyaratan dan implementasi yang mungkin, tetapi saya bekerja sendiri. Apakah ada forum di mana diskusi seperti ini disambut?
user1620696

2
Baiklah pertama, berhenti bekerja sendiri. Bahkan memiliki seorang pemula yang tidak tahu apa-apa yang memperlambat Anda untuk menjelaskan banyak hal lebih baik dari itu. Kedua, belajar memecah persyaratan menjadi beberapa bagian. Terus lakukan itu sampai Anda memiliki sesuatu yang bisa Anda atasi. Tuliskan bukti kode konsep dalam lingkungan yang sama sekali berbeda jika Anda harus. Lakukan saja sesuatu yang mengekspresikan pemahaman Anda tentang apa yang dibutuhkan. Kemudian ujilah ungkapan itu. Anda saya menemukan Anda membuat asumsi buruk. Itu bagus. Bersedia untuk mengubahnya.
candied_orange

1

Pengembangan perangkat lunak bermuara pada pengiriman perangkat lunak yang berfungsi, tepat waktu, sesuai anggaran sambil memenuhi semua kriteria penerimaan Anda. Dengan asumsi Anda telah berhasil melakukan itu, persepsi kualitas kode atau strukturnya adalah masalah sekunder.

Masalahnya tentu saja adalah bahwa menulis kode greenfield baru cenderung jauh lebih murah dan lebih mudah daripada mempertahankan kode warisan, jadi daripada terlalu tergantung pada kualitas kode atau arsitektur, ingatlah bahwa masalah Anda yang sebenarnya adalah kemampuan pemeliharaan.

Biasanya kode dianggap dapat dipertahankan ketika biaya, waktu dan risiko yang terkait dengan mengubah kode itu cukup rendah secara proporsional sehingga memperbaiki bug atau menerapkan perubahan pada persyaratan masih hemat biaya, dan bahwa dengan menerapkan perubahan itu Anda tidak mengabadikan "spiral kematian" "dari entropi kode.

Sebaliknya, kode dianggap tidak dapat dipelihara ketika Anda tidak dapat dengan yakin mengubah atau refactor tanpa risiko serius baik melanggar sesuatu atau menghabiskan waktu / uang yang berlebihan untuk memastikan tidak ada yang rusak - yaitu ketika waktu, biaya dan risiko yang terlibat dalam bekerja dengan kode itu adalah sangat tinggi dibandingkan dengan manfaat melakukan perubahan (mis. atasan atau pelanggan Anda tidak kehilangan uang dengan menambahkan fitur baru, memperbaiki bug, dll.)

Ingatlah bahwa bahkan kekacauan spageti yang paling kejam dapat berpotensi dipertahankan jika Anda memiliki cukup banyak persediaan di sekitar kekacauan untuk melindungi diri Anda sendiri dari melanggar perubahan (meskipun kasus seperti itu jarang terjadi). Masalah dengan kekacauan spaghetti adalah bahwa melindunginya dari memecah perubahan cenderung sangat mahal dan tidak efisien - terutama jika Anda melakukannya secara retrospektif.

Mungkin cara yang paling dapat diandalkan untuk memastikan Anda telah menulis kode yang dapat dipelihara adalah dengan menulis (jika memungkinkan) seperangkat tes otomatis yang memadai pada saat yang sama (sambil juga mengambil keuntungan penuh dari alat analisis statis lain yang mungkin tersedia).

Anda tidak perlu mengikuti metodologi pengembangan yang ketat seperti TDD / BDD untuk berakhir dengan tes otomatis yang cukup untuk memungkinkan Anda melakukan refactor; Anda hanya perlu cukup untuk melindungi kode dari perubahan melanggar yang tidak disengaja di masa depan.

Jika kode Anda dicakup oleh tes otomatis, maka Anda dapat bersantai tentang desain dan strukturnya mengetahui bahwa Anda dilindungi oleh tes tersebut; Anda dapat secara agresif refactor di kemudian hari, atau bahkan membuangnya dan mulai lagi.

Ini menimbulkan pertanyaan tentang bagaimana menulis kode yang mudah diuji; ini biasanya argumen utama untuk mengikuti prinsip-prinsip SOLID; pada kenyataannya, ciri khas kode yang menganut prinsip-prinsip SOLID adalah mudah dan hemat waktu untuk menulis unit test.

Tentu saja, kadang-kadang Anda juga tidak punya waktu untuk menulis tes unit; namun jika Anda telah menulis semua kode sambil mengingat pertanyaan "Bagaimana cara saya menulis tes otomatis untuk ini?" (bahkan jika Anda tidak benar-benar mengimplementasikan tes-tes itu), Anda mungkin juga berhasil menemukan desain yang cukup dapat dirawat.


1
kami tidak pernah punya waktu untuk menulis tes otomatis tetapi kami selalu punya waktu menjalankan tes manual berulang-ulang ...
Nick Keighley

Demikian juga, kita tidak pernah punya waktu untuk menulis kode "dengan benar" dan "bersih" untuk pertama kalinya tetapi tampaknya memiliki waktu yang tak ada habisnya untuk terus kembali dan memperbaikinya, berulang-ulang karena pola pikir yang sesat tetapi begitu lazim disajikan dalam posting ini.
Dunk

@Dunk Saya tidak berpikir realistis untuk mengharapkan kode tidak boleh berubah atau ditinjau kembali. Praktik pengujian unit dan pedoman SOLID adalah tentang mendorong praktik yang menghasilkan kode yang mudah dan murah untuk diubah ketika hal yang tak terhindarkan terjadi - misalnya seseorang menemukan bug yang sangat aneh yang tidak dipertimbangkan pengembang pada saat itu, atau pelanggan melihat solusi dan perubahan persyaratan, atau bahkan kode asli berisi kesalahan karena pengembang hanya manusia; atau mungkin pengembang salah paham tentang persyaratan, atau menemukan batasan teknis yang sebelumnya tidak diketahui ...
Ben Cottrell

1
@ BenCottrell - Saya setuju sepenuhnya. Kode akan selalu perlu ditinjau kembali. Namun, karena itu, itu membuat orang menunjuk ke waktu untuk melakukan "desain awal" dan menulis "kode bersih" sebagai semacam kegagalan. Mereka menggunakan mantra "tepat waktu" dan "sesuai anggaran" untuk menjustifikasi kode / desain yang buruk. Anda dapat menggunakan semua "praktik" yang Anda inginkan tetapi itu tidak akan membeli Anda "kode yang mudah dan murah untuk diubah" tanpa memiliki desain yang baik dan relatif "kode bersih" untuk memulai. Desain yang baik dan "kode bersih" akan memiliki produk sampingan untuk benar-benar mencapai tujuan tepat waktu dan sesuai anggaran.
Dunk

@Dunk Kedengarannya seperti Anda mengatakan banyak pengembang tidak peduli dengan kualitas kode, yang saya tidak percaya biasanya demikian. Pada kenyataannya saya pikir ada dua masalah yang lebih besar - pertama, sementara pengembang mungkin adalah orang-orang yang memberikan perkiraan untuk anggaran dan tenggat waktu, perkiraan dapat dengan mudah berubah menjadi salah. Kedua, pemangku kepentingan proyek mendapatkan keputusan akhir tentang waktu / biaya, yang berarti risiko, anggaran, dan tenggat waktu mengesampingkan masalah teknis. Diberi pilihan antara "pasti terlambat / melebihi anggaran" atau "kode berpotensi buruk", saya menemukan bahwa para pemangku kepentingan sering memilih yang terakhir.
Ben Cottrell
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.