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

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.

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.

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.