Bir yazılım mimarı olarak, o kadar çok günlükleri analiz etmeye ve diğerlerinin hatalarını gidermeye odaklanmam gerekir mi?

Mezun olduğumdan beri (2005 sonu) aynı şirkette c ++ yazılım mühendisi olarak çalışıyordum. Bir yıl önce bir yazılım mimarı olarak terfi ettim ama kendimi daha fazla kalifikasyon ve tamir hataları, seviye 2 desteği ile ilgilendim.

Notepad ++ 'da geçirdiğim zamanın% 50'si yazılım kayıtlarını analiz etmek ve neyin yanlış gittiğini anlamaya çalışmak. % 30'u diğerlerinin hatalarını gidermek ve kalanını (varsa) geliştiricilerin spagetti kodunu incelemek.

Bu üründen nefret etmeye ve bu şirketten çıkış stratejisini düşünmeye başladım.

Bu durumda ne yapabileceğimi düşünüyorsun? Başka bir yazılım mimarı hala koddaki hataları düzeltiyor musunuz?

Çoğu kişi bir Yazılım Mimarı'nın çoğunlukla yüksek düzeyde tasarıma, standartlar koymaya, araç veya çerçeveler seçmeye, ürünleri değerlendirmeye, prototipleri ve Kavram Kanıtını uygulamaya ve geliştiricilere eğitim ve mentorluğa dahil olması gerektiği konusunda hemfikirdir.

Bununla birlikte gerçek şu ki, unvan genellikle bir geliştiriciye politik bir atama, proje geliştiricilerini yönlendirmek için verilen özel bir unvan, ya da kötü bir şekilde ihtiyaç duyulan bir geliştiriciyi maaş veya oranla işe almak için yönetim-İK geçici çözümü kadar basit bir şey olabilir. İK veya üst yönetim, Yazılım Geliştirici veya Yazılım Mühendisi unvanı için kabul edilemezdir.

Başka bir deyişle, başlıklar çoğunlukla anlamsızdır.

Wikipedia makalesi, yazılım mimarını şöyle tanımlar :

Bir bilgisayar programcısı üst düzey tasarım seçenekleri ve dayatmalara teknik standartlar yapar yazılım kodlama standartları, araçlar veya platformlara dahil ...

Yukarıda verilenlere göre, tahminlerinizde "harcadığım zamanın% 50'si ... yazılım kayıtlarını incelemek ... diğerlerinin hatalarını% 30 düzeltmek" sizi yazılım mimarının normalde yapması beklenenden çok uzakta tuttu.

• Yukarıda size 50+30=80%sahte hakkında verdikleri unvanı verdiğini söyleyebilirim .

Günlükleri analiz etmek veya başkalarının hatalarını gidermek gibi faaliyetlerin başlı başına mimarın zamanının bir kısmını işgal edebileceğini - bunların , bu rolün temel amacına hizmet etmesi koşuluyla - yani üst düzey tasarım seçimleri yapmak ve teknik standartlar oluşturmak olduğunu unutmayın. Aslında, bu her türlü yazılım geliştirme / bakım / test faaliyetleri için geçerlidir.

Örneğin, günlükleri analiz etmek sizi nasıl daha kolay hale getirebileceğinize dair bir fikir verdiyse - tasarım geliştirerek, ya da takım standartlarıyla veya kodlama standartlarıyla - bu, bir mimar için mükemmel şekilde haklı bir çaba olabilir. Benzer şekilde, mimarın belirli hata (ları) düzeltmek için ellerini kirletmesi de tamamen doğru olabilir - bu, daha düşük hata oranına yol açan belirli tasarım / süreç iyileştirmelerine neden olacağı sürece, vs.

_{Biraz daha olumlu bir kayda göre, sorunuz mimar için oldukça önemli olan en az bir beceri gösterir: farklı türdeki aktiviteleri sınıflandırma ve bunlara harcanan çabaları izleme yeteneği. Gözlemlerinizi ve tahminlerinizi özetlemek ve bunları, özellikle yönetim merdivenine kadar açık bir şekilde iletmek için "araç kutusu" tamamlayıcı becerilerinizi eklemeyi düşünün. :)}

Bir yazılım mimarı olarak, o kadar çok günlükleri analiz etmeye ve diğerlerinin hatalarını gidermeye odaklanmam gerekir mi?

