Karmaşıklığa dua ediyor muyuz?
Karmaşıklık, yazılımın geliştirilmesindeki temel zorluktur. Bu nedenle, her zaman karmaşıklığı ortadan kaldırmak için bir çabadır. Sonuçta, her zaman komplekslerin basit problemlerini çözmek istemeliyiz. Ancak bazen karmaşıklık için dua ediyoruz – ve bu karmaşıklık sorunları çözülemez hale getirebilir.
Görünüşe göre yazılımın geliştirilmesi sadece programlama ile ilgilidir. Herkes ondan on yazabilir. Sorun karmaşık sistemlerdir. Bir sistem o kadar büyükse, tek başına bir kişi onu anlayamaz ve geliştiremezse, modülerleşme gibi kavramlar çok önemlidir. Sistem, modülerleştirmeyi bir kişinin daha da geliştirebileceği küçük birimlere böler. Böylece karmaşıklık çok önemli hale gelir. Ancak bu karmaşıklıkla, bireyler artık projeler yapamaz, sadece takım yapabilirler. Bu örgütsel zorluklara yol açar.
Conway Yasası
Conway'in yasası bu bağlamda önemlidir. Bir sistemin mimarisinin, sistemin uyguladığı kuruluşun iletişim yapılarını tanımladığını söylüyor. Yazılımdaki her modül için kuruluşta bir birim vardır ve organizasyon birimleri arasındaki her iletişim ilişkisi için, yazılımdaki modüller arasında bir bağımlılık vardır.
Bununla birlikte, 1968 tarihli Conways gazetesinde başka bir şey açıklanmaktadır: Bir kuruluş büyük bir sistem geliştirmek istiyorsa, birçok insanı projeye getirmelidir. Harika bir takımda iletişim zor olduğundan, ekibin belirli bir boyutundan çöker. İletişim ve mimari birbirini etkilediğinden, zayıf iletişim kaotik mimariye ve daha fazla karmaşıklığa yol açar.
Ancak Conway devam ediyor: Elbette, mümkünse, küçük bir ekibin uygulayabileceği zarif çözümlere odaklanmalısınız. Ancak Conway'e göre, bir yöneticinin prestiji ekibin büyüklüğüne ve sorumlu olduğu bütçeye bağlıdır. Bu nedenle, bir yönetici harika bir ekip ve yüksek bütçeye katılacaktır.
Başlangıçta bu bir sorun gibi görünmüyor. Proje gerçekten daha küçük bir ekiple çözülebilirse, bazıları oturur. Bu paraya mal olur, ancak projeyi ve mimariyi tehlikeye atmaz. Ancak Conway, Parkinson'un yasasının grev yaptığını söylüyor. Parkinson Yasası, bazı idarelerin neden daha fazla çalışanı aldığını açıklıyor, ancak yine de almıyorlar. Bu yasa, eksiksiz bir faaliyetin tüm çalışanların mevcut süresini tamamen tamamladığını belirtmektedir. Görev kolay ve hızlı bir şekilde detaylandırılabilse de, organizasyonun tüm insanlarına tedavi edilene kadar giderek daha fazla insan katılıyor. Bir yazılım projesinde, tüm ekip üyeleri bunun gerekli olduğu gerçeğine bakılmaksızın proje üzerinde çalışacaktır. Sonuç olarak, organizasyon büyüyecek, iletişim çökebilir ve mimari kaotik hale gelecektir
Şu anda 50 yaşında olan Conway'in bilgisi özellikle ilginçtir, çünkü büyük bir projenin kötü mimariye sahip olması ve geliştirilmesi zor geliştirilebiliyorsa bir açıklama olabilir.
Bu belgenin yöneticileri onlar için net olmadan karmaşıklık için dua ediyor. Daha büyük ekibin mümkün olmasını istiyorsunuz ve büyük bir kuruluş mimariyi düşürebilir çünkü çok karmaşık bir sorun yaratırsınız.
Ve yazılım mimarları?
Ancak sadece yöneticiler değil, aynı zamanda yazılım mimarları da bazen bilinçsizce dua ediyoruz. Bu, örneğin, belirli bağlamda ve karmaşıklıktaki avantajları göz önünde bulundurmadan, olayların temini, birçok seviyeli mimariyi yansıtmadan veya mikro hizmetlere sahip mimariler gibi modeller kullandığımızda olur.
Teknolojik içgüdü de coşkulu bir karmaşıklığa yol açabilir. Sonuçta, tüm teknik zorlukları arıyoruz ve özellikle ilginç projeler uygulamak istiyoruz. Modern yaklaşımlar ve özellikle karmaşık sistemler bunun için uygundur. Aynı şekilde, bazen kendilerini sunmadıkları teknik problemleri çözeriz. Bu, gerçek gereksinimler tarafından gerekli olmayan çok genel veya ölçeklenebilir çözümler yaratır ve bu nedenle çok fazla karmaşıklık yaratır.
Bir Mazeret Olarak Karmaşıklık
Özellikle açık bir karmaşıklık vakası “Bu bizim için işe yaramıyor. Zorluklarımız Amazon veya Google'dan çok daha büyüktür.” Bunu birkaç şirketin çalışanlarından duydum. Bu ifadeler şaşırtıcıdır: Amazon veya Google gibi şirketler son derece karmaşık BT sistemlerini yönetir ve ekonomik başarıları doğrudan bu BT sistemlerine bağlıdır. En azından bu BT sistemleri nedeniyle, dünyanın en değerli şirketleri arasındadır.
İlk bakışta, bildirimler savunmacı bir tutum olarak yorumlanabilir: Amazon ve Google modern bir organizasyona ve bir bulut altyapısına sahiptir, ancak maalesef bunun çok daha karmaşık bir ortamda hiçbir şey yapılamaz. Ama belki de gururla yankılanır, çünkü sonuçta neredeyse benzeri görülmemiş zorluklarla ilgilenirsiniz. Burada da bu şekilde geçerlidir: karmaşıklığın doğal olarak dezavantajları vardır, aynı zamanda bulut, sürekli dağıtım veya mikro hizmet gibi belirli yaklaşımlarla karşılaşmanız gerekmediği avantajı vardır, çünkü yine de işe yaramaz.
Bu yüzden her zaman karmaşıklıktan kaçınırsak tartışmalıdır. Sadece tekniklere odaklanarak, çizimleri mümkün olduğunca basit ve zarif hale getirerek, bilinçsizce karmaşıklığa bayılıyorsak yararlı değildir. Bu yüzden bu bilinçdışı mekanizmalarda net olmak önemlidir. Tabii ki, hala çözülmesi zor olan birçok karmaşık sorun var.
Meslektaşlarım Jens Bendispose, Jochen Christ, Lutz Hühnken, Michael Vitz ve Benjamin Wolf'a makalenin önceki bir versiyonuyla ilgili yorumlar için çok teşekkürler.
TL; Dr.
Yazılımın geliştirilmesi esas olarak karmaşıklığın yönetimi ile ilgilidir. Karmaşıklığı önlemek daha iyi olurdu. Ancak maalesef bazen – bilinçli veya bilinçsiz karmaşıklık vardır, bu da gereksiz yere karmaşık sistemlere yol açar.
()