Yeterlik

Deneyimli programcılar, iyi bir mimariyi kötü olandan kolayca ayırt edebilirler, ancak bunu birkaç kelimeyle açıklamaları istenirse, muhtemelen bunu yapamazlar. İyi mimari için tek bir kriter ve tek bir tanım yoktur.

Ancak biraz düşünürseniz iyi bir mimarinin sağlaması gereken bir takım kriterleri yazabilirsiniz. İyi bir mimari , her şeyden önce, bir programı geliştirme ve sürdürme sürecini daha basit ve daha verimli hale getiren mantıksal bir mimaridir.

Bir program iyi bir mimariye sahip olduğunda, nasıl çalıştığını ve nereye kod yazılacağını anlamak her zaman yeterince kolaydır. İyi tasarlanmış bir programın değiştirilmesi, test edilmesi, hatalarının ayıklanması ve geliştirilmesi daha kolaydır. Akıllı insanlar, iyi mimari için aşağıdaki kriterleri formüle ettiler:

  • Yeterlik;
  • Esneklik;
  • genişletilebilirlik;
  • ölçeklenebilirlik;
  • test edilebilirlik;
  • Kod sürdürülebilirliği.

Sistem verimliliği. Program, elbette, verilen görevleri çözmeli ve işlevlerini iyi ve çeşitli koşullarda yerine getirmelidir. Görünüşe göre herhangi bir program yapması gerekeni yapıyor (eğer yazılmışsa), ancak çoğu zaman durum hiç de böyle değil.

Sürekli olarak iddia ettiklerini yapmayan programlarla karşılaşacaksınız.

  • Libre Office, Microsoft Office'in tam yerine geçer (aslında değil);
  • Edge tarayıcısı tüm web standartlarını destekler (aslında değil);
  • Banka, kullanıcılarının kişisel verilerinin güvenliğini önemser (aslında önemsemez).

Ve henüz performansa, güvenilirliğe, zamanında hata düzeltmelerine veya bilinen güvenlik açıkları hakkındaki bilgilerin yayınlanmasına değinmedik.

Hiç kimsenin mükemmel olmadığı açıktır, ancak programın birincil görevlerini çözmesi gerekir. Bu nedenle, verimlilik olmadan, hiçbir yerde.

Esneklik

Bence verimlilikten daha önemli olan tek şey esnekliktir. Herhangi bir uygulama zamanla değişmek zorundadır, gereksinimler değiştikçe yenileri eklenir. Mevcut işlevsellikte değişiklik yapmak ne kadar hızlı ve kolaysa, neden olduğu sorun ve hata o kadar az olur, sistem mimarisi o kadar esnek olur .

Java webinar

Çoğu zaman acemi programcılar / mimarlar, mevcut görevler için ideal bir mimariye ihtiyaçları olduğunu düşünürler. HAYIR. Bir yıl içinde size duyurulacak görevler için ideal bir mimariye ihtiyacınız var. Artık gelecekteki görevleri bilmeyen siz, bunların ne olacağını bilmelisiniz.

Onları tahmin etmeye çalışmanın bir anlamı yok çünkü her zaman beklenmedik bir şeyler olacaktır. Ancak bu tür görevlerin ortaya çıkacağını dikkate almalısınız. Bu nedenle, geliştirme sürecinde elde edilenleri, nasıl değiştirilmesi gerekeceği açısından değerlendirmeye çalışın.

Kendinize şu soruyu sorun: "Mevcut mimari karar yanlış çıkarsa ne olur?", "Kod ne kadar değişecek?". Sistemin bir parçasının değiştirilmesi diğer parçalarını etkilememelidir.

Mümkün olduğunda, mimari kararlar değişmez olmamalı ve mimari hataların sonuçları makul ölçüde sınırlandırılmalıdır. "İyi mimari, önemli kararları GECİKTİRMENİZE olanak sağlar" (Bob Martin) ve hataların "maliyetini" en aza indirir.

Bu yaklaşımlardan biri, uygulamayı mikro hizmetlere bölmektir: zaten var olan mantığı ayrı parçalara bölmek kolaydır. Ancak en büyük sorun, küçük bir özelliği uygulamak için aynı anda bir düzine hizmette gelecekteki değişiklikleri yapmaktır.

ölçeklenebilirlik

Ölçeklenebilirlik, projeye yeni insanlar ekleyerek geliştirme süresini kısaltma yeteneğidir. Mimari, birçok kişinin aynı anda program üzerinde çalışabilmesi için geliştirme sürecinin paralelleştirilmesine izin vermelidir.

Görünüşe göre bu kural kendi başına uygulanıyor, ancak pratikte her şey tam tersi. Bir projeye yeni insanlar eklendiğinde geliştirme süresinin neden arttığını açıklayan The Mythical Man-Month adlı süper popüler bir kitap bile var .

Genişletilebilirlik

Genişletilebilirlik , bir sisteme çekirdek yapısını bozmadan yeni özellikler ve varlıklar ekleme yeteneğidir. İlk aşamada, sisteme yalnızca temel ve en gerekli işlevselliği koymak mantıklıdır.

Bu sözde YAGNI ilkesidir - ona ihtiyacınız olmayacak , "ihtiyacınız olmayacak". Aynı zamanda mimari, gerektiğinde ek işlevleri kolayca artırmanıza izin vermelidir. Ve böylece en olası değişikliklerin getirilmesi en az çabayı gerektiriyordu.

Sistemin mimarisinin esnek ve genişletilebilir olması (yani değişebilen ve gelişebilen) olması gerekliliği o kadar önemlidir ki, ayrı bir ilke - “Açık/Kapalı İlke” olarak bile formüle edilmiştir . Açık-Kapalı İlkesi, beş SOLID ilkesinden ikincisidir: yazılım varlıkları (sınıflar, modüller, işlevler) genişlemeye açık, ancak değişikliğe kapalı olmalıdır .

