Turknet Transformers Mühendislik Ekibinde bir mikro hizmet dönüşümünün hikayesi — teknik perspektif
Merhabalar ,
Daha önce business perspektifinden anlatmaya çalıştığım dönüşüm sürecinin bu sefer teknik taraftan ele almayı ve yaşadığımız deneyimi anlatmak istiyorum.
First Principle
Bir takıma girdiğimde genelde büyük resmi yukarıdan aşağıya göre anlamak isterim. Daha öncede dediğim gibi TDD’de ki top-down yaklaşımını kullanırım.
Yukarıda ki görselde de gördüğünüz üzere yazılım geliştirme süreçleri en temelde matematiksel teorilerden başlayarak bilgisiyar bilimlerinin temelini oluşturur. Bizler ise zaman içerisinde mesleği bu temel bilimler üzerine inşa edilen sistem ve araçlardan öğrendik.
En yukarıda app olması elbette tesadüf değil ama son yıllarda domain’e hakim olmak o kadar çok zorlaştı ki bir app’i meydana getiren bileşenlere hakim olmadan aslında temel quantumu görmek veya anlamak çok mümkün değil kanaatindeyim.
Bu bağlamda app’i anlamamızı sağlayan bir düzine araç var. Son bir kaç yılımı bu araçları öğrenmeye ayırdım ve zaman içinde de kendimce bu aletleri kullanarak business value yaratan takımların bu değeri ürettikleri app/app’leri anlamaya çalışıyorum.
Bir önceki makalemde de anlattığım üzere transformers ekibi olarak sahip olduğumuz spider web architecture’ı anlamak için kullandığım/kullandığımız bir kaç alet var.
Architecture Quantum
Distributed Development Stack
- Hosted PaaS
- Internal Services
Hosted Paas olarak Turknet’te cloud ekibinin bize sunduğu bir altyapı vardır. Bassi , Euler , Gaus adını verdikleri k8s cluster ortamları vardı. Bunlar self hosted,bakımı pahalı ve kaynak yönetimi zordu.
Zamanla cloud ekibimiz open-shift platformlarına bizi geçirdiler.Bu k8s cluster, bir managed servis idi. Tüm servislerimizi sırayla bu yeni platforma taşımaya başladık. Yukarıda da görselini koyduğum üzere app, altında yatan bir dizi tool ile kontrol edilirken bu app’lerin hayatlarını idame ettirdikleri platform open-shift idi.
Dev ekibi olarak bu platformun bir local ortamı olsaydı aslında çok daha rahat bir şekilde hem büyük resmi görecektik hem de debug edebileceğimiz bir ortam olacaktı. Aynı zamanda bu tip platformlar cloud native based olduğu için üzerine cloud native app’ler de rahatlıkla kurulabiliyordu.
Docker
Örnek olarak,localde dockerized ettiğimiz app’ler aslında bu applerin deploy edildiği ortamları simule edebileceğimiz anlamına geliyordu ve k8s based sistemlerin mini version’larını localde kullanabilirdik.
Tilt
Tilt,tam da k8s based sistemleri simule edebileceğimiz bir araç idi. Skaffold ,Devbox gibi containerized olan bir çok araç var ama bence tilt en yalın olanıydı ve docker-compose file’ını load edip direkt tilt’e adapte edebiliyordu.
Bir önceki makalede de bahsettiğim üzere sistem mimarisi bu şekilde idi.
Tilt ile nasıl göründüğü aşağıda ki gibidir,
Görüldüğü üzere miro çizimi olan bir mimariyi ete kemiğe bürünmüş halde görebiliyorsunuz. Çizimde ki katmalara göre tagleyebiliyor, top-down olarak sıralayabiliyor, filter ile istenen servisin direkt portuna ve loglarına ulaşabiliyorsunuz.
Örnek olarak ticket key’ine göre search ettiğinizde ticket süreçlerinin aktığı mikro servisleri görebiliyorsunuz.
- Debugging
- Log monitoring
- Node port
gibi tanımları görerek app’i bu tool ile çok rahat bir şekilde yönetebiliyorsunuz. Bu da anlamanızı daha da kolaylaştırıyor.
İlk başta ki görselde belirtildiği gibi cloud-infraya inme şansınız yok bir backend-developer olarak ama platformu simule eden tool’lar ile app’i anlayabilirsiniz.
Hosted Paas olarak kullanılan open shift üzerinde, Internal Services olarak kullanılan k8s plaformlarını localde simule etmemizi sağlayan tilt idi.
Buna mikro ekonomi deniyor. Yani Neal Ford’un Building Evoluation Architectures da dediği quantum, app’ler için domain ise bu cloud native platformlar söz konusu olduğunda bizim için tilt idi :)
Distributed System Fallacies
Dağıtık sistemler bilindiği üzere görselde göründüğü gibi bir çok yanılsama ile gelir. Yani yemeği beğenmediğinizde masadan kalkabileceğiniz öğle yemeği molası değildir. Bir kere girdiğinizde nasıl bir problem space’inin içinde olduğunuzu anlamanız gerekmektedir.
Açık konuşmak gerekirse işe alım süreçlerinde buna çok dikkat etmek lazım . Çünkü geliştireceğiniz ürünün mimarisi nasıl bir profil ile çalışacağınıza kadar düşünmeniz gereken detayları size zorunlu kılıyor .
Bu bağlamda yukarıda anlattığım development stack bir squad ekibinin ürününü anlamanız için gereken bir takım yöntemler sunabilir. Fakat geliştirmeye başladığınızda bir dizi problemleri ve çözümlerini düşünmeniz gerekmektedir.
Bir ürün, önce bir fikir ve bu fikri meydana getirecek olan bir dizi backlog item’dan oluşmaktadır. Ve bir engineer’ın işi hiç de kolay değildir. Yukarıda mevcut ürünü anlamak için bir takım tool’lar sunduk peki geliştirmeye başlamanız için nasıl bir stack gereklidir ?
Gördüğünüz gibi ürün fikir ve backlog item’lardan oluşuyor ise bunların birleştiği yer ise core business logic’dir.
Yani ürünün en kritik fikri altyapısı domain’in kalbinde yer alır. Yalnız bir engineer rolü ne yazık ki sadece domain geliştirme olmaz. Ürünü ortaya çıkaran ,üretim ortamlarına deploy etmenizi sağlayan ve monitor etmenizi sağlayan bir dizi katman vardır.
Tıpkı son dönemlerde haberlerde dolaşan milli savunma projesi “Çelik Kubbe” gibi. https://www.bbc.com/turkce/articles/cqjlrd98py5o
Core Business ,Domain ise diğer tüm katmanlar ürünün çalışmasını, yönetilmesini ve korunmasını sağlayan katmanlardır.
Bu problemlerin hepsini çözebildiğiniz ve yönetebildiğiniz bir şase gereklidir. Buna microservice-chassis denir.
Microservice chassis’ler şunları sunarlar;
Bir engineer’ın ikinci aleti ise kullanacağı application framework’tur. Çünkü toollar, platformlar üzerinde etkin ise bir app için en önemli tool application frameworklerdir. Bizim stack’imiz jvm olduğuna göre kullandığımız application fx ise Spring Boot idi.
Time-to-market için seçeceğiniz fx , yukarıda ki functional ve non-functional problemlerin önemli bir kısmını çözmesi gerekir.
Özetle
- minikube -> platform
- docker → tool
- tilt → tool
- spring boot → developer template
- microservices -> app
ile bottom-up olarak bir ürün çok rahat bir şekilde core business dışında ki tüm cross cutting’ler ignore edilerek geliştirilmeye başlanabilir.
Örnek olarak framework’un sundugu actuator metric ile oluşturduğumuz monitoring dashboard,
Metric
Ek olarak iyi bir developer template seçmek ürünün scale aşamasında düşünmeniz gereken bir çok konu hakkında size yardımcı olur. Çünkü erken aşamada ürün için genellikle core business’a odaklanırsınız ama ölçek aşamasına yavaş yavaş tırmanmaya başladığınızda tüm bakış açınız değişir. Aslında değiştirmek zorunda kalırsınız :)
Cache managementtan ,datayı nasıl tutacağına kadar sistematik bir dizi aksiyonlar almanız gereken evreye geçersiniz. Peki ya kod bunun neresinde ?
Spring boot,hızlı ürün geliştirmeye ek olarak ölçek aşamasına geldiğinizde de size bir takım out-of-box araç setleri sunar.
- cache
- tx management
- logging
- monitoring ki metric başlığında bir örneğini gösterdim
gibi bir çok seçeneği high level configurable adı altında yıllar içinde evrilerek community desteğiyle büyümüştür. Ve dünyada ki istatistiklere de baktığımızda en çok tercih edilen developer template olmuştur.
Bu seçimin diğer bir etkisi ise work & life balance’dır elbette :)
Çünkü engineering sıfırdan bir sistem inşa etmek değil onu optimize ederek iyileştirme sanatıdır. Replatforming, bu optimizasyonun artık mümkün olmadığı evrede devreye girer ve business agility olarak organizasyonun taleplerini time-to-market’a yetiştirebilme hızı ile doğru orantılı bir sistem inşa etmek zorunda olduğunuz bir konuma getirir sizi.
Eğer replatforming yapma kararı aldıysa organizasyon ,bunu sizin ve ekibinizin work & balance’sınıza uygun olacak şekilde yönlendirmek sizin elinizdedir.
Bunun içinde komple düşünce sisteminizin değişmesi gerekir. Düşünce sisteminizin değişmesi içinde codebase’i çok iyi hıfsetmeniz ,metricler ile hangi konularda
- tech depth
- high & low risk
- knowladge distribution
- offboarding simulation gibi hangi noktalarda app’in gelişmesi gereken noktaları var anlamanız gerekir.
Code Quantum
Buraya kadar olan kısım aslında first principle olarak bahsettiğim temel bilimleri kullarak keşfetmeye çalıştığımız mimariyi anlamak içindi.Bundan sonra ise anlamamız gereken kısım codebase.
Codebase kavramı çok kullanılır,herkesin elinin altındadır ve bir business’ı anlamak veya bir feature’ı düşünmek için ilk kontrol edilen yer kodun kendisidir. Aslında çok da önemine vakıf olamasak da bir şirketi ayakta tutan sadece codebasedir. Şirket, codebase’inden ibarettir. Codebase’i ve oluşturduğu business bağımlılıklarını anlayan sistemi çözer.
Benim de uzun sürelerden beri üzerinde düşünmeye çalıştığım kısım buydu. Bir de mikroservisler evrenine girdiğimiz ve eskisi gibi bir monolith’e de sahip olmadığımız dünyada dağıtık sistemler ,
- nasıl anlaşılır ?
- incelemeye nereden başlanılır ?
- takımın girdi ve çıktıları nasıl takip edilir ?
gibi sorulara cevap aramaya çalışıyordum.
Understanding Large Codebases
Piyasada aşağıda linklerini bıraktığım open source araçlar vardı. Ama ya çok eskiydi ya da eclipse gibi bizim kullanmadığımız ide entegresyon destekleri vardı. Yani aktif kullandığımız intelliJ için geçerli değildi.
Ama bir önceki makalemizde de anlattığım üzere ben yine vizyonu anlamış benzer işi gören ve modern tool’lar bakmaya başlamıştım.
Tabi bu bağlamda software systems as cities metaforunu benimseyen araştırma tezine rastlamıştım ama ihtiyacım daha da derine,codebase seviyesine kadar girip detayları anlamaktı.
Bu metaforu kullanan tool , codebase’i bir şehir metaforu olarak gösteriyor ama bu araştırma konusunda referans verilen aslında bunu daha da akademik olarak kaleme aldıkları başka bir kitap buldum.
https://www.amazon.com/Object-Oriented-Metrics-Practice-Software-Characterize/dp/3642063748
Bu kitap aslında piyasada ki bir çok tool’un çıkmasına hatta bunu çok daha modern olarak ele alınmasına sebep oldukları kanaatindeyim. Çünkü ciddi derece detaylı sosyal ve organizasyonel bütünlüğü ve aralarında ki ilişkileri gösterecek metrikleri sunan aletler var.
- codescene
- keypup
- linearb
gibi bir çok priced araçlar var ama free account ile bir kaç deneme yapıp istediğiniz metricleri genel olarak alıp,codebase ve takım hakkında genel bilgileri sahip olduktan sonra kapatabileceğiniz araçlar bunlar. Yani devamlı kullanmanıza gerek yok çünkü ciddi fiyatları var.
İncelediğim her araç birbirinden güzel metrikler sunmuştu.
- keypup daha çok dora metriklerini odaklanıyordu. Engineering pattern analizi adı verilen ekranları vardı ve bir engineer’ın haftasını nasıl geçirdiğini,ne kadar verimli kullandığını vs ölçüyordu. Buna ihtiyacımız çok yoktu çünkü kabiliyeti ölçmek için Hakan Çelebi ile kafa patlattığımızda buna benzer takımdan ziyade takım içinde ki üyenin verimliliğini ölçmek için teknikler geliştirmiştik. Hakan abi , jira’yı hatmetmiş ve şirket için kullanılacak olan developer ölçüm metric dashboard’unu geliştirmişti. Bitbucket’ı bile bağlamıştı.
- linearb,aslında Hakan abi’nin aletine benzer bir özellik seti sunuyor ,dora metriclerine ek olarak ,pr change rate’lerini gösteren,bir pr’ın ne kadar codebase üzerinde değişikliğe sebep olduğunu ,developer geliştirme hızları gibi bir çok metriği içeriyordu.
- codescene aracına baktığımda ,yukarıda ki linkini verdiğim kitabın içini karıştırdığımda gördüğüm ve yine yukarıda belirttiğim üzere modası geçmiş araçların özelliklerini de içeren bir çok kaliteli ölçüm metricleri sunuyor üstelik görselleştiriyordu.
Tabi bu aletler çok pahalı ama free account ile mevcut codebase’i hatmetmek için direkt kullanmaya başladım. Sunduğu detaylar harikaydı.
Bunları 4 ana başlıkta toplayacak olursak,
- code health
- knowledge distribution
- team code alignement
- delivery
Ama sadece code health konusunda kısa bilgi vereceğim.
Code Health
Bu metric, kodun hotspot noktalarını ,genel proje kapsamında code average count’larını ve kodun kötü performans gösteren kısımlarını görünür kılıyordu. Bunu sonar cloud’da yapıyor diyebilirsiniz ama codescene,x-ray adı verdiği sistem ile çok daha detay analiz çıkartıp refactoring modul,component ve architecture anlamında nereden başlayacağınıza kadar bir çok konuda bize bilgi veriyordu.
Örnek olarak,
- internal change coupling
- structural recommendations
- change frequency distribution
gibi codebase’e ait daha derin bilgiler sunabiliyordu.
Çok basit bir as-is ve to-be ticket service codebase’ini ele alacak olursak,
As-Is
Bir yıl içinde ufak da olsa healthy için iyileşme olduğu görünmektedir.
1k line of code için 5.5k ws (weight sum )yani ağırlık toplamı olduğu anlamına gelir . Algoritmalarda bu ,alan veya zaman olduğunu belirtmek için kullanıldığını düşünürsek burada alan veya zaman bir geliştiricinin beyni anlamına gelmektedir. O yüzden normal şartlar altında normal karşılanan tech depth aslında çilesini çeken için hiç de kolay değildir :)
Bir ticket controller’ın değişim etkisinin görüldüğü üzere 4 file’a hit ettiği görülmektedir. Yani bu file’lardan birine dokunduğunuzda olası 4 kombinasyonlu case başınıza gelebilir demektir.
To-BE
Bu görsellerde ise as-is ‘e göre nispeten healthy oranı daha iyi gözükmektedir. Ama Complexity yine yazılan koddan çok daha fazladır. Görüldüğü üzere etkili bir denge çıkarmak bir insan beyni için hiçte kolay değildir. Co-pilot gibi tool’lara olan meyilinde sebebi aslında budur. Çünkü motivasyon ile çözülecek durumlar değildir bu tip dengeleri yönetmek.
Teoride bir agile developer’ın strateji ve teknik derinliğini ( ki buna product engineering diyoruz) bir dengede tutması gerekir. Bu da hiç sanıldığı kadar kolay bir iş değildir. Bu coupling görselinde Unittest’in %40 bağımlılığını görüyoruz. Yani ani bir değişiklikte testin patlaması ile olası complexity’nin getirdiği yükün önüne geçilmesi beklenmektedir. Bu oran ne kadar artarsa o kadar complexty ile başa çıkılacağı anlamına gelmektedir.
O yüzden tech depth normalleşmesi gereken değil aksine korkulması gereken bir faktördür. Time-to-market ile work-life balance arasında ki görünmeyen denge işte burasıdır :)
Söz konusu business agility olduğunda bu değerlere hiç bir zaman bel bağlanılmaz ve durum bir anda business value üretmek için borç bırakılarak as-is’den daha vahim hale gelebilir :) Burada ki konu aslında sürekli refactoring edilmesi,sistemin sürekli bakımının yapılması,bırakılan borçların temizlenmeden devam edilemeyeceği,edilsede işlerin bir süre sonra yine sarpa saracağını ekip olarak bilmek ve bilincinin kazanılmasının domain takımları olarak sağlanmasına öncülük etmek olmalıdır.
Özetle, time-to-market ‘ın göz dolduran bir kavram olması direkt rekabet ve karlılık gündeme geldiği içindir ama yaratılan her bağımlılık altından kalkılmasının çok zor olduğu bir complexity yaratır. Super sonic beyne sahip olamadığımıza göre yaratılmaması da mümkün değildir. Bu yüzden mikroservisler efor,bakım,dağıtım,organizasyonel work load olarak sevimsiz gelsede doğası gereği bağımlılığın istensede yapılamayacağı varsayıldığından şirketlerin gündemine oturmuş durumdadır.
Çünkü ayrı repolarda ki codebase’e nasıl bağımlılık yaratılabilir ?
İşte sorunda burada başlar. Eğer distributed sistemlerin gerçekliği anlaşılmaz ise distributed monolith’e doğru bir meyile gidilir. Her projenin,
- servis’i
- consumer’ı
- job’ı
- servisler arası state machine’leri vs varsa artık geri dönülmez yola girilmiş demektir :)
Ama yine de distributed system yanılsamalarından kendimizi sıyırabilirsek bağımlılıkları yönetebiliriz. Sayıların gerçeği. Düzen bilginin azlığıdır.
Kod kafandan büyükse mikroservis değildir. — James Lewis
As-is — To-be dependecy graph
Solda ki gibi bir monolith’iniz varsa ne kadar squad kurarsanız kurun,herkesin ayağı birbirine değecektir. Ve kontrol edilmesi review rituelleri ile yapılamayacak kadar imkansız hale gelecektir.
Dikkat ederseniz, solda ki görselde ticket domain’i bulmak bile çok zor :)
Sağda ki graph ise ,solda ki görsele nispet ile sadece bir bounded context içini cover ettiğinden doğası gereği explosion zone’u çok küçük olmak zorundadır. Ama yine de bu kadar dependecy yaratmamak gerekir.
Mikroservis,organizasyonel bir karar olmasına karşın servislerin içi ise mimari bir karar olmalıdır. Bizim de şuan elimizde ki mikroservislerin iç mimarisi service layer based çalışıyor ama niyetimiz zamanla hexagonal based hale getirmek.
Architecture is abstract until operationalized
Sürekli Teslimat ve DevOps hareketi, bir mimarinin uygulanması ve güncel tutulması için gereken çabaların göz ardı edilmesinin getirdiği tehlikeleri gözler önüne serdi. Mimarinin modellenmesinde ve bu çabaların kaydedilmesinde bir sakınca yok ama uygulama sadece ilk adımdır. Mimari, işlevsel hale getirilene kadar soyut bir kavramdır.
Başka bir deyişle, herhangi bir mimarinin uzun vadeli sürdürülebilirliğini gerçekten değerlendiremezsiniz; onu sadece uygulamakla kalmayıp, aynı zamanda güncelleyip, olağandışı durumlara dayanacak şekilde de güçlendirmediğiniz sürece. — Neal Ford
Bu yüzden yukarıda verdiğim örnek araçlardan öğrenmek istediğim şey ,anlık bir görüntü yerine her sprint sonunda mimariye verdiğimiz şeklin ne olduğuydu :)
Çünkü Clean Architecture’da Uncle Bob’un “mimari bir shape’dir ve ekip olarak nasıl bir desene sahip olduğunuzu bilmelisiniz. Başarılı bir tasarımı da trade-off’u da hatta tech dept’i de ekip olarak sahiplenmelisiniz” demesi boşa değildi. Her sprint sonu ürünün mimarisine kattığımız veya azalttığımız değeri bilmeliydik. Bu tip araçları ara ara kullanmak istememin sebebi de buydu. Ama genel olarak en etkilisi software systems as cities metaforunu işleten eagle aracımdı :)
Yukarıda ki araçlar ise daha detaylı bir görüntü almamı sağlıyordu.
Mimari yapıların operasyonel yönlerini düşünmeden daha sağlam sistemler inşa edemezsiniz; bu, mikro servis mimarilerinin hedeflerinden biridir. — Neal Ford
Mikroservislere ihtiyaç olan genel tanım sanırım buydu. Bu yüzden codebase’i iyi anlamalı ,seems’leri net bir şekilde görmeliydik ki hybrid bir şekilde yeni data modelimiz üzerine oluşturduğumuz miroservice ve micro db’lerimize migration yapabilelim.
Bu migration’ın nasıl olduğunu görebilmek için genel olarak As-is ve To-be karşılastırması yapacak olursak ;
As-is Language Distribution
As-is Database Distribution
As-is Message Brokers
Burada ufak bir bilgi vermek gerekirse,ölçek aşaması bir takımın tek başına üstesinden geleceği bir konu değildir. 3 aşamalı zorlu bir denge gözetmeniz gerekir.
Takım olarak sadece tech stack’e karar kılabilirsiniz ama içinde bulunduğunuz organizasyonun kısıtlarına,mevcut bilgisine göre en uygun olan stack’lere ve knowledge distribution’larına bakmanız gerekmektedir.
Infra ,db ve devops’a siz karar veremezsiniz. Takımın backloguna ve önceliklerine siz tek başınıza karar veremezsiniz. Şimdiden siyaset yapmayı öğrenseniz çok iyi olur :)
Aşağıda, yukarıda ki 3 component’e göre verilmiş kararlar yer alıyor.
To-be Language Distribution
To-be Database Distribution
To-be Message Broker Distribution
Replatforming Strategy
- Greenfield approach — new implementation
- Brownfield approach — system conversion
- Hybrid approach — selective data transition
Hybrid approach — selective data transition
Hibrit bir yaklaşım,sisteminizi yeniden tasarlamak istediğiniz yönleri seçebilir, mevcut sisteminizin işe yarayan kısımlarını korurken verilerinizi yeni sisteme temizleyip taşıyabilirsiniz.
Hibrit uygulama yaklaşımının dezavantajı, işi yapmak ve göç planlarınızın bir parçası olan Greenfield ve Brownfield parçalarını ayıklamak için bir üçüncü taraf araca ihtiyacınız olmasıdır.
Bu yaklaşım CDC (Change Data Capture) iken ,kullandığımız araç ise debeizum idi.
Onehub , hybrid model yaklaşımı ile replatform edilmiştir.
Yukarıda top-down modelinden bahsetmiştim. Bir ürünü meydana getiren tüm parçaların ayrı bir component olduğu düşünüldüğünde core business’ın kalbi olan kısımların test edilmesi elzemdir.
Elbette squad olarak unit testler yazıyoruz ama sistem, birim testlerinin toplamından daha büyük olduğu için aslında bu componentlerin arasında ki yapıların test edilmesi gerekmektedir. Henüz olgunlaşmamış olsak da bir setup kurduk ve devamında iyileştirmeyi düşündüğümüz BDD style integration test planımız var.
TestContainers & Cucumber
Görselde görebileceğiniz üzere bir spring boot test, app’i boot ederken sırasıyla cucumber context class’ına bağlı alt sistemler de boot ediliyor. Yani bir sistemi meydana getiren alt sistemlerdir. Ve alt sistemlerden emin olduğunuzda aslında sistemin bütününün sağlıklı çalışmasından da emin olabilirsiniz.
Örnek bir kaç senaryo verecek olursak,
gibi cucumber test raporunda bulunan bazı senaryoları görebilirsiniz.
Bir cucumber feature set’i çalıştırıldığında aslında canlı bir ortamın kopyası ayağa kalktığı için arasında tüm db migrationlar,message brokerlar,servisler ve diger alt parcaların hepsi build edilmiş oluyor.
Ve tüm bu parçalar gerçek senaryolara göre özelleştirilebilir. Ama tabi henüz olgun değiliz . Planımız bu süreci bir rituel haline getirmek ve definition of done kapsamına sokmak.
Bir özet yapacak olursak makalenin başında belirtiğim piramidin, altından başlayarak,
- cloud — infra
- platform
- tool
- ve son olarak app
katmanına çıkana kadar transformers’ın way of working’lerine şahit oldunuz.
Vermeye çalıştığım mesaj,bunun sizin yolculuğunuz olduğudur ve her firmada sırasının değişkenlik gösterebildiğidir. Deneyimlerime göre spectur’umun 2 ucu vardır ;
Architecture ve Codebase Quantum — Bilal islam :)
Son olarak
Yine bir önce ki yazıda da olduğu gibi transformers ekibine bu özverili çalışmalarından dolayı sonsuz teşekkürlerimi borç bilirim.
Onehub be with you 🙂
Tech Stack
https://stackshare.io/turknet-transformers-team/transformers
Kaynaklar
https://www.youtube.com/watch?v=UsBTJFZhp-Y&t=4s
https://courses.cs.vt.edu/cs5204/fall09-kafura/Presentations/EventOrdering.pdf
