Mimariden gelişime geçiş konusunda en iyi uygulamalar var mı?

Görevleri mimariden gelişime devretme sürecini geliştirmeye çalışıyoruz.

Ölçeğin bir ucunda kaos alma riskiniz olan bir mimari rehberlik yoktur, her geliştirici işleri kendi kendine yapar.

Her şeyin belirtildiği ölçeğin diğer ucunda, şartname geliştirmeden daha uzun sürer ve çok sıkıcı geliştirme görevlerine sahip olma riskiyle karşı karşıya kalırsınız.

Bu uçlar arasında en uygun orta yolu bulmuş olan var mı? Gelişime hangi eserleri sunuyorsunuz? Örneğin: modüller, sınıf yapısı veya sıra diyagramları?

Ayrı bir "Mimarlık" ekibi kavramının iyi yazılım geliştirme uygulamalarına bir hakaret olduğunu söyleyerek başlayacağım. Kurumsal ortamlardaki mimari ekipler , geliştiriciler havuzu arasında bulunabilecek en kötü fildişi kulesi sahte-entelektüel boğa * * sanatçılarının doruk noktası olma eğilimindedir .

Diğer kuruluşlar Mimarlık gruplarına liyakat, bilgi ya da beceriye bakılmaksızın en üst düzey üyelere muazzam bir maaş verilmesinde siyasi bir ödül ve gerekçe gibi davranırlar. Çoğu her iki tipten oluşur.

Her geliştirici mimar olabilir ve olmalıdır ve bir şirketin üst düzey tasarımlarında yer almalıdır. Tek bir grubun yazılım tasarımının her yönü üzerinde tam bir diktatör kontrolüne sahip olduğu ve tasarıma katkıda bulunmayan, tasarım seçeneklerinin ardındaki mantığı anlamayan ve kritik kusurları anlayabilen geliştiricilere teslim edilmesi gerektiği düşüncesi tasarımın gerçek uygulama ve mevcut koda daha yakın ve daha yakın olması, açıkçası tamamen özünden kusurludur ve sürekli olarak üç senaryodan biriyle sonuçlanır:

• Geliştiriciler, tasarımı anlamamakta veya mevcut uygulamanın gerçekleri nedeniyle bunu açıkça reddetmekte ve sonuçta kendi belgelenmemiş tasarımlarını belirlemekte ve bunun yerine uygulamaktadır. Durum, yazılımın uygulanmasını yansıtmayan resmi tasarım belgeleridir.

• Geliştiriciler, kullanıcı hikayelerinin mevcut gereksinimlerini veya benzersiz yönlerini göz önünde bulundurabilen veya edemeyen tasarımı körü körüne takip ederek, hatalı ve düşük kaliteli bir uygulama ile sonuçlanır.

• Tasarım belgelerini anlayan ve bunları uygulayabilen akıllı geliştiriciler, tasarım tartışmalarına katılmamaktan hemen sıkılıyor. Siyasi ya da kıdem sorunları nedeniyle Mimarlık grubuna katılmaları muhtemel değildir, bu yüzden hayal kırıklığına uğrarlar, sıkılırlar ve daha yeşil otlaklar için ayrılırlar. Bu, olumsuz yazılım kalitesinin kısır döngüsünün devam etmesine neden olan bir beyin göçüne neden olan projeyi olumsuz etkiler.

Bu sorunu en aza indirmenin en iyi yolu Mimarlık grubunu DEĞİŞTİRMEK ve muhtemelen onları teknoloji liderlik pozisyonlarına sokmaktır. Mimarlık grubunun rolü az ya da çok bir "teknoloji adayı scrum" olmalıdır. Nadiren en üst düzey teknik yön konularını karşılamalı ve tartışmalıdırlar, ör. Java'dan Scala'ya geçen tartışmayı düşünün, MySQL için Oracle'ı terk edin, muhtemelen StarUML'den Altova UML'ye geçiş yaparak belirli bir tasarım sürecini diğerine göre zorunlu kılan ortak yardımcı program kütüphaneleri yazmayı düşünün.

