Geri dönüşü olmayan karmaşıklık noktası. Ona ne diyorsun?

Bir yazılım geliştiricisi olarak, ana görevlerimden biri karmaşıklığı kontrol altında tutmak.

Bununla birlikte, bazı projelerde, karmaşıklık düzeyinin o kadar yüksek olduğu bir an vardır ki, bir tür “geri dönüş yok” noktasına ulaşır. Bu andan sonra, projeyi hiçbir zaman kabul edilebilir bir karmaşıklık düzeyine geri döndüremezsiniz, böylece her şeyi sıfırdan yeniden yazmanız gerekir.

Bu özel anın programcılar lehçesinde bir adı var mı (Godwin'in troller yasasına benzer bir şey)?

--Düzenle--

Açık değilsem özür dilerim. Bu "an" ın resmi bir adı olduğunu veya ciddi bir metrik olduğunu düşünmüyorum. Xkcd'deki "Ballmer peak" ruhunda bir şey düşünüyordum .

Bu karmaşıklıktan ziyade bir sürdürülebilirlik meselesidir .

Bu fenomene "teknik borç" denir ve kritik seviyeye ulaştığında proje iflas yolundadır.

Demek istediğin bu muydu?

"Aşırı karmaşıklık noktası" İngilizce olarak şu şekilde ifade edilir:

Aman Tanrım BU ÇAP NEDİR?

Sorun şu ki, bu aslında basit bir şey için geçerli olabilir, ancak aynı reaksiyona sahip olacak kadar korkunç bir şekilde uygulanır.

Bu yüzden çok karmaşık bir şeyi çok korkunç bir şeyden ayırmak zor olabilir.

ANCAK: Aslında tüm yazılımların başına gelme eğilimi şu şekilde bir süreçtir:

Adım 1: güzel bir spec var, güzel bir tasarım yapmak, güzel şeyler uygulamak. Herkes mutlu.

1. adımın sonunda: geliştiriciler tasarımlarının harika zarafetinden dolayı kendilerini tebrik ederler ve mutlu düşünerek uzaklaşırlar. daha iyi bir yer."

Adım 2: Bazı değişiklikler yapılır, işler eklenir, yeni işlevler eklenir. Adım 1'deki mimari ve yapı bunu oldukça ağrısız bir süreç haline getirdi. [Ama ayy, "ham faktör" biraz arttı.]

2. adımın sonunda: geliştiriciler tasarımlarının harika zarafetinden dolayı kendilerini tebrik ederler ve mutlu düşünerek uzaklaşırlar. "Gee, Adım 1'deki tüm izinleri almak için çok zekiyim. burada başkalarının gelecekte bir şeyler eklemesi harika olacak ve dünya daha iyi bir yer olacak. "

Adım 3: Daha fazla değişiklik yapılır, daha fazla şey eklenir, daha yeni işlevler, bir sürü şey değiştirilir, kullanıcı geri bildirimi gerçekten dinlenir.

3. adımın sonunda: geliştiriciler tasarımlarının harika zarafetinden dolayı kendilerini tebrik ederler ve oldukça mutlu düşünerek uzaklaşırlar. X ve Y ve Z hakkında. Şimdi biraz temizlenebilirlerdi ama! Ahhh !!! Adım 1'deki tüm ödenekleri yapmak için çok zekiyim. Bu çok iyi gitti. Burada harika bir mirasım var. diğerleri gelecekte bir şeyler eklemek için harika olacak ve dünya daha iyi bir yer olacak. "

Adım 4: Tıpkı 3. Adım gibi.

4. adımın sonunda: geliştiriciler şöyle düşünüyor: "Bu kadar iyi olan şeyler Çirkinleşmeyi sürdürüyor. Gerçekten bazı ciddi değişikliklere ihtiyacı var. Bu konuda çalışmayı gerçekten sevmiyorum. Yeniden düzenleme ihtiyacı var. Patronun ne olduğunu merak ediyorum Ona 6 hafta gerektiğini söyledi ve kullanıcıların bunun sonunda görmek için hiçbir şey olmayacağını söyleyeceğim ... ama bunu yaparak nefis gelecek değişiklik kapsamı 5 yıl daha var .... hmmm .. ... bira içmek için bara gitme zamanı. "

5. Adım: Birkaç değişiklik yapılması gerekir.

Ve 5. adımda geliştiriciler birbirlerine: "Bu kod berbat. Bunu kim yazdı? Vurulmalılar. Korkunç. Yeniden Yazmamız Gerekiyor."

Adım 5 ölümcül. Bu, ham faktörün o kadar kötüye gittiği, kodun sadece birkaç değişikliğe sahip olamayacağı, bazı BÜYÜK değişikliklere sahip olması gerekiyor.

5. Adımdaki sorun, onu atma ve yeniden başlama arzusudur. Bunun ölümcül olmasının nedeni "Netscape Faktörü" dür. Google'a git. Şirketler bu noktada DIE, çünkü tekrar başlamak, gerçekler yerine yaklaşık% 50 varsayımlar, bilgi yerine% 150 coşku, alçakgönüllülük yerine% 200 kibir ile başladığınız anlamına gelir ("Bu adamlar çok stoooopid!"). Ve bir sürü yeni hata tanıtıyorsunuz.

Yapılacak en iyi şey refactor etmektir. Her seferinde biraz değiştirin. Mimari biraz yoruluyorsa düzeltin. Ekleme, genişletme, geliştirme. Yavaş yavaş. Yol boyunca her adımda, biraz daha test edin, test edin ve test edin. Bunun gibi artan değişiklikler, 10 yıl sonra mevcut ve orijinal kodun büyükbaba baltası gibi olduğu anlamına gelir ("10 yeni kafası ve 3 yeni kulpu vardı, ancak hala büyükbaba baltası"). Başka bir deyişle, pek fazla ortak nokta kalmamıştır. Ama yavaş yavaş ve dikkatli bir şekilde eskiden yeniye geçtiniz. Bu riski azaltır ve müşteriler için sinirli faktörü azaltır.

Anı tanımanın zor olduğunu ve uygun süreçlerle önlenebileceğini kabul ediyorum. Ancak, soru buna ne diyeceğiydi. Reel ekonomide "azalan getiriler" kavramı vardır: bir süreçte bir kaynak için artan girdinin birim başına toplam kazancınızı azalttığı nokta. Bu kesinlikle kodlama için geçerlidir ve soyutlama, yeniden kullanım vb. Gibi iyi şeylerin bile geri dönüşü azaltan bir noktası vardır. Programlamaya özgü genel terim "aşırı mühendislik" tir. Bunu yapmaya eğilimli biri için Joel'in " mimari astronot " terimini seviyorum .

Çoğu zaman iyi kodlar, yeni araçlara sahip yeni ekibin daha ucuz, daha güvenilir ve daha hızlı yapabileceği yanlış izlenimi ile atılır.

• Karmaşıklık belgesel gereksinimlerdedir
• Yeni araçların kullanımı daha zor, sonra flash web sitesi söz verdi
• Yeni ekip düşündükleri kadar 'sıcak' değil

Muhtemelen tarif ettiğiniz zaman bazı kod üsleri ile geliyor (Ben böyle düşünürdüm). Hiçbir zaman şahsen bir projenin açığa çıkmasına neden olan eski bir kod örneğini deneyimlemedim veya bir projeyi kaydeden kodu yeniden yazmadım.

Belirli sorunlu modülleri veya tasarımları tanımlamak için metriklerin kullanıldığı ve daha sonra kaldırılan ve değiştirilen bu durumları dahil etmiyorum.

Bu teorik "an" ile ilgili asıl sorun, sadece olaydan sonra fark edilmesidir. İş arkadaşlarınız psikopat olmadığı sürece, kod tabanına yapılan her taahhüt, bunun kod tabanındaki bir iyileştirme inancı ile yapılır. Sadece o “anı” geçtiğinizi görebileceğiniz karışıklığa geri dönüyor.

Ama buna bir isim verebiliriz. "Beyler," diyebilirsiniz, diğer geliştiricilerinizi etrafınıza çekerek, "Sürdürülebilirlik Hellespont'u geçtik. Karınıza mesaj atın ve onu bir süre göremeyeceğinizi bildirin."

Bir isim olup olmadığını bilmiyorum ama eğer yoksa "erime noktası" demeyi öneririm

Bu çok ilginç bir soru değil.

Gerçekten önemsiz.

O kadar önemsiz ki başa çıkmak için sayısız yol geliştirdik.

1. Şelale yöntemleri. Birçok kişi, karmaşıklığın yönetildiğinden emin olmak için gereksinimleri gözden geçirmek ve belgeleri tasarlamak için çok zaman harcar.

2. Çevik Metodolojiler. Daha az insan, birinin problemini çözmek ve onlara yazılım bırakmak için hemen neyin geçerli olduğunu tartışmak için daha az zaman harcar. Karmaşıklık yönetilir, çünkü herkes bir şeyi serbest bırakmaya odaklanmıştır.

Herkesin "karmaşıklık" ile güreştiği tek zaman, metodolojiyi takip edememek ve zamanlarını düzgün bir şekilde yönetmek değildir.

• Bir şelale metodolojisinde ayrıntılı denetim yok. Ara iş ürünlerini gereksinimler, mimari, üst düzey tasarım veya ayrıntılı tasarım incelemelerinde incelemeye zorlanmazlar.

• Çevik bir metodolojide sprint son tarihi veya uygun kullanım durumu öncelikleri yoktur. Mümkün olan en kısa sürede kullanıcıya bir şeyler yayınlamaya odaklanmazlar.

Karmaşıklık, hedefler belirlenerek sınırlandırılmalıdır.

Karmaşıklıkla güreşmek hedeflerin belirlenmediği veya uygun şekilde ödüllendirilemediği anlamına gelir.

"Dönüm noktası" yok. Karmaşıklık yönetimi bir şekilde bir sorunsa, bir şey zaten örgütsel olarak yanlıştır.

(Büyük) projeler ve kodlar için karmaşıklığı artırma riskini görselleştirmek ve izlemek için yöntemler vardır. Makul bir şekilde uygulandıklarında, umarım geri dönüşü olmayan nokta için yeni bir isim gerekli değildir. (OpenHPI'da ilgili bir MOOC var: https://open.hpi.de/courses/softwareanalytics2015/ )

Yapısal Karmaşıklık genel bir tasarım sorunudur - sadece büyük ekiplerdeki yazılım tasarımı için değil. Görselleştirme, yapısal karmaşıklık yönetiminde ilk adımdır. Matrisler ve yönlendirilmiş grafikler de bu amaç için kullanılabilir.

Yapısal karmaşıklığı azaltmanın bazı yöntemleri http://www.buch.de/shop/home/suche/?fq=3540878890 :

• modülarizasyon
• geri besleme döngülerinden kaçınma
• nirengi

Ayrıca aksiyomatik tasarım kavramı vardır: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ Bu konsept ile gereksiz karmaşıklıktan kaynaklanan güvenilirlik sorunlarından kaçınılabilir.

Böylece bir çok yöntem mevcuttur. Sonunda her zaman onlar hakkında düşünme kararı ile ilgilidir, çünkü bir proje yeterince büyür.