Kod Değişikliklerinde Güvenilir Kanıtlar Üreten Sistemler Tasarlama

Yeni bir özellik geliştirirken, sadece "çalışan kod" üretmek yetmez. Aynı zamanda gelecekteki geliştiricilerin, sistemdeki davranışları güvenle anlayabilmesi ve gerekçeli değişiklikler yapabilmesi için yeterli kanıtların da kod içinde yer alması gerekir. Peki, bu kanıtlar nasıl oluşturulur?

Düşünün ki altı ay önce gönderi şablonu özelliği yayımlandı. Bu özellik, her kiracının kendi müşterilerine göndereceği mesajları arka uçta değişiklik yapmadan özelleştirebilmesini sağlıyordu. Kod incelemesi sırasında tasarımın takip edilmesi zor olduğu fark edildi—özellikle şablondan oluşturulan nihai metne kadar olan yol karmaşık görünüyordu. Ancak özellik çalışıyordu, testler geçiyordu ve açık bir güvenlik açığı yoktu. Bu nedenle, incelemeden geçirildi ve üretime alındı.

Ardından, ciddi bir hata raporu geldi: bir müşteri, başka bir müşterinin verilerini içeren bir bildirim almıştı. Bildirim hattında veri sızıntısı yaşanıyordu.

Başlangıçta, düzeltme basit gibiydi: bildirimlerin yalnızca ilgili alıcının verilerini içermesini sağlamak. Ancak görevi devralan geliştirici, kod tabanında nerede değişiklik yapması gerektiğini anlamak için saatlerce uğraştı.

Şablonlar veritabanında saklanıyordu ve altı farklı şablon tipi vardı. Her biri, kod tabanının farklı bölümlerinde gerçek değerler üretiyordu. Bazı değerler müşteri kayıtlarından, bazıları iç workflow durumundan, bazılarıysa şablon özelinde üretiliyordu. Yer tutucuların gerçek değerlere eşleştirildiği mantık tamamen farklı bir yerdeydi. E-posta ve SMS kanalları, oluşturma yolunun bir kısmını paylaşıyordu, ancak tamamını değil.

Geliştirici, bu sızıntıyı nerede düzelteceğine karar vermeden önce, daha spesifik sorulara yanıt bulmak zorundaydı:

• Hangi yer tutucu yanlış değeri oluşturdu?
• Bu yanlış değer nereden geliyordu?
• Hangi şablon tipleri bu yer tutucuyu kullanıyordu?
• E-posta ve SMS kanalları aynı şekilde mi çözümlüyordu?
• Sızıntının tamamen giderildiğini gösteren hangi kanıtlar vardı?

Sonuç olarak, sistemdeki davranışı anlamak o kadar zordu ki, hataya yönelik güvenli bir düzeltme yapmak neredeyse imkansızdı.

İyi Tasarım, Kanıt Üretir

Bu senaryoda, kodun çalışması yetmiyordu—sistemin aynı zamanda gelecekteki geliştiricilere güvenilir kanıtlar sunması gerekiyordu. Geliştirici, bir şablonun nihai bir mesaj haline nasıl geldiğini anlamadan, nerede güvenli bir değişiklik yapabileceğine karar veremiyordu.

Yazılım geliştirmede bu durum sıkça yaşanır. Zorluk çoğunlukla editörün kendisinde değil, değiştirilecek davranışın nerede olduğunu ve değişikliğin güvenli olup olmadığını anlamakta yatar.

Bu anlayışı inşa etmek için geliştirici, kod tabanında güvenilir sinyallere ihtiyaç duyar. Bir paket adı, sınıf adı veya paylaşılan bir enum, ilgili kavramları bir araya getirebilir. Bağımlılıklar açıkça tanımlanırsa yan etkiler daha kolay görülür. Bir test, sistemin korumayı taahhüt ettiği davranışı adlandırabilir.

