ArchScan - Bulgu & kalite raporu

ArchScan kod tabanınızı tarar ve kategori ağırlıklı tek bir kalite skoru ile tam pariteli bir rapor üretir.

Raporun bölümleri

1. Özet skor - kategori ağırlıklı tek skor + durum, sürümler arası karşılaştırılabilir.
2. Bulgular - kod parçacığı ve tam dosya konumuyla.
3. SOLID dökümü - ihlaller beş ilkeye göre ayrıştırılır.
4. Paketler - bağımlılıklar ve sürümler.
5. Projeler - proje bazında metrikler.
6. Bağımlılık haritası - interaktif grafik görünümü.
7. Dışa aktarım - paylaşılabilir HTML/PDF; rapor dilini workspace bazında seçersiniz.

Skor nasıl hesaplanır?

Mimari, SOLID, bağımlılık ve metrik kategorileri ağırlıklarına göre tek bir skora indirgenir. Tarama sizin kendi CI’nızda çalışır.

Analitik panosu

ArchScan giriş sayfası, asenkron yüklenen çalışma alanı geneli bir panodur:

• Denetlenen proje, ortalama skor, açık bulgu, bu ayki denetimler - başlık kartları.
• Tarama eğilimi - son 12 haftanın koşu sayısı ve ortalama skoru.
• Genel durum - not halkası (A-E), kapsam ve sonuç çubukları, çalışma temposunu gösteren hız göstergesi.
• Dil kırılımı - dil başına proje, taranan pay, ortalama skor ve başarısızlık.
• Ne değişti - skoru en çok yükselen ve düşen projeler.

Kod Sağlığı (Code Health)

ArchScan → Code Health, skorun cevaplamadığı soruyu cevaplar: borç nerede. Bir projenin son koşusunu, Tüm projeler seçiliyken taranmış her projenin son koşusunu birleştirerek okur:

• Dosya risk haritası - karonun alanı yoğunlaşmış risk (bulgu × dosyanın en karmaşık metodu), rengi içindeki en kötü şiddet. Küçük dosyalar “diğerleri” karosuna katlanır, hiçbir şey sessizce düşmez.
• Karmaşıklık dağılımı - metotlar döngüsel karmaşıklığa göre bantlanır (1-5 / 6-10 / 11-20 / 21+), en kötü metot adıyla gösterilir.
• İlkeye göre tasarım borcu - bulgular kuralın koruduğu ilkeye göre gruplanır (SOLID, DRY, KISS, YAGNI).
• Ana dizi üzerinde bileşenler - her modül soyutluk × kararsızlık düzleminde; acı bölgesi ve işe yaramazlık bölgesi işaretlidir.
• Sıcak noktalar - bulgu ve karmaşıklığın kesiştiği dosyalar.

Metrik göndermeyen bir runner’ın projesi ölçülmedi olarak raporlanır - asla sıfır olarak değil.

Bağımlılık Sağlığı (Dependency Health)

ArchScan → Dependencies, proje başına paket listelerini kurulum geneli cevaplara çevirir:

• Paket tablosu - projeye değil pakete göre: hangi paket kaç projeyi geride tutuyor, en kötü sabitleme kaç sürüm geride, hangi proje hangi sürümde. Birden çok sürümde sabitlenmiş paket çatallanmış olarak işaretlenir.
• Platform sürümleri - her deponun bildirdiği SDK/runtime (csproj/global.json, pyproject.toml, go.mod, pom.xml, Gemfile, composer.json, package.json); “kim hâlâ .NET 6’da” tek bakışta. Yedi collector dili de bildirir.
• Proje satırları - toplamlar, güncellik dağılımı ve çözümlenemeyen sorgular (kapalı ağdaki runner kayıt defterine soramaz - bu bilinmiyor olarak raporlanır, güncel olarak değil).

SmartScan

ArchScan → SmartScan, bir .NET projesinin her web giriş noktasını, Quartz job’ını, arka plan servisini ve MassTransit consumer’ını servisler ve handler’lar üzerinden ORM’e (Entity Framework, Dapper) kadar izler ve bu zincirde gördüğü riskleri raporlar. Bir uyarı modülüdür: puanı düşürmez, pipeline’ı durdurmaz. Riski olmayan zincir hiçbir şey göndermez.

