En iyi tek uygulama: En iyi uygulamaları kullanmayın
Yazılım sistemleri karmaşıktır. Sistemin tasarımı için en iyi uygulamalar, karmaşıklığın mümkün olduğunca kolay bir şekilde evcilleştirilmesine yardımcı olabilir. Maalesef çok az kullanıyorlar.
Cynefin çerçevesiyle Dave Snowden, farklı sektörlerdeki sorunları, sistemleri ve görevleri böler:
- Basit Sistemler Bariz neden hakkında bir rapor var. Bu durumlarda, konsolide yaklaşımlar nasıl En İyi Uygulama kullanılmış. Örneğin, bir çağrı merkezi için bir cihaz veya konuşma kılavuzu için onarım talimatları, ilgili bağlamdaki prosedür için böyle bir uygulamayı temsil edebilir.
- Karmaşık sistemler Bariz bir neden-sonuç ilişkisi var. Bu durumda birkaç etkili yol vardır (İyi uygulamalar). Bu alanın bir örneği, bir programdaki karmaşık bir hata sonrasında sorunları çözebilir. Etki için deterministik bir ilişki vardır, ancak hatanın nedenini belirlemek zordur. Ayrıca, sorunların her çözümü farklıdır. Bununla birlikte, yardım ve programların hala etkili yolları vardır: genellikle edinirler.
- Karmaşık Sistemler: Neden ve sonuç burada önceden görülemez. Yani var Gelişmekte olan uygulamalar C: Olanlara tepki verelim. Bu, farklı alanlardan insanların işbirliğini gerektirir. Bunun örneği, genellikle bir yazılım geliştirme projesinin amacı olan yeni bir pazarın geliştirilmesi olabilir. Önceden, yazılım ürününün nerede başarılı olacağı ve hangi özelliklerin gerekli olduğu açık değildir, ancak başarıya ve hatalara tepki vermek ve dolayısıyla ürünü başarıya götürmek mümkündür.
- Kaotik sistemler Sebep ve sonuç arasında bir bağlantıları yoktur. Bu, örneğin, acil bir durumda veya bir felakette meydana gelir. Bu nedenle sistem stabilize edilmelidir e Yeni Uygulamalar kullanılabilir.
Bu blog yazısı Cynefin çerçevesine tam bir giriş olamaz. Ama Cynefin çerçevesinden onu takip ediyor En İyi Uygulama Sadece basit Açık neden-etki ilişkileri olan sistemler. Çoğu durumda, yazılım sistemleri sadece teknolojik olarak karmaşık değildir: geliştirme, geliştirme ekibindeki çeşitli rollerin ilgili taraflarla etkileşime girdiği karmaşık bir sosyal sistemde gerçekleşir. Bir yandan teknolojik yazılım sisteminin ne kadar zor olduğunu ve sosyal gelişimin yapısını tahmin etmek zordur. Yani konuşuyoruz karmaşık VEYA karmaşık Sistemler. İstisnalar olabilir, ancak basit sistemler, bireysel yazılımın uygulanması için çabayı haklı çıkarmaz, çünkü problemlerin çözülmesi kolaydır, örneğin standart yazılım yoluyla.
Ancak yazılım projeleri ise karmaşık VEYA karmaşık Onlar, bu yüzden aslında sadece yazılımın geliştirilmesinde İyi Uygulamalar hatta Gelişmekte olan uygulamalar. Bu yüzden sadece farklı bir bağlamdan yaklaşımları kabul ederseniz En İyi Uygulama Gerekirse, bu etkinlik için uygun olmayan bir çözüm seçin. Bir dizi farklı ve özel zorluk üzerinde çalışıyoruz ve her seferinde bu diğer ortama uyarlanmalı ve mevcut zorluklarla karşılaşan çözümler sunmalıyız.
Hala En İyi Uygulama Projede yer alan kişilerin seçilen yaklaşımları sorgulamasını zorlaştırıyor. Sonuçta, onlar en iyi uygulamalar. Ama gerçekte uygun olmayabilirler çünkü başka bir alandasınız. Bu nedenle, “Mikro hizmetler mimariden daha iyi bir uygulamadır” veya “monolitler, mimariden daha iyi bir uygulama” gibi ifadeler yararlı değildir. Ancak belli bir bağlamda başarılı olan yaklaşımlarla yüzleşmek ve ondan öğrenmek mantıklıdır.
Sadece en iyi uygulamaları uyguluyorum?
İyi veya en iyi uygulamalarla mücadele de sorunlu olabilir. Bana bilinen bir projede, Mimar: Yalnızca iki takım kullanan iç arayüzler en iyi uygulamalar olarak iletişim kurar. Yalnızca iki takım söz konusu olduğundan, arayüzler daha fazla ekip arabirimleri kullandığından daha kolay değiştirilebilir ve koordine edilebilir. Dolayısıyla, farklı takım özellikleri sunmak istiyorsanız, her takımın bağımsız çalışması için bir arayüz uygulayabilirsiniz.
Proje ekiplerinden biri bu fikri izlemişti, ancak arayüzler nispeten benzer ve değişmiyor. Bu durumda, değişikliklerde bağımsızlığın avantajı önemsizdir. Ancak, ekip tek tip bir arayüz uygulamadı. Ekibin kendisi bu alternatifi en iyi şekilde değerlendirdi. En iyi uygulamalar iletilmeden, Mimar: Ekip daha önce en iyi yaklaşımını kullanmış olabilir. Tabii ki, yaklaşımın birçok arayüze sahip dezavantajları vardır. Bu, korunması ve uygulanması gereken çeşitli arayüzler oluşturur.
Aktarılan en iyi uygulamalar sadece iyi bir uygulama olabilir veya daha iyi bir uygulama olduğu bağlam daha kesin olarak adlandırılmalıdır. Merkezi nokta, iletilen en iyi veya iyi uygulamaların bu örnekleri kolayca takip etmeye ve en iyi çözümlerinizi kullanmamaya çalışmasıdır. Bu nedenle, bu yaklaşımlar her zaman eleştirel olarak sorgulanmalıdır.
Temel sorulara sahip karar verme modelleri daha esnektir ve farklı en iyi veya iyi uygulamalar arasındaki karara yardımcı olabilir. Bu modeller birçok kâr bulur, ancak aynı zamanda çözümün alanını da sınırlarlar, çünkü akla gelebilecek tüm vakaları asla kapsamazlar.
Çözüm
Sonunda, projeye katılan bireysel kararlar almalı ve sorumlu olmalıdır. Onları da haklı çıkarmalısınız. Daha iyi bir uygulamanın arkasında ya da “bugün yapıyorsun!” Saklanmak yeterli değil.
Ayrıca birkaç iyi uygulama var. Dolayısıyla, birisi en sevdikleri yaklaşımdan farklı bir yaklaşım seçerse, bu yine de iyi bir uygulama – hatta özellikle meydan okumaya uyarlanmış gelişmekte olan bir uygulama olabilir. Bu yüzden “en iyi uygulamanızı” tavsiye etmek için veda etmelisiniz. Tabii ki, seçilen yaklaşım hiçbir anlam ifade edemez, bu yüzden kesinlikle başka birini tavsiye edebilirsiniz.
TL; Dr.
Yazılım geliştirme genellikle en iyi uygulamalar için çok karmaşıktır. Oryantasyon verebilmelerine rağmen, eleştirel bir yansıma olmadan kullanılırlar, optimal olmayan mimari projeler özel zorluk için ortaya çıkabilir.
Meslektaşım için çok teşekkürler: Makalenin önceki bir versiyonunda yorumlar için Robert Glaser, Anja Kammer, Martin Kühl, Joachim Praetorius ve Hermann Schmidt.
()