Başka bir deyişle: sistemin mevcut parçalarını yeniden yazmadan sistemin davranışını değiştirmek ve genişletmek mümkün olmalıdır .

Bu, uygulamanın, mevcut kodu değiştirmek zorunda kalmadan yeni kod (uzantılar) yazarak davranışını değiştirecek ve yeni işlevler ekleyecek şekilde tasarlanması gerektiği anlamına gelir.

Bu durumda, yeni gereksinimlerin ortaya çıkması, mevcut mantığın değiştirilmesini gerektirmeyecek, ancak öncelikle genişletilerek uygulanabilir. Bu ilke, "eklenti mimarisinin" (Eklenti Mimarisi) temelidir. Bunun başarılabileceği teknikler daha sonra tartışılacaktır.

Servlet'leri ve filtreleri hatırladınız mı? Aslında aynı mantık servletler kullanılarak uygulanabiliyorsa, neden filtrelere ihtiyaç duyuldu ve hatta ayrı arayüzlerle bile?

Çeşitli hizmet işlevlerini ayrı bir katmana taşımayı mümkün kılan filtre kavramının (servis servlet'leri) icadıydı. Ve gelecekte, filtrelerin davranışını değiştirirken servletleri değiştirmek gerekli değildi.

Filtrelerin icadından önce, isteklerin yeniden yönlendirilmesinden sorumlu olan tüm hizmet mantığı, servletlerin kendisinde bulunuyordu. Ve genellikle mantıktaki küçük bir değişiklik, tüm sunucu uygulamacıklarını gözden geçirme ve hepsinde çeşitli değişiklikler yapma ihtiyacına yol açar.

test edilebilirlik

Bir Java Arka Uç Geliştiricisiyseniz, sunucu uygulamalarınız genellikle bir dizi yöntemi REST API olarak kullanıma sunar. Ve tüm yöntemlerinizin amaçlandığı gibi çalışıp çalışmadığını kontrol etmek için testlerle ele alınmaları gerekir.

Genel olarak, API test kapsamı iyi bir stildir. API'nizin gerçekten amaçlanan şeyi yaptığından emin olmanızı sağlar. Ayrıca, daha da önemlisi, sunucu mantığında değişiklikler yapabilir ve yanlışlıkla herhangi bir şeyi bozmadığınızı kolayca kontrol edebilirsiniz .

Test yazmaya başlar başlamaz, çoğu kodun test edilemeyeceğini fark edeceksiniz: özel yöntemler, güçlü bağlantı, statik sınıflar ve değişkenler.

Yeni başlayan, “Kod çalışıyorsa neden testlere ihtiyacımız var?” Diye soracaktır.

Profesyonel, "Test edilemeyecekse neden çalışan koda ihtiyacımız var?" Diye soracaktır.

Test etmesi kolay olan kod daha az hata içerecek ve daha güvenilir olacaktır. Ancak testler yalnızca kod kalitesini iyileştirmez. Hemen hemen tüm geliştiriciler sonunda "iyi test edilebilirlik" gerekliliğinin aynı zamanda otomatik olarak iyi tasarıma yol açan bir kılavuz güç olduğu sonucuna varırlar.

İdeal Mimari kitabından bir alıntı: "Bir sınıfın "test edilebilirliği" ilkesini, iyi sınıf tasarımının "turnusol testi" olarak kullanın. Tek bir test kodu satırı yazmasanız bile, bu soruyu 90'da yanıtlayın. Vakaların yüzdesi, tasarımıyla her şeyin nasıl "iyi" veya "kötü" olduğunu anlamaya yardımcı olacak."

Testlere dayalı programlar geliştirmek için Test Odaklı Geliştirme (TDD) adı verilen eksiksiz bir metodoloji vardır. Bu elbette diğer uç noktadır: kod yazmadan önce kod yazın.

Kod sürdürülebilirliği

Kural olarak, program üzerinde birçok insan çalışır - bazıları ayrılır, yenileri gelir. Bir bilişim şirketinde programcının ortalama çalışma süresi bir buçuk yıldır. Yani 5 yıllık bir projeye geldiyseniz, o zaman iş arkadaşlarınızın sadece %20'si en başından bu proje üzerinde çalıştı.

Başkalarının yazdığı bir programı sürdürmek ve geliştirmek çok zordur. Program zaten yazılmış olsa bile, genellikle onu korumaya devam etmek gerekir: hataları düzeltin ve küçük düzeltmeler yapın. Ve çoğu zaman bu, onu yazmaya katılmayan kişiler tarafından yapılmalıdır.

Bu nedenle, iyi bir mimari , yeni insanların sistemi anlamasını nispeten kolay ve hızlı hale getirmelidir . Proje şu şekilde olmalıdır:

  • İyi yapılandırılmış.
  • Çoğaltma içermez.
  • İyi biçimlendirilmiş koda sahip olun.
  • Belgelerin dahil edilmesi arzu edilir.
  • Programcılar için standart ve tanıdık çözümler uygulamak gereklidir.

Üzerinde çalıştığınız projeyi 5 üzerinden kolayca derecelendirebilirsiniz . Bu gereksinimlerin her biri için sadece iki puan sayın . Ve 5 veya daha fazlasını alırsanız, o zaman şanslısınız.

Hatta programcıların bir ilkesi vardır : Sistem ne kadar egzotikse, diğerlerinin anlaması o kadar zor olur. Genellikle kullanıcı arayüzü ile ilgili olarak kullanılır, ancak kod yazmak için de geçerlidir.