Yazılım Mimarisi Kökleri? Kimin hedeflere ihtiyacı var?
Yazılımın mimarisinde, hedef görüntüler hakkındaki tartışma çok fazla alan kaplıyor – sonuçta üzerinde çalıştığınız bir hedef olmalı. Ancak öncelikler farklı dağıtılmalı ve gerçekte hedef görüntüler hedef değildir.
Hedef görüntüler, ideal olarak bir mimariyi ve tarafların sistemin bölünmesi gereken görünümü temsil eder. Bu mimarinin tasarımı merkezi mimari zorluk gibi görünüyor: ekiplerin bu görev için bu kadar uzun sürmesi şaşırtıcı değil.
Ancak çoğu durumda, mimari zaten mevcuttur. Yeni bir mimariyi proje için bir çerçeve olarak görmelidir. Bununla birlikte, hedef mimari mantıklıdır: Sonuçta, hangi hedefte çalışmanız gerektiğini bilmelisiniz. Mevcut mimari geçmişin hatasını tekrarlamaya yönlendirilebilir.
Fizibilite
Hedef görüntü bittiğinde, fizibilite sorununu sormalısınız: Hedef görüntüye ne zaman ulaşılması mümkündür? En geç bu noktada, bir hedef görüntünün başarılmasının kolay olduğu genellikle açıktır. Ancak bu, hedef görüntüyü tasarlama fikri bile değildi: bu nedenle gerçekçi bir şekilde erişilememesi gereken bir mimari tutopya olmalıdır.
Ancak, hedef görüntü tartışması yalnızca proje üzerinde bir etkisi varsa mantıklıdır. Hedef görüntünün genellikle mevcut durumla ilgisi yoktur. Yani hedef görüntüye doğru çalışabileceğiniz sayısız yer var. Ama nereden başlıyorsun?
Hedef görüntü hakkında bir tartışma için, bir keşif gezisi ile karşılaştırma dağın tepesi için açıktır: açıkça doğru yönde olup olmadığınızı görmek için dağın tepesine bir göz atmak mantıklıdır. Ancak bir sonraki adım ve bir sonraki nehir veya aşılması gereken bir sonraki engel daha da önemlidir.
Sevkiyat metaforu, hedef görüntünün, yani dağın tepesine ulaşılacağını varsayar. Bu, mimari merkezin bir görüntüsü olması gerekmez: en azından pratik olarak hedef görüntüye ulaşan projeleri asla görmüyorum. Bununla birlikte, bunun nedeni, danışmanların sadece bir şeyi geliştirmek için başvurursanız ve bu nedenle zor projeleri görürseniz gerekli olabilir.
Bu nedenle, bir projede geliştirmek için bir hedef görüntü elde etmek için bir tartışmadan daha önemli olan somut önlemleri buluyorum. Bu faaliyetler, “hedef görüntü” teriminin önerdiği gibi, sistemin yapılandırılmasıyla sınırlı olmamalıdır, ancak gereksinimlerin geliştirilmesi, işletilmesi veya yönetimi alanında çok farklı faaliyetler olabilir. Bir hedef görüntünün aksine, bu önlemler aslında uygulanabilir ve kısa süreye getirilebilir.
Hedef Görüntü Yok
Aslında, bir hedef görüntü bile dağıtılabilir. Bir sistemin ilgili tarafları, performans veya güvenlik olarak yazılımın işlevselliği ve nitelikleri ile ilgilenir. Bir hedef görüntünün gösterdiği iç yapı, yalnızca bakım gibi kaliteyi etkiliyorsa önemlidir. Hedef görüntü, kullanıcı dostluğu gibi birçok önemli niteliği etkilemez. Özellikler ve nitelikler aslında projenin amaçlarıdır. Ayrıca daha fazla sonuçları vardır: Kullanıcı dostluğu gibi nitelikler bir ürünün ve hatta bir şirketin başarısı için gerekli olabilir.
İncelemeler veya istişareler sırasında gördüğüm mimari belgelerin çoğu, sistemin veya bir hedef görüntünün bir bölümünü gösterir, genellikle ana bahçe türü olarak. Projenin amaçları ve bunlardan elde edilen özellikler ve nitelikler çok nadirdir, ancak daha önemli olmasına rağmen. Ve tam olarak bir hedef tartışmanın uygun olacağı yer: Proje neye ulaşmalı? Hangi kalite özellikleri ve hedeflerine ulaşılmalıdır? Bu, alanın daha iyi anlaşılmasına ve dolayısıyla proje için daha iyi bir temel oluşturur.
Ve sonra gerçekten kaliteli hedeflere ulaşmak için önlemler olmalıdır. Bu da çoğu projede ihmal edilmektedir. Sonuçta, kullanıcının dostluğu önemli olabilir, ancak ona mimariye bakmak için genellikle başarısız olur.
Belki de bu dağın tepesi, aslında bakıp tırmanmamız gerekiyor.
Meslektaşlarım Anja Kammer ve Martin'e çok teşekkürler, makalenin önceki bir sürümünde yorumlar için alıyorlar.
TL; Dr.
Hedef görüntü tartışmaları yararlı olabilir, ancak sadece somut önlemler gerçek bir iyileşmeye yol açar. Ve bir mimari çerçeveden daha önemli olan projenin amacı üzerinde netliktir.
()