Mimarlık hakkında çevrimiçi bir tartışma okuyordum. Aslında en azından birkaç kez son derece iyi kodlanmış olması, her zaman oldukça tuhaf bir konu olmuştur, ancak bu bilgi her zaman kaybolmuş gibi görünmektedir. Daha sık olarak, insanlar bunu kendi kişisel gündemlerine fayda sağladığı sürece olmasını istedikleri her şey olarak tanımlarlar.
Hemen hemen hepsi yanlış, ama bir sürü daha iyi ama eski referansa işaret etmek yerine, kendi tanımımı atmanın uzun ve acı verici bir geleneğini sürdüreceğim.
Bir yazılım sistemi, ancak ve ancak organize edilmişse bir mimariye sahiptir. Yani, eğer sadece bir araya getirilmiş bir yığın şeyse, o zaman mimarisi yoktur. İlk yıllarında bir mimarisi olmuş olabilir, ancak sonraki çalışmalar bunu görmezden geldiyse, o zaman şimdi sadece bir yığın malzemedir.
Bir mimari kurma süreci kısmen yapısal ve kısmen politiktir. Yani, önemsiz olmayan herhangi bir sistem için, inşa edilmesi hem o kadar yavaş hem de o kadar pahalıdır ki, kapsanacak işin önemli maliyetlerini düzenleme eylemi saf politikadır. Bu pastada her türden insanın parmağı var, bu yüzden temel olarak seçilecek teknolojiler ve yığınlar sadece para toplama eyleminin eseridir. Yeni başlayanlar için doğrudur, ancak herhangi bir büyük kuruluş için de geçerlidir.
Her temel bağımlılığın belirgin bir güçlü ve zayıf yönleri vardır. Herhangi bir çözüm için en uygun parçalara ulaşmak için bu özelliklere dayalı olarak aralarında rasyonel bir seçim yapabilirsiniz. Bu neredeyse hiç olmaz, siyaset insanları mantıksız bir şekilde, genellikle önyargı, kişilik veya sınırlı deneyimlere dayanarak seçim yapmaya iter. Bu nedenle, genellikle teknolojiler ve teknoloji yığınları, gerçek iş başlamadan çok önce çok önceden seçilir. Genellikle gereksinimlerle zayıf bir şekilde eşleştirilirler. Bu zayıflıkları kapatmak için özensiz yamalara çok fazla iş düşüyor.
Politikanın etkilerini bir kez geçtikten sonra gerisi yapısaldır. İki ana alan var.
Birincisi, ilgili parçaları birlikte ayrıştırmaktır. Yani raporlama gibi sistemin bir davranışı ile ilgili kodların tamamı bir araya getirilmelidir. Ama aslında o kadar basit değil, çünkü oyunda her zaman en az iki baskın boyut var. Genellikle iş olarak adlandırılan problem alanı sisteme dikey kısıtlamalar getirirken, teknik alan temel bir katman olarak yatay kısıtlamalar getirir. Bunlar birbiriyle çelişiyor, ancak modern zamanlarda herhangi bir büyük ölçekli teknik soruna sadece sözde hizmet etmek ve işi körü körüne takip etmek daha popüler hale geldi.
Yine de, kod tabanını, çok büyük olsa bile, alt bileşenleri hem yüksek hem de orta düzeyde net bir şekilde tanımlayan, hoş uyumlu kutulardan oluşan katmanlar halinde düzenleyebilirsiniz. Bunu erken yapmanın gücü, eğer parçalar birbirinden bağımsızsa, iş etkili bir şekilde ölçeklenebilir (paralelleştirilebilir) ve genel kalite çok daha iyi olacaktır.
Yine de daha ileri gidebilirsiniz. Benzer kod parçalarını bir araya getirerek mekaniği parçalamak yerine, temel bileşik veri türlerine göre düzenleyebilirsiniz. Bu doğru bir şekilde uygulandığında, dikey ve yatay uyumsuzlukları azaltma eğilimindedir, ancak aynı zamanda hem kodu hem de herhangi bir görselleştirmeyi basitleştirir. Bunun pratikte gerçekleştiğini görüyorsunuz, ancak çok gelişmiş bir teknik olduğu için, bu günlerde çok daha sık yazılan çok sayıda alana özel uygulama kodundan ziyade, yüksek kaliteli düşük seviyeli ticari ürünlere daha sık uygulanmaktadır.
İkinci birincil alan performansla ilgilidir. Tüm sistemlerin daha büyük bir ortama uyması gerekir. Çok fazla veri paylaşıyorlar, sürekli veri beslemeleri alıyorlar ve diğer sistemlere veri gönderiyorlar. Bu düzeyde, farklı sistemleri birbirine bağlamanın standartlaştırılmış kurumsal yolları vardır.
Temel sorun genellikle frekanstır. Bir sistem, diğerinin içe aktarabileceğinden çok daha hızlı veri üretebilir veya toplayabilir, bu nedenle, senkronizasyon sorunlarını önlemek için aralara yerleştirilen kuyruklar gibi ortak çözümler vardır.
Kelimenin tam anlamıyla 50 yıllık farklı veri formatları, iletişim araçları ve protokolleri ve verilerin kendisini modellemek için neredeyse sınırsız sayıda farklı doğru ve yanlış yolu olduğundan, bu veri aktarımlarına çok fazla zaman harcanmaktadır. Bazı durumlarda, tüm kuruluş için ortak bir veri yoluna sahip olmak gibi iyi kurulmuş iletişim kalıpları vardır, ancak garip bir şekilde, sabırsızlık daha çok bunların göz ardı edilmesi ve her bir beslemenin kötü bir şekilde eve döndürülmesi anlamına gelir. Çoğu zaman, sistemin iç kısımları sıkı bir şekilde organize edilmiş olsa bile, ithalat ve ihracatları değildir, çünkü genellikle sorumlu farklı ekipler, herhangi bir standartlaştırılmış veri taşıma yöntemi üzerinde anlaşmaktan hoşlanmazlar. Uygulamanın çok uzun sürdüğünü düşünüyorlar (aynı tekerlekleri tekrar tekrar icat ettikleri gerçeğini görmezden gelirken).
Merkezileştirme, çok sayıda tekrardan kaçınma, eski veriler ve cli, yerel, web, mobil vb. gibi arayüz türleri arasında seçim yapma gibi birkaç önemli mimari sorun daha var. Bunların tümü geçmişte yoğun bir şekilde araştırıldı ve çözüldü, ancak yine de bu bilgi de unutulmuştur.
Kısaca mimari bu kadar.
En azından büyük bir şirketin bazı bölümlerinde, gerçekten çok daha organize olabilir ve kendimizi büyük miktarda gereksiz işten kurtarabiliriz, ancak garip bir şekilde bunu yapamıyoruz. Başlangıçtaki siyasi bileşenin teknik sorunları gölgede bırakması, böylece orada harcanan ilk zaman kaybının, sonraki tüm işlerin korkunç bir şekilde aceleye getirilmesine ve ardından kötü bir şekilde yapılmasına neden olması mümkündür. Emin değilim, ancak on yıllar boyunca bu kaderden kaçınmak için fazlasıyla yeterli öğrendik, ancak yine de çoğu büyük iç projenin başına geliyor gibi görünüyor.
Bunun yerine, sadece tamamen tepkisel olmaya çalışmak ve ardından işin sihirli bir şekilde kendi kendine gelişmesine izin vermek yönündeki girişimlerimiz, saf düzensizliği “mimari” olarak görme eğilimindedir, bu nedenle genellikle çok, çok daha kötüdürler.
Her iki durumda da, bir şeyleri kötü bir şekilde inşa etmeye devam ediyoruz, sonra kötü olduklarını anlıyoruz, sonra tekrar sıfırdan yeniden başlıyoruz. Şimdiye kadar, 7. veya 8. nesillerinde olan berbat büyük sistemler var. Belki de aynı hataları tekrarlamak için acele etmeden önce işleri organize etmek için daha iyi bir iş yapmalıyız. Bilerek ortalığı karıştırmamak aslında mimarlığın amacıdır. İnsanların bu işte ne kadar iyi olduklarını geride bıraktıkları sonuçlardan anlayabilirsiniz.