Gerçek bir KISS çözümü ne kadar basittir? [kapalı]

İtiraf ediyorum : Çoğu zaman "Basit ve Kısa Tutmak" için bir sorunum var, çünkü okuduğum kitaplara, duyduğum tasarım modellerine vb. Göre yapmaya çalışıyorum. bunun olası bir mükemmellik için doğru yolda olduğum duygusu.

Öte yandan, evet, bazen son teslim tarihlerini iletme konusunda bana fazladan stres atıyor ...

Ama ne zaman kendi kendime, "Bir dahaki sefere basit olsun, aptal!" Bir dahaki sefere geldiğinde bunu "basit" hale getirmeyi çok zor buluyorum, çünkü garip hissetmeye başlıyor ... ve bir noktadan sonra rahatsız edici.

Sonra 'basit' anlayışımı yargılamaya başlıyorum ...

SIMPLE çalışmak için çok kısa, ancak bakımı ve genişletilmesi zor mu demek?

BASİT OOP ilkelerinin çoğunu kırmak mı demek?

BASİT hile demek mi?

SIMPLE, son teslim tarihlerini sağırsız tutmak anlamına mı geliyor? vb.

Aslında, nedir bu?

Soru : KISS prensibi açısından BASİT'in kesin tanımını yazabilir misiniz? -varsa.

Teşekkürler!

Bir Fransız KISS öğrenelim:

La perfection est atteinte, pas olmayan lorsqu'il n'y bir artı rien à ajouter, mais lorsqu'il n'y artı bir rien à emekli. - Antoine de Saint-Exupéry

Bu dilin çevirisi:

Eklenecek başka bir şey olmadığında değil, götürülecek hiçbir şey kalmadığında mükemmellik elde edilir. - Antoine de Saint-Exupéry

senaryo

Kesmeniz ve çimdiklemeniz gerekiyor.

Çözüm A: KISS değil

Çözüm B: ÖPÜCÜK

Bir gelince tam tanımı: Bu basitlik ölçmek için mutlak bir ölçek tanımlamak zor. Çoğunlukla gerçek sadelik, eldeki sorunun gerçek bir şekilde anlaşılmasını engeller ve bu nadiren elde edilebilir. Ancak diyelim ki A ve B çözeltisi, sırasıyla aşırı komplikasyon ve basitliğe yönelen çözeltiler arasındaki farkı göstermektedir.

"İşleri olabildiğince basitleştirin, ama basitleştirin" -Einstein

Kodu olabildiğince basit, ancak daha basit tutmak, çözülmekte olan soruna bağlıdır. Çözülen problem değiştiği sürece KISS de değişmektedir.

Aşırı mühendislik (oh adam bu Tasarım Deseni becerilerimi göstermek için harika bir yer gibi görünüyor!) Ve mühendislik (sadece bir fabrika kullansaydım 20 kod değişiklikleri ...). Amaç sürdürülebilirlik.

Basit, iyi programlama ilkelerini kırmak anlamına gelmez. Aslında, bunun tam tersi anlamına gelir.

SIMPLE çalışmak için çok kısa, ancak bakımı ve genişletilmesi zor mu demek?

Hayır. Korunması ve uzatılması zor olmak karmaşıklığın büyük bir belirtisidir. Aslında, kodun genişletilebilir hale getirilmesinin daha basit kodlara yol açtığını görüyorum, çünkü her bir durumla başa çıkmadığınız için temel kodu daha basit tutabilirsiniz.

BASİT OOP ilkelerinin çoğunu kırmak mı demek?

Hayır. Çoğu OOP ilkesi, kodu daha temiz ve daha düzenli tutmak için tasarlanmıştır; sonuçta daha basittir.

BASİT hile demek mi?

Hayır. Kodları ve hack'leri son teslim tarihlerini koruma kisvesi altında tutmak zor.

SIMPLE, son teslim tarihlerini sağırsız tutmak anlamına mı geliyor? vb.

Hayır. Son teslim tarihleri ​​ve kodunuzun sadeliği iki ayrı konudur. Basit kod yazmanın yazılması daha uzun sürmez (yaygın bir yanlış anlama olmasına rağmen).

Bunu açıklamak çok zordur çünkü basit herkes için aynı anlama gelmez.

Misal. Bazı geliştiriciler bunun ?:basit olduğunu düşünüyor, bazıları ise bir ififadenin daha iyi olduğunu düşünüyor . Bu seviyeye düştüğünde, herkesi memnun edemezsiniz.

Genel olarak, basit karmaşıklık olmadan anlamına gelir . Basitliği anlamak için karmaşıklığı anlamamız gerekir.

İki tür karmaşıklık vardır:

