Steel Threads güçlü ancak anlaşılması güç bir yazılım tasarımı yaklaşımıdır. Çelik İplikleri öğrenmek sizi daha iyi bir mühendis yapacaktır. Entegrasyon ağrısı gibi yaygın sorunlardan kaçınmak için bunları kullanabilirsiniz. Ve bunları sistem tasarımının karmaşıklığını ortadan kaldırmak için kullanabilirsiniz.
Çelik İplikler ne kadar bilinmiyor? Konsept 2013 yılında Vikipedi'den silindi çünkü "fikir yazılım mühendisliğinde dikkate değer değil ve kayda değer kaynaklardan önemli ölçüde yer almıyor." Kapsamı genişletelim ve bunun neden bu kadar yararlı bir yaklaşım olduğunu da konuşalım.
Çelik iş parçacığı, bir yazılım sisteminden geçen çok ince bir işlevsellik dilimidir. Bunlara "iş parçacığı" adı verilir çünkü yazılım sisteminin çeşitli kısımlarını bir araya getirirler ve önemli bir kullanım senaryosu uygularlar.
İplik daha sonraki iyileştirmeler için sağlam bir temel oluşturduğundan bunlara "çelik" adı verilir.
Steel Thread yaklaşımıyla sistemin sınırlarını aşan ve önemli bir kullanım durumunu kapsayan mümkün olan en ince versiyonu oluşturursunuz.
Monolitik kod tabanınızın bir kısmını değiştirmek için yeni bir hizmet oluşturduğunuzu varsayalım. Bunu yapmanın en yaygın yolu şu olacaktır:
Eski koda bakın ve yeni sistemin ihtiyaçlarını anlayın.
İhtiyacınız olan yetenekleri sağlayan API'leri tasarlayın ve oluşturun.
Eski koda gidin ve yeni API'leri kullanmak için referansları güncelleyin. Bunu bir özellik bayrağının arkasında yapın.
Özellik bayrağını kullanarak kesin.
Eski kod yoluna geri dönmek için gerekirse özellik işaretini kapatarak, çalışana kadar ortaya çıkan sorunları düzeltin.
Kararlı hale geldiğinde eski kod yollarını kaldırın.
Kulağa mantıklı geliyor değil mi? Bu, yazılım mühendislerinin en yaygın çalışma şeklidir, ancak bu yaklaşımın birçok kara mayını vardır.
Bu projede ne gibi sorunlar bekleyeceğim?
Yeni hizmeti eski sistemden kopuk bir şekilde oluşturmak cazip gelebilir. Sonuçta tasarım daha saf görünebilir. Ama aynı zamanda çok daha fazla yapısal değişiklik getiriyorsunuz ve bu değişiklikleri eski sisteme herhangi bir entegrasyon olmadan yapıyorsunuz. Bu, entegrasyon acısını önemli ölçüde artırır. Benim beklentim, projeye ilişkin tüm tahminlerin gerçekçi olmamasıdır. Ortaya çıkan hizmet genel olarak iyi bir tasarıma sahip olsa bile, projenin tamamlandıktan sonra bir başarısızlık olarak değerlendirilmesini beklerim.
Yeni sisteme geçişin sorunlu olmasını bekliyorum. Geçiş yaptığınızda, eski kod yollarına geri dönmenizi veya projenin son aşamalarında sorunları çözmek için yoğun bir şekilde çalışmayı gerektirecek bir dizi sorun ortaya çıkacaktır.
Çok büyük bir kesinti olmadığı için bunların her ikisi de önlenebilir. Bir özellik bayrağıyla yeni hizmete giden trafiğin yüzde birinden fazlasının kesilmesinin bile bir geçiş yaklaşımı olduğunu unutmayın. Neden? Tüm değişikliklere olan trafiğin yüzde birini aynı anda kesiyorsunuz.
Yine de iyi gitmesini beklemiyordum. Çok büyük adımlar atıyorsunuz.
Bu yaklaşımı Steel Thread'in bunu yapma yöntemiyle karşılaştırın.
Kurduğunuz yeni sistemi düşünün. Sistemin Çelik Konularını temsil eden bazı dar kullanım senaryoları bulun; bunlar sistemdeki yararlı işlevleri kapsar, ancak tüm kullanım durumlarını ele almaz veya bazı açılardan kısıtlanır.
Bir miktar değer sağlayan, mümkün olduğu kadar dar bir başlangıç kullanım senaryosu seçin. Örneğin, yeni hizmetin parçası olacağını düşündüğünüz bir API seçebilirsiniz.
Yeni API'yi yeni bir hizmette oluşturun.
Sadece bu dar kullanım durumu için çalışmasını sağlayın. Başka herhangi bir kullanım durumu için eski kod yolunu kullanın. Üretime alın ve tam kullanıma alın. (İpucu: Hem yeni hem de eski kod yolunu bile yapabilir ve karşılaştırabilirsiniz!)
Daha sonra, ihtiyacınız olan tüm işlevleri yeni hizmete taşıyana kadar ek kullanım örneklerini yavaş yavaş eklersiniz. Her kullanım durumu üretimdedir.
İşiniz bittiğinde eski kodu ve özellik bayraklarını sökersiniz. Zaten yeni sistemde çalıştığınız için bu hiç de riskli değil.
Bu aynı zamanda "boğma" modeli değil mi? Evet ama bu yeni projeler için de kullanılabilir. Yeşil alan örneği için okumaya devam edin.
Entegrasyon sıkıntısı, projelerdeki son dakika sorunlarının en büyük nedenlerinden biridir. Yeni bir sisteme geçtiğinizde her zaman beklemediğiniz sorunlarla karşılaşırsınız. Kesinti içeren her şeyden şüphelenmelisiniz. İşleri küçük artışlarla yapın.
Steel Threads en baştan entegre olur, böylece hiçbir zaman üstesinden gelmeniz gereken çok fazla entegrasyon sıkıntısı yaşamazsınız. Bunun yerine, yol boyunca küçük bir entegrasyon acınız olur.
Ayrıca, hizmetinizin yayınlanmadan önce test edilmesine asla gerek yoktur, çünkü onu yol boyunca aşamalı olarak test etmiş olursunuz. Üretim yüklerini kaldırabileceğini biliyorsun. Zaten ağ gecikmesini eklediniz, dolayısıyla bunun sonuçlarını biliyorsunuz.
Tüm sürprizler, hizmeti kademeli olarak kullanıma sunma yönteminizin bir parçası olarak ileriye taşınır ve aşamalı olarak ele alınır.
Önemli olan çalışan, entegre bir sisteminiz olması ve üzerinde çalıştıkça onu çalışır durumda tutmanızdır. Ve zamanla bunu somutlaştırıyorsun.
Bir sistem tasarlarken çok fazla karmaşıklıkla karşılaşırsınız. Yeni sistem için bir dizi gereksinim oluşturmak zorlu bir çaba olabilir.
Steel Thread yaklaşımını kullanırken, temel gereksinimlerden bazılarını seçer ve bunları sistemin katmanlarını kesecek şekilde ifade eder ve tasarımınızı uygularsınız. Tüm sistem için bir çeşit iskelet yapısı sağlar.
Bu Çelik İpliğin uygulanması daha sonra üzerine başka gereksinimlerin inşa edilebileceği kemikler haline gelir.
Dolayısıyla Çelik İplikler bir sistemin gereksinimlerinin bir alt kümesidir .
Diyelim ki Slack'in bir klonunu uyguluyorsunuz. İlk Çelik İpliğiniz şöyle bir şey olabilir:
“Kimliği doğrulanmamış herhangi bir kişi, sabit kodlu bir hesaptaki, sabit kodlu bir #genel odaya mesaj gönderebilir. Mesajlar sayfa yenilenmesiyle varlığını sürdürüyor.”
Bu ilk Çelik İpliğin ne kadar sınırlı olduğuna dikkat edin. Kimlik doğrulamayı, kullanıcıları veya hesapları işlemez. Mesaj yazmayı ve onları sürdürmeyi yönetir.
İkinci Çelik İpliğiniz sistemi daha kullanışlı hale getirebilir. Örneğin, mesaj posterinin altına göndereceği adı seçmesine olanak tanıyan bir Çelik Konuya sahip olabilirsiniz.
Bu ikinci Çelik İplik aslında pek bir şey yapmadı. Hala kimlik doğrulamanız, hesaplarınız ve hatta kullanıcı konseptiniz yok. Ancak kullanmaya başlayabileceğiniz kadar çalışan bir sohbet odası oluşturdunuz.
Ayrıca Çelik İpliği sistemin her kısmından çekmediğinizi unutmayın. Ancak kullanıcı ve hesap kavramlarını ortadan kaldırdınız.
Bu Slack klonu örneğinde, henüz çok fazla bir şey oluşturmamış olsanız bile, oluşturmakta olduğunuz sistem hakkında erken geri bildirim alabileceğinizi unutmayın. Bu, Çelik İpliklerin kullanılmasının bir başka güçlü nedenidir.
Sadece bu iki Steel Thread'den sonra ekibiniz sohbet odasını tam zamanlı olarak kullanmaya başlayabilir. Ekibinizin sisteminizi kullanarak ne kadar öğreneceğini düşünün. Çalışan bir sistem.
Bunu, Kullanıcı ve Hesap sistemlerini oluşturmayı, her şeyi birbirine bağlamayı ve son olarak bir sohbet odası oluşturmayı öğreneceklerinizle karşılaştırın.
Çelik Konular genellikle projelerinizi tasarlarken başlamak için iyi bir yerdir. İşin geri kalanı için bir iskelet oluşturuyorlar. Sistemin çekirdek kısımlarını çiviliyorlar, böylece detaylandırılacak doğal yerler var.
Çelik Dişli yaklaşımını denemenizi tavsiye ederim. Sanırım projelerinizi dönüştürebileceğini göreceksiniz. Bununla ilgili deneyimlerinizi bana bildirin!
“Dikey dilimleme” terimini duymuş olabilirsiniz. Konsepti Kilometre Taşları hakkındaki yazımda açıklıyorum.
Steel Threads, yazılımınızı dikey dilimler halinde teslim etmenizi sağlayan bir yazılım tasarım tekniğidir. Terim, bir sistemin başlangıçtaki dikey dilimlerini tanımlamak için kullanılma eğilimindedir.
Bunlar birbiriyle yakından ilişkili kavramlardır ancak tamamen aynı değildir.
Ayrıca Steel Threads'in "izli mermiler" olarak anıldığını da duydum.
Resim Steen Jepsen tarafından Pixabay'a yüklendi
Bu hikaye ilk olarak şu adreste yayınlandı: https://www.rubick.com/steel-threads/