Sürdürülebilir Web Uygulamaları Oluşturmak için Bildirime Dayalı Programlamadan Yararlanma

Bu makalede, bildirim temelli programlama tekniklerini makul bir şekilde benimsemenin, ekiplerin genişletilmesi ve bakımı daha kolay web uygulamaları oluşturmasına nasıl izin verebileceğini gösteriyorum.

“…bildirimsel programlama, kontrol akışını tanımlamadan bir hesaplamanın mantığını ifade eden bir programlama paradigmasıdır.” —Remo H. Jansen, TypeScript ile Uygulamalı İşlevsel Programlama

Yazılımdaki çoğu problem gibi, uygulamalarınızda bildirimsel programlama tekniklerini kullanmaya karar vermek, ödünleşimlerin dikkatli bir şekilde değerlendirilmesini gerektirir. Bunlarla ilgili derinlemesine bir tartışma için önceki makalelerimizden birine göz atın.

Burada odak noktası, birden çok paradigmayı destekleyen bir dil olan JavaScript'te yazılmış hem yeni hem de mevcut uygulamalar için bildirimsel programlama modellerinin kademeli olarak nasıl benimsenebileceğidir.

İlk olarak, kodunuzu daha anlamlı ve değişime dirençli hale getirmek için TypeScript'in hem arka hem de ön uçta nasıl kullanılacağını tartışıyoruz. Ardından, ön uç geliştirmeyi kolaylaştırmak ve paydaşların geliştirme sürecine katılımını artırmak için sonlu durum makinelerini (FSM'ler) keşfediyoruz.

FSM'ler yeni bir teknoloji değildir. Yaklaşık 50 yıl önce keşfedildiler ve yazılım doğruluğunun kritik olabileceği sinyal işleme, havacılık ve finans gibi sektörlerde popülerler. Ayrıca, karmaşık asenkron durum güncellemelerini ve animasyonları koordine etmek gibi modern web geliştirmede sıklıkla ortaya çıkan modelleme problemlerine de çok uygundurlar.

Bu fayda, devletin yönetilme şekli üzerindeki kısıtlamalardan kaynaklanmaktadır. Bir durum makinesi aynı anda yalnızca bir durumda olabilir ve harici olaylara (fare tıklamaları veya getirme yanıtları gibi) yanıt olarak geçebileceği sınırlı komşu durumlara sahiptir. Sonuç genellikle önemli ölçüde azaltılmış bir kusur oranıdır. Ancak, FSM yaklaşımlarının büyük uygulamalarda iyi çalışması için ölçeklendirilmesi zor olabilir. Durum çizelgeleri adı verilen FSM'lerin son uzantıları, karmaşık FSM'lerin görselleştirilmesine ve çok daha büyük uygulamalara ölçeklenmesine olanak tanır; bu, bu makalenin odaklandığı sonlu durum makinelerinin tadıdır. Gösterimiz için, JavaScript'teki FSM'ler ve durum çizelgeleri için en iyi çözümlerden biri olan XState kitaplığını kullanacağız.

Node.js ile Back End Bildirimi

Bildirimsel yaklaşımları kullanarak bir web sunucusu arka ucunu programlamak geniş bir konudur ve tipik olarak uygun bir sunucu tarafı işlevsel programlama dilini değerlendirerek başlayabilir. Bunun yerine, arka ucunuz için Node.js'yi zaten seçtiğiniz (veya almayı düşündüğünüz) bir zamanda bunu okuduğunuzu varsayalım.

Bu bölüm, varlıkları arka uçta modellemeye yönelik aşağıdaki avantajlara sahip bir yaklaşımı detaylandırır:

• Geliştirilmiş kod okunabilirliği
• Daha güvenli yeniden düzenleme
• Tip modellemenin sağladığı garantiler nedeniyle gelişmiş performans potansiyeli

Tip Modelleme Yoluyla Davranış Garantileri

JavaScript

