“Süper” siteler için ve bu siteler için nelere dikkat edilmelidir?

Şirketim, tüm 1. kademe uygulamalarını (yani üst düzey üretim) ve siteleri her şeyi kapsayan tek bir kod tabanında birleştirmeyi düşünüyor.

Teori, izinlerinin, tasarımının ve genel işlevselliğinin homojenize edilebileceği ve merkezi olarak yönetilebileceği yönündedir.

Her bir yaklaşımı destekleyen veri yapıları çok farklı olduğundan, iş kuralları her uygulama için karmaşık ve benzersiz olduğundan ve mevcut uygulamalar için genel kod tabanları son derece farklı ve ihmal edildiğinden, bu yaklaşımla ilgili kaygılarım yok.

DÜZENLE :

Mevcut ortam, ilk yazıldığından beri neredeyse hiç gerçek bir sevgi görmemiş olan üç ASP.Net 1.1 sitesinden (esas olarak şirkette deneyimli geliştiricilerin yokluğundan dolayı) ve aynı zamanda bir ASP.Net 1.1 sitesi olan bir MVC2 uygulamasından oluşmaktadır. geçen sene yükseltti. Biz sadece C # yazıyoruz.

Şirket, yaklaşık 50 personeli ile oldukça küçük bir şirkettir; bunlardan üçü gerçek geliştiriciler. Yönetim (hatta BT yönetimi), BT projelerinin proje yönetimi dışında BT arka planına veya deneyimine sahip değildir (ve bu nedenle bazı terminoloji ve iş etkileri hakkında bilgi sahibidir).

Uygulamalar esas olarak şirket tarafından satılan ürünleri desteklemek için çevrimiçi hizmetlerdir. Şirket doğrudan yazılım satmıyor.

Bu nedenle, tüm durumu makul ve cevaplanabilir bir soruyla ifade etmek için: Mevcut koşullar (ör. Eski kod tabanı, karmaşık iş sistemleri ve kurallar) göz önüne alındığında, tüm sistemlerinizi tek bir aşırı kemerli çözümde bir araya getirmeye çalışmanın ve almanın zorlayıcı nedenleri nelerdir? )?

Kötü bir fikir

Bu reaksiyon aşağıdaki varsayımlara dayanmaktadır:

1. Homojenleştirilen birçok farklı uygulama var
2. Farklı uygulamalar üzerinde çalışan birçok takım var
3. Uygulamaları etkin bir şekilde yöneten saygın ve yetkili bir yazılım mimarı yoktur

Eğer devam edersen ne olacak

Büyük olasılıkla, her şeyi tek bir tasarım yaklaşımı altında bir araya getirmek için inital birleştirilmiş bir çaba olacaktır. Bu, her şeyin aynı şekilde çalışması için gereken büyük çabayı gösterecek ve işlenemez olarak konserve haline gelebilir.

Üzerine basarsa, yapılandırma verilerini içeren bir tür merkezi depo (örn. Güvenlik erişimi, günlük kaydı düzeyleri vb.)

"Hey, neden bu haricilaştırılmış yapılandırma yaklaşımını eski uygulamalara uyarlamıyoruz, çok daha hızlı olacak?"

ve bir süre sonra bir başkası

"Ve yine de yeniden düzenleme yaptığımız için, neden sadece uygulama alanlarının her biri için bir tasarım standardı uygulamıyoruz - web işleme böyle görünüyor, iş kuralı bu şekilde işliyor ve veritabanı erişimi böyle oluyor."

sonuna kadar

"Oh, ve burada kolayca paylaşılan bazı kütüphaneleri bir araya getirmemek için birçok ortak kod var. Muhtemelen her gece düzenli aralıklarla bir çeşit entegrasyon derlemesine ihtiyacımız olacak."

Bu noktada herkes muazzam bir monolitin inşa edilmediğine dair rahat bir nefes alır.

Şirketimde bunun üzerinde çalışıyoruz. Bence bu mümkün ve bariz faydalar var (bunlardan bahsettiniz), ancak bu muhtemelen en az 5 ila 7 yıllık bir proje olacak ve temel olarak her şeyin yeniden yazılmasını gerektiriyor. Böyle bir şeye imza atabilirseniz, bunun için git derim. Değilse, kabus ölüm yürüyüşü için hazırlanın.

Google bunu yapar, bu yüzden kesinlikle mümkündür .

Bu bağlantı BTW, bir Google çalışanının kod tabanlarını, sürekli entegrasyonunu, testlerini vb. Nasıl yönettikleri hakkında ilginç bir sunumdur.

Bununla birlikte, benzer şekilde güçlü bir takım taahhüdü olmadan, Google'ın yaptığı gibi, muhtemelen bir incinme dünyası içindesiniz.

Burada kilit soru neden ? Üst yönetim neden bunu yapmak istiyor? Hangi tasarrufları, kaldıraçları veya diğer avantajları kazanmayı umuyorlar?

