Yazılım Mimarı olarak masaya ne getirmelisiniz? [kapalı]

Bir Yazılım Mimarı'nın (SA) StackOverflow ve Programmers SE'deki rolü hakkında iyi cevapları olan birçok soru vardır . Bunlardan biraz daha odaklanmış bir soru sormaya çalışıyorum. Bir SA'nın tanımı geniştir, bu nedenle bu soru için bir SA'yı aşağıdaki gibi tanımlayalım:

Bir Yazılım Mimarı bir projenin genel tasarımına rehberlik eder, kodlama çabalarına katılır, kod incelemeleri yürütür ve kullanılacak teknolojileri seçer.

Başka bir deyişle, SA'nın sorguç türlerinde idari dinlenme ve yelekden bahsetmiyorum. Eğer herhangi bir SA pozisyonunu takip edecek olsaydım, kodlamadan uzak olmak istemiyorum. Müşteriler ve İş Analistleri vb. İle arayüz kurmak için biraz zaman feda edebilirim, ancak hala teknik olarak ilgiliyim ve sadece toplantılarda neler olduğunun farkında değilim.

Bu hususlar göz önünde bulundurulduğunda, bir SA masaya ne getirmelidir? “Yasayı koyma” (tabiri caizse) ve “kendi yollarına” uymak için belirli araçların kullanımını zorunlu kılma anlayışıyla mı gelmelidirler? Yoksa başlangıç ​​yönünü ve stratejisini belirtmeli mi, daha sonra geminin yönünü düzeltmek için gerekli şekilde geri koyulmalı mı?

Kuruluşa bağlı olarak bu işe yaramayabilir. Her şeyi uygulamak için TFS'ye güvenen bir SA, planlarını sadece StarTeam kullanan bir işverende uygulamakta zorlanabilir. Benzer şekilde, SA'nın projenin aşamasına bağlı olarak esnek olması gerekir. Yeni bir proje ise daha fazla seçeneğe sahip olurken, mevcut projeler için daha az seçeneğe sahip olabilirler.

Sorularıma verilen yanıtların da bu konulara ışık tutabileceği umuduyla bazı geçmişleri paylaşmanın bir yolu olarak deneyimlediğim bazı SA hikayeleri:

• Takımın her bir kod satırını tam olarak inceleyen bir SA ile çalıştım. SA bunu sadece projemiz için değil, organizasyondaki diğer projeler için de yapardı (bunun için harcanan zamanı hayal edin). İlk başta belirli standartları uygulamak yararlı oldu, ancak daha sonra sakatlandı. FxCop, SA'nın sorunları nasıl bulacağıdır. Beni yanlış anlamayın, genç geliştiricilere öğretmek ve onları seçtikleri yaklaşımın sonuçlarını düşünmeye zorlamak için iyi bir yoldu, ancak üst düzey geliştiriciler için biraz acımasız olarak görülüyordu.

• Belirli bir SA, belirli bir kütüphanenin kullanımına karşıydı ve yavaş olduğunu iddia ediyordu. Bu, bizi farklı şeyler başarmak için tonlarca kod yazmaya zorlarken, diğer kütüphane bize çok zaman kazandıracaktı. Hızlı bir şekilde projenin son ayına kadar müşteriler performanstan şikayet ediyorlardı. Tek çözüm, geliştiricilerin erken uyarılarına rağmen orijinal olarak yok sayılan yaklaşımı kullanmak için belirli işlevleri değiştirmekti. Bu noktada çok fazla kod atıldı ve tekrar kullanılamaz, fazla mesai ve strese yol açtı. Ne yazık ki proje için kullanılan tahminler, projemin kullanılmasının yasak olduğu eski yaklaşıma dayanıyordu, bu nedenle tahmin için uygun bir gösterge değildi. Başbakan'ın "bunu daha önce yaptık" dediğini duyarım.

• Tüm projeler için DTO, DO, BO, Hizmet katmanı vb. Kullanımını zorunlu kılacak SA. Yeni geliştiriciler bu mimariyi ve SA'yı zorunlu olarak uygulayan kullanım yönergelerini öğrenmek zorunda kaldı. Kullanım yönergelerinde istisnalar, yönergelere uymanın kesinlikle zor olduğu durumlarda yapılmıştır. SA yaklaşımlarına dayandırıldı. DTO'lar ve tüm CRUD operasyonları için sınıflar CodeSmith aracılığıyla oluşturuldu ve veritabanı şemaları da benzer bir mum topuydu. Ancak, bu kurulumu her yerde kullanan SA, LINQ to SQL veya Entity Framework gibi yeni teknolojilere açık değildi.