Temel karmaşıklık , bir soruna tüm makul çözümlerin karmaşık (ve muhtemelen kafa karıştırıcı) olması gerektiği bir durumu ifade eder, çünkü "basit" çözümler sorunu yeterince çözmez. - Wikipedia

Kazara oluşan karmaşıklık , bilgisayar programlarında veya bunların çözülmesi gereken sorun için gerekli olmayan geliştirme süreçlerinde (bilgisayar programlama) ortaya çıkan karmaşıklıktır. - Wikipedia

Temel karmaşıklığı aşağıdaki sorularla kontrol edebilirsiniz:

Bu çözüm basit mi? Birkaç dakika içinde akranıma açıklayabilir miyim? Sorunun daha basit bir çözümü var mı? Evet ise, karmaşık çözüm ile basit çözüm arasında herhangi bir ödünleşim var mı? Bu ödünleşmelerle yaşayabilir miyiz? Örneğin, birçok programcı her şeyi optimize etmek için mikro hata yapar ve çözümlerini (ve kodunu) aşırı derecede karmaşık hale getirir.

Yanlışlıkla karmaşıklığınızı kontrol etme:

Kod basit mi? Üç ay içinde geri gelirsem, yapmam gereken değişikliği yapabilmem için beynimdeki bağlamı oluşturmam ne kadar sürer? Kaynak kodumdaki her şeyin açık bir amacı var mı ve bu amacı bana ve diğer geliştiricilere etkili bir şekilde aktarıyor mu? Kodumu test etmek ne kadar zor? Genellikle kodunuz ne kadar karmaşıksa, birim testi o kadar zor olur, bu yüzden bunu genellikle karmaşıklığın bir ölçüsü olarak kullanırım. Genellikle küçük, iyi adlandırılmış ve odaklanmış sınıflar ve yöntemler istersiniz. Tasarım modelleri genellikle bunları başarmanıza da yardımcı olur.

Kendinizi sadece okuduğunuz için bir tasarım deseni kullanmak isteyen bulursanız, muhtemelen yanlışlıkla karmaşıklık getirecektir. Kendinizi 'akıllı olduğunu' düşündüğünüz için bir şey koymak istediğinizi bulursanız, muhtemelen yanlışlıkla karmaşıklık getirecektir.

Umarım bu yardımcı olur ve unutma: Basit, KOLAY anlamına gelmez .

Her zaman X11'in ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) arkasındaki ilkelerin heeding değerinde olduğunu hissettim . Her zaman bu hedefe ulaşamıyorum.

Özellikle, kendime hatırlatmaya devam ediyorum ... "Gerektirecek gerçek bir uygulama bilmiyorsanız yeni işlevsellik eklemeyin." Ve "İşin yüzde 10'u için istenen efektin yüzde 90'ını alabiliyorsanız, daha basit bir çözüm kullanın. "

Soru: KISS prensibi açısından BASİT'in kesin tanımını yazabilir misiniz? -varsa.

Hayır.

Basit - bu özel bağlamda kompleksin tam tersidir. Basit gerekli değildir: Her aptal fikirli kişi bunu anlamak zorundadır - ama kendiniz yazmamış olsanız bile, anlayabildiğinizden emin olmalısınız.

Karmaşıklık, referansları anlamak zor olabilir - onlardan kurtulun! Birçok dosya / sınıf birbirine bağlı - hiçbir şekilde! Ve karmaşık kod (yani: zincirleme döngüler, çoklu ITE katmanları, vb.) - kimse bunu okumak istemiyor.

Bence: Başka bir işlev eklemek çok kolaydır, sınıflarda özel işlevler de ekleyebilirsiniz, böylece arayüzle uğraşmazsınız. Öyleyse neden bu avantajı kullanmıyorsunuz ve işlevlerinizi / prosedürlerinizi 50 satıra sınırlamıyorsunuz. Belki daha da az. Bazı anlamlı isimler edinin. Bu şekilde çoğu yorumu eski haline getirmiş olursunuz. Bu şekilde işlevlerinizin okunması, değiştirilmesi / genişletilmesi kolaydır.

Tabii ki ... son birkaç cümle şu şekilde çalışırdı: Sınıflarda özel işlevleri tanımlamak için kullanılabilirlik var, sadece işlevleri 50 astara bölmek için kullanın, böylece çok daha okunabilir olacak (iyi isimleri unutmayın, bu yüzden çok fazla yorum yapmanız gerekmez).

AMA: Şunu gösteren bir fullstop varsa her şeyi okumak çok daha basittir (!): Bir düşünceyi bitirdim, bir sonrakine geçelim.

Bu basit olarak tanımlamak istiyorum.