Eski bir uygulamada tutarlı bir mimari başlatma

Asp.Net tabanlı büyük bir web sitesi için sorumluluğum var. Şu anda bir web sitesi (web uygulaması değil), bazı windows hizmetleri ve bir dizi sınıf kütüphanesidir.

Veri katmanı, LLBLGEN ve Linq To LLBGen'in bir karışımının yanı sıra yeniden düzenlenmemiş bir dizi eski satır içi SQL örneğini kullanır.

Bazı yönetici tipi uygulamaları vardır, ancak çoğu durumda uygulama Akıllı UI anti-desenini sergiler (yani sınıfların arkasındaki kodda çok fazla iş mantığı)

Site oldukça yüksek trafik ve performans iyi, ancak geliştirme yeteneğimizi yaklaşık 10 kişilik bir ekibe dönüştürüyoruz ve giderek artan bir şekilde mevcut ara katman yazılımının üstünde kapsayıcı katmanlı bir tasarıma ihtiyacımız olduğu açıktır.

Benim sorum nereden başlamalı? 10 yıllık kodumuz var (bazıları hala gerçekten ASP Klasik şeyler geçirdi), birçok farklı yaklaşım ve stilleri var.

Kod tabanının tamamını yeniden düzenlemek gerçekçi değildir ve muhtemelen istenmez

Bunun yeni bir durum olmadığını biliyorum, bu soruna nasıl yaklaşılacağı konusunda yararlı fikirler veya kavramlar var mı?

Ben de benzer durumlarda çalışıyorum ve size aşağıdaki tavsiyelerde bulunabilirim.

1. Teknik borcu azaltmanız gerekiyor . Şimdi. Neden? Çünkü teknik borç finansal borç gibidir. Ona faiz ödeyeceksiniz.
2. Kod tabanının tamamının yeniden düzenlenmesi mümkün olmadığından, kendinize sorun: önleyen nedir? Sadece çok fazla iş mi? Neden?
3. Zaman içinde teknik borcu azaltmak için bir plan oluşturun. Örneğin, kurallar " ekibin dokunduğu her kod parçası yeni standarda sabitlenmeli / yeniden düzenlenmelidir " şeklinde ayarlanarak . Tipik olarak: birim testleri yazılmalı, kod doğru katmanlarda taşınmalıdır, vb.
4. Saçmalığı sar. Ayrıştırma, yeniden düzenleme ve iyi mimarinin anahtarıdır. Kod tabanını bir şekilde bölümleyebiliyorsanız, daha küçük bitleri yeniden düzenleyebilirsiniz.
5. Teknoloji borcunu daha fazla artırmayın. Teknoloji borcunu daha fazla artırmayın. Teknoloji borcunu daha fazla artırmayın. Yapma...

Tüm kod tabanının yeniden düzenlenmesi istenmiyor. Yeniden düzenleme, bu gelişmeyi daha pürüzsüz hale getirmek için yeni geliştirmeden önce yaptığınız bir şeydir. Kod tabanınızdaki tüm kodu değiştirmeyi planlamıyorsanız, yeniden düzenleme, verimsiz bir zaman kullanımını kanıtlayacaktır.

Sklivvz'in söylediklerine ek olarak bazı tavsiyeler:

1. Kodu sık ve nadiren değiştirilmiş bölümlere ayırın. Sadece sık sık değiştirilen bölümlerin tamamen yeni mimariye getirilmesi gerekir. Nadiren değiştirilmiş kodu, mümkün olduğunca az değişiklik kullanarak (veya ondan kurtulabiliyorsanız değişiklik yapmadan) yeni mimariye entegre edin. Tam yeniden yazmanın cazibesine karşı koy, ondan daha pahalıya mal olacak. Çirkin olsa bile, mevcut kodun çalıştığını takdir edin.

2. Yeniden düzenleme hedefinizin ne olduğunu öğrenin. Siteye içerik eklemeyi kolaylaştırmak ister misiniz? Çok fazla hatanız var ve kullanıcı tarafından algılanan kaliteyi artırmak mı istiyorsunuz? Bunun yerine özellik geliştirme süresini azaltmak istiyor musunuz? Yoksa daha iyi bir UX mi istiyorsunuz? Mimariniz belirlediğiniz hedeflere ulaşmak için kodu yeniden düzenlemeyi kolaylaştırmalıdır. Yeniden düzenlemenizin birincil faydalanıcısının sizin kullanıcı / müşteri / işiniz olması gerektiğini asla unutmayın. Temiz kod kendi başına bir hedef değildir, bir son için bir yöntemdir ve son bir kullanıcıyı içerir.

3. Mümkün olduğunca çok referans mimarisi bulmaya çalışın ve bunları kopyalamaktan korkmayın. Tekerleği yeniden icat etme. Başka birinin sizinki gibi siteler için iyi çalışan bir mimarisi varsa, onlardan öğrenin.

4. İşlerin insan yönetimi yönünü düşünün. Kendi göç projelerimde en zor kısım insanların yeni yolları öğrenmesini ve onlara bağlı kalmasını sağlamaktı. Referans uygulamalara ve mimariyi ekipteki herkese (hem eski hem de yeni) öğretmenin bir yoluna ihtiyacınız olacak. Değişime karşı direnci azaltmak için, karar vermeden önce ekipteki herkesin girdisini isteyin. Yeni tasarımın aslında şeyleri geliştiricilerin kişisel bakış açısıyla geliştirdiğinden ve derinliklerinden hissettikleri büyük bir sıçrama olmadığından emin olun.

Eski bir kod temeli ile uğraşmaya çalışırken gördüğüm EN önemli şey, ne çekim yaptığınızı değiştirmeye devam etmemektir. Yani, istediğiniz mimariyi anlayın, sonra BU PLANLA YAPIN! Son konumumdaki en büyük sorunlardan biri, kod tabanının zaman içinde nasıl görünmesi gerektiğine dair birkaç farklı fikre sahip olmasıydı. Her yeni fikir denendiğinde, kodun bazıları dönüştürüldü, bazıları değişmedi ve daha sonra birisinin daha iyi bir fikri vardı. Zamanla giderek tutarsızlaştı ve sonunda hurdaya çıkarıldı.

Yeniden yapılanma eski yazılımı hakkında gerçekten güzel bir ücretsiz kitap / pdf var: http://scg.unibe.ch/download/oorp/

OO başlığında diyor ama fikirlerin çoğu herhangi bir yazılım için geçerlidir. Nereden başlayacağınızı, yeniden yapılanma sırasında sistemin farklı bölümleriyle nasıl başa çıkılacağını ve bu konuların çok daha fazlasını tartışıyor.

Tutarlı bir mimariye sahip değilse, bunun nedeni yönetimin sorunu anlamaması / umursamamasıdır. Sadece kodla. Yeni kod yazarken yeni iyi mimariyi tanıtmalısınız.

Bazı şeyleri ancak gerçekten ciddi hatalara sahip olmaya başlıyorlarsa, yeniden genişletmelisiniz, genişletmeniz gerekiyor ve yapamıyorsunuz, ya da sadece gereksinimlerine uymuyor.

Temel olarak sadece yöneticilerinizin gerçekten önemsediği sorunları önemsediğimi söylüyorum.

Yönetime yeniden mimari satabiliyorsanız, teste başlayın. Teste yatırım yapmak istemezlerse, çabalarınız sadece size sorun çıkarır.