Zaten birkaç yıl süren orta ölçekli bir projenin ortasına katıldım. Sorunlardan biri, mimariyi tanımlayan belgenin asla yazılmamış olmasıdır. Şimdi mimari açıklamayı yazmak için bana bir görev verildi.

Bu proje üzerinde çalışırken, belgeyi yazmak için ihtiyacım olan tüm bilgileri topladım. Ayrıca bazı özellikler eklediğimden, açıklandığı gibi mimariyi açıkça parçalayan bazı kod parçaları belirledim.

Örneğin, GUI'nin iş mantığı olmadan ince bir katman olması gerekiyordu. Bana böyle söylendi. Uygulama birçok mantık içerir.

Patronum bana sistemin mimarisini tanımlayan belgeyi yazmak için görev verdi. Hedef kitle, proje üzerinde çalışan mevcut ve gelecekteki geliştiricilerdir. Ne olması gerektiğini anlatmalıyım, ama aynı zamanda sapmaları bir şekilde tanımlamam gerekiyor.

Peki, bu sorunları nerede tarif etmeliyim? Hata izleme yazılımı? Yoksa uygulamanın mimarisini tanımlayan belgedeki uygulamanın mimariden sapmalarını mı tanımlamalıyım?

Halihazırda oluşturulmuş bir sistemin tasarımını veya mimarisini belgeliyorsanız, belgenin tasarlandığı veya tasarlandığı veya tasarlanmadığı şekilde yapıldığını açıklamalıdır. Mimaride tuhaflıklar veya tutarsızlıklar varsa, bu belge bu sorunları çağırmalı ve bir okuyucuya mümkün olduğunca açıklamalıdır.

Sistem üzerinde en başından beri çalışan kişilerden (ya da en azından sahip olduğunuzdan daha uzun süre) bilgi alabiliyorsanız, aslında neyin amaçlandığı ve mimari ve tasarımın neden bundan saptığı hakkında daha fazla bilgi yakalamak yararlı olacaktır. niyeti.

Günün sonunda, bir tasarım belgesi koda rehberlik etmelidir. Belge yeni bir geliştiricinin kod tabanının geçerli durumunu ve nasıl yapılandırıldığını anlamasına yardımcı olmazsa, belge yararlı değildir.

Bu belge, sistemdeki değişikliklerin gelecekteki planlamasına ve tasarımına rehberlik etmek için kullanılan ve daha sonra geliştirme süreciniz dahilinde güncellenen canlı bir belge olmalıdır. Tasarım zaman içinde değiştikçe ve geliştikçe, belge aynı zamanda geliştiricilere olayların neden şu anda olduğu gibi anlamalarına yardımcı olmalıdır.

Mimariyi ele geçirme konusunda tavsiye almak istiyorsanız, IEEE Standardı 1016-2009 IEEE Bilgi Teknolojisi Standardı - Sistem Tasarımı - Yazılım Tasarım Açıklaması'nda önerilen yaklaşımı seviyorum . Hem mimari hem de ayrıntı düzeyinde tasarım bilgilerini yakalamak için kullanılabilecek bir tasarım açıklaması için makul bir yapı sağlar.

Ayrıca bu sapmaları bir tür teknik borç olarak değerlendiririm. Sorunları çözmek büyük bir girişim, belki de küçük bir proje olabilir, teknik borcun varlığını daha görünür hale getirmenizi tavsiye ederim. Bu, hata izleme aracınızı kullandığınız anlamına gelirse, oraya bir veya daha fazla sorun koyabilirsiniz. Yazılımdaki önerileri ve geliştirmeleri izlemek için kullandığınız başka bir aracınız varsa, bu, onu koymak için başka bir yer olabilir.

Sistem mimarisini resmileştirirken sadece mimarinin masaya getireceği değerin ardındaki değeri değil, aynı zamanda ne olması gerektiğini de anlamanız ve takdir etmeniz önemlidir.

Yazılım veya Teknik Mimarinin birincil hedefleri , Sistem Mimarisini yönlendirecek Kalite Nitelikleri tarafından gerçekleştirilen İşlevsel Olmayan gereksinimleri belirlemektir .

İşlevsel Olmayan Gereksinimler Hakkında:

İşlevsel olmayan bir gereklilik, belirli davranışlardan ziyade bir sistemin çalışmasını değerlendirmek için kullanılabilecek ölçütleri belirleyen bir gereksinimdir. Belirli davranışları veya işlevleri tanımlayan fonksiyonel gereksinimlerle karşılaştırılırlar. İşlevsel gereksinimleri uygulama planı sistem tasarımında ayrıntılı olarak açıklanmıştır. İşlevsel olmayan gereksinimleri uygulama planı sistem mimarisinde detaylandırılmıştır.

Genel olarak, işlevsel gereksinimler bir sistemin ne yapması gerektiğini ve işlevsel olmayan gereksinimler bir sistemin nasıl olması gerektiğini tanımlar. ... İşlevsel olmayan gereksinimlere genellikle bir sistemin "kalite özellikleri" denir. İşlevsel olmayan gereksinimlerle ilgili diğer terimler "nitelikler", "kalite hedefleri", "hizmet kalitesi gereklilikleri", "kısıtlamalar" ve "davranış dışı gereksinimler" dir.

Elbette mimari açıdan önemli gereksinimleri tanımlamak bir yeşil alan projesinde ne zaman mantıklıdır, ancak mevcut yazılımla çalışırken mümkün olduğunca disiplinli olmak en iyisidir. Yazılım mimarinizin mevcut sistemden etkilenmesini istemezsiniz.

Yazılım mimarisinin yetkili olması için 3 şey olması gerekiyor.

bildiren

Bu, belgelerin NEDEN OLMADIĞINI, ancak işlerin nasıl OLMASI gerektiğini bildirdiğiniz kısmıdır. Bunu, sistemin çeşitli Mimari Görünümlerini kullanarak yapıyoruz. Olması gereken bileşenleri, nasıl etkileştiklerini tanımlarız ve daha sonra sistemin nasıl tasarlanması gerektiğini bildiren daha ayrıntılı görünümler için isteğe bağlı olarak her bir bileşeni ayrıntılı olarak inceliyoruz.

Bu önemli bir ayrım. Sistem Tasarımı, Sistem Mimarisi tarafından sınırlandırılmalıdır, aslında ayrı ancak ilgili şeylerdir.

gerekçe

Yazılım Mimarinizin Gerekçesi, alınan mimari kararlarına meşruiyet ve otorite sağlayan şeydir. Belki de bir toplu işi tetiklemek için MQ üzerinden bir Pub / Sub olay dinleyicisi kullanma kararı alındı ​​ve bunu diyagram haline getirdiniz mi?

Bu karar neden verildi? Neden Gerekçe bölümünde açıklıyoruz ve açıklamamızı İşlevsel Olmayan Gereksinimler, Kalite Özellik Hedefleri veya Mimari olarak Önemli Gereksinimler ile ilişkilendiriyoruz. (Ör. İşler eşzamansız ve tekrarlanabilir olmalıdır, bir kalite özniteliği olarak sürdürülebilirlik, bir toplu iş başarısızlığı durumunda işlerin bir MQ mesajı ile yeniden başlatılabileceğini, Sistemin eşzamansız iletişim ile Sıfır İleti Kaybına sahip olması gerektiğini vb. ..)

Riskler

Artık mimarlığın nasıl olması gerektiğini açıkladığınıza ve Gerekçenizle kanıtladığınıza göre, artık sistemin geçerli olmadığı sistemdeki mevcut durumdaki Riskleri tanımlayabilirsiniz.

(Örneğin, sunucu tarafı doğrulaması istemci tarafı Javascript kodunda çoğaltılıyor. Bu DRY ilkesinin ihlalidir ve bu, Sürdürülebilirliğin Kalite Özelliğine ters düşmektedir. Bu alanda Performans etrafında tanımlanmış İşlevsel olmayan gereksinimler yoktur. geçerli sistem davranışı için bir Gerekçe yoktur)

Riskleriniz, mevcut durumun şu anda Mimarlık'tan saptığı yeri de çizebilir. Bu Riskler, proje planları aracılığıyla veya bunu biriktirme listesine ekleyerek şimdi geliştirme ekibi tarafından ele alınabilir.

Projenin mevcut yapısını mı yoksa projenin istenen yapısını mı yoksa her ikisini mi belgeleyeceğinize gerçekten karar vermeniz gerekiyor .