JavaScript'te belirli bir kullanıcıyı e-posta adresi aracılığıyla arama görevini düşünün:

 function validateEmail(email) { if (typeof email !== "string") return false; return isWellFormedEmailAddress(email); } function lookupUser(validatedEmail) { // Assume a valid email is passed in. // Safe to pass this down to the database for a user lookup.. }

Bu işlev, bir e-posta adresini dize olarak kabul eder ve bir eşleşme olduğunda ilgili kullanıcıyı veritabanından döndürür.

Varsayım, lookupUser() yalnızca temel doğrulama gerçekleştirildikten sonra çağrılacağıdır. Bu önemli bir varsayımdır. Birkaç hafta sonra yeniden düzenleme yapılırsa ve bu varsayım artık geçerli değilse? Birim testlerinin hatayı yakaladığını ya da veritabanına filtrelenmemiş metin gönderiyor olabileceğimizi gösterdiler!

TypeScript (ilk deneme)

Doğrulama işlevinin TypeScript eşdeğerini düşünelim:

 function validateEmail(email: string) { // No longer needed the type check (typeof email === "string"). return isWellFormedEmailAddress(email); }

Bu, TypeScript derleyicisinin bizi ek bir çalışma zamanı doğrulama adımı eklemekten kurtardığı için küçük bir gelişmedir.

Güçlü yazmanın getirebileceği güvenlik garantileri, henüz tam anlamıyla yararlanılmamıştır. Bunu inceleyelim.

TypeScript (ikinci deneme)

Tür güvenliğini iyileştirelim ve işlenmemiş dizelerin looukupUser girdi olarak geçirilmesine izin vermeyelim:

 type ValidEmail = { value: string }; function validateEmail(input: string): Email | null { if (!isWellFormedEmailAddress(input)) return null; return { value: email }; } function lookupUser(email: ValidEmail): User { // No need to perform validation. Compiler has already ensured only valid emails have been passed in. return lookupUserInDatabase(email.value); }

Bu daha iyi, ama zahmetli. ValidEmail tüm kullanımları, gerçek adrese email.value aracılığıyla erişir. TypeScript, Java ve C# gibi diller tarafından kullanılan nominal yazım yerine yapısal yazım kullanır.

Güçlü olsa da, bu, bu imzaya uyan herhangi bir türün eşdeğer olduğu anlamına gelir. Örneğin, aşağıdaki parola türü, derleyicinin şikayeti olmaksızın lookupUser() :

 type ValidPassword = { value: string }; const password = { value: "password" }; lookupUser(password); // No error.

TypeScript (üçüncü deneme)

Kavşak kullanarak TypeScript'te nominal yazmayı başarabiliriz:

 type ValidEmail = string & { _: "ValidEmail" }; function validateEmail(input: string): ValidEmail { // Perform email validation checks.. return input as ValidEmail; } type ValidPassword = string & { _: "ValidPassword" }; function validatePassword(input: string): ValidPassword { ... } lookupUser("[email protected]"); // Error: expected type ValidEmail. lookupUser(validatePassword("MyPassword"); // Error: expected type ValidEmail. lookupUser(validateEmail("[email protected]")); // Ok.

Artık yalnızca doğrulanmış e-posta dizelerinin lookupUser() iletilebileceği hedefine ulaştık.

Profesyonel İpucu: Aşağıdaki yardımcı türünü kullanarak bu kalıbı kolayca uygulayın:

 type Opaque<K, T> = T & { __TYPE__: K }; type Email = Opaque<"Email", string>; type Password = Opaque<"Password", string>; type UserId = Opaque<"UserId", number>;

Artıları

Alan adınızdaki varlıkları güçlü bir şekilde yazarak şunları yapabiliriz:

1. Değerli sunucu CPU döngülerini tüketen çalışma zamanında gerçekleştirilmesi gereken kontrollerin sayısını azaltın (çok küçük bir miktar olsa da bunlar dakikada binlerce istek sunarken toplanır).
2. TypeScript derleyicisinin sağladığı garantiler nedeniyle daha az temel testi sürdürün.
3. Düzenleyici ve derleyici destekli yeniden düzenlemeden yararlanın.
4. İyileştirilmiş sinyal-gürültü oranı ile kod okunabilirliğini iyileştirin.

Eksileri

Tip modelleme, dikkate alınması gereken bazı ödünleşimlerle birlikte gelir:

1. TypeScript'in tanıtılması, genellikle araç zincirini karmaşıklaştırır ve daha uzun derleme ve test paketi yürütme sürelerine yol açar.
2. Amacınız bir özelliğin prototipini oluşturmak ve onu en kısa sürede kullanıcıların eline geçirmekse, türleri açıkça modellemek ve bunları kod temeli aracılığıyla yaymak için gereken ekstra çaba buna değmeyebilir.

Sunucudaki veya paylaşılan arka uç/ön uç doğrulama katmanındaki mevcut JavaScript kodunun, kod okunabilirliğini iyileştirmek ve ekipler için önemli gereksinimler olan daha güvenli yeniden düzenlemeye olanak sağlamak için türlerle nasıl genişletilebileceğini gösterdik.

Bildirime Dayalı Kullanıcı Arayüzleri

Bildirimsel programlama teknikleri kullanılarak geliştirilen kullanıcı arayüzleri, çabayı “nasıl” yerine “ne”yi açıklamaya odaklar. Web'in üç temel bileşeninden ikisi, CSS ve HTML, zamana ve 1 milyardan fazla web sitesine dayanan bildirimsel programlama dilleridir.

React, 2013 yılında Facebook tarafından açık kaynaklıydı ve ön uç geliştirme sürecini önemli ölçüde değiştirdi. İlk kullandığımda, GUI'yi uygulamanın durumunun bir işlevi olarak nasıl ilan edebileceğimi sevdim. Artık DOM manipülasyonunun karmaşık ayrıntılarıyla uğraşmadan ve kullanıcı eylemlerine yanıt olarak uygulamanın hangi bölümlerinin güncellenmesi gerektiğini izlemeden daha küçük yapı taşlarından büyük ve karmaşık UI'ler oluşturabiliyordum. Kullanıcı arayüzünü tanımlarken zaman yönünü büyük ölçüde görmezden gelebilir ve uygulamamın bir durumdan diğerine doğru şekilde geçişini sağlamaya odaklanabilirim.

Kullanıcı arabirimlerini geliştirmenin daha basit bir yolunu elde etmek için React, geliştirici ile makine/tarayıcı arasına bir soyutlama katmanı ekledi: sanal DOM .

Diğer modern web UI çerçeveleri de farklı şekillerde olsa da bu boşluğu doldurdu. Örneğin, Vue, JavaScript alıcıları/ayarlayıcıları (Vue 2) veya proxy'ler (Vue 3) aracılığıyla işlevsel reaktivite kullanır. Svelte, fazladan bir kaynak kodu derleme adımı (Svelte) aracılığıyla reaktivite sağlar.

Bu örnekler, sektörümüzde geliştiricilerin bildirimsel yaklaşımlarla uygulama davranışını ifade etmeleri için daha iyi, daha basit araçlar sağlama konusundaki büyük isteğini gösteriyor gibi görünüyor.

Bildirimsel Uygulama Durumu ve Mantığı

Sunum katmanı bir tür HTML (örneğin, React'te JSX, Vue, Angular ve Svelte'de bulunan HTML tabanlı şablonlar) etrafında dönmeye devam ederken, bir uygulamanın durumunun şu şekilde modellenmesi sorununun olduğunu varsayıyorum. diğer geliştiriciler tarafından kolayca anlaşılabilir ve uygulama büyüdükçe bakımı yapılabilir hala çözülmedi. Devlet yönetimi kütüphanelerinin ve bugüne kadar devam eden yaklaşımların çoğalmasıyla bunun kanıtlarını görüyoruz.

Durum, modern web uygulamalarının artan beklentileri ile karmaşıklaşıyor. Modern devlet yönetimi yaklaşımlarının desteklemesi gereken bazı yeni ortaya çıkan zorluklar:

• Gelişmiş abonelik ve önbelleğe alma tekniklerini kullanan ilk çevrimdışı uygulamalar
• Sürekli küçülen paket boyutu gereksinimleri için özlü kod ve kodun yeniden kullanımı
• Aslına uygun animasyonlar ve gerçek zamanlı güncellemeler aracılığıyla giderek daha karmaşık hale gelen kullanıcı deneyimleri talebi

Sonlu Durum Makinelerinin ve Durum Çizelgelerinin (Yeniden) Ortaya Çıkışı

Sonlu durum makineleri, havacılık ve finans gibi uygulama sağlamlığının kritik olduğu belirli endüstrilerde yazılım geliştirme için yaygın olarak kullanılmaktadır. Ayrıca, örneğin mükemmel XState kitaplığı aracılığıyla web uygulamalarının ön uç geliştirmesi için sürekli olarak popülerlik kazanıyor.

Wikipedia sonlu durum makinesini şu şekilde tanımlar:

Herhangi bir zamanda tam olarak sonlu sayıdaki durumlardan birinde olabilen soyut bir makine. FSM, bazı harici girdilere yanıt olarak bir durumdan diğerine geçebilir; bir durumdan başka bir duruma geçişe geçiş denir. Bir FSM, durumlarının, başlangıç ​​durumunun ve her geçiş için koşulların bir listesiyle tanımlanır.

Ve ilerisi:

Durum, bir geçiş yürütmeyi bekleyen bir sistemin durumunun açıklamasıdır.

Temel biçimlerindeki FSM'ler, durum patlaması sorunu nedeniyle büyük sistemlere iyi ölçeklenemez. Son zamanlarda, FSM'lerin ticari uygulamalarda geniş bir şekilde kullanılmasını sağlayan FSM'leri hiyerarşi ve eşzamanlılık ile genişletmek için UML durum çizelgeleri oluşturuldu.

Uygulama Mantığınızı Bildirin

İlk olarak, bir FSM kod olarak nasıl görünür? JavaScript'te bir sonlu durum makinesini uygulamanın birkaç yolu vardır.

• Switch ifadesi olarak sonlu durum makinesi

Bir JavaScript'in bulunabileceği olası durumları açıklayan, bir switch ifadesi kullanılarak uygulanan bir makine:

 const initialState = { type: 'idle', error: undefined, result: undefined }; function transition(state = initialState, action) { switch (action) { case 'invoke': return { type: 'pending' }; case 'resolve': return { type: 'completed', result: action.value }; case 'error': return { type: 'completed', error: action.error ; default: return state; } }

Bu kod stili, popüler Redux durum yönetimi kitaplığını kullanan geliştiricilere tanıdık gelecektir.

• JavaScript nesnesi olarak sonlu durum makinesi

JavaScript XState kitaplığı kullanılarak JavaScript nesnesi olarak uygulanan aynı makine:

 const promiseMachine = Machine({ id: "promise", initial: "idle", context: { result: undefined, error: undefined, }, states: { idle: { on: { INVOKE: "pending", }, }, pending: { on: { RESOLVE: "success", REJECT: "failure", }, }, success: { type: "final", actions: assign({ result: (context, event) => event.data, }), }, failure: { type: "final", actions: assign({ error: (context, event) => event.data, }), }, }, });

XState sürümü daha az kompakt olsa da, nesne gösteriminin çeşitli avantajları vardır:

1. Durum makinesinin kendisi, kolayca devam ettirilebilen basit JSON'dur.
2. Bildirimsel olduğu için makine görselleştirilebilir.
3. TypeScript kullanılıyorsa, derleyici yalnızca geçerli durum geçişlerinin gerçekleştirildiğini kontrol eder.

XState durum çizelgelerini destekler ve çok büyük uygulamalarda kullanıma uygun hale getiren SCXML belirtimini uygular.

Bir sözün Statecharts görselleştirmesi:

XState En İyi Uygulamaları

Projelerin sürdürülebilir olmasına yardımcı olmak için XState kullanırken uygulanacak en iyi uygulamalardan bazıları aşağıdadır.

Mantıktan Ayrı Yan Etkiler

XState, yan etkilerin (günlüğe kaydetme veya API istekleri gibi etkinlikleri içerir) durum makinesinin mantığından bağımsız olarak belirtilmesine izin verir.

Bunun aşağıdaki faydaları vardır:

1. Durum makinesi kodunu mümkün olduğunca temiz ve basit tutarak mantık hatalarının saptanmasına yardımcı olun.
2. Önce ekstra kazan plakasını çıkarmaya gerek kalmadan durum makinesini kolayca görselleştirin.
3. Sahte hizmetler enjekte ederek durum makinesinin daha kolay test edilmesi.

 const fetchUsersMachine = Machine({ id: "fetchUsers", initial: "idle", context: { users: undefined, error: undefined, nextPage: 0, }, states: { idle: { on: { FETCH: "fetching", }, }, fetching: { invoke: { src: (context) => fetch(`url/to/users?page=${context.nextPage}`).then((response) => response.json() ), onDone: { target: "success", actions: assign({ users: (context, event) => [...context.users, ...event.data], // Data holds the newly fetched users nextPage: (context) => context.nextPage + 1, }), }, onError: { target: "failure", error: (_, event) => event.data, // Data holds the error }, }, }, // success state.. // failure state.. }, });

Hala işleri yürütürken durum makinelerini bu şekilde yazmak cazip gelse de, yan etkileri seçenekler olarak ileterek endişelerin daha iyi ayrılması sağlanır:

 const services = { getUsers: (context) => fetch( `url/to/users?page=${context.nextPage}` ).then((response) => response.json()) } const fetchUsersMachine = Machine({ ... states: { ... fetching: { invoke: { // Invoke the side effect at key: 'getUsers' in the supplied services object. src: 'getUsers', } on: { RESOLVE: "success", REJECT: "failure", }, }, ... }, // Supply the side effects to be executed on state transitions. { services } });

Bu ayrıca, durum makinesinin kolay birim testine izin vererek, kullanıcı getirmelerinin açık bir şekilde alay edilmesine izin verir:

 async function testFetchUsers() { return [{ name: "Peter", location: "New Zealand" }]; } const machine = fetchUsersMachine.withConfig({ services: { getUsers: (context) => testFetchUsers(), }, });

Büyük Makineleri Bölme

Başlarken, bir problem alanının iyi bir sonlu durum makine hiyerarşisinde en iyi nasıl yapılandırılacağı her zaman hemen açık değildir.

İpucu: Bu süreci yönlendirmeye yardımcı olması için UI bileşenlerinizin hiyerarşisini kullanın. Durum makinelerinin UI bileşenlerine nasıl eşleneceğine ilişkin sonraki bölüme bakın.

Durum makinelerini kullanmanın en büyük yararı, uygulamalarınızdaki tüm durumları ve durumlar arasındaki geçişleri açıkça modellemektir, böylece ortaya çıkan davranış net bir şekilde anlaşılır ve mantık hatalarını veya boşlukları tespit etmeyi kolaylaştırır.

Bunun iyi çalışması için makinelerin küçük ve özlü tutulması gerekir. Neyse ki, durum makinelerini hiyerarşik olarak oluşturmak kolaydır. Bir trafik ışığı sisteminin kurallı durum çizelgeleri örneğinde, "kırmızı" durumun kendisi bir alt durum makinesi haline gelir. Ana "hafif" makine, "kırmızı"nın dahili durumlarının farkında değildir, ancak ne zaman "kırmızı" girileceğine ve çıktıktan sonra amaçlanan davranışın ne olduğuna karar verir:

1-1 Durum Makinelerinin Durum Bilgili Kullanıcı Arabirimi Bileşenleriyle Eşleştirilmesi

Örneğin, aşağıdaki React görünümlerine sahip çok basitleştirilmiş, kurgusal bir e-ticaret sitesini ele alalım:

 <App> <SigninForm /> <RegistrationForm /> <Products /> <Cart /> <Admin> <Users /> <Products /> </Admin> </App>

Yukarıdaki görüşlere karşılık gelen durum makineleri oluşturma işlemi, Redux durum yönetimi kitaplığını kullananlar için tanıdık gelebilir:

1. Bileşenin modellenmesi gereken bir durumu var mı? Örneğin, Yönetici/Ürünler; sunucuya disk belleğine alınmış getirmeler artı bir önbelleğe alma çözümü (SWR gibi) yeterli olabilir. Öte yandan, SignInForm veya Cart gibi bileşenler genellikle alanlara girilen veriler veya mevcut sepet içeriği gibi yönetilmesi gereken durumları içerir.
2. Yerel durum teknikleri (örneğin, setState() / useState() ) sorunu yakalamak için yeterli mi? Sepet açılır modunun şu anda açık olup olmadığının izlenmesi, sonlu durumlu bir makinenin kullanılmasını pek gerektirmez.
3. Ortaya çıkan durum makinesinin çok karmaşık olması muhtemel mi? Eğer öyleyse, başka yerlerde yeniden kullanılabilecek alt makineler yaratma fırsatlarını belirleyerek makineyi birkaç küçük parçaya bölün. Örneğin, SignInForm ve KayıtForm makineleri, model doğrulama ve kullanıcı e-postası, adı ve parola alanları için durum için bir alt textFieldMachine örneğini çağırabilir.

Sonlu Durumlu Makine Modeli Ne Zaman Kullanılır?

Durum çizelgeleri ve FSM'ler bazı zorlu sorunları zarif bir şekilde çözebilse de, belirli bir uygulama için kullanılacak en iyi araçlara ve yaklaşımlara karar vermek genellikle birkaç faktöre bağlıdır.

Sonlu durum makinelerinin kullanıldığı bazı durumlar:

• Uygulamanız, saha erişilebilirliğinin veya görünürlüğünün karmaşık kurallarla düzenlendiği önemli bir veri girişi bileşeni içerir : örneğin, bir sigorta tazminatı uygulamasında form girişi. Burada FSM'ler, iş kurallarının sağlam bir şekilde uygulanmasını sağlamaya yardımcı olur. Ayrıca, durum çizelgelerinin görselleştirme özellikleri, teknik olmayan paydaşlarla işbirliğini artırmaya ve geliştirmenin başlarında ayrıntılı iş gereksinimlerini belirlemeye yardımcı olmak için kullanılabilir.
• Daha yavaş bağlantılarda daha iyi çalışmak ve kullanıcılara daha yüksek kaliteli deneyimler sunmak için web uygulamalarının giderek karmaşıklaşan zaman uyumsuz veri akışlarını yönetmesi gerekir. FSM'ler, bir uygulamanın içinde bulunabileceği tüm durumları açıkça modeller ve eşzamansız veri sorunlarının tanılanmasına ve çözülmesine yardımcı olmak için durum çizelgeleri görselleştirilebilir.
• Çok sayıda karmaşık, durum tabanlı animasyon gerektiren uygulamalar. Karmaşık animasyonlar için, animasyonları RxJS ile zaman içinde olay akışları olarak modelleme teknikleri popülerdir. Birçok senaryo için bu iyi çalışır, ancak zengin animasyon bilinen bir dizi karmaşık durumla birleştirildiğinde, FSM'ler, animasyonların arasında aktığı iyi tanımlanmış "dinlenme noktaları" sağlar. RxJS ile birleştirilen FSM'ler, bir sonraki yüksek kaliteli, etkileyici kullanıcı deneyimleri dalgasını sunmaya yardımcı olmak için mükemmel bir kombinasyon gibi görünüyor.
• Fotoğraf veya video düzenleme, diyagram oluşturma araçları veya iş mantığının çoğunun istemci tarafında yer aldığı oyunlar gibi zengin istemci uygulamaları . FSM'ler, doğal olarak UI çerçevesinden veya kitaplıklardan ayrılır ve yüksek kaliteli uygulamaların hızla yinelenmesine ve güvenle gönderilmesine izin vermek için yazma testleri kolaydır.

Sonlu Durum Makinesi Uyarıları

• XState gibi durum haritası kitaplıkları için genel yaklaşım, en iyi uygulamalar ve API, özellikle daha az deneyimli ekipler için üretken olmak için zaman ve kaynak yatırımına ihtiyaç duyan çoğu ön uç geliştirici için yenidir.
• Önceki uyarıya benzer şekilde, XState'in popülaritesi artmaya devam ederken ve iyi bir şekilde belgelenirken, Redux, MobX veya React Context gibi mevcut durum yönetimi kitaplıkları, XState'in henüz eşleşmediği çok sayıda çevrimiçi bilgi sağlayan çok sayıda takipçiye sahiptir.
• Daha basit bir CRUD modelini izleyen uygulamalar için, SWR veya React Query gibi iyi bir kaynak önbelleğe alma kitaplığı ile birleştirilmiş mevcut durum yönetimi teknikleri yeterli olacaktır. Burada, FSM'lerin sağladığı ekstra kısıtlamalar, karmaşık uygulamalarda inanılmaz derecede yardımcı olurken, geliştirmeyi yavaşlatabilir.
• Araç, diğer durum yönetimi kitaplıklarından daha az olgundur ve geliştirilmiş TypeScript desteği ve tarayıcı geliştirme araçları uzantıları üzerinde çalışmalar devam etmektedir.

Toplama

Bildirime dayalı programlamanın web geliştirme topluluğundaki popülaritesi ve benimsenmesi artmaya devam ediyor.

Modern web geliştirme daha karmaşık hale gelmeye devam ederken, bildirimsel programlama yaklaşımlarını benimseyen kitaplıklar ve çerçeveler artan bir sıklıkla ortaya çıkıyor. Nedeni açık görünüyor; yazılım yazmaya yönelik daha basit, daha açıklayıcı yaklaşımların oluşturulması gerekiyor.

TypeScript gibi güçlü yazılan dillerin kullanılması, uygulama etki alanındaki varlıkların kısa ve net bir şekilde modellenmesine olanak tanır, bu da hata olasılığını ve manipüle edilmesi gereken hataya açık kontrol kodunun miktarını azaltır. Ön uçta sonlu durum makinelerini ve durum çizelgelerini benimsemek, geliştiricilerin durum geçişleri aracılığıyla bir uygulamanın iş mantığını beyan etmesine olanak tanıyarak zengin görselleştirme araçlarının geliştirilmesine olanak tanır ve geliştirici olmayanlarla yakın işbirliği fırsatını artırır.

Bunu yaptığımızda, odak noktamızı uygulamanın nasıl çalıştığına ilişkin somun ve cıvatalardan, müşterinin ihtiyaçlarına daha da fazla odaklanmamıza ve kalıcı değer yaratmamıza olanak tanıyan daha üst düzey bir görünüme kaydırıyoruz.