Gerçek ve gerçek yazılım tasarımı, Mimarlık grubunun son derece üst düzey yönlendirmesiyle ortaya konan TÜM yazılım geliştiricilerini içeren bir topluluk süreci olacaktır.

Bilginin mimarlıktan geliştirme testine ve operasyonlarına nasıl aktarıldığı konusunda her zaman sorunlar olmuştur. Bu sorunların üstesinden gelmenin yolu aşağıdakiler gibi çeşitli faktörlere bağlıdır:

• yazılımın boyutu
• karmaşa
• kuruluşunuzdaki kültür
• inanç.

Bu faktörlerin bazı kombinasyonları için, ortaya çıkan tasarıma sahip, saf, çevik bir yaklaşım olan çapraz fonksiyonel ekipler uygundur. Bilgi birlikte çalışarak akar. Disiplinler ihtiyaç duyduklarını belgelemektedir.

Bu faktörlerin diğer kombinasyonları için küçük bir mimar, test cihazı, operasyon uzmanı ve öncü geliştiriciler ekibi, mimariyi yavaş yavaş inşa eden mimari yinelemelerle başlayabilir, mimari kararlarını belgeleyip anında geri bildirim alabilir. Yavaş yavaş özellikleri uygulayan geliştiriciler ekibe eklenebilir ve orijinal çekirdek ekip daha küçük hale getirilebilir.

Çoğunlukla devlet ve finans projeleri için, daha fazla dokümantasyonun önceden yazılması ve seçimlerinizle ilgili gerçek bir dünya geri bildirimi olmadan uzun sürebilir. Bence bu projelerin çoğunun başarısız olmasının en büyük nedeni. Yine de durumunuz buysa, dokümantasyonu gereksinimlere uyacak şekilde yaparım ve yazılımı gerçekten oluşturmak ve dokümantasyonu düzeltmek / uyarlamak için seçenek 1 veya 2'yi kullanmaktan daha iyidir.

Bu yardımcı olur umarım.

Bunun çok popüler olmayacağını biliyorum ama yaptığınız yorum

Ölçeğin diğer ucunda her şey belirtilirse, şartname geliştirmeden daha uzun sürer. Ve çok sıkıcı geliştirme görevlerine sahip olma riskiyle karşı karşıyasınız.

aslında uğraşmanız gereken bir şeydir. Tasarım ve şartname, geliştirme görevlerinin sıkıcı olacağı kadar sağlamsa, geliştirme maliyeti düşer. Bir spesifikasyonu düzeltmek kodu düzeltmekten çok daha ucuzdur ve yazılım projelerinin en büyük maliyeti derleme değildir, uzun vadeli destektir. Ve sağlam bir spesifikasyona dayanan destek kodu çok daha ucuzdur.

Ben maple_shaft'ın cevabı ile tamamen aynı fikirde değilim, ama benim bütün bit söylemek söylemek yeterli yer yoktu! ;-)

Her geliştiricinin mimar olabileceğini ve olması gerektiğini kabul ediyorum, ancak bu her geliştiricinin bir ürünün veya sistemin tüm mimarisinden sorumlu olması gerektiği anlamına gelmez. Ayrıca, her mimari ekibi aynı geniş fırçayla boyayabileceğinizi düşünmüyorum ve doğru mimari ekipler yapıldığında genel ürün geliştirme sürecine büyük değer katabiliyor. Yanılgı, mimarların sistem tasarımının her yönünü dikte etmesi gerektiğidir. Bunun yerine daha üst düzey tasarıma odaklanmalı ve uygulama ayrıntılarını geliştirme ekiplerine bırakmalıdırlar. Ancak bu, geliştiricilerin en başından planlama ve tasarım sürecine dahil olmaması gerektiği anlamına gelmez.