Eğer ele alabilir Eğer yeterince onların hedefleri gerçekleştirmek öyle ki bu sorunların hala hepsine aynı etkili sonuçları verirken, iyi, endişeleri bu tek kod tabanını sen önleyebilir.

Benzer bir süreçten geçiyoruz. Bir süredir var olan bir ürünümüz vardı. Geçen yıl birincisi ile% 95 aynı olan, bazen% 5'i bazen ince ama önemli farklılıkları olan başka bir ürünü tanıttık, bu farklılıklar ayrı bir ekip tarafından geliştirilecek ve korunacak.

Yeni ürün üzerinde çalışmaya ilk başladığımızda, eski ekip yeni ürünü anlamadıklarından bizi% 5'in üzerinde olumsuz etkileyen değişiklikler yapmaya devam etti. Bu yüzden kodun% 5'ini tamamen çatalladık, bu da ilk sürümü zamanında bitirmemizi sağladı.

Sonra daha fazla bakım çalışması başladı ve neredeyse aynı kodda neredeyse aynı değişiklikleri yaptığımızı gördük. Eski ekip de şimdi yeni ürün hakkında çok daha iyi bir anlayışa sahip, bu yüzden çatallandıklarımızı yavaş yavaş yeniden entegre ediyoruz ve farklılıkları ifade etmek için daha verimli mimari yollar buluyoruz.

Veri yapılarının farklı olduğunu ve genel kod tabanlarının farklı olduğunu söylediğinizde, soracağım soru, bu şekilde olmaları gerekip gerekmediği ya da o anın uygunluğu nedeniyle nasıl geliştikleri. Açıkçası, farklı iş kurallarını ve gereksinimlerini hesaba katmanız gerekir, ancak anahtar, bu farklılıkları mümkün olduğunca küçük bir modüle ayırmaktır. Sıklıkla aynı özelliği farklı kod tabanları için birden fazla müşteri için biraz farklı şekillerde uyguladığınızı düşünüyorsanız, konsolidasyon gerçekten yardımcı olabilir ve durumun veya yönetimin muhtemelen bunu teklif etmeyeceğinden şüpheleniyorum.

Büyük olasılıkla çok sayıda uygulamayı aynı kod tabanında birleştiremeyeceksiniz çünkü bu biraz çaba gerektirecek ve eski, ihmal edilmiş programlar için bu başlangıçta beklenenden çok daha fazla iş olabilir.

Bununla birlikte, tüm uygulamalarınızın aynı kod deposunda bulunmasının yanlış olduğu bir şey yoktur , burada her uygulama ayrı bir alana sahiptir. Bu, örneğin tüm kod tabanı için tek bir tutarlı görünümde oluşturulmuş herhangi bir çevrimiçi belgeye sahip olmanızı sağlar; bu da elde edebildiğiniz kadar görünürlük istediğiniz kadar iyi bir şeydir.

Buna karar verenler, NEDEN bunu yapmak istediklerini ve oraya ulaşmak için ne kadar iş harcamak istediklerini düşünmelidir.

Kurumsal gelişmeyi bu kadar verimsiz ve pahalı yapan tek bir şey varsa, her şeyi yapan tek bir sistem yapmanın mümkün olduğu yanılsamasıdır. Sistemin tüm ayrıntılarını anlayan ve tüm kararları bir haftalık toplantılara ihtiyaç duymadan alabilen tek bir ürün sahibiniz varsa, işe yarayabilir, ancak bunun hiç görmediğini gördüm.

Genel olarak daha çok internet için geliştirmek gibi davranırsanız daha iyi olacaksınız - sadece kendi uygulamanızı oluşturun, pratikte kendi kodunuzun dışındaki herhangi bir şeyin sıfır kontrolüne sahip olduğunuzu itiraf edin. OAuth ve kullanıcı ayarları için basit bir API ve biraz paylaşılan CSS ile istediğiniz tüm tutarlılığı hemen hemen elde edebilirsiniz.

Bu, SOA'nın orijinal amacına oldukça benziyor, ancak eğer onu çağırırsanız, her şeyi yapmaya çalışan farklı bir büyük, zar zor çalışan sistemle sonuçlanacaksınız.

İlk düşüncem, bunun sürümler için toplam bir PITA olacağı.

Tüm yönetim ve onay katmanlarından kaçınmak için, yönetilebilir işlevsellik parçalarına ayrılmak çok daha mantıklıdır.

Bileşenlere / hizmetlere ortak şeyleri ayırmak ve bu şekilde standartlaştırmak IMHO'yu çok daha kolay hale getirecektir.

Aşağıdaki gibi bir entegrasyon teknolojisi kullanılarak, bunu farklı yaklaşabilir Deliverance'ye tüm web uygulamalarının benzer temaya. Temel olarak, her uygulama hala ayrıdır; Kurtuluş, çıktılarını tasarladığınız statik bir HTML şablonuna bağlamak için XSLT kurallarını kullanır. Bu, nispeten basit bir statik HTML / CSS temasının en az sıkıntıya sahip tüm uygulamalara uygulanmasına izin verir.