Gerekiyordu? Evet ve hayır. Ürün kalitesinin ve evrim yolunun toplamından siz sorumlusunuz - yarın çalışmasını sağlayın, gelecek yıl da çalışmasını sağlayın.
Bu zor meseleleri çözmek için yardım eli vermek anlamına mı geliyor? Kesinlikle - en azından yaparım. Müşterileriniz sizi terk ederse ürünü yarın çalıştıramazsınız.
Bu, vaktinizi TÜM zamanınıza ayırmanız gerektiği anlamına mı geliyor? Kesinlikle hayır. Kalite ve evrimin TOPLAMiyetinden siz sorumlusunuz. Sorunları kovalamaya bu kadar zaman ayırmak karşı üretkendir.

Proaktif olmanız gerekiyordu:

1. Eğitim planlarını başlat, böylece diğer insanlar (dev / destek) yükü kaldırabilir. "Balık tutmayı öğreten biri" ve tüm bu caz.
2. Hata analizi ve kök neden izolasyonunu daha hızlı ve daha kolay desteklemek için yollar geliştirin ve araçlar geliştirin. Bunu sıkıcı bulursanız, diğer, muhtemelen daha az yetenekli ya da deneyimli geliştiriciler, bunu sadece sıkıcı değil, aynı zamanda zor ve hatta korkutucu bulabilir. Teknolojiyle bunun üstesinden gelmelerine yardımcı olun.
3. Ürün kalitesini yükseltmek için çaba sarf edin - basitleştirin, modülerleştirin, test çerçevelerini oluşturun - istifa etmeksizin sızlanıp tehdit etmeyerek, örneğin önderlik edin.
4. Geliştiricilerin ne yaptığınızı ve aynı zamanda yöneticilerinizi bildiğinden emin olun. Bir mimar rolü, diğer insanlarla ilişkiler hakkında çok daha fazla, o zaman kodlama ve analiz ile ilgilidir. Bundan nefret edebileceğiniz kadar, politika burada önemli bir rol oynamaktadır. Meslektaşlarınızın başarılarınızı görmesini sağlamak, daha sonra haklı olduğunuza ikna etmenizi kolaylaştırır. Henüz orada değilseniz, iddialarınızı araştırma ve POC'ler tarafından destekleyin.
5. Diğer her şey başarısız olursa ve yalnızca işleri daha iyi hale getirmek için zaman harcadıktan sonra yöneticinizle konuşun. Becerilerinizin planlama ve tasarım aşamalarında daha iyi kullanıldığını ve mevcut durumu değiştirmek için neler yapılabileceğini görün. Ürününüz bir tutam içinde olabilir ve yöneticinizin cevabı "şu anda bu şey için size ihtiyacımız var" olabilir. Ancak uzun vadeli bir plan üzerinde ısrar ediyorum - mevcut durumu nasıl değiştireceğiz?

Bir mimarın rolünü bir ayrıcalık olarak görüyorum. Ürünü, başka pek çok insanın yapamayacağı şekilde etkileyebiliyorsunuz - teorik olarak sizden daha etkili olan tek ürün Ar-Ge yöneticisi (ve muhtemelen pazarlama).

Bir Yazılım Mimarı'nın rolü geleneksel olarak hataları düzeltmez. Yazılım Mimarları, tasarım sorunlarının yazılımda düzeltilmesine yardımcı olur; böylelikle, yazılımın tasarlanmasının temel yolunu kastediyorsanız, genişletme / sürdürme konusunda daha kırılganlık veya zorluklar yaşatırsa, bu durumda SA’nın yönlerini önermek veya yeniden tasarlamak işidir. Bu problemi çözmek için yazılım.

Ne söylediğini verdim:

Notepad ++ 'da geçirdiğim zamanın% 50'si yazılım kayıtlarını analiz etmek ve neyin yanlış gittiğini anlamaya çalışmak. % 30'u diğerlerinin hatalarını gidermek ve kalanını (varsa) geliştiricilerin spagetti kodunu incelemek.

Bu gerçek bir SA'nın rolü değildir ve bunun yerine geliştirici 1 ve geliştirici 2 seviye programcılarının üst düzey bir geliştiricinin yanında başlayacağı şeyden daha fazlasıdır. Özellikle, şirketimizdeki yeni geliştiricilerin, kod kalitesi konularında bu düzeyde çalışarak ürün ve koda girmelerine gerçekten yardımcı olduğunu buldum. Şirketinizde yeni bir SA mısınız ve sisteme girmek için bu işi yapmanıza neden oluyorlar? Eğer öyleyse o zaman belki kısa bir süre için sorun yok. Bu sizin günlük çalışmanızsa ve bir yıldan uzun süredir çalışıyorsa, muhtemelen başka bir rol aramanın zamanı gelmiştir.

