Bu yazı Summit’den katıldığım sunumlara ait kendime çıkardığım notları içerir.
Yazılım Tasarımında Mimari Bir Bakış Açısı Geliştirmek
- Yazılım mimarisinde düşünmeye teknolojiden değil, kavramsal olarak bakılmalıdır. Teknoloji ve imkanlarını bilmek gerekir. Teknolojiyi bilerek sorunlarımızın farkına varabiliriz.
- Her gereksinim için ayrı kod yazılırsa sistem arap saçına dönebilir.
- SaaS geliştirmek için tavsiye edilen kaynak: 12factor.net
“İyi mimarinin pahalı olduğunu düşünüyorsanız, bir de kötü olanını deneyin.” Brian Foote & Joseph Yoder
Microservis Mimarisi
Monolitic Uygulamanın avantajları:
- Tüm özelliklerin bir yapıda olması ve bu yapı üzerinde olayların handle edilmesi. Bu yüzden startup şirketler tarafından tercih edilebilir.
Monolitic Uygulamanın dezavantajları:
- difficult to scale, operational difficulty (hatayı bulmak zor, fail olan bir uygulama başka sıkıntı yaşatabilir), to much software coupling(ayrı yazılımcıların datayı aynı library den alması), bakımı ve geliştirmesi zor, kod karışıklığı oluşabilir, yazılımın ve production hızı düşmekte, projeden developer ın ayrılması ya da yeni bir developer dahil olması duurmunda uyum süresinin fazla olması.
- Şirket büyüyünce monolitic yapı anti-pattern oluşturabilir.
Microservis:
- Her servis uygulamanın bir özelliğini taşır. Bu servisler network üzerinden birbiriyle iletişime geçer.
- Bir servis diğer servisten bağımsız olarak update edilir, başka bir servise bağlılığı bulunmaz.
- İlgili davranışları içeren servisler bir arada, davranışları farklı olan servisler uzakta tutulabilir.
- Gereklilikleri: Backward & forward compatibility, servisin diğer servis tarafından kullanımı kolay olmalı, her servis için internal logic bağımsız olmalı.
- İletişim Stilleri: Request/Response , Asekron/Sekron, Event-driven(bu stil single point of failure oranını azaltır), Choreography, Orchestration
- Mikroservis modelini, business concept doğrultusunda yapmak gerekir.
StencilJS ile Geleceğin Web Arayüz Bileşenleri
- Ionic ekibi tarafından geliştirilen compiler’dır. Bir frawework değildir.
- “Web component” temeline dayanır. Yani kendi componentlerinizi yazarak farklı teknoljilere uygulanabilir.
- Birçok browser tarafından destekleniyor. Fakat bazı browser lar polyfill isteyebilir. (polyfill: browser ın desteklemediği özellik yüklenebilir fakat bu durumda daha yavaş çalışır)
- Immutable objeler kullanılmalı (öneri:immutableJS)
Exception Handling Best Practices
- Hata durumunda loglama alma gibi aksiyon istenirse try-catch’e alınır.
- Üst seviyede try-catch varsa ve alt seviyede özel bir durum yoksa, alt seviyelerde try-catch’e alınmaya gerek olmayabilir.
- Exception seviyelerine göre catch blogları yazılmalıdır.
- Hata catch blogunda tanımlanırsa, kodun akışı tamamlanır.
- try-catch blogundan return ile çıkılsa dahi finally blogu çalışır. Yani finally sembolik bir blog değildir.
- Hata mesajları arayüze direk olarak bastırılmamalı, kullanıcının anlayacağı basit ve anlaşılır mesajlar oluşturulmalıdır.
- Metodların ve kullanılan exceptionların ne yaptığına dair yorumlar yazılmalı.
- ‘ExceptionManager’ gibi bir class ya da method tanımlayarak exception tipine göre hata mesajları oluşturulabilir.
- Loglama yaparken inner exceptionlar, recursive olarak alınmalıdır.
- StackTrace: Hatanın oluştuğu sınıf, method, satır numarasına ait bilgiyi saklar.
- Hata mesajı ile birlikte StackTrace de loglanmalıdır.
- ‘throw’ ile StackTrace korunur, ‘throw new’ ile StackTrace korunmaz.
- Zorunlu olmadıkça exception farklı bir exception ile wrap edilmemelidir.
- Yakalanan exception gizlenmemelidir.
- try-finally blogunda amaç, exception ı handle etmek ve loglamak değilse yazılabilir.
- Handle edilen hatanın throw edilmesi durumunda sistem sistem iki kez throw gönderir.
- ‘CustomException’ gibi bir class ile hatalar ihtiyaca göre oluşturulabilir.
- Exception fırlatmak CPU’ya iş yükü getirdiği için maliyetlidir. Döngü içinde ve birçok blog içinde try-catch performansı etkiler.
- RESTful API’lerde Exception Handling ; -Hata mesajlarının aynısı arayüzde çıkarılmamalıdır. Hata mesajı özel bilgi içerebilir, kullanıcı anlamayabilir vs. -HTTP status code belirlenmeli. -Exception kullanıcıya durum kodu, mesajı varsa işlem ile yazılmalıdır. -‘transactionId’ gibi bir alan vermek developerın hatanın nerede olduğunu anlaması için kolaylık sağlar.