Bir ürün ne kadar büyük ve modüler ve nihayetinde daha karmaşıksa, ürünün farklı geliştirme ekipleri tarafından kullanılan çeşitli parçalarını bulma olasılığınız o kadar artar. Bu ekiplerin, sistemin sorumlu oldukları kısımlarını tam olarak anlamaları şartıyla sistemi bir bütün olarak anlamaları gerekmez. Genellikle bu ek ekipler, mimarların veya diğer ekiplerin uzmanlık sahibi olamayacağı belirli bir teknoloji alanında bir modül geliştirmek için taşeron olarak getirilir. Kendi özel yeteneklerim API'leri geliştirmede yatıyor ve henüz görmedim kullanılabilirlik açısından tam bir karmaşa olmadan tamamen organik olarak geliştirilmiş iyi faktörlü bir API, veya API'nın farklı yönleri arasında bir tekdüze düzeyi olduğundan emin olan birisinin göze çarpmasını gerektirmeyen. Birçok örnek ve nedeni listelemeye devam edebilirim, ancak bu tür durumların birçoklarının düşündüğü fildişi kulesi BS olduğunu düşünmüyorum. Ne yazık ki, özellikle savunma, medikal ve kurumsal paranoyaların akla geldiği ve maple_shaft'ın en çok endişe duyduğu türden daha kötü yönetilen ürün geliştirme ile sonuçlandığı finans sektörlerinde birçok yer var. Bunlar, mimarlara biraz hak ettiği kötü bir isim verdiğini düşündüğüm şeyler (genel olarak konuşursak). Ne yazık ki, özellikle savunma, medikal ve kurumsal paranoyaların akla geldiği ve maple_shaft'ın en çok endişe duyduğu türden daha kötü yönetilen ürün geliştirme ile sonuçlandığı finans sektörlerinde birçok yer var. Bunlar, mimarlara biraz hak ettiği kötü bir isim verdiğini düşündüğüm şeyler (genel olarak konuşursak). Ne yazık ki, özellikle savunma, medikal ve kurumsal paranoyaların akla geldiği ve maple_shaft'ın en çok endişe duyduğu türden daha kötü yönetilen ürün geliştirme ile sonuçlandığı finans sektörlerinde birçok yer var. Bunlar, mimarlara biraz hak ettiği kötü bir isim verdiğini düşündüğüm şeyler (genel olarak konuşursak).

Peki OP'nin aradığı orta yol nerede? Cevap, iletişim kanallarının açılmasıyla ilgilidir. Mimarlar, geliştirme ekiplerinin sınırların nerede olduğunu anlamalarını sağlamak için tasarımlarını tanımlayan özellikleri teslim etmelidir. Her şeyin bir kara kutu olarak kabul edildiği en geniş anlamda Hikayeler ve Özellik Senaryoları. Mimarlar daha sonra ekiplerin herhangi bir varsayımı onaylamak için mimarın zamanına erişmesini sağlamalı ve çok geniş veya belirsiz görünen özellikler hakkında soruları yanıtlamalıdır. Bundan sonra, münferit takımların diğer takımların ne üzerinde çalıştıklarından haberdar edilmesini sağlamak ve sistemin her bir bölümünün diğer bölümlerle güzel bir şekilde oynamasını sağlamak için diğer takımlarla kiminle bağlantı kuracağını bilmekle ilgilidir. Bu takımlar birbirleriyle doğrudan tanışırlar. Sistem en geniş düzeyde tasarlandıktan sonra, mimarlar gerçekten sadece akıl sağlığı kontrolüne ihtiyaç duyduklarında ekiplerin başvurduğu insanlar olmalı ve ürünün "vizyonunun" korunmasını sağlamalıdır. Ayrıca, gerekli tüm entegrasyon süreçlerini üstlenmeli ve bu çeşitli insanların aralarında çalışmak için bir araya gelebilmelerini sağlarken, yöneticiler, müşteriler ve diğer paydaşlardan geliştirme ekipleri için çok ihtiyaç duyulan "hava örtüsü" sağlamalıdırlar. Onlara işler nasıl olmalı.

