Geliştirme sürecinde neden herhangi bir belgeye ihtiyacımız var? bu ifadeye ne dersiniz? Kodun kendisini belgelediği 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 geliştirmek için ne tasarlayabiliriz? veri yolu faktörünü 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 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. RFC Tasarım Taahhüdü ve ADR Tamam, ve . Sıradaki ne? teknik gereklilikleri tanımladık diğer ekiplerin gerekliliklerini topladık Bu aşamada gerekmektedir. Bu amaçla bir yazıyoruz. sistem tasarımının ve gerçekleştireceği tüm ana fonksiyonların sonuçlandırılması ADR veya "Mimari Karar Kaydı", yazılım geliştirme süreci sırasında alınan önemli mimari kararları kaydeden bir belgedir. Her 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. ADR ADR, Böyle bir belge, her ekip üyesinin (ve diğer ekiplerin de) tasarımın temelini oluşturan ilke ve değerleri 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. anlamasına Ş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. : 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. Önemli bir nokta Test planı Neden gerekli? Test planının, spesifikasyona göre yazılan , kritik senaryoları içeren oluşturulması kritik önem taşıyor. . 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. kodlar (kodlar ve bu kodlara yönelik testler geçsin diye yazıyoruz) üzerinden değil bir tasarım temelinde doğru işlenmesi gerekir 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) tamamladık, kodu ve yazdık ve derledik. Zaten oldukça sağlam geliyor! Peki başka ne ekleyebiliriz? Tasarımı spesifikasyonu test planını Dağıtım Planı 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. Veri yolu faktörünü iyileştirmek 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 . 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. tamamen DevOps'a devredilebilir 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 ve belirli kişilere . İstediğimiz bu değil mi? , veri yolu faktörünü önemli ölçüde iyileştirebilir güvenmeyi önleyebilir Çö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 , 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. kodun kendisi olabilir Dokümantasyon (Yorum İsteği), (Mimari Kayıtlar), , , ve daha fazlasını içerir. Bu garanti edecek, sürecini basitleştirecek ve . RFC ADR Spesifikasyon Test Planları Dağıtım Planları , ekipte bilginin korunmasını yeni çalışanların projeye entegre edilmesi sistemin genel güvenilirliğini ve değişikliklere karşı direncini artıracaktır

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

Making security fun one episode at a time

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

Çok uzun; Okumak

Roman Kolpakov

STORY’S CREDIBILITY

Guide

About Author

ETİKETLERİ ASIN

Languages

BU YAZI...

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

Çok uzun; Okumak

Roman Kolpakov

STORY’S CREDIBILITY

Guide

About Author

ETİKETLERİ ASIN

Languages

BU YAZI...

İLGİLİ ÖYKÜLER