Daha azı daha fazla: ne iyi kod (ve iyi mimari) kırıldı
Belki durumu biliyorsunuz: Başkasının geliştirdiği bir proje açın ve birkaç dakika sonra kendinizi düşüneceksiniz:
“Ama oldukça karmaşık uygulandı!”
Golo Roden, yerel web GmbH'nin kurucusu ve CTO'sudur. Olaylara ve hizmetlere dayalı olarak dağıtılmış mimarilere özellikle dikkat ederek web ve bulut uygulamalarının ve arıların anlayışı ve geliştirilmesi ile ilgilidir. Yol gösterici ilkesi, yazılımın gelişiminin kendi başına bir son olmaması, ancak her zaman aşağıda bir profesyonellik izlemesi gerektiğidir.
Kod ne kadar çok okursa, bu çok gereksiz bir şekilde karmaşık olan duygu o kadar fazla olur. Genellikle pragmatik olarak ve kolayca çözülmüş olabilecek şeyleri maskeleyen soyutlama seviyeleridir. Bu yaklaşımlar kodun anlaşılmasını zorlaştırır – ve bu sadece kod için değil, aynı zamanda bir projenin mimarisi için de geçerlidir. Belki de iyi bir kod yazmak için daha az dikkat çekildiğini, ancak birisinin abartılı bir karmaşıklık konusunda sanatsal olduğunu zaten hissettiniz.
Bugün tam olarak budur: ideal olarak, mimari görünmez olmalıdır. Ama bu tam olarak ne anlama geliyor? Ve bu prensibi kendiniz nasıl kullanabilirsiniz?
İyi mimari görünmez
İyi mimarinin görünmez olduğu ne anlama geldiği sorusuyla başlayalım. Gerçekle karşılaştırma bunu açıklığa kavuşturmaya yardımcı olur. Etkileyici binaları düşünün: Belki de her ayrıntının uyum sağladığı ve tüm kararların sorunsuz bir şekilde aktığı modern bir villa. Ya da mimari olarak büyüleyen Köln Katedrali gibi tarihi bir binaya. En önemli nokta: her iki durumda da binaya bir bütün olarak hayranlar. Arkasında iyi yansıtılmış bir mimari olduğunu biliyorsunuz, ancak bu ortaya çıkmıyor. Aksine, her şey tüm ayrıntıların tasarlandığını hissedebileceğiniz kesin bir genel tablo gibi görünüyor. Bu, iyi mimarinin arka koltuk aldığı ve sürekli dikkatinizi gerektirmediği anlamına gelir.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Yazılım mimarisi kendi içinde bir son değil
Tabii ki, her mimari kararın açıkça görülebildiği bir alternatif de oluşturulabilir. Bu şık görünebilir, ancak büyük bir bina için bir üs olarak kendi başına daha fazla olan ortaya çıkan bir çalışmanın izlenimini verecektir. Ve tam olarak bunu kastettiğim dediğimde: iyi mimari görünmez. Ön plana girmeden yapılar oluşturun.
Mimarlık yazılımın mimarisini karşılıyor
Bu ilke sadece binalar için değil, yazılım için de geçerlidir. Burada da mimari kendi içinde bir son değil. İyi yapılandırılmış, bekleme ve uzun vadeli yazılımların ortaya çıkabileceği sağlam bir taban sağlamalıdır. Bir mimari bu hedeflere çok önemli bir şey yapmadan ulaşırsa, başarılı oldu. Ancak, bu hedefleri kaçırırsanız veya ön planda boşuna koyarsanız, bu kötüdür.
Buraya kadar, her şey oldukça açık görünebilir. Ama o kadar basit olsaydı, o kadar sık projelerle karşılaşmadık ki:
“Nedir? Bu konuda ne düşündü?”
Yıllar geçtikçe, bir model belirgindir: Programlamaya yeni başlayan insanlar, sadece ona yardım edemedikleri için genellikle basit ve pragmatik çözümler geliştirirler. Bununla birlikte, artan bilgi ile geliştiriciler giderek daha fazla sorunu soyutlamaktadır. Bu nihayet oluşturulmada öğretilir: bir dosyanın gönderilmesi “dosya gönderimi” için soyuttur, bu da bir alıcıya bir verici mesajına ve sonunda sadece “mesajlaşma” hakkında konuşuruz. Başlangıçta sadece ve -mail üzerinden bir kelime dosyası göndermek istediler.
Yagni – buna ihtiyacın olmayacak
Sorun genellikle çok erken ve her şeyden önce çok erken. Her soyutlama, kodun anlaşılmasını zorlaştıran başka bir dolaylara yol açar. Geliştiricinin koddaki mevcut düşünce trenini anlayabilmek yerine, önce başka bir seviyeye çevirmeniz gerekir. Bu seviyeler ne kadar çok olursa, kodu anlamak o kadar zordur. Ancak, kod yalnızca bir kez yazılır, ancak birçok kez okuyun. Bu nedenle dikkatin okunması, anlaşılabilirlik ve anlaşılabilirlik, artık mümkün olmayan soyutlamalar olmamalıdır. “İhtiyaç duymayacak” prensibi (Yagni) yazılımın geliştirilmesinde bir leitmotif değildir: basit tutun! Bu ilke kod ve mimari için geçerlidir.
Merkezi bir husus, sorumluluğun açık bir tanımıdır: neyin hangi işlev, sınıf veya hizmet sorumludur? Düşük bağlantı ve yüksek uyum ilkeleri burada yardımcı olur: Bireysel unsurlar mümkün olduğunca bağımsız olarak var olmalıdır, bir göreve ait olan her şey tek bir yerde birleşir. Dolayısıyla, bir hatayı düzeltmeniz gerekiyorsa, değişiklik bir noktada sistemin diğer bölümlerini etkilemeden yeterli olmalıdır.
Uygulamadan bir örnek
Uygulamanın bir örneği şunları göstermektedir: Kodun revizyonunda, bir Go kodu tabanında işe yaramaz bir soyutlamaya rastladım. Geliştirici, bir değerin isteğe bağlı olduğunu ifade etmek için bir işaretçi kullanmak yerine, belki de işlevsel programlamadan bir Tip A konsepti getirmişti. Bununla birlikte, bu tip, ne tutarlı ne de hassas olmayan kodun tek bir yerinde kullanıldı. Basit bir işaretçi aynı amacı elde ederdi ve önemli ölçüde daha anlaşılabilir ve hatalara daha az eğimli olurdu.
Kullanışsız soyutlama sorunu sadece kodda değil, aynı zamanda mimari düzeyde de gerçekleşir. Bazen bir mikro hizmet, gerekli olduğu için değil, mikro hizmet kavramını uygulamak için tanıtılır. Bu, gereksiz karmaşıklıklara yol açar ve yazılımın yapısını ve anlaşılabilirliğini iyileştirmenin gerçek hedefinden yoksundur.
Okunabilirlik yazmayı yener
Uzman geliştiriciler neden bu kadar sık? Sebeplerden biri mükemmellik arzusu, tanınma için bir mücadele. Bu etkinin farkında olmak ve kodunuzu ve mimarinizi yansıtmanız önemlidir. Kod incelemeleri ve çiftlerin programlaması burada yardımcı olabilir, çünkü başkaları için pragmatik yaklaşımları ve anlaşılabilirliği teşvik ederler.
Mimari ve kod, kendi içinde bir amaç değil, bir amaç için araçlardır. Ekibin teknik gereksinimlerine ve ihtiyaçlarına odaklanmalısınız. Çözümler yinelemeli ve pragmatik olarak geliştirilmelidir. Her zaman kendinize sorun: Takım gerçekten bu soyutlamaya ihtiyaç duyuyor mu yoksa gereksiz yere işleri karmaşıklaştırıyor mu?
(RME)