• Kayıt bulunamadı - bir sorgu (FirstOrDefault, Find, …) boş dönebilir ve sonuç kontrol edilmeden kullanılır. Etki, isteğin 500 ile mi bittiğini yoksa yukarıdaki genel bir catch’in bunu yanlış bir mesaja mı çevirdiğini söyler.
• Yarım kalan yazma - tek istek, etrafında transaction olmadan birden fazla kez commit eder.
• Kolondan uzun değer, eksik zorunlu değer, tekrarlanan değer - bir istek alanı, yolda eşleşen bir kural olmadan sınırlı, NOT NULL ya da benzersiz bir kolona ulaşır.
• Kodun okuyamadığı istek değeri (.NET, Java, Kotlin, Python, Go, Ruby, PHP) - istekten gelen bir değer önce kontrol edilmeden int.Parse, Guid.Parse, Convert.ToInt32 gibi bir metotla okunur; hatalı bir değer 400 yerine 500 ile biter. İsteğin işaret ettiği kaydı First / Single ile okumak da aynı şekilde Kayıt bulunamadı altında gösterilir: kayıt yoksa istek “bulunamadı” yerine 500 ile biter.
• İlişkili kayıtların engellediği silme (.NET, Java, Kotlin, Python, Go, Ruby, PHP) - başka kayıtlar Restrict, NoAction ya da ClientSetNull ile hâlâ ona bağlıyken bir kayıt gerçekten silinir (yumuşak silme değil); veritabanı silmeyi yabancı anahtar hatasıyla reddeder. Bu kayıtları önce kontrol eden, silen ya da başka kayda bağlayan akışlar gösterilmez.
• Kolonun tutamayacağı değer (.NET; decimal durumu Java, Kotlin, Python, Go, Ruby, PHP’de de; enum durumu Ruby ve PHP’de de) - decimal(p, s) kolonunun tutabileceğinden büyük bir sayı, istekte gönderilmeyebilecek bir tarihin SQL Server datetime kolonuna 0001-01-01 olarak gitmesi ya da tanımsız bir değerin PostgreSQL enum kolonuna ulaşması.

Bir proje seçin, bir kategoriyi açın; riskler katman ve servise (ya da istek tipine) göre gruplanır. Açılan risk, zinciri dosya ve satırıyla adım adım, kodu, çözümü ve bir yapay zeka asistanına kopyalanabilecek prompt’u gösterir. Risk kapatılabilir (yanlış alarm, kabul edilen risk, düzeltilmeyecek) ve aynı risk bulunduğu sürece kapalı kalır.

Consumer için etki, yeniden denenen (genel bir catch arkasında yutulan) mesajdır; job için başarısız bir çalışmadır. Job’ın bir isteği olmadığından yalnızca yarım kalan yazma açısından denetlenir; döngüde her turda commit job’ın tasarımıdır, risk değildir.

Bir TypeScript frontend’inde (React, Next.js) zincir kullanıcının işlem yaptığı ya da framework’ün render ettiği yerde başlar - bir JSX olay handler’ı, bir useEffect, sunucu tarafı render (getServerSideProps, async sayfa), bir Next.js route handler’ı - ve hook’lar, Redux thunk’ları ve servisler üzerinden isteğe (fetch, axios) iner; istemci isteğinden projenin kendi API route’una geçiş de buna dahildir. Oradaki kategoriler: Yakalanmayan istek (hiçbir yerde yakalanmayan istek hatası: kullanıcıya bir şey söylenmez ya da sunucu tarafı render 500 döner), Hata başarı gibi taşınıyor (yakalanıp sıradan bir değer olarak dönen hata, veri gibi okunan fetch hata yanıtı, kimsenin bakmadığı thunk reddi), Kayıt bulunamadı (o boş değer sonra okunur ve ekran hata verir) ve Yarım kalan yazma (kendi backend’ine art arda iki yazma isteği). Her hatayı kullanıcıya gösteren bir HTTP istemcisi (interceptor’da toast) hatayı ele almış sayılır.

Ruby on Rails ve Kotlin Spring backend’leri .NET gibi izlenir: controller action’ları (ve Grape uç noktaları), job’lar ve consumer’lar ActiveRecord ya da Spring Data / JPA’ya kadar, aynı kategorilerle; kolon sınırları db/schema.rb’den ya da @Column işaretlerinden okunur. Android (Kotlin) ve iOS (Swift) uygulamaları bir frontend gibi izlenir: dokunuştan, ekranın yaşam döngüsünden ya da view model’den isteğe kadar (Retrofit, OkHttp, Ktor; URLSession, Alamofire, Moya). Orada coroutine’den kaçan yakalanmamış bir istek hatası ya da bir try! uygulamayı çökertir; nil’e ya da varsayılan bir değere çevrilen hata, başarı gibi taşınan hata olarak raporlanır.

Java (Spring Data, JPA, JdbcTemplate, MyBatis), Python (Django ve DRF, Flask, FastAPI, Celery; Django ORM, SQLAlchemy), Go (net/http, gin, echo, chi, fiber, gRPC; database/sql, sqlx, GORM, pgx) ve PHP (Laravel, Symfony; Eloquent, Doctrine) backend’leri de aynı şekilde, aynı kategorilerle izlenir. Go’da bulunamayan kayıt null değil bir hatadır: yok sayılan bir ‘bulunamadı’ hatası yüzünden boş bir kayıt bulunmuş gibi kullanılıp istek başarılı yanıt veriyorsa bu sessiz etkiyle gösterilir. Go ayrıca hatası atılan bir yazmayı da raporlar (çıplak db.Create(...), _ = ya da yalnızca loglanan hata) ve istek yine başarı döner: istemciye veri kaydedildi denir ama kaydedilmemiş olabilir.

SmartScan proje bazında açılır, varsayılan olarak kapalıdır: Proje → Ayarlar → Tarama → SmartScan’i çalıştır. Açıldıktan sonra bir sonraki pipeline çalışmasından itibaren o projenin derin taramalarında çalışır; pipeline’da değişiklik gerekmez. SmartScan modülünün açık olması gerekir; yönetici Yönetim → Ayarlar → Modüller altından kapatabilir.