Başlangıçta büyük ve eski bir projeyi anlamak her zaman zordur. Mimarlık, mimar değerlendirme faaliyetlerinden biridir. Genellikle büyük, eski projelerle çalışmanız gerekir ve sonuçların bir hafta içinde teslim edilmesi gerekir.
Bir haftada 100 veya daha fazla kod satırından oluşan bir projenin değerlendirilmesi ve aynı zamanda müşteriye gerçekten yararlı sonuçlar sağlanması.
Çoğu mimar ve teknik lider benzer proje değerlendirmeleriyle karşılaştı. Bu, şirketimizde yapıldığı gibi yarı resmi bir süreç veya ayrı bir hizmet gibi görünebilir, öyle ya da böyle çoğunuz bununla uğraşmışsınızdır.
Rusça konuşmayan arkadaşlarınız için İngilizce orijinali burada: .
Şirketimizin yaklaşımı
Şirketimizde işlerin nasıl yürüdüğünü ve benzer durumlarda nasıl davrandığımı anlatacağım ancak siz projenizin ve şirketinizin ihtiyaçlarına göre bu yaklaşımı kolaylıkla değiştirebilirsiniz.
İki tür mimari değerlendirme vardır.
Iç – bunu genellikle şirket içindeki projeler için yapıyoruz. Herhangi bir proje çeşitli nedenlerden dolayı mimari değerlendirme talep edebilir:
- Ekip, projelerinin mükemmel olduğunu düşünüyor ve bu şüpheli. Bu tür vakalarla karşılaştık ve çoğu zaman bu tür projelerde her şey ideal olmaktan uzaktır.
- Ekip projelerini ve çözümlerini test etmek istiyor.
- Takım işlerin kötü olduğunu biliyor. Ana sorunları ve nedenleri bile listeleyebilirler, ancak sorunların tam bir listesini ve projenin iyileştirilmesine yönelik önerileri isteyebilirler.
Harici iç değerlendirmeden daha resmi bir süreçtir. Müşteri her zaman yalnızca tek bir durumda, her şey kötü olduğunda - çok kötü olduğunda gelir. Genellikle müşteri küresel sorunların olduğunu anlar, ancak nedenleri doğru bir şekilde belirleyemez ve bunları bileşenlere ayıramaz.
Bir mimariyi harici bir istemci için değerlendirmek daha karmaşık bir durumdur. Süreç daha resmi olmalı. Projeler her zaman büyük ve eskidir. Pek çok sorunları, hataları ve çarpık kodları var. Yapılan çalışmalara ilişkin ana sorunları ve iyileştirme önerilerini içeren bir raporun en geç birkaç hafta içinde hazır olması gerekmektedir. Dolayısıyla projenin dış değerlendirmesini ele alırsak, iç değerlendirme çocuk oyuncağı olacaktır. En zor durumu ele alalım.
Kurumsal proje mimarisi değerlendirmesi
Değerlendirilecek tipik bir proje, birçok sorunu olan büyük, eski bir kurumsal projedir. Bir müşterimiz bize geliyor ve projesini düzeltmemizi istiyor. Tıpkı bir buzdağında olduğu gibi, müşteri sorunlarının yalnızca ucunu görür ve suyun altında (kodun derinliklerinde) ne olduğu hakkında hiçbir fikri yoktur.
Müşterinin şikayet edebileceği ve farkında olabileceği sorunlar:
- Performans sorunları
- Kullanılabilirlik sorunları
- Uzun vadeli dağıtım
- Birim ve diğer testlerin eksikliği
Müşterinin büyük olasılıkla farkında olmadığı ancak projede mevcut olabileceği sorunlar:
- Güvenlik sorunları
- Tasarım sorunları
- Yanlış mimari
- Algoritmik hatalar
- Uygunsuz teknolojiler
- Teknik borç
- Yanlış geliştirme süreci
Resmi mimari inceleme süreci
Bu firma olarak takip ettiğimiz resmi bir süreçtir ancak siz firmanıza ve projenize göre özelleştirebilirsiniz.
Bir müşteriden gelen istek
Müşteri mevcut projenin mimarisini değerlendirmeyi ister. Tarafımızdaki sorumlu kişi projeyle ilgili temel bilgileri toplar ve gerekli uzmanları seçer. Projeye bağlı olarak bunlar farklı uzmanlar olabilir.
Çözüm Mimarı – değerlendirme ve koordinasyondan sorumlu asıl kişi (ve çoğunlukla tek kişi).
Spesifik uzmanlar yığını – .Net, Java, Python ve projeye ve teknolojilere bağlı olarak diğer teknik uzmanlar
Bulut uzmanları – bunlar Azure, GCP veya AWS bulut mimarları olabilir.
Altyapı – DevOps, Sistem yöneticisi vb.
Diğer uzmanlar – büyük veri, makine öğrenimi, performans mühendisi, güvenlik uzmanı, QA lideri gibi.
Proje hakkında bilgi toplamak
Proje hakkında mümkün olduğunca fazla bilgi toplamalısınız. Duruma göre farklı teknikler kullanabilirsiniz:
- Anketler ve posta yoluyla diğer iletişim yöntemleri. En etkisiz yol.
- Çevrimiçi toplantılar.
- Bilgi alışverişi için özel araçlar, örneğin: Google doc, Confluence, depolar vb.
- Sahada “canlı” toplantılar. En etkili ve en pahalı yol.
Müşteriden ne almalısınız?
Temel bilgiler. Proje neyle ilgili? Amacı ve değeri. Geleceğe yönelik ana hedefler ve planlar. İş hedefleri ve stratejileri. Temel sorunlar ve istenilen sonuçlar.
Proje bilgisi. Teknoloji yığını, çerçeveler, programlama dilleri. Şirket içi veya bulut dağıtımı. Proje bulutta ise hangi hizmetler kullanılıyor? Hangi mimari ve tasarım kalıpları kullanıldı?
İşlevsel olmayan gereksinimler. Sistemin performansı, kullanılabilirliği ve kullanım kolaylığı ile ilgili tüm gereksinimler. Güvenlik gereksinimleri vb.
Temel kullanım durumları ve veri akışları.
Kaynak koduna erişim. En önemli kısım! Projenin nasıl oluşturulacağına ilişkin depolara ve belgelere mutlaka erişmelisiniz.
Altyapıya erişim. Canlı sistemle çalışmak için sahne veya prodüksiyon altyapısına erişimin olması güzel olurdu. Müşterinin altyapıyı ve performansı izlemeye yönelik araçlara sahip olması büyük bir başarıdır. Bir sonraki bölümde bu araçlardan bahsedeceğiz.
Belgeleme. Müşterinin belgeleri varsa bu iyi bir başlangıçtır. Güncelliğini yitirmiş olabilir ama yine de iyi bir başlangıçtır. Hiçbir zaman belgelere güvenmeyin; bunları istemciyle, gerçek altyapıda ve kaynak kodunda test edin.
Mimari Değerlendirme Süreci
Bu kadar büyük miktarda bilgiyi bu kadar kısa sürede nasıl işleyebiliriz? Öncelikle işi paralelleştirin.
DevOps altyapıya bakmalıdır. Teknoloji kodun içine giriyor. Performans ölçümlerini görüntülemek için performans mühendisi. Bir veritabanı uzmanı veri yapılarını daha derinlemesine incelemelidir.
Ancak bu, çok fazla kaynağa sahip olduğunuzda ideal bir durumdur. Genellikle bir ila üç kişi bir projeyi değerlendirir. Tahmini kendiniz bile yapabilirsiniz; projenin tüm alanlarında gerekli bilgi ve deneyime sahipseniz bu genellikle geçerli olur. Bu durumda tüm süreçleri mümkün olduğunca otomatikleştirmeniz gerekir.
Ne yazık ki, belgeleri manuel olarak okumanız gerekecek. Doğru miktarda deneyimle dokümantasyonun kalitesini hızlı bir şekilde anlayabilirsiniz. Doğru olan ve gerçeklikle açıkça örtüşmeyen şey. Bazen gerçek hayatta hiçbir zaman işe yaramayacak mimariyi belgelerde görebilirsiniz. Bu, projede gerçekte nasıl yapıldığını düşünmeniz için bir tetikleyicidir.
Proje değerlendirmesini otomatikleştirmek için faydalı araçlar
Kod değerlendirmesi basit bir alıştırmadır. Size tasarım, performans ve güvenlik sorunlarını gösterecek statik kod analizörlerini kullanabilirsiniz. İşte bunlardan birkaçı:
bir mimar için harika bir araçtır. Size büyük resmi, modüller arasındaki bağımlılıkları ve yeniden düzenleme için potansiyel alanları gösterecektir. Tüm iyi araçlar gibi, maliyeti de yüksektir, ancak 30 günlük deneme sürümünden yararlanabilirsiniz.
- eski güzel bir araç. Statik kod analizi için bir araç. 20'den fazla programlama dili için hatalı kodları, hataları ve güvenlik sorunlarını tanımlamanıza olanak tanır.
Tüm bulut sağlayıcılarının altyapı izleme araçları vardır. Bu, altyapınızın etkinliğini maliyet ve performans açısından doğru bir şekilde değerlendirmenize olanak sağlayacaktır. AWS için bu . Azure için çok kolay .
Ek performans izleme ve günlük kaydı, her düzeydeki performans sorunlarının bulunmasına yardımcı olacaktır. Etkisiz sorguların olduğu bir veritabanından başlayıp ön uçla bitiyor. Müşteri bu araçları daha önce yüklememiş olsa bile performans sorunlarını belirlemek için bunları mevcut sisteme oldukça hızlı bir şekilde entegre edebilirsiniz.
Her zaman olduğu gibi, iyi araçlar buna değer. Birkaç ücretli araç önerebilirim. Elbette açık kaynak kullanabilirsiniz ancak bu daha fazla zamanınızı alacaktır. Ve bu, mimari değerlendirme sürecinde değil, önceden yapılmalıdır.
– uygulama performansını değerlendirmek için bir araç
– bulut sistemi izleme hizmeti
Güvenlik testi için birçok araç mevcuttur. Bu sefer size ücretsiz bir sistem tarama aracı önereceğim.
– web uygulamalarını güvenlik standartlarına uygunluk açısından taramak için bir araç.
Her şeyi bir bütün halinde bir araya getirelim.
Rapor hazırlamak
Raporunuza müşteriden topladığınız verilerle başlayın. Proje hedeflerini, kısıtlamaları ve işlevsel olmayan gereksinimleri açıklayın. Bundan sonra tüm girdi verileri belirtilmelidir: kaynak kodu, dokümantasyon, altyapı.
Sonraki adım. Manuel olarak veya otomatik araçları kullanarak bulduğunuz sorunları listeleyin. Otomatik olarak oluşturulan büyük raporları uygulamalar bölümünün sonuna yerleştirin. Bulunan sorunlara ilişkin kısa ve öz kanıtlar bulunmalıdır.
Hata, uyarı, bilgi ölçeğinde bulunan sorunları önceliklendirin. Kendi ölçeğinizi seçebilirsiniz, ancak genel olarak kabul edilen ölçek budur.
Gerçek bir mimar olarak, bulunan sorunları düzeltmek için önerilerde bulunmak sizin sorumluluğunuzdadır. Müşterinin elde edeceği iyileştirmeleri ve iş değerini açıklayın. İş değeri nasıl gösterilir? daha önce tartışmıştık.
Küçük yinelemelerle bir yol haritası hazırlayın. Her yinelemenin tamamlanma süresi, açıklama, iyileştirme için gereken kaynak miktarı, teknik değer ve iş değeri içermesi gerekir.
Mimari değerlendirmeyi tamamlıyoruz ve müşteriye bir rapor sunuyoruz
Asla sadece bir raporu postayla göndermeyin. Hiç okunmayabilir veya uygun bir açıklama yapılmadan okunup anlaşılmayabilir. Kısacası canlı iletişim, insanlar arasındaki yanlış anlamaların ortadan kaldırılmasına yardımcı olur. Müşteriyle bir toplantı planlamalı ve en önemli olanlara odaklanarak bulunan sorunlar hakkında konuşmalısınız. Müşterinin dikkatini, farkında bile olmadığı sorunlara çekmek faydalı olacaktır. Güvenlik sorunları gibi ve bunların işi nasıl etkileyebileceğini açıklayın. Yol haritanızı iyileştirmelerle gösterin ve müşteri için daha uygun olan farklı seçenekleri tartışın. Bu zaman, kaynaklar, iş miktarı olabilir.
Toplantınızın özeti olarak raporunuzu müşteriye gönderin.
Sonuç olarak
Mimari değerlendirme karmaşık bir süreçtir. Değerlendirmeyi doğru bir şekilde gerçekleştirmek için yeterli deneyim ve bilgiye sahip olmanız gerekir.
Müşteriye sadece bir hafta içinde kendisi ve işi için faydalı sonuçlar sağlamak mümkündür. Bunu tek başına yapsan bile.
Deneyimlerime göre birçok iyileştirme yarıda indirildi ve bazen hiç başlatılmadı. Kendileri için altın yolu seçenler ve iş için en yararlı iyileştirmelerin yalnızca bir kısmını minimum işçilik maliyetiyle gerçekleştirenler, ürünlerinin kalitesini önemli ölçüde artırdı. Hiçbir şey yapmayanlar birkaç yıl sonra projeyi tamamen kapatabildiler.
Amacınız müşteriye minimum fiyat karşılığında maksimum iyileştirmeleri göstermektir.
Bölümdeki diğer makaleler boş zamanınızda okuyabilirsiniz.
Size temiz kod ve iyi mimari kararlar diliyorum.
Facebook grubumuz - .
Kaynak: habr.com