Tek en iyi uygulama: en iyi uygulamaları kullanmayın
Yazılım sistemleri karmaşıktır. Sistem tasarımıyla ilgili en iyi uygulamalar, karmaşıklığı olabildiğince kolay bir şekilde evcilleştirmeye yardımcı olabilir. Ne yazık ki çok az işe yarıyorlar.
Dave Snowden, sorunları, sistemleri ve görevleri farklı alanlara ayırmak için Cynefin çerçevesini kullanır:
- Basit sistemler bariz bir neden-sonuç ilişkisi vardır. Bu durumlarda, yerleşik yaklaşımlar gelir En iyi uygulamalar kullanmak için. Örneğin, bir cihaz için bir onarım kılavuzu veya bir çağrı merkezi için bir tartışma kılavuzu, ilgili bağlamda prosedür için en iyi uygulamayı temsil edebilir.
- karmaşık sistemler açık olmayan bir neden-sonuç ilişkisi vardır. Bu durumda, birkaç etkili yol vardır. (iyi alışkanlıklar). Bu etki alanına örnek olarak, bir programdaki karmaşık bir hatayı ayıklamak verilebilir. Belirleyici bir neden-sonuç ilişkisi varken, başarısızlığın nedenini belirlemek zordur. Ayrıca, her sorun giderici farklıdır. Bununla birlikte, yardımcı olan ve genellikle programcıların öğrendiği etkili yollar vardır.
- karmaşık sistemler: Bu durumda neden ve sonuç önceden belirlenemez. Öyleyse kendini teklif et Gelişmekte olan uygulamalar to: olanlara tepki veririz. Bu, farklı alanlardan insanların işbirliğini gerektirir. Buna bir örnek, genellikle bir yazılım geliştirme projesinin hedefi olan yeni bir pazarın açılması olabilir. Yazılım ürününün nerede başarılı olacağı ve bunun için hangi özelliklerin gerekli olduğu önceden belli değildir, ancak başarı ve başarısızlıklara tepki gösterilebilir ve böylece ürün başarılı olabilir.
- kaotik sistemler sebep-sonuç ilişkisi yoktur. Örneğin bir acil durum veya afet durumunda olan budur. Daha sonra sistemin stabilize edilmesi ve Yeni uygulamalar uygulanacak.
Bu blog gönderisi, Cynefin çerçevesine eksiksiz bir giriş olamaz. Ancak Cynefin çerçevesinden şu izlenir: En iyi uygulamalar sadece basit Açık neden-sonuç ilişkileri olan sistemler anlamlıdır. Bununla birlikte, çoğu durumda yazılım sistemleri yalnızca teknolojik olarak karmaşık değildir: geliştirme, geliştirme ekibindeki farklı rollerin paydaşlarla etkileşime girdiği karmaşık bir sosyal sistemde gerçekleşir. Bir yanda teknolojik yazılım sistemi ile diğer yanda toplumsal gelişme yapısının birbiriyle nasıl etkileşime girdiğini tahmin etmek güçtür. Yani hakkında konuşuyoruz karmaşık veya karmaşık sistemler. İstisnalar olabilir, ancak basit sistemler bireysel yazılım uygulama çabalarını pek haklı çıkarmaz çünkü problemler, örneğin standart yazılımlarla basitçe çözülebilir.
Yazılım projelendiriyorsa ancak karmaşık veya karmaşık öyleler, yani yazılım geliştirmede aslında sadece bir tane var. iyi alışkanlıklar veya ayrıca Gelişmekte olan uygulamalar. Dolayısıyla, farklı bağlamlardan ve ötesinden yaklaşımlar alırsanız En iyi uygulamalar bu görev için uygun olmayan bir çözüm seçer. Bir dizi farklı ve özel zorluk üzerinde çalışıyoruz ve her seferinde bu farklı ortama uyum sağlamamız ve mevcut zorluklara yanıt veren çözümler sunmamız gerekiyor.
yine de kim En iyi uygulamalar projede yer alanların seçilen yaklaşımları sorgulamasını zorlaştırır. Sonuçta, bunlar en iyi uygulamalardır. Ancak gerçekte, sırf farklı bir alanda olduğunuz için uygun olmayabilirler. Bu nedenle, “mikro hizmetler en iyi mimari uygulamadır” veya “monolitler en iyi mimari uygulamadır” gibi ifadeleri işe yaramaz bulmuyorum. Ancak elbette belirli bir bağlamda başarılı olmuş yaklaşımlara bakmak ve onlardan ders çıkarmak mantıklıdır.
En iyi uygulamaları uygulamanız yeterli mi?
İyi veya en iyi uygulamalarla uğraşmak da sorunlu olabilir. Bildiğim bir projede mimarlar, en iyi uygulama olarak yalnızca iki ekibin kullandığı arayüzleri iletti. Aynı anda yalnızca iki ekip dahil olduğundan, arabirimler birden fazla ekibin arabirimleri kullandığı duruma göre daha kolay değiştirilebilir ve koordine edilebilir. Bu nedenle, birden çok ekibe işlevsellik sunmak istiyorsanız, her ekibin bağımsız çalışması için bir arayüz uygulayabilirsiniz.
Arayüzler nispeten benzer olmasına ve yakın gelecekte değişmeyecek olmasına rağmen, proje ekiplerinden biri bu fikri benimsemişti. Değişiklik durumunda bağımsızlığın avantajı bu nedenle bu durumda önemsizdir. Ancak ekip tek tip bir arayüz uygulamadı. Ekibin kendisi bu alternatifi en iyi olarak değerlendirdi. Mimarlar tarafından iletilen en iyi uygulamalar olmasaydı, ekip daha önce en iyi yaklaşımlarını kullanabilirdi. Çünkü çok arayüzlü yaklaşımın dezavantajları olduğu açıktır. Bu, sürdürülmesi ve uygulanması gereken çok sayıda arayüzle sonuçlanır.
Bu nedenle, iletilen en iyi uygulama sadece iyi bir uygulama olabilir veya iyi bir uygulama olduğu bağlamın daha kesin olarak tanımlanması gerekir. Temel nokta, iletilen en iyi veya iyi uygulamaların, insanları yalnızca bu örnekleri izlemeye ve kendi en iyi çözümlerini kullanmamaya yönlendirmesidir. Bu nedenle, bu tür yaklaşımlar her zaman eleştirel olarak incelenmelidir.
Anahtar soruları olan karar modelleri daha esnektir ve farklı en iyi veya iyi uygulamalar arasında karar vermeye yardımcı olabilir. Birçoğu bu tür modelleri yararlı bulur, ancak aynı zamanda çözüm alanını da sınırlar çünkü asla akla gelebilecek tüm durumları kapsayamazlar.
Çözüm
Nihayetinde, projeye dahil olanlar bireysel kararlar almak ve onlar için sorumluluk almak zorunda kalacaklar. Ayrıca onları haklı çıkarmanız gerekir. Bir en iyi uygulamanın veya “İşte bugün bunu nasıl yapacağınız!” saklanmak yetmez.
Ayrıca birkaç en iyi uygulama vardır. Bu nedenle, birisi tercih ettiği yaklaşımdan farklı bir yaklaşım seçerse, bu yine de iyi bir uygulama olabilir veya hatta bu zorluğa özel olarak uyarlanmış yeni ortaya çıkan bir uygulama olabilir. O zaman “en iyi uygulamanızı” tavsiye etmeye elveda demelisiniz. Tabii ki, seçilen yaklaşım bir anlam ifade etmeyebilir, bu nedenle kesinlikle farklı bir yaklaşım önerebilirsiniz.
tl; doktor
Yazılım geliştirme genellikle en iyi uygulamalar için çok karmaşıktır. Eleştirel yansıma olmadan uygulanırsa rehberlik sağlayabilecek olsalar da, belirli bir zorluk için optimal olmayan mimari tasarımlar ortaya çıkabilir.
Meslektaşlarım Robert Glaser, Anja Kammer, Martin Kühl, Joachim Praetorius ve Hermann Schmidt’e makalenin önceki bir versiyonuna yaptıkları yorumlar için çok teşekkürler.
()
ana sayfaya