it-swarm-tr.com

Endişelerin Başkalarına Ayrılmasını Nasıl Açıklıyorsunuz?

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

37
Marcie

Yayımlanmış bir programınız olduğunu düşünün. Bir müşteri gelir ve özelliklerinden birinde bir geliştirme için ödeme yapmayı teklif eder. Parayı elde etmek için, yeni özelliği eklemek için programınızı değiştirmeniz gerekecektir. Kâr marjınızı etkileyecek şeylerden bazıları şunlardır:

  1. ne kadar kodu 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
  4. mevcut modeli/mimariyi ne kadar yeniden kullanabilirsiniz

Endişelerin ayrılması, bu sorulara daha olumlu cevaplar almanıza yardımcı olur.

  1. uygulamanın belirli bir davranışı için tüm kod ayrılırsa, yalnızca yeni özelliğinizle doğrudan ilişkili kodu değiştirmeniz gerekir. Hangi değiştirmek için daha az kod olmalıdır.
  2. i̇lgilendiğiniz davranışlar uygulamanın geri kalanından düzgün bir şekilde ayrılırsa, programın geri kalanını tam olarak anlamak veya değiştirmek zorunda kalmadan yeni bir uygulamada takas edebilmeniz daha olasıdır. Hangi kodu değiştirmeniz gerektiğini bulmak daha kolay olmalıdır.
  3. Değiştirmeniz gerekmeyen kodun kırılma olasılığı, değiştirdiğiniz koddan daha azdır. Bu nedenle, endişeleri bölmek, arayabilecekleri kodu değiştirmek zorunda kalmanızı önleyerek ilgisiz özelliklerde kırılmayı önlemenize yardımcı olur. Özellikleriniz birbirine karışırsa, bir başkasını değiştirmeye çalışırken birinin davranışını yanlışlıkla değiştirebilirsiniz.
  4. Mimariniz teknik veya iş mantığı detaylarına karşı agnostik ise, uygulamadaki 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.
53
flamingpenguin

Bir hastaneye bakın ve bir hastaya bakım sağlamada yer alan tüm farklı rolleri düşünün: triyaj hemşireleri, doktorlar, tıbbi asistanlar, teknikler, büro personeli, kafeterya vb.

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

10
RationalGeek

Bir ofiste çalışıyorsa, örnek olarak alın, o ofisdeki her personelin rolünü açıklayın ve ona, bu personelin işlerine göre bölünmemiş olması durumunda ne olacağını sorun.

5

Kodunda/tasarımında SoC'yi nasıl uygulayamayacağına ve onunla ilişki kurabileceği ve açıkça istenmeyen bir gerçek dünya örneğine dönüştüğüne bakardım.

Örneğin, müşterinin bu müşterilerle ilgili olmayan birkaç bilgi sağlaması gereken bir sınıfı varsa, o zaman satın almak istiyorsanız kendi tahıllarınızı ve mayalarınızı getirmeniz gereken bir fırının benzetmesini kullanırdım. bir ekmek.