Bu yazıyı havalandırma için bir platform olarak kullanmıyorum. Yukarıda bahsedilen SA hikayeleriyle ilgili deneyimlerimin olumlu ve olumsuz yönleri vardı. Sorularım kaynıyor:

1. Bir SA masaya ne getirmelidir?
2. Karar alma süreçlerinde nasıl bir denge kurabilirler?
3. Bir SA işine (daha önce tanımlandığı gibi) belirli temel kuralları uygulaması gerektiği zihniyetiyle yaklaşmalı mıdır?
4. Dikkate alınacak başka bir şey var mı?

Teşekkürler! Eminim bu iş görevleri, üst düzey geliştiriciler veya teknik potansiyel müşteriler için kolayca genişletilebilir, bu nedenle bu kapasitede de cevap vermekten çekinmeyin.

Bir Sistem Mimarı:

1. Üst düzey mimariyi belirtme
2. Kod incelemelerine katılın
3. Kullanılan teknolojileri onaylayın
4. Geliştiricilere kodlama çabalarında yardımcı olun
5. Geliştirme programını sürdürmek ve izlemek
6. UML diyagramları, Gantt şemaları ve benzerleri gibi SA yapıları üretin.

SA'lar kodlamayı bilmeli ve bazı kodlama çalışmalarına katılmalı, ellerini ıslatmalıdır. Bu onları geliştirme çabasının gestaltıyla temas halinde tutar. Bob Martin Amca'nın bir zamanlar söylediği gibi, Mimar kodlamaların bazılarını kendisi yapmalı, böylece tasarımlarıyla başkalarına verdiği acıyı görebiliyor.

SA tüm tasarım, teknoloji ve kodlama tarzı kararları hakkında son sözü vermelidir. Ancak, tüm yöneticiler gibi, SA'nın görevi de üretken olabilmeleri için halkının yolunu temizlemektir. Bu, çoğunlukla, geliştiricilerin kendi seviyelerinde problemlerin nasıl çözüleceğine karar vereceği anlamına gelir. SA'nın sivri saçlı patronları geliştiricilerin kabinlerinden uzak tuttuğu anlamına gelir. Ve SA'nın gerektiği gibi yardım etmek için devreye girdiği anlamına gelir.

Tüm insanlar gibi SA'lar da hata yapabilir ve yapabilirler. İyiler bu hatalardan ders alırlar ve daha iyi SA'lar olurlar.

Asla kullanışlı olmadıkları için hiçbir zaman faydalı olan bir mimara rastlamadım.

Benim için gördüğüm en büyük sorunlar:

• süreç uğruna sürece kör bağlılık
• sorunu bilmeden teknolojiye kör önyargı
• iyi bir gerekçe olmadan kuralların oluşturulması ve uygulanması
• rewrite from scratch zihniyet

Birlikte çalıştığım en iyi "Mimarlar":

• Sorunun ve potansiyel çözümlerin daha iyi anlaşılmasına yol açan sorular.
• Tasarım seçenekleri / teknolojileri ve değiş tokuşları.
• Tasarımların ve teknolojilerin hem kınanması hem de onaylanması için açık ve rasyonel açıklamalar.

Benim için sorun, çalıştığım en iyi "Mimarlar" ın başlığında Mimar yoktu.Çoğu zaman, belirli bir sorun ve projelere dayanan Yazılım Mühendisleriydi. t Çalışan bir kod tabanının sıfırdan yeniden yazılması pratiktir.Tasarım kararı verir veya seçenekler ile bunların nedenlerini veya gerekçelerini sağlarlar.Kodbazının zaman içinde yeni bir mimariye nasıl tekrarlanacağını ve hala her şeyi işlevsel tutmayı tavsiye ederler. Her şeyin nasıl çalışması ve neden çalışması gerektiği konusunda tutarlı bir vizyon iletecekler , ancak daha da önemlisi oraya nasıl gidileceğini ve maliyeti haritalayacaklardı.

1 Bir SA masaya ne getirmelidir?

