Son zamanlarda , özellik kavşakları hakkındaki bu makalede açıklananlara benzer daha fazla soruna tanık oldum . Bunun için başka bir terim ürün grupları olacaktır, ancak bunları gerçekten farklı ürünlere atfetme eğilimindeyken, genellikle bu sorunlarla olası ürün yapılandırmaları şeklinde karşılaşıyorum.
Bu tür bir sorunun temel fikri basittir: Bir ürüne bir özellik eklersiniz, ancak mevcut diğer özelliklerin bir kombinasyonu nedeniyle işler bir şekilde karmaşıklaşır. Sonunda, KG, daha önce kimsenin düşünmediği nadir bir özellik kombinasyonu ile bir sorun bulur ve basit bir hata düzeltmesinin ne olması gerektiği bile büyük tasarım değişiklikleri gerektirebilir.
Bu özellik kavşak sorununun boyutları akıl almaz bir karmaşıklığa sahiptir. Mevcut yazılım sürümünün Nözelliklere sahip olduğunu ve yeni bir özellik eklediğinizi varsayalım . Ayrıca, özelliklerin her birinin yalnızca açılıp kapanabileceğini söyleyerek işleri basitleştirelim, o zaman 2^(N+1)dikkate almanız gereken özellik kombinasyonlarına zaten sahipsiniz . Daha iyi ifade / arama terimleri eksikliğinden dolayı, bu kombinasyonların varlığını özellik kavşak sorunu olarak adlandırıyorum . (Daha yerleşik bir terim için referans (lar) dahil bir cevap için bonus puanlar.)
Şimdi mücadele ettiğim soru, geliştirme sürecinin her seviyesinde bu karmaşıklık sorunuyla nasıl başa çıkılacağı. Açıkça görülen maliyet nedenlerinden ötürü, her kombinasyonu ayrı ayrı ele almak istemek, ütopya olma noktasına kadar pratik değildir. Sonuçta, iyi bir nedenden dolayı üstel karmaşıklık algoritmalarından uzak durmaya çalışıyoruz, ancak çok geliştirme sürecinin kendisini katlanarak boyutlandırılmış bir canavara dönüştürmek tamamen başarısızlığa yol açacak.
Öyleyse, herhangi bir bütçeyi patlatmayan ve iyi, yararlı ve profesyonel olarak kabul edilebilir bir şekilde tamamlanan sistematik bir şekilde en iyi sonucu nasıl elde edersiniz?
Özellikler: Yeni bir özellik belirttiğinizde - diğer tüm çocuklarla iyi oynatılmasını nasıl sağlarsınız?
Birinin mevcut her bir özelliği yeni özellikle birlikte sistematik olarak inceleyebildiğini görebiliyorum - ancak bu diğer özelliklerin izolasyonunda olacaktı. Bazı özelliklerin karmaşık doğası göz önüne alındığında, bu izole görüş çoğu zaman zaten o kadar dahil olur ki,
2^(N-1)isteyerek göz ardı edilen diğer özelliklerin neden olduğu faktör hariç , kendi içinde yapılandırılmış bir yaklaşıma ihtiyaç duyar .Uygulama: Bir özellik uyguladığınızda - kodunuzun her durumda düzgün bir şekilde etkileşmesini / kesişmesini nasıl sağlarsınız?
Yine, karmaşıklığı merak ediyorum. Kesişen iki özelliğin hata potansiyelini azaltmak için çeşitli teknikler biliyorum, ancak hiçbiri makul bir şekilde ölçeklenemez. Bununla birlikte, şartname sırasında iyi bir stratejinin, uygulama sırasında problemi uzak tutması gerektiğini varsayıyorum.
Doğrulama: Bir özelliği test ettiğinizde - bu özellik kavşak alanının yalnızca bir kısmını test edebileceğiniz gerçeğiyle nasıl başa çıkıyorsunuz?
Tek bir özelliği tek başına test etmenin, hatasız kod yakınında hiçbir yerde hiçbir şeyi garanti etmediğini bilmek yeterince zordur, ancak bunu bir kısmına
2^-Nindirdiğinizde yüzlerce test, tüm okyanuslarda tek bir damla suyu bile kaplamıyor gibi görünüyor. . Daha da kötüsü, en sorunlu hatalar, herhangi bir soruna yol açmayı beklemeyebilecek özelliklerin kesişiminden kaynaklanan hatalardır - ancak bu kadar güçlü bir kavşak beklemiyorsanız bunları nasıl test edersiniz?
Başkalarının bu sorunla nasıl başa çıktıklarını duymak isterim, ancak öncelikle konuyu daha derinlemesine inceleyen literatür veya makalelerle ilgileniyorum. Dolayısıyla, belirli bir stratejiyi kişisel olarak takip ederseniz, yanıtınıza karşılık gelen kaynakları dahil etmek iyi olur.