Bagaimana Anda menjelaskan Pemisahan Kekhawatiran kepada orang lain?

Jika Anda memiliki kolega yang tidak memahami manfaat Separation of Concerns, atau tidak cukup memahaminya untuk diterapkan secara konsisten dalam pekerjaan sehari-hari mereka, bagaimana Anda menjelaskannya kepada mereka?

Bayangkan Anda memiliki program yang telah dirilis. Seorang pelanggan datang dan menawarkan untuk membayar Anda untuk peningkatan ke salah satu fitur-fiturnya. Untuk mendapatkan uang, Anda perlu mengubah program Anda untuk menambahkan fitur baru. Beberapa hal yang akan mempengaruhi apa margin keuntungan Anda adalah:

1. berapa banyak kode yang harus Anda ubah
2. betapa mudahnya melakukan perubahan
3. seberapa besar kemungkinan Anda memecah fitur yang ada yang sedang digunakan oleh pelanggan lain
4. seberapa banyak Anda dapat menggunakan kembali model / arsitektur yang ada

Pemisahan masalah membantu Anda mendapatkan lebih banyak jawaban positif untuk pertanyaan-pertanyaan ini.

1. jika semua kode untuk perilaku tertentu dari aplikasi dipisahkan, maka Anda hanya perlu mengubah kode yang terkait langsung dengan fitur baru Anda. Kode mana yang harus diubah lebih sedikit.
2. jika perilaku yang Anda minati dipisahkan dengan rapi dari sisa aplikasi, kemungkinan besar Anda akan dapat bertukar dalam implementasi baru tanpa harus sepenuhnya memahami atau memanipulasi sisa program. Seharusnya juga lebih mudah untuk mengetahui kode mana yang perlu Anda ubah.
3. Kode yang tidak harus Anda ubah cenderung lebih kecil daripada kode yang Anda ubah. Jadi memecah kekhawatiran membantu Anda untuk menghindari kerusakan pada fitur yang tidak terkait dengan mencegah Anda harus mengubah kode yang dapat mereka panggil. Jika fitur Anda digabungkan bersama, Anda mungkin mengubah perilaku satu secara tidak sengaja saat mencoba mengubah yang lain.
4. Jika arsitektur Anda agnostik dengan detail logika teknis atau bisnis, maka perubahan pada implementasi cenderung membutuhkan fitur arsitektur baru. Misalnya, jika logika domain utama Anda adalah agnostik basis data maka mendukung basis data baru semudah bertukar dalam implementasi baru dari lapisan persistensi.

Lihatlah rumah sakit, dan pikirkan semua peran berbeda yang terlibat dalam memberikan perawatan kepada pasien: perawat, dokter, asisten medis, teknisi, staf administrasi, kafetaria, dll.

Apakah ada satu orang yang tahu bagaimana semua dari orang-orang mendapatkan pekerjaan mereka dilakukan? Tidak, karena itu akan sangat luar biasa. Mereka harus memisahkan tanggung jawab yang berbeda menjadi peran yang berbeda dan titik kontak antara peran tersebut sangat spesifik.

Jika dia bekerja di kantor, ambil sebagai contoh, jelaskan peran masing-masing staf di kantor itu, dan tanyakan padanya, apa yang akan terjadi, jika staf itu tidak dibagi sesuai dengan pekerjaan mereka?

Saya akan melihat bagaimana dia gagal menerapkan SoC dalam kode / desainnya dan mengubahnya menjadi contoh dunia nyata yang bisa dia hubungkan dengan dan itu jelas tidak diinginkan.

Misalnya, jika ia memiliki kelas di mana klien perlu menyediakan beberapa informasi yang tidak relevan untuk klien tersebut, maka saya akan menggunakan analogi toko roti di mana Anda harus membawa biji-bijian dan ragi sendiri jika Anda ingin membeli sebuah roti.

Salah satu contoh mungkin pengembang html mungkin ingin memisahkan html, css dan javascript menjadi file terpisah. Dengan cara ini Anda dapat mengubah tampilan dan nuansa dari sesuatu yang dikatakan hanya dengan memodifikasi css atau perilaku sesuatu dengan mengubah file javascript yang dimuat secara terpisah. Jika Anda memiliki situs yang responsif atau adaptif, paradigma ini berfungsi dengan baik karena Anda dapat memuat css atau javascript yang berbeda tergantung pada viewport pengguna atau agen pengguna. Namun jika Anda memodifikasi html atau templat, kemungkinan css atau javascript bisa pecah. Kekhawatiran terpisah ini juga bisa tergantung.

Pendekatan lain adalah menggabungkan semua javascript dan html css Anda ke dalam sekelompok komponen atau modul. Ini berarti bahwa Anda dapat membuat perubahan pada satu modul dan itu seharusnya tidak mempengaruhi komponen atau modul lain pada halaman yang berjalan di sampingnya yang tidak terkait. Di sini file css, js dan html digabung menjadi satu komponen yang dapat diuji unit. Jadi pemisahan kekhawatiran datang dalam bentuk komponen atom individu yang dapat diuji unit daripada pemisahan elemen markup, gaya dan perilaku. Pendekatan kedua ini lebih cocok untuk membuat aplikasi web yang lebih kompleks.

sunting. Karena saya telah menerima tanggapan negatif terhadap komentar ini, saya pikir saya akan mengunjungi kembali dan mencoba untuk memenuhi syarat beberapa pov saya. Sayangnya umpan balik apa pun di sini tidak terlalu konstruktif, tetapi saya memang melihat diskusi menarik di tempat lain yang membahas React, teknologi panas saat ini dalam pengembangan web, contoh dunia nyata, dan bertanya apakah itu memecah masalah atau khususnya jika itu memecah salah satu prinsip dari metodologi desain berorientasi objek SOLID Feather.

Perspektif Pengembang JavaScript teknis

NO, because JSX is a view language. That's one responsibility.
BUT, this implies that the JS developer is self-enforcing SoC/SRP on his own      architecture by not mixing ViewModel concerns in his JSX. This type of vigilance "in the wild" is highly suspect because JSX involves the full JavaScript dialect.

Perspektif Desainer UX / UI

YES, because JSX mixes Semantic Content (Model) with Behavior (Controller)
YES, because the intrusion, specifically of JavaScript, into the Semantic Model makes it difficult or impossible for me to play my role and leverage my expertese and skills.

Perspektif Tim

NO, if both...
Separate files are used for the View (JSX) and ViewModel (JS).
Either there aren't UI/UX/Designers involved, or they are productive working    directly with JSX (not very common).
YES, if either...
Everything is in the same file, causing problems for version control or productive use of modern editors.
Members of the team who are comfortable with HTML/CSS but less capable with JavaScript are excluded because of mixture or roles.

https://hashnode.com/post/does-react-really-violate-separation-of-concern-by-putting-html-and-js-in-a-single-fil-cil3bn5hj0011a65347rsdut0

Juga pada halaman tersebut adalah tautan ke presentasi yang menarik dari Pete Hunt, dari Facebook, di mana ia berbicara tentang komponen bukan template, dan memisahkan kekhawatiran dalam aplikasi bahasa daripada memisahkan kekhawatiran kerangka kerja, yaitu template, css dan javascript dll.

Sehubungan dengan memisahkan kekhawatiran Anda dalam bahasa aplikasi Anda, ini dapat melibatkan berbagai pola untuk memisahkan atau memisahkan kode Anda ke dalam bentuk modular yang dapat diuji unit dll.

Jadi untuk meringkas, memisahkan kekhawatiran dapat bergantung pada peran atau sudut pandang Anda, seperti yang disebutkan di tempat lain.