Belge Odaklı Geliştirme Hakkında Ne Biliyorsunuz?

Geliştirme sürecinde neden herhangi bir belgeye ihtiyacımız var?

Kodun kendisini belgelediği bu ifadeye ne dersiniz?

En yaygın senaryoyu ele alalım: Sistemin kodu (bir program, proje veya ürün olabilir) uzun bir süre boyunca yazılıyor ve ekip bu süreç sırasında yavaş yavaş değişiyor ve geliştiriciler ayrılırken sistem hakkındaki belirli bilgileri yanlarında götürüyor.

Böyle bir durumda ne yapabiliriz?

En basit cevap, sistemin orijinal gereksinimleri karşıladığından emin olmak için tüm uygulama ayrıntılarını kapsayan bir spesifikasyon yazmaktır .

Ancak böyle bir belgenin önceden yazılması çok zordur ve geliştirme sürecinde bazı uygulama detayları değişebilir (pazara uyum sağlama/mekanik için yeni talepler vb.). Peki veri yolu faktörünü geliştirmek için ne tasarlayabiliriz?

Yukarıda bahsedilen soruna yönelik olası çözümlerden biri olabilecek bir akış izlemeye çalışalım.

Gereksinimler ve RFC

Öncelikle paydaşların gereksinimlerine göre ilk tasarımı tanımlamamız ve belgelememiz gerekiyor. Bundan sonra, bu belge diğer ekiplerle paylaşılabilir ve onlardan geri bildirim istenebilir: belirli özelliklerin uygulanmasını isteyin, ilk tasarım hakkında yorum yapın, belirli bir arayüzü düzeltin vb. Böyle bir belgeye RFC denilebilir.

RFC veya "Yorum İsteği", geri bildirim, yorum ve önerileri toplamak için geliştiriciler, mimarlar ve diğer ekipler dahil olmak üzere ilgili taraflar arasında dağıtılan bir belgedir. Spesifikasyondan daha az ayrıntılıdır ve yalnızca başlangıç problemini, görevini ve çözüm alanını içerir. Daha esnek olması, görevin derinlemesine anlaşılmasını sağlayarak tasarımdaki değişikliklerin aktif olarak kabul edilmesine olanak tanır ve kaliteyi ve düşünceli karar almayı kolaylaştırır.

Tasarım Taahhüdü ve ADR

Tamam, teknik gereklilikleri tanımladık ve diğer ekiplerin gerekliliklerini topladık . Sıradaki ne?

Bu aşamada sistem tasarımının ve gerçekleştireceği tüm ana fonksiyonların sonuçlandırılması gerekmektedir. Bu amaçla bir ADR yazıyoruz.

ADR veya "Mimari Karar Kaydı", yazılım geliştirme süreci sırasında alınan önemli mimari kararları kaydeden bir belgedir. Her ADR, belirli bir üst düzey mimari kararı, bağlamını, dikkate alınan alternatifleri, alınan kararı ve bu belirli ayrıntıları diğerlerine tercih etme motivasyonunu açıklar.

Böyle bir belge, her ekip üyesinin (ve diğer ekiplerin de) tasarımın temelini oluşturan ilke ve değerleri anlamasına olanak tanır. Yıllar sonra ekibe yeni bir geliştirici katılırsa ve "Neden bu şekilde yaptın?" diye sorarsa, tüm sorularına cevap verecek bu belge onlara gösterilebilir.

Şartname

Şimdi kodu ve özelliklerini yazmanın zamanı geldi. Bu aşamada, tüm bilgileri ve uygulama ayrıntılarını aynı anda özel bir belgede derleyerek her özellik üzerinde ayrıntılı bir şekilde çalışıyoruz. Bu belge, sistem için mevcut düşük seviyeli gereksinimleri yansıtmalıdır.

Önemli bir nokta : Yazılımın yaşam döngüsü sırasında böyle bir spesifikasyon önemli ölçüde değişebilir ve bu sorun değil. Ancak kod tabanının yönetilemez bir hale gelmesini önlemek için yine de orijinal tasarım ve mimaride kalmak çok önemlidir.