Ancak bu sinyaller otomatik olarak kanıt değildir. Bir paket adı her şeyi kapsayan olabilir. Bir sınıf orijinal amacından sapmış olabilir. Bir test adı aslında başka bir durumu test ediyor olabilir. Bir sinyalin kanıt olabilmesi için kodun, sinyalin vaat ettiği şeyi tutması gerekir. İşte o zaman geliştirici, bu sinyallerden hareketle akıl yürütebilir.

İyi bir tasarım, yalnızca kodun temiz olmasını sağlamaz—aynı zamanda sistemin sinyallerini o kadar güvenilir kılar ki, geliştirici, davranışın nerede olduğunu, hangi unsurların bir arada olduğunu, hangi yolların önem taşımadığını ve bir değişikliğin ne kadar yayılabileceğini anlayabilir.

Geliştiricinin araştırması sırasında güveneceği sinyaller değişir. Başlangıçta, davranışın nerede olduğunu bulmaya ve mantığı anlamaya odaklanır. Daha sonra, sonuçları takip etmeye ve kalan riskin ne kadar küçük olduğunu değerlendirmeye geçer.

Anlaşılabilirlik Katmanları

Geliştiriciler, bu katmanlar arasında düzgün bir sırayla ilerlemez. İlk olarak bir dosyayı açarlar, yanlış yerde olduğunu fark ederler, bir bağımlılığı takip ederler ve yeniden arama yaparlar. Ancak bu katmanlar, geliştiricinin sistemdeki güvenilir unsurları nasıl inşa ettiğini tanımlar.

Algılama: Bakmakta Olduğum Şeyi Anlayabiliyor muyum?

Geliştirici, veri sızıntısının kaynağını araştırmaya başlamadan önce, karşısındaki kodun yapısını anlamalıdır. Girintiler, boşluklar, hiyerarşi ve gruplandırmalar, hangi unsurların birlikte olduğunu ve bir fikrin nerede bittiğini gösterir.

Eğer oluşturma kodu yoğun bir koşul bloğu, yer tutucu değiştirmeleri ve kanal özelindeki dallardan oluşuyorsa, geliştiricinin ilk odaklanması gereken şey, bu bloğun yapısını yeniden inşa etmek olacaktır. Yani, analizden önce algılama uğraşır.

Bu katman başarısız olduğunda, geliştirici kodun şeklini yeniden inşa etmek için dikkatini harcar—ardından, nerede hata olduğunu anlamaya başlar.

Yerel Akıl Yürütme: İlgili Fikirleri Aklımda Tutabiliyor muyum?

Yerel akıl yürütme, geliştiricinin bir kod parçasını bulduktan ve o birimin neye hizmet ettiğini anlamaya çalıştığı aşamadır.

Örneğin, şablonOluştur adlı bir metot dar bir görev çağrışımı yapar. Ancak bu metot, şablon yükleme, alıcı arama, kiracı kuralları, yer tutucu çözümleme, kanal biçimlendirme, eksik değer davranışı ve atlama koşullarını tek bir yerde topluca uyguluyorsa, bu metot vaat ettiği dar görevden sapar. Her adım gerekli olabilir, ancak aynı ayrıntı düzeyinde olmamaları gerekir.

İyi sınırlar, okuyucuya hangi tür akıl yürütmenin içeride yer alması gerektiğini söyler. Oluşturma, alıcı arama, kiracı kuralları, kanal biçimlendirme ve gönderim kararları birbirinden farklı zihinsel yükler gerektirir. Bu unsurları ayrı sınıflara, modüllere veya katmanlara ayırmak, kodun anlaşılmasını kolaylaştırır. Böylece geliştirici, her bir birimin neyi vaat ettiğini bilir ve gerçeğiyle karşılaştırabilir.

Bu katman, geliştiricinin hangi unsurları güvenle inceleyebileceğini ve hangilerinin incelenmesi gerektiğini ayırt etmesine yardımcı olur. İyi sınırlar, sistemdeki kanıtların güvenilirliğini artırır.