Kaygıların Başkalarına Ayrılmasını Nasıl Açıklarsınız?

Endişelerin Ayrılmasının faydalarını anlamayan veya günlük işlerinde tutarlı bir şekilde uygulamak için yeterince yeterince anlamadığınız bir meslektaşınız varsa, bunu onlara nasıl açıklarsınız?

Serbest bırakılmış bir programınız olduğunu hayal edin. Bir müşteri gelir ve özelliklerinden birinde bir geliştirme için ödeme yapmayı teklif eder. Para almak için, yeni özellik eklemek için programınızı değiştirmeniz gerekecektir. Kar marjınızın ne olduğunu etkileyecek şeylerden bazıları şunlardır:

1. ne kadar kodunu değiştirmek zorundasın
2. değişiklikleri yapmak ne kadar kolay
3. diğer müşteriler tarafından kullanılan mevcut özellikleri bozma olasılığınız ne kadar
4. Mevcut modeli / mimariyi ne kadar tekrar kullanabilirsiniz

Kaygıların ayrılması, bu sorulara daha olumlu cevaplar almanıza yardımcı olur.

1. Uygulamanın belirli bir davranışına ilişkin kodun tümü ayrılırsa, yalnızca yeni özelliğinizle doğrudan ilişkili kodu değiştirmeniz gerekecektir. Değiştirmek için daha az kod olması gerekir.
2. İlgilendiğiniz davranışlar, uygulamanın geri kalanından tamamen ayrıysa, programın geri kalanını tamamen anlamak veya değiştirmek zorunda kalmadan yeni bir uygulamada takas etme olasılığınız daha yüksektir. Hangi kodu değiştirmeniz gerektiğini bulmak da kolay olmalı.
3. Değiştirmek zorunda olmadığınız kodun, değiştirdiğiniz koddan daha az kırılması olasıdır. Bu nedenle endişeleri bölmek, arayabilecekleri kodları değiştirmenizi engelleyerek ilgisiz özelliklerde kırılmayı önlemenize yardımcı olur. Eğer özellikleriniz birbirine karışmışsa, bir başkasını değiştirmeye çalışırken birinin davranışını yanlışlıkla değiştirebilirsiniz.
4. Eğer mimariniz teknik veya ticari mantık detaylarına aşikarsa, uygulamada yapılan değişikliklerin yeni mimari özellikler gerektirme olasılığı daha düşüktür. Örneğin, ana etki alanı mantığınız veritabanı agnostik ise, yeni bir veritabanını desteklemek, kalıcılık katmanının yeni bir uygulamasında takas etmek kadar kolay olmalıdır.

Bir hastaneye bakın ve bir hastaya bakım sağlamada rol oynayan tüm farklı rolleri düşünün: triyaj hemşireleri, doktorlar, sağlık görevlileri, teknisyenler, büro personeli, kafeterya vb.

Tüm bu insanların işlerini nasıl yaptığını bilen bir kişi var mı ? Hayır, çünkü çok zor olurdu. Farklı sorumlulukları farklı rollere ayırmak zorundadırlar ve bu roller arasındaki temas noktaları çok spesifiktir.

Bir ofiste çalışıyorsa, bir örnek olarak ele alın, o personeldeki her personelin rolünü açıklayın ve bu personel işlerine göre ayrılmazsa ne olacağını sorun.

SoC'yi kodunda / tasarımında nasıl uygulayamadığına bakar ve bunu ilişki kurabileceği ve açıkça istenmeyen bir gerçek dünya örneğine dönüştürürdüm.

Örneğin, müşterinin bu müşterilerle alakalı olmayan birkaç bilgi vermesi gereken bir sınıfa sahipse, o zaman satın almak istiyorsanız kendi tahıllarınızı ve mayalarınızı getirmeniz gereken bir fırın analojisini kullanırdım. bir ekmek.

Bir örnek, bir html geliştiricisi, html, css ve javascript'i ayrı dosyalara ayırmak isteyebilir. Bu şekilde, ayrı olarak yüklenen javascript dosyasını değiştirerek css veya bir şeyin davranışını değiştirerek söylenen bir şeyin görünümünü ve hissini değiştirebilirsiniz. Yanıt veren veya uyarlanabilir bir siteniz varsa, bu paradigma, bir kullanıcının görünümüne veya kullanıcı aracısına bağlı olarak farklı css veya javascript yükleyebildiğiniz için çalışır. Bununla birlikte, html veya şablonunu değiştirirseniz, css veya javascript öğesinin bozulma olasılığı vardır. Bu ayrı endişeler de bağımlı olabilir.

Diğer bir yaklaşım da, tüm css javascript ve html'nizi bir bileşen veya modül grubuna toplamaktır. Bu, bir modülde değişiklikler yapabileceğiniz anlamına gelir ve sayfa boyunca çalıştığı taraftaki diğer bileşenleri veya modülleri etkilememelidir. Burada css, js ve html dosyaları ünite testinden geçirilebilen tek bir bileşen halinde birleştirilir. Bu nedenle, kaygıların ayrılması, işaretleme, stil ve davranışsal öğelerin ayrılmasından ziyade birim test edilebilen ayrı atomik bileşenler şeklinde gelir. Bu ikinci yaklaşım daha karmaşık web uygulamaları oluşturmak için daha uygundur.

Düzenle. Bu yoruma olumsuz cevap aldığım için, tekrar ziyaret edip pov'umun bir kısmını nitelendirmeye çalışacağımı düşündüm. Maalesef buradaki herhangi bir geri bildirim özellikle yapıcı değil, başka bir yerde React'e, web geliştirmedeki güncel sıcak teknolojiye, gerçek bir dünya örneğine bakan ve endişelerin ayrılmasını engelleyip engellemediğini veya özellikle de bunlardan birini ihlal edip etmediğini soran ilginç bir tartışma gördüm. Feather'ın SOLID nesne yönelimli tasarım metodolojisinin prensibi.

Teknik JavaScript Geliştirici Perspektifi

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.

UX / UI Tasarımcısı Perspektifi

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.

Takım Perspektifi

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-file-cil3bn5hj0011a65347rsdut0

Sayfada ayrıca, şablonlardan değil bileşenlerden bahsettiği Pete Hunt, Facebook'tan ilginç bir sunum ve çerçevedeki kaygıları ayırmak yerine dil uygulamasındaki kaygıları ayırma, yani şablonlar, css ve javascript vb.

Endişelerinizi başvurunuzun dili ile ayırmakla ilgili olarak, bu, kodunuzu ayırmak veya ünite testine tabi tutulabilecek modüler bir forma ayırmak için çeşitli desenler kullanmayı içerebilir.

Bu yüzden, özetlemek gerekirse, endişeleri ayırmak, başka yerlerde de belirtildiği gibi rolünüze veya bakış açınıza bağlı olabilir.