Hesapkurdu frontend mimari dönüşümü : Teknoloji seçimleri

Merhabalar,

Bugün sizlerle Frontend projemizdeki dönüşümü anlattığımız yazı serimize bir başlangıç yapacağız. Kullandığımız teknolojiler, build sistemlerimiz, CDN cache invalid etme, Frontend Devops ve asset versiyonlama sürecimiz bu yazı serisinde bulabileceğiniz konulardan bazıları olacaktır.

Daha önce Devops süreçlerimiz hakkında Orhun bir yazı dizisi ele almıştı. Yazı serisine buradan ulaşabilirsiniz.

Dönüşüme neden ihtiyaç duyduk?

Bu tarz büyük dönüşümler başlamak için önemli sebepler, başarıya ulaşmak için yüksek motivasyon gerektirir. Bizim nedenlerimiz ve motivasyon kaynaklarımız şu şekilde özetlenebilir;

• Biz son kullanıcı odaklı bir firmayız ve geliştirdiğimiz tüm çözümlerin önemli bir kısmı günün sonunda Frontend’e bağlanıyor.
• Her ay milyonlarca session alıyoruz. Ev kredisi, kredi kartı, kasko, trafik, dask, hesaplama araçları vb. çok farklı alanda kullanıcı deneyimi odaklı senaryoları kullanıcılarımıza sunuyoruz.
• Tüm bu alanlarda hızlı geliştirme yapabilmek, yeni ürün çıkarabilmek ve kaliteyi yüksek tutmak bizim için çok önemli.
• Bu sebepler yüzünden yazılan kodun kalitesi, verimliliği, sayfa hızları, cache kullanım verimliliği sürekli olarak geliştirmek zorunda olduğumuz hedeflerimiz olmuş durumda.
• Bu vizyonu gerçekleştirmek için frontend mimarimizin doğru kurgulanması en kritik görevimiz.

Amaçlarımıza yönelik teknoloji seçimlerimiz

Teknoloji seçimi zor ve stresli bir dönem olarak ifade edilebilir. İhtiyaçların belirlenmesi ve bu doğrultuda doğru seçimler yapmak, seçimler sırasında hype teknolojilerin göz boyamasına izin vermemesini sağlamak ( özellikle javascript ) orta ve uzun vade için kritik kararlar. Bununla beraber ihtiyacınız olan bir işi gerçekleştirmek için genellikle birden fazla opsiyonunuz bulunur. Yola başlarken bizim de bu konuda kafamızda yer alan büyük sorular vardı. Bu sorunu çözüme kavuşturmak için bir ihtiyaç listesi hazırladık.

Hedeflediğimiz çıktıya ait görev listesi aşağıdaki gibi gerçekleşti;

• Kaynak kodumuz optimal bir şekilde derlenebilmeli,
• Daha önce büyük zorluklarla oluşturduğumuz bizim için önemli olan critical path css oluşturmayı verimli ve hızlı bir otomasyona bağlamalı,
• Kod kalitemizi korumak için çeşitli linter vb. araçlara eklenebilmeli,
• Frontend projesinde oluşturduğumuz yeni komponentler dokümante edilebilmeli,
• Unit test yazmaya imkan vermeli,
• Test, Production gibi ortamlar için environment bazlı yönetimlere destek vermeli.
• Deploy ardından tarayıcı önbelliğine yakalanmamak için bir versiyonlama sistemine entegre olmalı.
• Ortam, işletim sistemi ve Backend projesinden bağımsız Frontend projesi kendi başına yaşayabilmeli.

Bu görev listesinin ardından kullanmaya karar verdiğimiz temel araçlar ve teknojiler aşağıdaki gibi oldu.

• Yarn : Paket Yöneticisi
• Gulp : Task Runner
• Webpack : Bundle Tool
• Jest : Unit Test Tool
• Astrum : Pattern Library
• Eslint, SassLint : Linter araçları
• Jenkins : Devops Tool
• Babel, Postcss vb.
• Geliştirme ortamı: Nerede istersek 😍. VS Code, WebStorm, Notepad vb.

Yaşasın tam bağımsız Frontend

