Merhaba arkadaşlar. Kursun açılması beklentisiyle , geleneksel olarak yararlı materyallerin çevirisini sizinle paylaşır.
Yazılım, giderek daha karmaşık hale gelirken, her geçen gün daha fazla günlük görevi çözmektedir. Marc Andressen'in dediği gibi, dünyayı tüketiyor.
Sonuç olarak, uygulamaların geliştirilme ve sunulma şekli son birkaç yılda önemli ölçüde değişti. Bunlar, bir dizi ilkeyle sonuçlanan tektonik ölçekteki değişimlerdi. Bu ilkelerin ekip oluşturma, tasarlama, geliştirme ve uygulamanızı son kullanıcılara teslim etmede yardımcı olduğu kanıtlanmıştır.
İlkeler şu şekilde özetlenebilir: uygulama küçük, web tabanlı ve geliştirici merkezli bir mimariye sahip olmalıdır.. Bu üç ilkeyi göz önünde bulundurarak, son kullanıcıya hızlı ve güvenli bir şekilde teslim edilebilen, kolayca ölçeklenebilir ve genişletilebilir, sağlam, uçtan uca bir uygulama oluşturabilirsiniz.
Önerilen ilkelerin her birinin, bakımı ve kullanımı kolay, güvenilir uygulamaların hızlı bir şekilde sunulması olan nihai hedefe nasıl katkıda bulunduğunu göstermek için tartışacağımız bir dizi yönü vardır. İlkelerin ne anlama geldiğini açıklığa kavuşturmak için karşıtları ile ilgili olarak bakacağız, "Mutlaka kullandığınızdan emin olun" deyin. küçüklük ilkesi'.
Bu makalenin, sürekli büyüyen bir teknoloji yığını bağlamında tasarıma birleşik bir yaklaşım sağlayacak modern uygulamalar oluşturmak için önerilen ilkeleri kullanmanızı teşvik edeceğini umuyoruz.
Bu ilkeleri uygulayarak, kendinizi yazılım geliştirmedeki en son trendlerden yararlanırken bulacaksınız. uygulamaların geliştirilmesi ve teslimi, konteynerlerin kullanımı (örneğin, ) ve kapsayıcı düzenleme çerçeveleri (örneğin, ), mikro hizmetlerin kullanımı (Mikro hizmet Mimarisi dahil и mikro hizmet uygulamaları için.
Çağdaş uygulama nedir?
Modern uygulamalar? Çağdaş yığın mı? "Çağdaş" tam olarak ne anlama geliyor?
Çoğu geliştirici, modern bir uygulamanın nelerden oluştuğuna dair yalnızca genel bir fikre sahiptir, bu nedenle bu kavramı net bir şekilde tanımlamak gerekir.
Modern bir uygulama, ister bir React JavaScript kitaplığı kullanıcı arabirimi, ister bir Android veya iOS mobil uygulaması veya başka bir API'ye bağlanan bir uygulama olsun, birden çok istemciyi destekler. Modern bir uygulama, veri veya hizmet sağladığı belirsiz sayıda müşteri anlamına gelir.
Modern bir uygulama, istenen veri ve hizmetlere erişmek için bir API sağlar. API değişmez ve sabit olmalı ve belirli bir müşteriden gelen belirli bir istek için özel olarak yazılmamalıdır. API, HTTP(S) üzerinden kullanılabilir ve GUI veya CLI'de bulunan tüm işlevlere erişim sağlar.
Veriler, JSON gibi yaygın olarak kabul edilen, birlikte çalışabilir bir formatta mevcut olmalıdır. RESTful API veya GraphQL gibi bir API, nesneleri ve hizmetleri temiz ve düzenli bir şekilde ortaya koyar ve iyi bir arayüz sağlar.
Modern uygulamalar, modern yığın üzerine kuruludur ve modern yığın, sırasıyla bu tür uygulamaları destekleyen yığındır. Bu yığın, bir geliştiricinin bir HTTP arabirimi ve açık API uç noktaları ile kolayca bir uygulama oluşturmasına olanak tanır. Seçilen yaklaşım, uygulamanızın kolayca JSON formatında veri alıp göndermesini sağlayacaktır. Başka bir deyişle, modern yığın, On İki Faktör Uygulamasının öğelerine karşılık gelir. .
Bu tür yığının popüler sürümleri şuna dayalıdır: , , , , и . Mikro Hizmet Mimarisi belirtilen dillerin her birinde uygulanan modern bir yığının bir örneğini temsil eder.
Lütfen yalnızca bir mikro hizmet yaklaşımını savunmadığımızı unutmayın. Birçoğunuz gelişmesi gereken yekpare yapılarla çalışırken, diğerleriniz mikro hizmet uygulamalarına dönüşecek şekilde genişleyen ve gelişen SOA uygulamalarıyla uğraşıyorsunuz. Yine de diğerleri sunucusuz uygulamalara doğru ilerliyor ve bazıları yukarıdakilerin kombinasyonlarını uyguluyor. Makalede belirtilen ilkeler, yalnızca birkaç küçük değişiklikle bu sistemlerin her biri için geçerlidir.
Ilkeler
Artık modern uygulamanın ve modern yığının ne olduğu konusunda ortak bir anlayışa sahip olduğumuza göre, modern bir uygulamanın geliştirilmesinde, uygulanmasında ve sürdürülmesinde size iyi hizmet edecek mimari ve geliştirme ilkelerine dalmanın zamanı geldi.
İlkelerden biri "küçük uygulamalar yap" gibi geliyor, hadi ona diyelim küçüklük ilkesi. Birçok hareketli parçadan oluşan inanılmaz derecede karmaşık uygulamalar var. Buna karşılık, küçük, ayrık bileşenlerden bir uygulama oluşturmak, onu bir bütün olarak tasarlamayı, sürdürmeyi ve onunla çalışmayı kolaylaştırır. ("Basitleştirir" dediğimize dikkat edin, "basitleştirir" değil).
İkinci ilke, geliştiricilerin geliştirdikleri özelliklere odaklanmalarına yardımcı olurken aynı zamanda uygulama sırasında onları altyapı ve CI/CD endişelerinden kurtararak üretkenliğini artırabilmemizdir. Yani, kısaca, yaklaşımımız geliştiricilere odaklı.
Son olarak, uygulamanızla ilgili her şeyin ağa bağlı olması gerekir. Son 20 yılda, ağlar daha hızlı ve uygulamalar daha karmaşık hale geldikçe, ağ bağlantılı bir geleceğe doğru büyük adımlar attık. Gördüğümüz gibi, modern bir uygulama bir ağ üzerinden birçok farklı müşteri tarafından kullanılmalıdır. Ağ düşüncesini mimariye uygulamanın, aşağıdakilerle iyi giden önemli faydaları vardır: küçüklük ilkesi ve yaklaşım kavramı, geliştirici odaklı.
Bir uygulamayı tasarlarken ve uygularken bu ilkeleri göz önünde bulundurursanız, ürününüzün geliştirilmesinde ve sunulmasında yadsınamaz bir avantaja sahip olursunuz.
Bu üç ilkeye daha ayrıntılı olarak bakalım.
küçüklük ilkesi
İnsan beyninin aynı anda büyük miktarda bilgiyi algılaması zordur. Psikolojide bilişsel yük terimi, bilgiyi bellekte tutmak için gereken toplam zihinsel çaba miktarını ifade eder. Tüm uygulamanın mevcut karmaşık modelini ve geliştirilmekte olan özellikleri kafalarında tutmak yerine sorunu çözmeye odaklanmalarını sağladığı için geliştiriciler üzerindeki bilişsel yükün azaltılması bir önceliktir.
Uygulamalar aşağıdaki nedenlerle ayrışır:
- Geliştiriciler üzerindeki azaltılmış bilişsel yük;
- Testin hızlandırılması ve basitleştirilmesi;
- Uygulamadaki değişikliklerin hızlı teslimi.
Geliştiriciler üzerindeki bilişsel yükü azaltmanın birkaç yolu vardır ve burada küçüklük ilkesi devreye girer.
İşte bilişsel yükü azaltmanın üç yolu:
- Yeni bir özellik geliştirirken göz önünde bulundurmaları gereken zaman dilimini azaltın - zaman çerçevesi ne kadar kısa olursa, bilişsel yük o kadar düşük olur.
- Tek seferlik çalışmanın gerçekleştirildiği kod miktarını azaltın - daha az kod - daha az yük.
- Bir uygulamada artımlı değişiklikler yapma sürecini basitleştirin.
Geliştirme zaman çerçevesini azaltmak
Metodolojinin kullanıldığı günlere geri dönelim. waterfall geliştirme süreci için standarttı ve bir uygulamayı geliştirmek veya güncellemek için altı aydan iki yıla kadar olan zaman dilimleri yaygın bir uygulamaydı. Mühendisler tipik olarak önce ürün gereksinimleri (PRD), sistem referans belgesi (SRD), mimari planı gibi ilgili belgeleri okur ve tüm bunları kodladıkları tek bir bilişsel modelde bir araya getirmeye başlar. Gereksinimler ve dolayısıyla mimari değiştikçe, bilişsel modeldeki güncellemeler hakkında tüm ekibi bilgilendirmek için ciddi bir çaba gösterilmesi gerekiyordu. Böyle bir yaklaşım, en kötü ihtimalle, işi felç edebilir.
Uygulama geliştirme sürecindeki en büyük değişiklik, çevik metodolojinin getirilmesiydi. Metodolojinin ana özelliklerinden biri agile yinelemeli bir gelişmedir. Bu da mühendisler üzerindeki bilişsel yükün azalmasına yol açar. Geliştirme ekibinin uygulamayı tek bir uzun döngüde uygulamasını gerektirmek yerine, agile yaklaşımı, hızlı bir şekilde test edilebilen ve konuşlandırılabilen küçük kod miktarlarına odaklanmanıza ve aynı zamanda geri bildirim almanıza olanak tanır. Uygulamanın bilişsel yükü, büyük bir uygulamanın daha bulanık bir şekilde anlaşılmasını hedefleyen iki haftalık bir ekleme veya özellik değişikliği için çok sayıda özellik ile altı aylık bir zaman diliminden iki yıllık bir zaman dilimine kaydı.
Odağı devasa bir uygulamadan iki haftalık bir sprintte tamamlanabilecek belirli küçük özelliklere kaydırmak, akılda bir sonraki sprint'ten önce birden fazla özellik olmaması önemli bir değişikliktir. Bu, sürekli dalgalanan bilişsel yükü azaltırken geliştirme üretkenliğini artırmamızı sağladı.
Metodolojide agile nihai uygulamanın orijinal konseptin biraz değiştirilmiş bir versiyonu olması bekleniyor, bu nedenle geliştirmenin bitiş noktası zorunlu olarak belirsiz. Yalnızca her bir sprintin sonuçları net ve kesin olabilir.
Küçük kod tabanları
Bilişsel yükü azaltmanın bir sonraki adımı, kod tabanını azaltmaktır. Kural olarak, modern uygulamalar çok büyüktür - sağlam, kurumsal bir uygulama binlerce dosyadan ve yüzbinlerce kod satırından oluşabilir. Dosyaların nasıl organize edildiğine bağlı olarak, kod ve dosyalar arasındaki bağlantılar ve bağımlılıklar açık olabilir veya bunun tersi de geçerlidir. Kullanılan kitaplıklara ve hata ayıklama araçlarının kitaplıklar/paketler/modüller ile özel kod arasında ne kadar iyi ayrım yaptığına bağlı olarak hata ayıklama kodunun yürütülmesi bile sorunlu olabilir.
Bir uygulamanın kodunun çalışan bir zihinsel modelini oluşturmak etkileyici bir zaman alabilir ve geliştiriciye bir kez daha büyük bir bilişsel yük bindirebilir. Bu, özellikle büyük miktarda kodun bulunduğu, işlevsel bileşenleri arasındaki etkileşimin net bir şekilde tanımlanmadığı ve işlevsel sınırlara uyulmadığı için dikkat nesnelerinin ayrılmasının genellikle bulanık olduğu yekpare kod tabanları için geçerlidir.
Mühendisler üzerindeki bilişsel yükü azaltmanın etkili yollarından biri, bir mikro hizmet mimarisine geçmektir. Bir mikro hizmet yaklaşımında, her hizmet bir dizi özelliğe odaklanır; hizmetin anlamı ise genellikle tanımlanmış ve anlaşılırdır. Bir hizmetin sınırları da açıktır - bir hizmetle iletişimin bir API aracılığıyla yapıldığını ve böylece bir hizmet tarafından üretilen verilerin kolayca diğerine aktarılabileceğini unutmayın.
Diğer hizmetlerle etkileşim genellikle birkaç kullanıcı hizmeti ve REST kullanmak gibi basit ve temiz API çağrıları kullanan birkaç sağlayıcı hizmetiyle sınırlıdır. Bu, mühendis üzerindeki bilişsel yükün ciddi şekilde azalması anlamına gelir. En büyük zorluk, hizmet etkileşimi modelini ve işlemler gibi şeylerin birden çok hizmette nasıl gerçekleştiğini anlamaktır. Sonuç olarak, mikro hizmetlerin kullanımı, kod miktarını azaltarak, net hizmet sınırları tanımlayarak ve kullanıcılar ile sağlayıcılar arasındaki ilişkinin anlaşılmasını sağlayarak bilişsel yükü azaltır.
Küçük artımlı değişiklikler
İlkenin son unsuru küçüklük değişim yönetimidir. Geliştiriciler için kod tabanına (belki kendi eski kodlarına bile) bakmak ve "Bu saçmalık, hepsini yeniden yazmamız gerekiyor" demek özellikle cazip geliyor. Bazen bu doğru karardır ve bazen değildir. Küresel model değişikliğinin yükünü geliştirme ekibine yükler ve bu da büyük bir bilişsel yüke yol açar. Mühendislerin sprint sırasında yapabilecekleri değişikliklere odaklanmaları daha iyidir, böylece gerekli işlevleri kademeli de olsa zamanında kullanıma sunabilirler. Nihai ürün, önceden planlanmış olana benzemeli, ancak müşterinin ihtiyaçlarına uygun bazı değişiklikler ve testler yapılmalıdır.
Büyük kod bölümlerini yeniden yazarken, diğer sistem bağımlılıkları devreye girdiği için değişikliği hızlı bir şekilde iletmek bazen mümkün olmayabilir. Değişiklik akışını kontrol etmek için özellik gizlemeyi kullanabilirsiniz. Prensip olarak bu, işlevselliğin üretimde olduğu, ancak ortam değişkeni ayarları (env-var) veya başka bir yapılandırma mekanizması kullanılarak kullanılamadığı anlamına gelir. Kod tüm kalite kontrol süreçlerinden geçmişse, üretimde gizli bir durumda kalabilir. Ancak, bu strateji yalnızca özellik sonunda etkinleştirilirse işe yarar. Aksi takdirde, yalnızca kodu karıştırır ve geliştiricinin üretken olmak için uğraşması gereken bilişsel bir yük ekler. Değişiklik yönetimi ve artımlı değişikliklerin kendisi, geliştiricilerin bilişsel yükünü karşılanabilir bir seviyede tutmaya yardımcı olur.
Mühendisler, ek işlevlerin basit bir şekilde tanıtılmasıyla bile birçok zorluğun üstesinden gelmek zorundadır. Yönetim açısından, kilit işlevsel unsurlara odaklanabilmesi için ekip üzerindeki gereksiz yükü azaltmak ihtiyatlı olacaktır. Geliştirme ekibinize yardımcı olmak için yapabileceğiniz üç şey vardır:
- Metodolojiyi kullan
agileekibin temel özelliklere odaklanması gereken zaman çerçevesini sınırlamak için. - Uygulamanızı birden çok mikro hizmet olarak uygulayın. Bu, uygulanabilecek özelliklerin sayısını sınırlayacak ve bilişsel yükü iş başında tutan sınırları güçlendirecektir.
- Büyük ve hantal yerine artımlı değişiklikleri tercih edin, küçük kod parçalarını değiştirin. Değişiklikleri ekledikten hemen sonra görünmeyecek olsalar bile uygulamak için özellik gizlemeyi kullanın.
Çalışmanızda küçüklük ilkesini uygularsanız, ekibiniz çok daha mutlu olacak, gerekli özellikleri uygulamaya daha iyi odaklanacak ve niteliksel değişiklikleri daha hızlı uygulamaya koyma olasılığı daha yüksek olacaktır. Ancak bu, işin daha karmaşık hale gelemeyeceği anlamına gelmez, bazen tam tersine, yeni işlevlerin getirilmesi birkaç hizmetin değiştirilmesini gerektirir ve bu süreç, yekpare bir mimaride benzerlerinden daha zor olabilir. Her durumda, küçüklük yaklaşımını benimsemenin faydaları buna değer.
İlk bölümün sonu.
Yakında çevirinin ikinci bölümünü yayınlayacağız ve şimdi yorumlarınızı bekliyor ve sizi okumaya davet ediyoruz. bugün saat 20.00'de gerçekleşecek.
Kaynak: habr.com