OOP'un aşırı komplikasyonu için bir terim var mı?

Bir veya iki yıl önce, OOP (Java) hakkında, iki veya üç satırlık koddan oluşan basit bir beton kaydedicinin ilerlemesini ve temelde oh, yapmam gerektiğini söyleyen deneyimsiz geliştirici tarafından teorik aşırı düşünce süreçlerini gösteren mükemmel bir makale gördüm bunu istememiz durumunda ekleyin! Makalenin sonunda bu basit kaydedici, orijinal geliştiricinin kendini neredeyse anlayamadığı dev bir çöp karmaşasıydı ...

Bu tip aşırı komplikasyon için ortak bir terim var mı? Bu makale (tekrar bulabildiğimi dilerim) yalıtılmış bir vaka için kavramı harika bir şekilde gösteriyor, ancak geliştiricilerin esasen desenlerin, çerçevelerin, kütüphanelerin ve kütüphanelerin aşırı kullanımı ile kendilerini bir düğüme programladıkları tüm projelere rastladım. diğer sorunlar. Kendi yöntemiyle, bu, değiştirme için devraldığımız eski VB6 spagetti uygulamalarından daha kötü (veya daha kötü).

Gerçekten aradığım şey, görüşme yaparken bunu gündeme getirmek. Birisinin mimari / ön planlama eksikliği (ve yerinde doğru dengeye sahip olup olmadıkları için düşme) ile bunun ne kadar kolay olduğunun farkında ve bilinçli olup olmadığını bilmek istiyorum, ama gerçekten bir şey değil Hakkında çok fazla bilgi bulabilirim.

Bu tür tasarımları tanımladığım en sık kullanılan terim aşırı mühendisliktir . Orijinal anlamı o kelimenin Ancak yazılım geliştirme ile ilgili değildir ve yazılım geliştirme dışında o kadar kötü bir sesi muhtemelen vardır değil.

Daha genel bir düzeyde, Joel Spolsky mimari tasarımları çok karmaşık hale getiren tasarımcılara " mimari astronotlar " adını verdi .

Ancak, özellikle bir röportaj için, tam tersine ne denildiğini bilmek, sadece gerçekten gerekli olan bir tasarıma koymak ve sağlıksız "her ihtimale karşı" yaklaşımını unutmak için daha önemli olduğunu düşünüyorum - buna YAGNI prensibi denir .

Evet, aşırı mühendislik bunu açıklamak için en basit terimdir. Yıllar boyunca hatırlayabildiğimden, aşırı mühendislik gerektiren, gereksiz yere karmaşık tasarımlar gördüm. Yıllar önce bir Microsoft GWBasic kursu alırken, eğitmen tekrar tekrar KISS yöntemini çekiçledi (Basit Aptal Tutun). Bu bugün olduğu gibi doğrudur.

Bu yüzden her zaman KISS'i hatırlıyorum ve daima SOLID Prensipleri göz önünde bulundurularak tasarlıyorum . Ancak bununla birlikte, SOLID ilkeleri tamamen göz önünde bulundurularak bir tasarımı yenilemek hala mümkündür. Sağduyu ve genel olarak kabul edilebilir OOP yönergelerine uyma arzusu ile sağduyu, pragmatik bir yaklaşımı dengelemelisiniz. Yeterli zaman verilirse ve karmaşık çözümler oluşturmayı seviyorsanız, bir kaykay için bir motor tasarlama yolunu bitirebilirsiniz, çünkü sonunda bir arabaya dönüşeceğini düşündünüz. Neyse ki, bunu yıllar boyunca yapamayacak kadar disiplinli oldum, ama birçok kez gördüm.

Özetlemek gerekirse, kodun aşırı karmaşıklığını önlemek için:

1) ÖPÜCÜK (Basit Aptal Tutmak)

2) Pratikliği göz önünde bulundurarak SOLID ilkelerini takip edin.

3) Her olasılık için tasarım yapmaya çalışmayın. Ve bazen küçük, sızdıran soyutlamalar , yalıtılmış, kasıtlı ve onları önleme çabası, onları tutmanın etkilerinden çok daha ağır basarsa korkunç şeyler değildir.

4) Çözümleri tasarlarken uygulamayı düşünün. Sadece "oh, bu bir uygulama detayı" diyemezsiniz ve tasarımınızın pratik olduğunu varsayabilirsiniz. Bunu sık sık yapan bir mimarla çalışıyordum ve ne yazık ki, tasarımları hiç işe yaramadı ve sonuç olarak artık orada çalışmıyorum.

5) Bunu koruyacakmış gibi kodlayın.

Yani, bu röportajı yapacaksınız ve adayı yazılım mühendisliği hakkında bildiklerini göstermesi için kandırmayı planlıyorsunuz ve sonra "Hayır, muhtemelen ilk ödevinizde bildiklerinizi uygulamak istiyorsunuz, şimdi devam edin , size iş değeri olmayan yaratıcı mühendislik altın kaplama! Shoo! "

Somut bir örnek sunmak ve bazı kalıpları uygulamak için profesyonelleri ve eksileri tartışmak daha güvenli olacaktır. "Bu duruma bağlı, hızlı mı istiyorsun? Hepsi bu kadar mı? Sorun ne kadar karmaşık? Halihazırda hangi kalıplar var?" ve kendiniz bir şeyler öğrenebilirsiniz. Bu aynı zamanda adayın bağlam duygusunu kanıtlamasına izin verirken daha açık bir soru olurdu. Belirli bir cevabı beklemek ve istemek, en iyi şekilde sizinkiyle en büyük endişeye sahip birini almanızı sağlayacaktır. Cevabınızı almazsanız, aday sadece beyinsiz olarak kabul edilir.