Prinsip-prinsip SOLID vs YAGNI

Kapan prinsip-prinsip SOLID menjadi YAGNI?

Sebagai pemrogram, kami membuat pertukaran sepanjang waktu, antara kerumitan, pemeliharaan, waktu untuk membangun, dan sebagainya. Di antara yang lain, dua pedoman paling cerdas untuk membuat pilihan ada dalam pikiran saya prinsip-prinsip SOLID dan YAGNI. Jika Anda tidak membutuhkannya; jangan membangunnya, dan jaga kebersihannya.

Sekarang misalnya, ketika saya menonton seri dimecast pada SOLID , saya melihatnya dimulai sebagai program yang cukup sederhana, dan berakhir sebagai yang cukup kompleks (ujung ya kompleksitas juga di mata yang melihatnya), tetapi masih membuat saya bertanya-tanya: kapan prinsip SOLID berubah menjadi sesuatu yang tidak Anda butuhkan? Semua prinsip yang solid adalah cara kerja yang memungkinkan penggunaan untuk membuat perubahan di tahap selanjutnya. Tetapi bagaimana jika masalah yang harus dipecahkan adalah masalah yang cukup sederhana dan ini adalah aplikasi yang dapat dibuang, lalu bagaimana? Atau apakah prinsip-prinsip SOLID sesuatu yang selalu berlaku?

Seperti yang ditanyakan dalam komentar:

• Prinsip SOLID
• YAGNI

Selalu sulit untuk menilai pendekatan berdasarkan screencast, karena masalah yang dipilih untuk demo biasanya sangat kecil sehingga menerapkan prinsip-prinsip seperti SOLID dengan cepat membuatnya tampak seperti solusi yang sepenuhnya direkayasa.

Saya akan mengatakan prinsip-prinsip SOLID hampir selalu berguna. Setelah Anda menjadi mahir dengan mereka, menggunakannya tidak tampak seperti sesuatu yang harus Anda pikirkan secara sengaja. Itu menjadi alami. Saya telah melihat banyak sekali aplikasi sekali pakai menjadi lebih dari itu, jadi saya sekarang takut mengatakan bahwa saya akan membuang sesuatu, karena Anda tidak pernah tahu.

Pendekatan yang biasanya saya ambil adalah bahwa jika saya sedang menulis aplikasi sederhana untuk tugas tertentu, saya kadang-kadang akan melupakan prinsip-prinsip nama besar demi beberapa baris kode yang berfungsi. Jika saya menemukan bahwa saya kembali ke aplikasi itu untuk membuat perubahan lebih lanjut, saya akan meluangkan waktu untuk membuatnya SOLID (setidaknya agak, karena penerapan prinsip 100% jarang layak).

Dalam aplikasi yang lebih besar, saya memulai dari yang kecil dan seiring perkembangan program, saya menerapkan prinsip-prinsip SOLID jika memungkinkan. Dengan cara ini saya tidak mencoba untuk mendesain semuanya di muka sampai akhir. Bagi saya, itu adalah sweet spot tempat YAGNI dan SOLID hidup berdampingan.

Pikirkan masalah yang dihadapi terlebih dahulu dan terutama. Jika Anda secara membuta menerapkan prinsip-prinsip YAGNI atau SOLID, Anda dapat melukai diri sendiri nantinya. Sesuatu yang saya harap kita semua bisa mengerti adalah bahwa tidak ada pendekatan desain "satu" yang cocok untuk semua masalah. Anda dapat melihat bukti bahwa ketika sebuah toko menjual topi yang diiklankan sebagai "satu ukuran cocok untuk semua", tetapi itu tidak sesuai dengan kepala Anda. Itu terlalu besar atau terlalu kecil.

Alih-alih, lebih baik untuk memahami prinsip dan masalah yang berusaha diatasi oleh SOLID; serta prinsip dan masalah yang YAGNI coba atasi. Anda akan menemukan bahwa yang satu berkaitan dengan arsitektur aplikasi Anda dan yang lainnya berkaitan dengan proses pengembangan secara keseluruhan. Meskipun ada beberapa kasus yang tumpang tindih, mereka merupakan masalah yang sangat berbeda.

YAGNI (Anda Tidak Akan Membutuhkannya [akronim Amerika kuno]) berkaitan dengan menghemat waktu pengembang dengan menambahkan fondasi beton bertulang baja kembali ke jembatan yang hanya dimaksudkan untuk menjangkau anak sungai selebar 3 kaki ketika jembatan kayu yang lebih sederhana akan melakukan hal yang sama. baik. Jika kita membentang sungai selebar satu mil dan perlu mendukung beberapa trailer traktor, tentu saja kita akan membutuhkan pekerjaan pondasi ekstra. Intinya, YAGNI memberitahu Anda untuk melihat gambar yang lebih besar dan desain untuk kebutuhan saat ini . Ini menangani masalah membuat sesuatu terlalu rumit karena kami mengantisipasi sejumlah kebutuhan potensial yang belum diidentifikasi oleh pelanggan.