Test planı

Neden gerekli? Test planının, spesifikasyona göre yazılan kodlar (kodlar ve bu kodlara yönelik testler geçsin diye yazıyoruz) üzerinden değil , kritik senaryoları içeren bir tasarım temelinde oluşturulması kritik önem taşıyor. doğru işlenmesi gerekir . Ayrıca böyle bir test planını incelenmek üzere diğer ekiplere (entegrasyonlar için veya sadece ek testler için) gönderebilmeniz ve sistemin farklı durumlarda nasıl davranacağını netleştirmeniz de çok kullanışlıdır.

Neleri içerir?

• Tüm olası sistem çalışma senaryoları

  • Mutlu yol
  • Üzücü yol
  • Hata yönetimi

• Sistemin çalışması sırasında korunması gereken tüm olası değişmezler

• Başlangıçta sistem durumunu kontrol etmek için kabul testleri (ortamı, örneğin ağdaki verileri dikkate almalıdır)

  
  

Tasarımı tamamladık, kodu ve spesifikasyonu yazdık ve test planını derledik. Zaten oldukça sağlam geliyor! Peki başka ne ekleyebiliriz?

Dağıtım Planı

Veri yolu faktörünü iyileştirmek ve herhangi bir ekip üyesinin sistemi konuşlandırabileceği ve durumunu doğrulayabileceği koşulları yaratmak için böyle bir plana bir dereceye kadar ihtiyaç duyulabilir.

Neden onsuz yapamıyoruz? Yapabiliriz, ancak gerçek dünyada sistemin farklı bölümlerinden birçok kişinin sorumlu olduğu büyük ekipler vardır ve dağıtım süreci tamamen DevOps'a devredilebilir . Testler yazdığımıza, bunları CI'ya koyduğumuza ve güvenlik açıklarını kontrol ettiğimize göre, başka bir şeye ihtiyacımız var mı? Belki hayır, ancak çoğu zaman testler sistemin mevcut durumunu dikkate almaz ve tam olarak istediğimiz gibi testler yapmaz.

Hangi dağıtım planı şunları içerebilir :

• Dağıtımın gerçekleşmesi için gerçekleştirilmesi gereken eylemlerin tam açıklaması
• Dağıtım parametreleri:
  • Ortam Değişkenleri
  • Başlangıç hali
  • Başlatma parametreleri
• Herhangi bir adımda bir şeylerin ters gitmesi durumunda bir plan
• Mümkünse bir yedekleme planı
• Dağıtımın sürdürülmesinin mümkün olmaması durumunda sistemin getirilmesi gereken durum
• Dağıtımdan sonra gerçekleştirilmesi gereken eylemler
  • Diğer takımlara haber ver
  • Gerekirse gerekli entegrasyonları etkinleştirin

Karmaşık bir şey yok, değil mi? Belirli bir güncelleme için böyle bir belgeye sahip olmak , veri yolu faktörünü önemli ölçüde iyileştirebilir ve belirli kişilere güvenmeyi önleyebilir . İstediğimiz bu değil mi?

Çözüm

Yazılım geliştirme sürecinde sadece kod yazmak değil, aynı zamanda geliştirmenin tüm aşamalarında anlaşılırlığı ve tutarlılığı sağlayan belgeler oluşturmak da önemlidir. Dokümantasyon kodun kendisi olabilir , ancak deneyimler, özellikle geliştirme sırasında ekip değiştiğinde ve ayrıca proje gelişip yeni gereksinimlere uyum sağladığında, sistemin kalitesini, istikrarını ve gelecekteki ölçeklenebilirliğini korumak için dokümantasyonun çok önemli olduğunu göstermiştir.

Dokümantasyon RFC (Yorum İsteği), ADR (Mimari Kayıtlar), Spesifikasyon , Test Planları , Dağıtım Planları ve daha fazlasını içerir. Bu , ekipte bilginin korunmasını garanti edecek, yeni çalışanların projeye entegre edilmesi sürecini basitleştirecek ve sistemin genel güvenilirliğini ve değişikliklere karşı direncini artıracaktır .