Gelecekteki gelişimi istenen satırlar boyunca yönlendirmek amacıyla hedefi belgeleyebilir ve sapmaları hata olarak yükseltebilirsiniz (belki de belgenin ilgili bölümlerinden bu hatalara bağlantı verin). Ya da koda bir giriş / genel bakış sağlamak için gerçeği belgeleyebilirsiniz. Ya da aynı anda gelecekteki gelişimi için bir rehber olması böylece, hem yan-yana belgelemek olabilir ve tek bir yerde geçerli kod doğru bir açıklama. Belgenin ne için olması gerektiğine bağlı olarak hepsi makul, bu yüzden hangisini yapacağınızı size yararlı bir şekilde söyleyebileceğimizi sanmıyorum.

Ayrıca unutmayın ki istenen mimarinin ilgili olanlar arasında evrensel olarak kabul edilemeyebileceğini de (farklı şeyler istedikleri için veya bazıları orijinal paylaşılan arzuların imkansız veya pratik olmadığını ve bu nedenle mevcut kodu yazmaya başvurduğunu fark etmelisiniz. hedeften sapan). Bu yüzden , neyin arzu edildiğine karar verme yetkisine sahip olup olmadığınızı ve kimin yapmadığını da bilmeniz gerekir . Mevcut yapı en azından belgelemek için sadece bir tane var.

Mimari tasarım belgesine ne olması gerektiğini yazın ve her çatışma için çatışmayı tanımlayan hata izleyicide bir bilet açın. Biletin yorumlar bölümü, ilgili kişilerin bu çatışmayı tartışmaları için bir platform sunacak.

Bu biletlerin her birinin çözünürlüğünün uygulamayı tasarıma uyacak şekilde değiştirmek olabileceğini unutmayın; ancak aynı zamanda tasarımı uygulamaya uyacak şekilde değiştirmek de olabilir. İdeal olarak ilk tercih edilir, ancak bazen daha sonra seçmeyi daha verimli / pragmatik / mümkün kılan teknik ve / veya iş kısıtlamaları vardır. Bu durumda, mimari tasarım belgesindeki bilete başvurmak iyi bir fikir olabilir, böylece belirli alt tasarım seçiminin neden seçildiğini anlamayan gelecek okuyucular biletin tartışmasını okuyabilir ve arkasındaki mantığı anlayabilir. o.

3 ana bölüm halinde düzenlenmiş bir mimari belge yazmaya meyilli olurum.

İlki, başlangıçta tasarlanan tasarımı / mimariyi tanıttı. Bu, yeni geliştiricilerin / okuyucuların sistemin ne yapması gerektiği hakkında bir fikir edinmesine izin verecek ve açıkçası gereksinimlere / kullanımlara vb.

İkinci bölüm mimarinin gerçekte ne olduğunu tam olarak açıklamalıdır . Bu, yeni geliştiricilerin / okuyucuların mevcut oyun durumu ve yazılıma (ve potansiyel olarak diğer belgelere) baktıklarında neyle uğraştıklarına dair bir fikir edinmelerini sağlar. Bu bölüm , orijinal mimari ile çok yanlış olan şeyleri (umarım çok fazla değil!) Ve kısayolların / korsanların (muhtemelen varsa adil bir kaçını) vurgulayacağından, amaçlanan ve gerçeklik arasındaki farkı açıkça belirtmelidir. geliştirici ekibine büyük bir baskı uygulandı) ve gereklilikler yerine getirilmiyor ya da yazılım 'kötü' tasarlanmış bir tasarıma, yani kırılgan, kararsız, taşınabilir görünmeye başlıyor.

Sonunda, şimdi olması gerekenler için önerileri ayrıntılandıran bir bölüm düşünüyorum. Bu, vizyonunuzu gerçeğe dönüştürmek için mimaride / tasarımda herhangi bir değişiklik ve şu anda yazılımda yapılacak değişiklikler için bir yol haritası olmalıdır.

Bence bu (yüksek düzeyde) yakalanması gerekenleri kapsıyor. Bunu, kullandığınız dokümanın veya hata izleme yazılımının alt bölümleri açısından nasıl yaptığınız, çalıştığınız alana / kişisel tercih / takım büyüklüğü / bütçe / zaman ölçeği vb.