Belirli vakaları çözmek yerine genelleştirilmiş bir çözüm ne zaman tercih edilir?

Programlamada genellikle bir seçim ile karşı karşıyayız: akla gelebilecek her kullanım durumunu ayrı ayrı ele alın veya genel sorunu çözün:

Anlık sorunun çözülmesinin daha hızlı olduğu açıktır, ancak genel bir çözüm oluşturmak gelecekte zaman kazandıracaktır.

Sonlu vaka listesini denemenin ve kapsamayı en iyi şekilde deneymenin veya tüm olasılıkları kapsayacak şekilde genel bir sistem oluşturmanın ne zaman olduğunu nasıl bilebilirim?

İlk olarak, tuzu geçersiniz. Sonra biberi geçiyorsun. Sonra rendelenmiş parmesan peynirini geçersiniz. Bu noktada, genel bir çeşni geçirme sistemi geliştirmeye başlamak için yeterli deneyime sahipsiniz.

Yazılım projelerinde aynı şekilde çalışır: genelleştirilmiş olanlara öğrenme adımlarınız olarak geliştirdiğiniz özel amaçlı sistemleri kullanın, bu nedenle genel amaçlı sisteminize başlama zamanı geldiğinde, ne inşa ettiğinize daha fazla güvenirsiniz, çünkü kemerinizin altında birkaç özel amaçlı sisteminiz var.

Sonlu vaka listesini denemenin ve kapsamayı en iyi şekilde deneymenin veya tüm olasılıkları kapsayacak şekilde genel bir sistem oluşturmanın ne zaman olduğunu nasıl bilebilirim?

Deneyim.

Bilmenin tek yolu daha önce bir yol denemek, seni kıçından nasıl ısırdığını görmek (ya da bir sürü zaman harcadın). Kıçından daha az bitene kadar tekrarlayın.

O zaman bile, gerçekten bilmiyorsunuz ; sadece daha iyi bir tahmininiz var.

Dasblinkenlight ve Paddy3118'in cevaplarını geliştirmek için, uygulamak için birden fazla vakanız yoksa, genellemeniz gerekmez! XKCD karikatürünün komik olmasının nedeni, erken genelleştirmeyi ortaya koymasıdır . Tuzu geçmesi istendiğinde, görünmeyen karakter hemen ilk istenen tuz olduğu zaman "keyfi çeşnileri geçmek için bir sistem geliştirmeye" atlar. Bu, geliştiriciler için iyi bir şaka, çünkü hepimizin erken genelleme vakalarını gördüğümüzü düşünüyorum.

Erken genellemenin aksine prensip YAGNI'dır (Buna İhtiyacınız Yoktur). Web üzerinde bu konuda birçok malzeme vardır, ancak temel olarak YAGNI, birden fazla kullanım vakasının gerçekte görünmeme olasılığı da dahil olmak üzere, mevcut birkaç gerçek kullanım durumunun faydası olmadan genellemede bir takım risklere işaret etmektedir. Ya da daha açık bir ifadeyle, fiili kullanım durumlarının olmaması, kişinin gelecekte neyin gerekli olduğuna dair varsayımlar yapmasını gerektirir. Bu varsayımlar yanlış olabilir ve çoğu zaman yanlış olabilir.

Küçüklerde genel olmak daha kolay görünüyor, yani herhangi bir çift türü işleyen makul bir sözlük sınıfı oluşturabildiğinizde tam sayıları dizelerle eşleyen bir arama tablosunu işlemek için bir sınıf yapmayın (ilk tür bir karşılaştırma).

Önceki bir yaşamda, sürekli malzeme ağını işleyen makineler için birçok endüstriyel otomasyon projesi yaptım. Çelik, alüminyum, kağıt, plastik, .... Ortada yararlı bir şey yaptıktan sonra bir ucundan çözer ve diğer tarafa tekrar yuvarlarsınız. Bir endüstride, "çözülme" değil, "ödeme makarası" nda başlarsınız. Yanlış terminoloji kullanırsanız, müşterinin multi-milyon dolarlık gözünde aptalsınız demektir. Bir projeden diğerine yeniden kullanım için ne kadar az soyutlanabileceğine şaşıracaksınız . OTOH, genellikle bir başlangıç ​​noktası olarak bir çerçeve veya şablon oluşturabilir. Eldeki iş için özelleştirilebilir, ancak en azından önceki projelerden öğrenme avantajına sahipti. Takımdaki herkes nereden başladığımızı biliyordu.

Bir kez yapın, iki kez yapın, üç kez yapın, genelleştirin.

Bir, iki, çok!

İkinci durumda genelleme üzerine düşünmelisiniz. Üçüncüsü sorulduğunda, genelleştirilmiş koddan sağlamalısınız ve daha önce ayrı ayrı çözülmüş olan birinci ve ikinci vakayı test senaryoları olarak kullanmalısınız.