En büyük mottomuz Frontendi tamamen bağımsız bir hale getirmek. Bunu yüzde yüz çalışır hale getirmek için biraz daha zamana ihtiyacımız var. Bu değişime ön ayak olmak için ise Frontend projemizi Backend projemizden sökmeye karar verdik. Artık assetlerimizi bağımsız bir şekilde üretebiliyoruz. Bir entegrasyon katmanımız mevcut. ASP .Net MVC üzerinde yaşayan bu katmanın tek görevi Frontend projemizde üretilen assetleri çağırarak arayüzlerimizi çizmek.

Şuna emin olabilirsiniz ki ilk adım olarak yaptığımız bu proje ayırma operasyonu bile Frontend geliştirme ekibine büyük bir alan açtı. Artık kendi kararlarımızı kendimiz verebilir bir haldeyiz. Build sistemlerimiz Visual Studio üzerinde çalışan ve bizce yeterli olmayan IDE eklentilerine mahkum değiller.

Visual Studio çok başarılı bir IDE. Fakat asset üretmek isteyeceğimiz zamanlarda kullanmayı tercih etmeyeceğimiz kadar hantal bir organizmaydı. Artık bu ağırlığı omuzlarımızdan attık. Daha verimli ve hızlı bir şekilde yeni komponentler, yeni layoutlar ortaya çıkartabiliyoruz.

Bağımlılıkları kördüğüm olmadan yönetin

Genellikle dünyayı yeniden keşfetmemek için bazı ihtiyaçlarımızı daha önce yardımsever opensource gönüllülerinin paylaşımlarını kullanarak gideririz. Kullanılan bu paketleri tek bir yerden yönetmenin en kolay yolu ise paket yöneticisi kullanmaktır.

Kişisel olarak bir Bower severdim. Bower deprecate olduktan sonra Yarn kullanmamızı biz severlerine öneren mesajını siz de görmüş olmalısınız. Biz de dönüşüm projemizde Yarn’ı kullanmayı tercih ettik. Şu ana kadar bizi herhangi bir şekilde yarı yolda bırakmadı. Paketleri olması gerektiği gibi patlatmadan yönetmeyi başarabilen bir araç olarak bizimle yola devam etmekte.

Kullandığımız node modüllerini bir kara deliğe dönüştürmeden bu işi keyifli bir hale getiriyor. Kullandığımız bir uygulamaya beklediğimiz bir özellik gelmişse hiç düşünmeden upgrade yapabiliyoruz.

Ayrıca kullandığımız vendorleri paketler halinde indirerek sadece gerekli modülleri kodumuzdan çağırıyoruz. Böylece son derece yüksek bir kod optimizasyonu oluşturabiliyoruz.

Build sistemi : Webpack + Gulp’ın gücü

Doğdukları gün amaçları farklı olan bu 2 araç günümüzde birçok konuda birbirini ikame edebilmekte. Biz de öncelikli olarak tek bir seçim yaparak ilerlemek istedik. Ardından yaptığımız çalışmalar ve ihtiyaçlarımız doğrultusunda bu iki güçlü aracı entegre bir şekilde kullanmaya karar verdik.

Planlarımız gereği kullanmak istediğimiz task ağırlıklı pipelinelarımız mevcuttu. Statik assetler üreteceğimiz için bu görevleri Gulp’a emanet ettik. Gulp bizim için icon font üretiyor, critical path css oluşturuyor, image dosyalarımızı optimize ediyor, html lerimizi derleyip W3C validasyonu gerçekleştiriyor, scss linter uygulayıp bu dosyaları derliyor vb. Bunun yanında Webpack ile javascript ağırlık bundle işlemlerimizi yönetiyoruz.

ES6 kulanabilmek için Babel’i pipelinemıza entegre ettik. Böylece javascript kodlarımızı crossbrowser uyumlu bir şekilde derleyebilmeye başladık. Benzer bir işlemi SCSS tarafında Postcss ile gerçekleştirdik. Postcss’in özellikle Autoprefixer plugini çok faydalandığımız bir özellik oldu. Böylece tarayıcı prefixlerini kaynak kodumuza eklemekten kurtulduk. Desteklemek istediğimiz tarayıcı versiyonlarını config dosyasından düzenleyerek bu ve benzeri işlemleri otomatize bir hale getirdik.

Kod kalitemizi korumak için SCSS ve Javascript linterları geliştirme ortamımıza ekledik. Linterlarımızı geliştirme hızımızı azaltmayacak şekilde ama oldukça katı kurallar kullanarak biçimlendirdik. Geliştirmenin başlarında linterlar ekibimizin hızını belirli bir ölçüde yavaşlattı. Bu kabul edilmesi gereken ve öngördüğümüz bir gerçekti. Bir haftadan sonra ise artık herkes bu yazım standartlarına alışmıştı.

