Daha azı daha fazladır: iyi kodu (ve iyi mimariyi) bozan şey.
Belki durumu biliyorsunuzdur: Başka birinin geliştirdiği bir projeyi açıyorsunuz ve birkaç dakika sonra kendi kendinize düşünüyorsunuz:
Duyuru
“Fakat uygulanması oldukça karmaşık!”
Golo Roden, native web GmbH'nin kurucusu ve CTO'sudur. Etkinlik ve hizmet odaklı dağıtılmış mimarilere odaklanarak web ve bulut uygulamaları ile API'lerin tasarımı ve geliştirilmesiyle ilgilenmektedir. Yol gösterici ilkesi, yazılım geliştirmenin kendi başına bir amaç olmadığı, her zaman temeldeki profesyonelliği takip etmesi gerektiğidir.
Ne kadar çok kod okursanız, çoğunun gereksiz derecede karmaşık olduğunu hissedersiniz. Aslında pragmatik ve kolay bir şekilde çözülebilecek şeyleri gizleyen şey genellikle soyutlama düzeyleridir. Bu tür yaklaşımlar kodun anlaşılmasını zorlaştırıyor ve bu sadece kod için değil proje mimarisi için de geçerli. Belki siz de birisinin iyi kod yazmaya dikkat etmek yerine çok fazla karmaşıklık yaratmaya çalıştığı hissine kapılmışsınızdır.
Bugünlerde konsept tam olarak şu: Mimarlık ideal olarak görünmez olmalıdır. Peki bu tam olarak ne anlama geliyor? Peki bu prensibi kendiniz için nasıl kullanabilirsiniz?
İyi mimari görünmez
İyi mimarinin görünmez olmasının ne anlama geldiği sorusuyla başlayalım. Gerçekle karşılaştırma bu noktayı açıklığa kavuşturmaya yardımcı olur. Etkileyici binaları düşünün: Belki her detayın uyum sağladığı ve tüm kararların sorunsuz bir şekilde aktığı modern bir villa. Ya da mimari açıdan da büyüleyici olan Köln Katedrali gibi tarihi bir bina. Önemli olan nokta şu; her iki durumda da binaya bir bütün olarak hayranlık duyuyorsunuz. Arkasında iyi düşünülmüş bir mimarinin olduğunu biliyorsunuz ama bu size çok açık gelmiyor. Aksine, her şey, tüm detayların düşünüldüğünü hissettiğiniz tutarlı bir genel resim gibi görünüyor. Bu, iyi mimarinin arka planda kaldığı ve sürekli dikkatinizi gerektirmediği anlamına gelir.
Önerilen editoryal içerik
İzniniz doğrultusunda harici bir YouTube videosu (Google Ireland Limited) buraya yüklenecektir.
Her zaman YouTube videolarını yükle
YouTube videosunu şimdi indirin
Yazılım mimarisi başlı başına bir amaç değildir
Doğal olarak her mimari tercihin açıkça görülebildiği bir bina yaratmak da bir alternatif olabilir. Şık görünebilir ancak büyük bir binanın temelinden ziyade başlı başına bir amaç olan aşırı iddialı bir çalışma izlenimi verebilir. İyi mimari görünmezdir derken kastettiğim de tam olarak bu. Kendinizi ön plana çıkarmadan yapılar oluşturun.
Mimari yazılım mimarisiyle buluşuyor
Bu prensip sadece binalar için değil aynı zamanda yazılımlar için de geçerlidir. Burada da mimarlık başlı başına bir amaç değildir. İyi yapılandırılmış, bakımı yapılabilir ve uzun vadede kullanılabilir bir yazılım oluşturmak için sağlam bir temel sağlamalıdır. Bir mimari kendisini fazla ciddiye almadan bu hedeflere ulaşıyorsa bu bir başarıdır. Öte yandan, eğer bu hedeflere ulaşamaz ya da bunlara gereksiz vurgu yaparsa bu kötüdür.
Bu noktaya kadar her şey muhtemelen oldukça açık görünüyor. Ancak bu kadar kolay olsaydı, bizi düşündüren projelere bu kadar sık rastlamazdık:
“Bu nedir? Birisi ne düşünüyordu?”
Yıllar geçtikçe bir model ortaya çıkıyor: Kodlamaya yeni başlayan insanlar, sırf bunu başka türlü yapamadıkları için genellikle basit, pragmatik çözümler geliştirirler. Ancak geliştiricilerin bilgileri arttıkça problemleri soyutlama eğilimi daha da artıyor. Bu bize eğitimde öğretiliyor: Bir Word dosyası göndermek, “dosya gönderme”ye indirgenir, bu da gönderenden alıcıya bir mesaj haline gelir – ve sonunda özette sadece “mesajlaşma”dan bahsederiz. Başlangıçta sadece bir Word dosyasını e-postayla göndermek istiyordunuz.
YAGNI – Buna ihtiyacın olmayacak
Sorun genellikle aşırıdır ve her şeyden önce çok erken soyutlamadır. Her soyutlama ek dolaylılık getirerek kodun anlaşılmasını zorlaştırır. Geliştiricinin koddaki gerçek düşünce sürecini anlamak yerine, öncelikle onu zihinsel olarak başka bir düzeye çevirmeniz gerekir. Ne kadar çok katman varsa kodu anlamak o kadar zorlaşır. Ancak kod yalnızca bir kez yazılır ancak birçok kez okunur. Bu nedenle odak noktası mümkün olduğu kadar çok soyutlama değil, okunabilirlik, anlaşılırlık ve anlaşılırlık olmalıdır. “İhtiyacınız Olmayacaktır” (YAGNI) prensibi, yazılım geliştirmede yol gösterici bir prensiptir ve bunun bir nedeni vardır: basit tutun! Bu prensip hem kod hem de mimari için geçerlidir.
Sorumlulukların açık bir şekilde tanımlanması temel bir husustur: Hangi işlev, sınıf veya hizmet neden sorumludur? Düşük bağlantı ve yüksek uyum ilkeleri burada yardımcı olur: Bir göreve ait olan her şey tek bir yerde bir araya getirilirken, bireysel öğeler birbirinden mümkün olduğunca bağımsız olarak var olmalıdır. Dolayısıyla bir hatayı düzeltmek gerekiyorsa sistemin diğer kısımlarını etkilemeden tek bir yerde değiştirmeniz yeterli olacaktır.
Pratik bir örnek
Gerçek dünyadan bir örnek bunu göstermektedir: Bir kod incelemesi sırasında, Go kod tabanında gereksiz bir soyutlamayla karşılaştım. Geliştirici, bir değerin isteğe bağlı olduğunu ifade etmek için bir işaretçi kullanmak yerine, işlevsel programlamadan bir kavram olan Maybe türünü tanıttı. Ancak bu tür kodda yalnızca tek bir yerde kullanılmıştı ve bu ne tutarlı ne de kullanışlıydı. Basit bir işaretçi aynı amaca hizmet edebilirdi, çok daha anlaşılır ve hataya daha az açık olurdu.
Gereksiz soyutlama sorunu yalnızca kod düzeyinde değil aynı zamanda mimari düzeyde de ortaya çıkıyor. Yani bazen bir mikro hizmet ihtiyaç duyulduğu için değil, mikro hizmet konseptini uygulamak için tanıtılır. Bu, gereksiz karmaşıklığa yol açar ve yazılımın yapısını ve anlaşılırlığını iyileştirme yönündeki asıl hedefe ulaşmaz.
Okunabilirlik yazılabilirliği yener
Deneyimli geliştiriciler neden bu kadar sık hareket ediyor? Bunun bir nedeni mükemmellik arzusu, diğeri ise tanınma arzusudur. Bu etkinin farkında olmanız ve kodunuz ve mimariniz hakkında düşünmeniz önemlidir. Kod incelemeleri ve eşli programlama burada yardımcı olabilir çünkü bunlar başkaları için pragmatik yaklaşımları ve anlaşılırlığı teşvik eder.
Mimarlık ve kod, kendi başlarına bir amaç değil, bir amaca yönelik bir araçtır. Ekibin teknik gereksinimlerine ve ihtiyaçlarına odaklanmalısınız. Çözümler yinelemeli ve pragmatik olarak geliştirilmelidir. Her zaman kendinize şunu sorun: Ekibin gerçekten bu soyutlamaya ihtiyacı var mı, yoksa bu sadece işleri gereksiz yere karmaşıklaştırıyor mu?
(Ben)