PADAT berkaitan dengan bagaimana kita memastikan potongan-potongan jembatan cocok bersama dengan benar, dan dapat dipertahankan dari waktu ke waktu. Anda dapat menerapkan prinsip SOLID pada jembatan kayu serta jembatan beton bertulang baja.

Singkatnya, kedua konsep ini tidak harus bertentangan satu sama lain. Ketika Anda menemukan sebuah situasi di mana Anda percaya bahwa mereka ada, inilah saatnya untuk melihat gambaran besarnya. Bergantung pada kesimpulan Anda, Anda mungkin memutuskan untuk menghilangkan sebagian dari prinsip-prinsip SOLID atau Anda mungkin memutuskan bahwa Anda benar-benar membutuhkannya.

Prinsip-prinsip SOLID tidak diperlukan ketika itu adalah aplikasi yang dibuang; kalau tidak mereka selalu dibutuhkan.

SOLID dan YAGNI tidak berselisih: Desain kelas yang baik membuat aplikasi lebih mudah dirawat. YAGNI hanya menyatakan bahwa Anda seharusnya tidak menambahkan kemampuan aplikasi Anda untuk menjadi monster yang dapat dikonfigurasi yang dapat melakukan segalanya di bawah matahari - kecuali jika benar-benar membutuhkannya.

Perbedaan antara kelas mobil yang memiliki batas yang jelas (SOLID) dan kelas mobil yang memiliki kemampuan untuk sembuh sendiri (YAGNI) sebelum pelanggan memintanya.

Tidak ada yang selalu berlaku! Jangan Biarkan Astronot Arsitektur Menakutkan Anda! Yang penting adalah mencoba dan memahami masalah apa yang sedang dicoba diatasi oleh prinsip-prinsip ini sehingga Anda dapat membuat keputusan berdasarkan informasi tentang penerapannya.

Baru-baru ini saya berusaha memahami kapan saya harus menggunakan Prinsip Tanggung Jawab Tunggal ( inilah yang saya kemukakan.)

Semoga ini membantu!

Ada kutipan yang dikaitkan dengan Einstein (mungkin variasi yang asli ):

"Semuanya harus dibuat sesederhana mungkin, tetapi tidak sederhana."

Dan itu kurang lebih pendekatan yang saya ambil ketika dihadapkan dengan tradeoff SOLID vs YAGNI: menerapkannya sebagai alternatif, karena Anda tidak pernah tahu apakah suatu program kode 'membuang-buang' atau tidak. Jadi, tambahkan saja lapisan kotoran yang berfungsi, lalu poleskan ke antarmuka yang lebih bersih ... dan ulangi sampai Anda bertemu ke tingkat entropi yang tepat. Semoga.

Ada banyak cara untuk merancang program untuk masalah yang diberikan; SOLID adalah upaya untuk mengidentifikasi sifat-sifat desain yang baik. Penggunaan SOLID yang benar seharusnya menghasilkan program yang lebih mudah untuk dipikirkan dan dimodifikasi.

YAGNI dan KISS prihatin dengan cakupan fitur. Suatu program yang memecahkan lebih banyak jenis masalah lebih kompleks dan abstrak. Jika Anda tidak membutuhkan generalisasi itu, Anda telah menghabiskan waktu dan upaya membuat kode yang lebih sulit untuk dipahami dan dipelihara tetapi tidak menawarkan nilai tambah.

Program yang dirancang dengan baik tidak selalu berfokus hanya pada fitur yang dibutuhkan saja. Program yang hanya berfokus pada fitur yang dibutuhkan belum tentu dirancang dengan baik. Tidak ada trade-off, hanya dua sumbu ortogonal di ruang pengambilan keputusan. Program yang ideal bersifat modular dan hanya memiliki fitur-fitur penting.

Saya pikir Anda harus memulai YAGNI dan kapan pun ada kebutuhan, PADAMKAN itu.

Apa yang saya maksud adalah SOLID ada sehingga ketika Anda menambahkan kelas baru Anda tidak perlu refactor, cukup beralih implementasi (misalnya), baik menurut saya, tulis kode Anda sederhana, dan ketika Anda melihat bahwa Anda mengubah barang - ubahlah dengan SOLID (yaitu refactoring yang ditakuti SOLID seharusnya menyelamatkan Anda - tidak begitu buruk ketika Anda baru memulai).

Anda tidak membuang-buang waktu karena Anda harus tetap melakukan pekerjaan (di awal) dan di mana pun diperlukan, kode Anda bagus dan rapi.

Saya kira Anda bisa menyebutnya evaluasi malas SOLID.