Hayal kırıklığınızı anlıyorum, ancak kodu yazdıysanız veya ilk dokunuşunuz olsaydı, zamanın kısa olduğunu ve size ulaşabileceklerini anlayın, başlığınız ne olursa olsun, birçok yönetici size düzeltmek için gidiyor.

Krizde bulunan gelişim grubunda hala arkadaşlarınız olduğunu belirleyerek, yardımcı olacaksınız. Sorun, onların ve daha da önemlisi, yönetimin size yardımcı olmaya alışması, geri gelmeye devam etmeleridir. “İyi bir tapu cezasız kalmaz” dediği gibi, başlığınız ne olursa olsun, sorunları çözmek için size güvenebilirlerse, sadece başka bir geliştiricisiniz ve kullanabilecekleri başka biri.

Çözülmesi zor bir problem ama benim tavsiyem:

1. Bu yazılım dışı mimar mimarı proje süresi için projenin ücret numarasını isteyin. Proje yöneticilerinin zaman ayırmak için istekli olmadıklarını, bunun için sorumlu olmaları gerekmediğini düşünüyorum.

2. Yöneticinizle ne kadar zamanın kaybolduğu ve hangi grup veya projelerin olduğu hakkında konuşun. Yöneticiniz size yardım etmemenizi ve projelerine odaklanmanızı söyleyebilir. Eğer öyleyse, o zaman diğer grup gelir ve yardım ister, onlara patronunuzun da olmadığını söyleyin.

3. İşlerinizi organize edin, önceliklerinizi açık tutun ve mimari projelerinizin dışına duyarlı olmayın.

4. Bir mimar gibi davranın, akranlarınızın sizi yıllardır aynı geliştiriciyle değil, bir mimar olarak görmesini sağlayın. Başkalarına, tıpkı geliştirici gibi davranma alışkanlığından koptun.

İyi şanslar.

Hayır, büyük resmi yönetmek için buradasınız.

Bir yönetim sorununuz var: hataları düzeltmek ve kod kalitesini iyileştirmek, geliştiricilerin işidir, bir mimar olarak kılavuzlar ve gerçek mimariler (UML veya teknenizi ne kaptırırsa) vermelisiniz, ardından bu kılavuzların doğru bir şekilde takip edildiğinden emin olmak için düzenli kod incelemeleri yapın .

Bununla birlikte, çekirdek mimaride hataları uygulayabilir ve düzeltebilirsiniz.

Örnek: Bir WPF / C # projesinde PRISM, MEF vb. Üzerinde çalışacaksınız, ancak açılış ekranını görüntülemek için XAML üzerinde çalışmayacaksınız.

DB tasarımı üzerinde çalışacaksınız ancak CRUD işlemleri için saklı yordamlar yazmazsınız.

vb.

Cevabın bir kısmı bu yükü almaya istekli bir mühendis bulmak olacaktır.

Elbette, bunun bir problem olması sebebi, bu işi istenmeyen bulmanızdır, bu da diğer mühendislere çekici geldiği mesajını göndermez, bu yüzden onu almaya istekli de değildirler.

İki olasılık görüyorum.

1. Mimarın konumu size daha büyük resim öğeleri üzerinde çalışabilmeniz için verildi.
   Bu durumda, yönetime, bu daha büyük resim öğeleri üzerinde çalışamayacağınızı söylemelisiniz, çünkü kimse daha düşük seviyedeki destek rolünü üstlenmek için adım atmadı. O zaman çözmek onların problemidir.

2. Başlığı büyük ölçüde tören - seni tutmak için atılmış bir kemik.

Bu durumda, yönetim destek yükünüzü hafifletmekle çok ilgilenmeyebilir.

-

Kesinlikle olacak bir şey değil hedef için yararlı ben sorunuzu sızan bkz diğer geliştiriciler ve mühendisler için hor bir tutum benimsemektedir. Bu insanların adım atmasını ve bu sorunları güvenle ele almasını ve böylece yol boyunca bazı hatalar yapmanıza gerek kalmamasını istiyorsunuz. Eğer onların çözümlerini kötüye kullanacağınızı ve daha sonra onlar için düzelteceğinizi biliyorlarsa, muhtemelen hiç yükselmeyeceklerdir.