SCSS için sass-lint aracını kullandık. Indentation kısıtlamaları, !important yasaklaması gibi kurallar koyduk. Bu kurallar ihlal edilmeye çalışılırsa kod derlenmeyi bırakıyor. Böylece kaba kuvvetlede olsa kurallarımızı bütün ekibe empoze etmiş olduk. Aynı yaklaşımı çok daha katı sayılabilecek bir şekilde javascript tarafında gerçekleştirdik. Linter kurallarımızda Airbnb kurallarını referans aldık. Birkaç küçük değişikle -end of file kuralını kapatmak gibi- katı bir şekilde uygulamaya başladık. Kurallara uymayan kod derlenemiyor. Bu kurallar sayesinde kimin yazdığı farketmeksizin kodlarımız belirli bir patternle yazılmaya başlandı. Pattern dışındaki kod kalitesini korumak için Pull Request ler zaten hali hazırda kullandığımız bir yöntemdi. Yeni kurallarımız ile Pull Requestler approvelanmadan önce daha kapsamlı şekilde incelenmeye başlandı.

İpucu : Başlangıçta environment değişkenleri dışında dev ve prod ortamı konfigürasyonlarımız tamamen aynı idi. Fakat bir süre sonra bu stratejinin bizi oldukça yavaşlattığını farkettik. Bunu iyileştirmek için geliştirme ortamımızdan minify, transpile gibi ekstra zaman alacak işlemleri çıkardık. Bu adımlar artık sadece test ve productiona çıkacak koda uygulanıyor. Şu an daha stabil ve hızlı tepki veren bir geliştirme ortamına sahibiz.

Yaşayan dokümantasyon

Daha önceki büyük şikayetlerimizden birisi gelen taleplerde yer alan komponentlerin daha önce yapılıp yapılmadığını bilememekti. Bu birçok sıkıntıyı beraberinde getiriyor. Ürün ekipleri istedikleri bir özellik hali hazırda bir yerlerde var mı sorusuna cevap bulamıyorlardı. Aynı sorun developer ekibi içinde geçerli idi. Bu da sık sık aynı işlevlere sahip komponentleri tekrar tekrar yazılmasına sebep oluyordu.

Bu probleme çözüm getirmek için bir dokümantasyona ihtiyacımız vardı. Buradaki ihtiyacımızı çözerken bir adım ileri gitmeye karar verdik. Bize başlangıçta developer maliyeti olarak bir ekstrası olacaktı fakat kodumuz ile beraber yaşayan bir ortam hazırlayabilirsek bu sorunu kökünden çözebilirdik. Seçeneklerden birisi kendimizin böyle bir altyapı yazmasıydı. Fakat bu bütçemizi aşacak bir efor istiyordu. Hazır araçlara yönelme ihtiyacı duyduk. Astrum bu konuda bize cevap verdi. Artık bir kere dokümantasyon listemize eklenen bir komponentimiz css ve javascript değişikliklerinde kendini koda göre adapte edebiliyor. Böylece yaşayan, nefes alan, organik bir style guide’a sahip olmuş olduk. Zaman zaman bakım maliyeti gerektirse bile bu maliyetin çok daha fazlasını efor bazında bize geri veren bir çalışma ortaya çıktı. Ekip olarak iş planlama ve geliştirme aşamasında faydalanmaya başladığımız bir başucu kaynağı haline geldi. Bizi ise tekrardan yazılan aynı işlevi gören modüllerin karmaşasından kurtarmış oldu. Konu hakkında daha detaylı yazıya Hakan’ın postundan ulaşabilirsiniz.

Bu yazımızda geliştirme ortamımızda ortaya koyduğumuz değişikleri ele aldık. Yazı serimizin devamında geliştirme ortamı ve diğer teknojiler ile production sürecine kodumuzu nasıl taşıdığımızı inceleyeceğiz.

Bu yazıda bahsettiğimiz konuların çıktılarını canlı yayında görmek için kredi hesaplama sayfamıza göz atabilirsiniz.

Bu yazı veya herhangi başka bir içerik hakkında sormak istediğiniz soruları ve konuşmayı istediklerinizi dev@hesapkurdu.com mail adresinden bize iletebilirsiniz.

Yeniden görüşmek üzere.