• Kalın bir cilt
• İyi müzakere becerileri
• Çeşitli yazılım katmanlarının iyi anlaşılması (whizzy AJAX iyiliğinden düşük seviyeli ağ I / O'suna kadar). Mutlaka uzman olmanız gerekmez, ancak hangi katman (lar) da hangi yazılımın yürütülmesi gerektiği konusunda önemli kararlar vereceksiniz.
• Kodda ellerini kirletmeye istekli olan beyaz kağıt tasarımları kesmiyor.
• Yazılım işçiliğinin özendirilmesi - işleri mümkün olan en doğru şekilde ve diğer durumlarda sınırlamalar göz önüne alındığında en iyi şekilde yapmak için amigo olun. Kaynak kontrolü, TDD, build ve CI, DOJO'ları kodlama, kod incelemeleri, iyi bir sorun izleme sistemi vb.

2 Karar verme süreçlerinde nasıl bir denge kurabilirler?

• Bunların çoğu ekiplerinize ve ne kadar yetenekli olduklarına bağlıdır.
• Ortamınız (örneğin belirli bir satıcının ürününü kullanmak zorunda kalabilirsiniz)
• Genel olarak, bir fildişi kule mimarı olmamak, elinizin altında olmak, ekibin bir parçası olmak en iyisidir - insanlar kararlarınızı bu şekilde anlayacaktır.

3 Bir SA işine (daha önce tanımlandığı gibi) belirli temel kuralları uygulamak zorunda oldukları zihniyetiyle yaklaşmalı mıdır?

• Evet, sürüm kontrolü ve bir inşa sistemi gibi şeyler oldukça önemlidir ve geliştiricilerin bunları kullanması gerekir. Ancak bunları çözümün bir parçası haline getirmek en iyisidir.

Çok daha fazlası var, bence bu soru için gerçekten iyi cevaplar olacak.

1. Bir SA masaya ne getirmelidir?

"'Yasayı koyma' anlayışıyla mı gelmeli ... Yoksa başlangıç ​​yönünü ve stratejisini belirtmeli mi, daha sonra geminin yönünü düzeltmek için gerektiği gibi koyulmalı mı?

Her ikisinin bir kombinasyonu söyleyebilirim. Teknolojilere ve süreçlere karar verirken, görüşlere ve önerilere açık olmak, kararlar hakkında değerli geri bildirimler / girdiler verebilir ve başkalarından öğrenmenize neden olabilir. Ekibiniz (umarım) akıllıdır; bundan yararlanın. Ancak bir karar (kararınız) verildikten sonra yasa atılmıştır. Seçimleri olmayan her şeyden şikayet edecekleri ve sadece bir şey seçip umursamayanları belirleyin ve sonra onları görmezden gelin.

Teknolojilere gelince: sahip olduklarınızla çalışın, şirket StarTeam kullanıyorsa, kullandığınız şey budur. Herhangi bir ürün / teknoloji / süreçle evlenmek sizin için hiçbir şey yapmaz.

2. Karar verme süreçlerinde nasıl bir denge kurabilirler?

Ekibi dinlemek ve ne zaman doğru ve yanlış olduklarını bilmek önemlidir ve ortakların onlara yanlış olduklarını söyleme ve kararınıza bağlı kalmalarını sağlamak. Dinlememek, kararlarınızda kaybolmak gibi saygı eksikliği getirecektir.

3. Bir SA işine (daha önce tanımlandığı gibi) belirli temel kuralları uygulamaları gerektiği zihniyetiyle yaklaşmalı mıdır?

Her zaman. Aksi takdirde, mahkmatmlar sığınmayı açıkça veya gizlice yürütürler. Ancak bu temel kurallara karar vermek, ekiple konuşmak yoluyla olabilir. Herhangi bir takımın şu anda sahip olduğu üyelere her zaman sahip olamayabileceğini unutmayın, bu nedenle küçük bir grup için taviz vermek, gittikten sonra takımı gelecekte engelleyebilir. Buna SA dahildir.

4. dikkate alınacak başka bir şey?

• İkinci örneğinize atfen: Proje ekibinin kurum içi bir alt sisteme sıkı sıkıya bağlı bir bağımlılık oluşturduğu görülüyor. Gevşek bağlı cepheler sadece üçüncü taraf kodları için değildir. Bu alt sistem için bir soyutlama oluşturmak, şirket içi çözüm başarısız olursa bu kitaplığın kullanımına daha kolay bir geçişe izin verebilirdi. Bu tek başına bir yazılım mimarı için mantıklı bir çözümdür, fakat aynı zamanda ekip ifadesi endişeleriyle bir Proje Yöneticisi biçimi olmak, iki kat daha açık bir çözüm olmalıydı.
• Üçüncü örneğinizle ilgili olarak: Yazılım üretmek için bilinen bir mimariye veya sürece sahip olmak kötü bir fikir değildir (ancak, kuşkusuz, 'tüm projeler' dediniz). Bu işe yarıyor. Bununla birlikte, yeni tekniklerin ek değer getirip getirmediklerini görmek için denenebilecek fırsatlara ihtiyaç vardır. Yalnızca şirket içi yazılımlar veya bu teknolojilerin denenebileceği daha küçük kapsamlı projeler ideal yerlerdir. Yine de, teknolojilerin benimsenmesi için araştırılmış ve ikna edici gösteriler / argümanlar sağlamak için geliştiricilerin de üzerinde olduğunu unutmayın. Ve SA'nın diğer rakiplere kıyasla her rakip ORM'yi ve güçlü ve zayıf yanlarını bilmesi beklenemez.