IMHO mimarları her şeyden önce kolaylaştırıcılar, iletişimciler ve tasarımcılar olmalıdır. Hangi spesifikasyon seviyesine gelince? Bence en iyi mimarlar takımlarına bir takımın istediği ayrıntı düzeyi hakkında soru soranlar ve aralarında çalışan bir denge buluyorlar. Farklı ekipler, gereken belge veya yön miktarı bakımından farklı gereksinimlere sahip olabilir. Üst düzey ekipler kabaca çizilmiş bir diyagram bulabilir ve hızlı bir sohbet başlayabilir, ancak nispeten genç geliştiricilerle dolu ekipler, onları devam ettirmek için biraz daha gerekebilir. Her şeyden önce, mimar her takımdan en iyi sonucu almak için geliştiricileri kendi tasarım yeteneklerini kullanmaya teşvik etmelidir.

Bir şeyi iyileştirmeye çalıştığınız için, işleminizde zaten bir sorun algıladınız. Belirli bir durumun temel nedeni şunlar olabilir: Geliştiriciler kendilerini mimariyle özdeşleştiremezler, çünkü dışarısı tarafından onlara dayatılmıştır. Mimariyi gelişime teslim etmek büyük olasılıkla bu temel nedeni çözmeyecektir.

Mimariyi geliştirme ekibinin bir parçası haline getirin. Mimar ve geliştirici arasındaki sınırı yıkın. Bu, bilgilerin akmasını sağlar. Geliştirme ekibi mimariyi şekillendirmeye katılırsa, onu yabancı bir şey olarak görmezler. Ekibe mimarlık hakkında bilgi verin. Bahsettiğiniz kaosu önlemek için onlara kurumsal mimarinin arkasındaki itici faktörleri öğretin. Bahsettiğiniz sıkıntıdan kaçınmak için mimari kararların alınması gerektiğinde geliştiricileri dahil edin. Artık devir gerekmiyor ve bir geliştirme ekibinde mimar olarak rolünüzü yerine getirdiniz.

Gelecekteki ekibin kodu sürdürmesi için mümkün olduğunca fazla bilgi vermeniz gerekir. Örneğin dizi diyagramlarınız yoksa, geliştirici kodu adım adım izlemeye zorlanır, böylece zaman kaybeder.

Ayrıca yeni takımın geçersiz varsayımlar yapmasına yer var.

Genel olarak, projenin ne olduğu, teknik özellikler, birim test senaryoları ve dizi / sınıf diyagramları hakkında bir belge olmalıdır.

Sınıf diyagramları bir kod yanı sıra bir model oluşturma görünümleri bir çözüm olduğunu söyleyebilirim. Sınıf diyagramı, proje mimarinizin statik görünümünü temsil eder. Yani paketler var> sınıflar, arayüzler, enum> öznitelikler, mehtodlar vb ...> vb.

Projelerimizde kullandığımız tek bir modele kaydedilen sınıf diyagramlarıdır. Sınıflandırıcı zaten varsa modelin görünümlerini oluşturur veya yeni ise grafiksel olarak yeni bir tane oluştururuz. Geliştiriciler diyagramlarımızı ve modelimizi görebilir, çünkü CVS içindeki proje klasörü köküne kaydedilmiştir. Ne gibi bir şey kod düzeyinde değiştirilirse, model otomatik olarak tüm ekip için CVS güncellenir çünkü geliştirici de model olabilir.

Gerçekten iyi çalışıyor ve sınıf diyagramı gerçekten basit ve ters mühendislik işi yapacak ve kodun grafik görünümünü yaratacağı için UML'yi bilmenize gerek yok. Basit navigasyon, her zaman güncel olan ve CVS'de doğrudan projede görülebilen diyagramlarla bol miktarda yorum eklenebilecek gelişmiş ve ayrıntılı görünümler. UML sınıf diyagramım şimdi Magic :-)