Birçoğu gerçekten iyi yazılım mimarlarının kod yazması gerektiğine inanıyor. Neden aslında? Sonuçta, mimari ve kod iki farklı yazılım geliştirme seviyesidir.
Her şey iyiydi: Mimarlar tasarlanan mimarlık, geliştiriciler bu gereksinime göre planlandı. Görevlerin açık bir bölünmesi – bir sorunla: Mimarlar geliştiricilerin çalışmasıyla temasını kaybettiler. Birçok mimar, “kirli” programlama etkinliğini uzun zamandır bıraktığı için gurur duyuyordu. Ancak mimarlar fildişi kulesinde gerçekliğe atıfta bulunmadan kararlar aldılar. Bu kararlar teknolojiler veya genellikle projedeki “vahşi büyümeyi” sınırlamak için çerçeve kullanımı ile ilgilidir. Sonuçta, sadece yüksek nitelikli mimarlar bu tür kararları gerçekten iyi verebilirler.
Sonuç, ekibin eylem özgürlüğünün büyük bir kısıtlamasıydı. Projelerde genellikle sadece iki alternatif vardı: mimarın kararlarını görmezden gelin – ve proje kararlara rağmen çalıştı. Ya da mimar kararları bastırdı, genellikle proje için ciddi sonuçlar verdi.
Moderatör yazarı ve mimar
İletişim, kodun yazı mimarıdır: sadece mimari üzerinde değil, aynı zamanda kod üzerinde de çalışır. Bu yüzden gerçeklikle temasını kaybedemez. Ancak bu prosedürün de dezavantajları vardır: projenin belirli bir boyutu ve karmaşıklığından mimarlık tam zamanlı bir iştir. Sonra sadece iki seçenek vardır: mimar, mimari çalışmayı birkaç omuzda dağıtır veya kodun taslağını bırakır – belki de en fazla çiftlerin programlanması bağlamında maksimuma. Özellikle, bağlantı mimar için bilgi akışını geliştirir ve diğer faaliyetler daha önemli olduğu için herhangi bir zamanda kod seviyesinden çekilmesine izin verir.
Bir mimar olarak fildişi kulesinden kaçmanın başka yolları da vardır. Mimar, kararları kendi başlarına almak yerine, teknik kararları ılımlı ve geri bildirim alabilir. Bununla birlikte, bu iyi bir fikirdir, çünkü proje kararlarda tüm çalışanların teknik yeterliliğinden yararlanabilir. Arkasındaki rol hakkında farklı bir anlayış var: Mimar, projenin en iyi teknisyeni değil. Mimari ve bu nedenle takımlardan farklı bir seviyede, ancak geliştiricilerle yakın koordinasyonda çalışıyor. Mimari, geliştiricilerin ve ilgili tarafların zorlukları ile daha da geliştirilebilir.
Kodun yazılması, bir mimarın teknik becerilerinizi güncel tutmasının bir yolu da olabilir. Bu projede olmamalı, ancak hobi projelerinde de yapılabilir. Her durumda, mimarlar temel teknolojiler için makul derecede yüksek bilgiye sahip olmalıdır.
Mikro hizmetlerin bağlamı
Mikro hizmetlerle, mimarlar için başka bir görev daha var: mikro hizmetler arasındaki protokolleri veya fonksiyonların mikro hizmetlere dağıtılmasını tanımlarlar. Mikro hizmetlerde, ekipler genellikle kullanılacak çerçeve ve programlama dillerine kadar büyük bir özgürlüğe sahiptir. Son olarak, mikro hizmetler ayrı işlemler, sanal makineler veya docker kapları olarak çalıştırılır. Bu nedenle, dahili mikro hizmetler için birçok yönerge oluşturmak artık gerekli değildir.
Mimarlar bu soruları önerebilir ve geri bildirim sağlayabilir, ancak ekipler kendi başlarına daha fazla karar verebilirler. Mimar rolünü böyle anlamalıdır: ılımlı kararlar ve diğerlerine önemli sorularla yardımcı olun, ancak geliştiricilere ne yapmaları gerektiğini reçete etmemelidir.
PS: Meslektaşları Innoq Carmen Burmeister, Falk Hoppe, Holger Kraus, Andreas Krüger, Jerry Preissler, Philipp Schirmacher, Silvia Schreier, Michael Vitz ve Till Till Schulte, blog yazısının ilk versiyonunda tartışma için teşekkürler!
()
Her şey iyiydi: Mimarlar tasarlanan mimarlık, geliştiriciler bu gereksinime göre planlandı. Görevlerin açık bir bölünmesi – bir sorunla: Mimarlar geliştiricilerin çalışmasıyla temasını kaybettiler. Birçok mimar, “kirli” programlama etkinliğini uzun zamandır bıraktığı için gurur duyuyordu. Ancak mimarlar fildişi kulesinde gerçekliğe atıfta bulunmadan kararlar aldılar. Bu kararlar teknolojiler veya genellikle projedeki “vahşi büyümeyi” sınırlamak için çerçeve kullanımı ile ilgilidir. Sonuçta, sadece yüksek nitelikli mimarlar bu tür kararları gerçekten iyi verebilirler.
Sonuç, ekibin eylem özgürlüğünün büyük bir kısıtlamasıydı. Projelerde genellikle sadece iki alternatif vardı: mimarın kararlarını görmezden gelin – ve proje kararlara rağmen çalıştı. Ya da mimar kararları bastırdı, genellikle proje için ciddi sonuçlar verdi.
Moderatör yazarı ve mimar
İletişim, kodun yazı mimarıdır: sadece mimari üzerinde değil, aynı zamanda kod üzerinde de çalışır. Bu yüzden gerçeklikle temasını kaybedemez. Ancak bu prosedürün de dezavantajları vardır: projenin belirli bir boyutu ve karmaşıklığından mimarlık tam zamanlı bir iştir. Sonra sadece iki seçenek vardır: mimar, mimari çalışmayı birkaç omuzda dağıtır veya kodun taslağını bırakır – belki de en fazla çiftlerin programlanması bağlamında maksimuma. Özellikle, bağlantı mimar için bilgi akışını geliştirir ve diğer faaliyetler daha önemli olduğu için herhangi bir zamanda kod seviyesinden çekilmesine izin verir.
Bir mimar olarak fildişi kulesinden kaçmanın başka yolları da vardır. Mimar, kararları kendi başlarına almak yerine, teknik kararları ılımlı ve geri bildirim alabilir. Bununla birlikte, bu iyi bir fikirdir, çünkü proje kararlarda tüm çalışanların teknik yeterliliğinden yararlanabilir. Arkasındaki rol hakkında farklı bir anlayış var: Mimar, projenin en iyi teknisyeni değil. Mimari ve bu nedenle takımlardan farklı bir seviyede, ancak geliştiricilerle yakın koordinasyonda çalışıyor. Mimari, geliştiricilerin ve ilgili tarafların zorlukları ile daha da geliştirilebilir.
Kodun yazılması, bir mimarın teknik becerilerinizi güncel tutmasının bir yolu da olabilir. Bu projede olmamalı, ancak hobi projelerinde de yapılabilir. Her durumda, mimarlar temel teknolojiler için makul derecede yüksek bilgiye sahip olmalıdır.
Mikro hizmetlerin bağlamı
Mikro hizmetlerle, mimarlar için başka bir görev daha var: mikro hizmetler arasındaki protokolleri veya fonksiyonların mikro hizmetlere dağıtılmasını tanımlarlar. Mikro hizmetlerde, ekipler genellikle kullanılacak çerçeve ve programlama dillerine kadar büyük bir özgürlüğe sahiptir. Son olarak, mikro hizmetler ayrı işlemler, sanal makineler veya docker kapları olarak çalıştırılır. Bu nedenle, dahili mikro hizmetler için birçok yönerge oluşturmak artık gerekli değildir.
Mimarlar bu soruları önerebilir ve geri bildirim sağlayabilir, ancak ekipler kendi başlarına daha fazla karar verebilirler. Mimar rolünü böyle anlamalıdır: ılımlı kararlar ve diğerlerine önemli sorularla yardımcı olun, ancak geliştiricilere ne yapmaları gerektiğini reçete etmemelidir.
PS: Meslektaşları Innoq Carmen Burmeister, Falk Hoppe, Holger Kraus, Andreas Krüger, Jerry Preissler, Philipp Schirmacher, Silvia Schreier, Michael Vitz ve Till Till Schulte, blog yazısının ilk versiyonunda tartışma için teşekkürler!
()