Not: Bu yöntemi ve ismi community’ye armağan ediyorum fakat herhangi bir yerde kullandığınızda lütfen bu sayfaya referans veriniz.

Not: Yazı Cocoa geliştiricileri için daha kolay anlaşılır çünkü örnekler iOS dünyasından. Fakat yine de tüm yazılımcılar anlayabilir ve uygulayabilir.

TL;DR (Okumaya üşenenler için)

Eğer bir bağımlılığınızı hemen güncelleyemiyorsanız, bağımlılığın versiyonu değiştiğinde değişen kısımları iyice anlayıp bu değişikliklere hazırlanmak ve geçişi kolaylaştırmak için bağımlılığın eski versiyonunu kullanırken değişiklikleri siz kendiniz implement edin, bağımlılığı güncelledikten sonra ise bu eski implementasyonları silin.

Örnek: Result type

Result type Swift 5’te duyurulmuştu, beta Xcode indirip bu yeni yöntemi kullanarak ufak tefek geliştirmeler yaptıktan ve öğrendikten sonra Swift 4 destekleyen appimizde kendi Result type’ımızı implement edip kullandık. Ardından Swift 5 migration tech debt’imiz dahilinde eskisini sildik ve zero cost bir maliyetle bu yeni API’a adapte olduk.

Örnek: SwiftUI

SwiftUI gerçekten 2019’da bir devrim oldu. Felsefesinde imperative kod yazmak yerine declarative yazıyoruz bunu kısaca şöyle özetleyeyim, artık data ve UI ayni düzlemde değil, UI, data’nın zorunlu bir fonksiyonu haline geldi (aslında hep böyleydi ama artık bu keyfe dayalı değil.). SwiftUI son 3 yılda çok gelişti, bazı API’lar deprecate oldu, bazıları her iOS sürümünde yeni eklendi. SwiftUI’in artık apple sistemlerinde UI geliştirmek isteyen takımların zorunlu bir durağı olacağı ağı çok açık, çünkü hem eskiden çok zor olan isleri kolaylaştırıyor, hem de daha functional bir sekilde maintainable ve scalable kod yazmayı olanaklı kılıyor. Tabii ki problemleri de yok değil ancak bunların da son 3 yılda gördüğümüz gibi giderileceğini öngörüyorum.

Peki SwiftUI’ı yukarıdaki Land Ahoy Method© çerçevesinde nasıl imite ederiz? İlk önce bu değişikliklerin temelini anlamamız gerekiyor, dediğim gibi SwiftUI imperative kod yazma biçimini declarative’e çevirtiyor, sizi başka bir düşünme şekline sokuyor. Siz de bu felsefeyi eski kodunuza yavaş yavaş uydurmaya, en azından yeni yazılan kodları bu nosyonla (declarative UI) yazmaya başlayabilirsiniz. Bu yöntemle hem üzerinde yazılım geliştirdiğiniz platformun ne yöne doğru gittiğini uygulayarak öğrenecek hem de takımınızın önündeki migration iş yükünü dramatik ölçüde düşüreceksiniz.

Risk faktörü - Combine

Bu işin riskli bir kısmı da var. Örneğin 2019 WWDC’de duyurulan ve SwiftUI’in belkemiğini oluşturan Combine framework'ü o yıldan sonra çok da beklenildiği kadar gelişmedi. Diğer WWDC’lerde bazen çok az geliştirildi bazen de hiç. Bu durumda 2019’da eğer Combine’ın yeni bir geliştirme yöntemi olacağını ve Apple’in bunu öne süreceni sanıp biz de migration hazırlansaydık, herşeyi Combine ile yazmaya başlasaydık bu doğru bir yatırım olmayacaktı. Bunu Apple’in Combine ile çözdüğü bazı islemleri başka bir API ile daha (async-await) çözmeye başladığında anladık. async-await, Combine’in çözdüğü şeyleri çözüyor (hepsini olmasa da) bir de üstüne asenkron kod geliştirme kolaylıkları, local reasoning ve type-safety de vaat ediyordu.

Anlattığım Combine örneği biraz temkinli olmayı gerekli kılıyor, yani platformların çıkarttığı yenilikleri hemen benimsemektense community’nin ve özellikle platformu geliştiren sağlayıcının bu yeni teknolojiye ne kadar yatırım yaptığını yakından takip etmek gerekiyor. Bunu bazen deklare de ediyorlar.

Migration gerçekten takımın önemli zamanını alan bir tech-debt. Girdiğim takımlarda migration için temel motivasyon çoğunlukla yeni API’ları kullanmak oluyor. Bazen önemli bir security patch’i bazense performans iyileştirmeleri driving etken olabiliyor. Motivasyon her ne olursa olsun, smooth bir geçiş için tavsiye ettiğim bu yöntemi takımınızda bir best practice haline bugün siz uygulamaya başlayarak geçirebilirsiniz.

Image taken at Fitzwilliam Museum - Cambridge