Notepad ++ 'da geçirdiğim zamanın% 50'si yazılım kayıtlarını analiz etmek ve neyin yanlış gittiğini anlamaya çalışmak. % 30'u diğerlerinin hatalarını gidermek ve kalanını (varsa) geliştiricilerin spagetti kodunu incelemek.

Bu, kesinlikle bu rol için yapmamanız gereken bir tür iş. Tecrübelerime / gözlemlerime göre mimar , ele alınması veya kaçınılması gereken uygulama tasarımına, iyileştirmelere, teknik gereksinim açıklamalarına ve potansiyel performans sorunlarına (günlükleri kontrol etmemek, ancak öncelikli olarak ciddi sorunları / hataları analiz etmek ) dahil olmak zorundadır.

Başka bir deyişle, benim açımdan # 1 - mimarlar, teknolojinin iç çalışmalarının nasıl işlediğine / uygulanmasına ve kullanılması gerektiğine dair uygulamalı deneyime sahip üst düzey tasarımcılar ve sistem entegratörleridir.

Kod kalitesini belirleme ve yönetme fırsatınız varsa, iş yönetimi becerilerinizin geliştirilmesi gerekir. Bu nedenle, iş planlaması "işin nasıl yapılacağı" yaklaşımı konusundaki önceliğiniz olmalıdır.

Nokta # 2 : Bu uygulamalarda birkaç geliştiriciden biriyseniz - bu başlık sizi yeni bir süslü ünvan ile aynı "düzeltmek" rolünde tutmak için şirket yönetimi tarafından sırlandırılan başka bir şekerdir .

Bir Yazılım Mimarının rolü, şu anki şirketinizde yaptığınızdan çok daha fazla. Yazılım tasarım standartlarını tanımlamaktan, üst seviye tasarım yapmaktan, kodlama için standartlardan vb. Sorumlu olmaktan sorumludur ve hataları düzeltmek, aslında aslında olmadığı düşünüldüğünde küçük bir kısmı olarak kabul edilebilir. Ancak dediğiniz gibi, bir ürün üzerinde çalışıyorsunuz demektir, bir Yazılım mimarı olmak, sizden ürünün güvenilirliği için beklentiniz oldukça yüksek olacak ve böyle bir durumda bu tür şeylere katılımınız sadece Ürüne yardımcı olmanın yanı sıra şirkete de oldukça tecrübeli olarak. Ancak, mevcut organizasyonunuza ilginizi çekecek yeni özellik geliştirme ve yeni görevlere biraz maruz kalmanız da sağlanmalıdır.

Bir yazılım mimarı olarak, o kadar çok günlükleri analiz etmeye ve diğerlerinin hatalarını gidermeye odaklanmam gerekir mi?

Konuşma konusunda, 'Evet'.

İşte cevabımı nasıl niteleyeceğim:

1. Varsayılan olarak, yazılım geliştiricilerin günlükleri analiz etmelerine ve hataları gidermelerine izin vermelisiniz.
2. Ancak ... Sen gerekir , bir veri kaybı meydana ekonomik açıdan dezavantajlı bir veritabanı geri alma gerektiren kusurların farkında, Çözmek, geliştiriciler için uzun bir zaman alabilir ya da bir müşteri özrü gerektirir.
   1. Kural olarak, doğrudan raporlarınız bu gibi kusurları size bildirmelidir.
   2. Doğrudan raporlarınızın bu tür kusurlardan bahsetmek için güçlendiği , önemsiz olanları size söylemeye zorlamadığı bir kültür yaratmalısınız .

# 2 hakkında daha fazlası:

1. Bu tür kusurlar genellikle mimari bir başarısızlığa işaret eder. Onlar yaptıklarında, kusurun kesin doğasını anlamalısınız ve bir tamir yapmalısınız.
   1. Bu nedenle, uzantıya göre, günlükleri elemek ve diğer kişilerin hatalarını gidermek için hazır, istekli ve kabiliyetli olmalısınız (doğrudan kaynak kod havuzuna kod işlemeseniz bile).

Bu sorunun cevabı hayır muhtemelen. Neden bu kadar zaman harcıyor ve sorunları destekliyorsunuz? Biri bu işi sana mı veriyor?

Ne yapman gerektiğini açıklığa kavuşturman gerekiyor gibi geliyor. Hataları düzeltmeniz gerekebilir; Bu muhtemelen zamanınızın çoğunluğu olmamalıdır.