“Tanrı objeleri” nin yanlış olduğunu nasıl ispatlayabilir veya çürütebilirim?

Sorun Özeti:

Uzun lafın kısası, bir kod üssünü ve değiştirmeme izin verilmeyen bir geliştirme ekibini miras aldım ve God Objects kullanımı büyük bir sorun. Devam edersek, bize bir şeyleri yeniden faktörlendirmek istiyorum, ancak Tanrı Nesneleri ile her şeyi yapmak isteyen ekiplerden geri adım atıyorum "çünkü daha kolay" ve bu da yeniden faktörlendirmeme izin vermeyeceğim anlamına geliyor. Yıllar süren gelişim tecrübemden bahsettim, bu şeyleri, vb. Tanıyan yeni patron benim olduğumu ve üçüncü taraf denizaşırı şirketlerin satış temsilcilerini hesapladığını ve şimdi yönetici düzeyinde ve toplantımda olduğunu belirttim. yarın ve en iyi uygulamaları savunmak için çok fazla teknik mühimmat almak istiyorum çünkü şirket için uzun vadede daha ucuz olacağını düşünüyorum (Ve şahsen üçüncü tarafın endişelendiğini hissediyorum).

Sorunum teknik düzeyde, uzun vadesinin iyi olduğunu biliyorum, ancak ultra kısa ve 6 aylık dönemle ilgili sorun yaşıyorum ve "bildiğim" bir şeyi referanslar ve kaynak göstererek kaynaklarla kanıtlayamıyorum. bir kişiden (Robert C. Martin, diğer adıyla Bob Amca), benden bir kişiden veri aldığı söylendiği gibi yapmam isteniyor. Sadece bir kişiden (Robert C Martin) bir tartışma yeterince iyi değil .

Soru:

Alanında tanınmış uzmanlar tarafından doğrudan "Unvan, yıl yayınlandı, sayfa numarası, alıntı" diyebileceğim bazı kaynaklar nelerdir Açıkça "Tanrı" Nesneleri / Sınıfları / Sistemlerini kullanmanın kötü olduğunu (veya aradığımızdan beri iyidir) en teknik olarak geçerli çözüm için)?

Araştırma yaptım zaten:

1. Burada birkaç kitabım var ve “tanrı nesnesi” ve “tanrı sınıfı” kelimelerini kullanmak için endekslerini aradım. Tuhaf bir şekilde neredeyse hiç kullanılmadığını ve GoF kitabının kopyasının, örneğin hiç kullanmadığını (en azından önümdeki dizine göre) buldum, ancak aşağıdaki iki kitapta buldum, ancak daha fazlasını istiyorum. Kullanabilirim.
2. "God Object" için Wikipedia sayfasını kontrol ettim ve şu anda küçük referans bağlantılarına sahip olan bir saplama var, bu yüzden kişisel olarak onunla aynı fikirde olduğumu kabul etsem de, kişisel deneyimimin geçerli olmadığı kabul edilen bir ortamda kullanabileceğim fazla bir şey yok. Alıntı yapılan kitabın, bu teknik noktaları tartıştığım insanlar tarafından geçerli olamayacak kadar eski olduğu da iddia ediliyor; “bir zamanlar kötü olduğu düşünülüyordu ama kimse bunu ispatlayamıyordu, ve şimdi modern yazılım” diyor. "nesneler kullanmak iyidir". Şahsen, bu ifadenin yanlış olduğuna inanıyorum, ancak gerçeği kanıtlamak istiyorum, her neyse.
3. Robert C Martin'in "C # 'da Çevik İlkeleri, Kalıpları ve Uygulamaları" nda (ISBN: 0-13-185725-8, ciltli) 266. Sayfada "Herkes tanrı sınıflarının kötü bir fikir olduğunu biliyor. Bir sistemin tüm zekasını tek bir nesneye veya tek bir işleve yoğunlaştırmak. OOD'nin amaçlarından biri de davranışların birçok sınıfa ve birçok işleve ayrılması ve dağıtılmasıdır. ” - Ve sonra bazen bazen yine de Tanrı Sınıflarını kullanmanın daha iyi olduğunu söylemeye devam ediyor.
4. Robert C Martin'in “Temiz Kodu: Çevik Yazılım İşçiliğinin El Kitabı”, sayfa 136 (Ve sadece bu sayfa) “Tanrı sınıfı” hakkında konuşur ve “sınıflar küçük olmalı” kuralının ihlal edildiğinin en önemli örneğidir. 138. sayfada başlayan "Tek Sorumluluk İlkesini" teşvik etmek için kullanıyor.

Sahip olduğum sorun tüm referanslarım ve alıntılarım aynı kişiden (Robert C. Martin) ve aynı kişiden / kaynaktan geliyor. Bana sadece tek bir görüş olduğu için "Tanrı Sınıfları" nı kullanma arzumun geçersiz olduğunu ve yazılım endüstrisinde standart en iyi uygulama olarak kabul edilmediği söylendi. Bu doğru mu? Bob Amca'nın öğretisine devam etmeye çalışarak teknik açıdan yanlış şeyler mi yapıyorum?

Tanrı Nesneleri ve Nesneye Dayalı Programlama ve Tasarım:

Bunu düşündüğümden daha fazla düşünüyorum, bunun daha fazla OOP okuduğunuzda öğreneceğiniz bir şey olduğunu düşünüyorum ve asla açıkça söylenmiyor; İyi tasarımın anlamı benim düşüncem (beni düzeltmek için çekinmeyin, lütfen öğrenmek istediğim gibi), sorun bunu "bildiğim" ama herkesin yapamadığı, bu durumda geçerli bir argüman olmadığı için Aslında, çoğu insanın istatistiksel olarak cahil olduğu, çünkü istatistiksel olarak çoğu insanın programcı olmadığı, etkili bir şekilde evrensel bir gerçek olarak adlandırıyorum.

Sonuç:

Teknik bir iddiada bulundukları için alıntı yapmak için en iyi sonuçları elde etmek için neyin aranacağı konusunda bir kayıbım var çünkü gerçek bir mühendis / bilim insanı gibi alıntılarla kanıtlayabiliyorum ve gerçeği bilmek istiyorum. Tanrının nesnelerine, onları kullanan kodla ilgili kişisel deneyimim nedeniyle önyargılıyım. Herhangi bir yardım veya alıntı derinden takdir edilecektir.

Herhangi bir uygulama değişikliği için durum, mevcut tasarım tarafından yaratılan acı noktaları tespit edilerek yapılır. Özellikle, mevcut tasarımdan dolayı ne olması gerekenden daha zor olduğunu, neyin kırılgan olduğunu, şimdi neyin kırıldığını, hangi davranışların doğrudan (veya hatta biraz dolaylı) bir sonuç olarak basit bir şekilde uygulanamayacağını tanımlamanız gerekir. mevcut uygulama veya bazı durumlarda, performansın ne kadar düşük olduğu, yeni bir ekip üyesini hızlandırmak için ne kadar zaman aldığı, vb.

İkincisi, çalışma kodu teori veya iyi tasarım hakkındaki tüm tartışmalara değiniyor. Bu ne yazık ki kötü kod için bile geçerlidir. Bu yüzden daha iyi bir alternatif sunmanız gerekecek, bu da sizin daha iyi kalıpların ve uygulamaların savunucusu olarak, daha iyi bir tasarıma kavuşmak için refactor'a ihtiyaç duyacağınız anlamına geliyor. Mevcut tasarım boyunca dar, iz bırakan bir kurşunsuz stil düzlemi bulun ve belki de yineleme için tanrı nesnesi uygulamasının çalışmaya devam etmesini sağlayan, ancak gerçek uygulamayı yeni tasarıma savunan bir çözüm uygulayın. Ardından, bu yeni tasarımdan yararlanan bir kod yazın ve performans, bakım, özellik, hata veya yarış koşullarının düzeltilmesi veya geliştirici için bilişsel yükün azaltılması gibi nedenlerden dolayı kazandıklarınızı gösterin.

Kötü dizayn edilmiş sistemlere saldıracak kadar küçük bir yüzey alanı bulmak genellikle zor bir iştir, başlangıç ​​değeri vermek istediğinizden daha uzun sürebilir ve başlangıçtaki kazanç herkes için bu kadar etkileyici olmayabilir, ama aynı zamanda çalışabilirsiniz. En azından biraz sempatik olan ekip üyeleriyle eşleşirseniz, yeni yaklaşımınızın bazı savunucularını bulma konusunda.

Tanrı Nesnesini laminatlamak sadece koroya vaaz verirken işe yarar. Bu bir problemi adlandırmak için bir araçtır ve sadece bir şey yapacak kadar kıdemli ve motive olmuş alıcı bir kitleye sahip olduğunuzda çözmek için çalışır. Tanrı nesnesini sabitlemek argümanı kazanır.

Endişelenmenizin sorumluluğu yönetici olarak göründüğü için, bu kodu değiştirmenin stratejik bir hedef olması ve bunları sizin sorumlu olduğunuz iş hedefleriyle ilişkilendirmesi gerektiğine dair bir dava açmanın en iyisi olduğunu düşünüyorum. Bence, öncelikle mevcut tasarımla ilgili çekinceleri olan bir veya iki teknik kişiden gelen kaynakları içeren teknik bir çiviyi çalıştırarak, yerine değiştirmek için yapılması gerekenler üzerine bir teknik yönlendirme sağlayabileceğinizi düşünebilirsiniz.

Bence argümanınızı haklı çıkarmak için yeterli kaynakları buldunuz; bu tür toplantılardaki kişiler yalnızca araştırmanızın özetine dikkat eder ve iki ya da üç destekleyici kaynaktan bahsettikten sonra dinlemeyi durduracaklar. Odak noktanız, başkasının yanlış veya kendinizin doğru olduğunu kanıtlamak zorunda değilsiniz, gördüğünüz problemi yerine getirmek için satın almaktır. Bu sosyal bir problem, mantıklı değil.

Bir teknoloji liderliği rolünde, girişimlerinizden herhangi birini iş hedeflerine bağlamanız gerekir; bu nedenle, yöneticinizi dava etmek için en önemli şey işin bu hedefler için yapacağı şeydir. Ayrıca “yeni adam” olarak kabul edildiğiniz için, insanların işlerini atmalarını ya da hızla sıraya girmelerini bekleyemezsiniz; teslim edebileceğinizi kanıtlayarak biraz güven inşa etmeniz gerekir. Uzun vadeli bir endişe olarak, liderlik rolünde, sonuçlara odaklanmayı da öğrenmeniz gerekir, ancak sonucun özelliklerine bağlı olmanız gerekmez. Artık stratejik yön sağlamak, ekibinizin ilerleyişindeki taktik engelleri kaldırmak ve kendi ekip üyelerinizle güvenilirlik savaşları kazanmak değil, takım danışmanlığınızı sunmak için buradasınız.

Yukarıdan aşağıya bir karar vermek, oyunda biraz cildiniz olmadığı sürece nadiren güvenilir olacaktır; Tekrar tekrar benzer bir durumdaysanız, durumun kontrolden çıktığını hissettiğinizde bir kez daha tırmanmak yerine organizasyonunuzdaki fikir birliği oluşturmaya odaklanmalısınız.

Ama şimdi nerede olduğunuzu göz önünde bulundurarak, en iyi bahsinizin, yaklaşımınızın deneyimlerinize dayanarak ölçülebilir uzun vadeli faydalar getireceğini ve bunun Bob amca ve co gibi tanınmış pratisyenlerin çalışmaları ile uyumlu olduğunu iddia etmek olduğunu söyleyebilirim. ve iyi tasarım görüşünüzün nasıl görünmesi gerektiğini göstermek için örnek olarak birkaç gün / hafta harcayacağınızı ve en yüksek paranın karşılığını en iyi şekilde yansıtan dar bir yeniden düzenlemeye karar vermek istediğinizde. Bununla birlikte, durumunuz ne olursa olsun, kişisel tercihlerinizin ötesinde belirli iş hedeflerine uyum sağlamanız gerekir.

Öncelikle, ölçülebilir herhangi bir kuruluşun sektördeki en iyi uygulamaları benimsemesi gerektiğini göstermeniz gerekir. "Sadece bizim için işe yarıyor!" ne zaman ne de kaynakta tahmin edilemez olduğu için ölçülemez. Yazılım mühendisliği, diğer bilim alanlarında olduğu kadar bir bilimdir ve bu kavramlar incelenmiştir, araştırılmıştır, test edilmiştir ve belgelenmiştir.

1. Tanrı Nesne bir olan anti-desen belirtiyor

   Yazılım mühendisliğinde, bir anti-patern (veya antipattern), sosyal veya ticari operasyonlarda veya yaygın olarak kullanılabilen ancak pratikte etkisiz ve / veya verimsiz olan bir yazılım paternidir.

2. In 2009 tarihinde IO konferansında MVP desen açıkladı edildiğinde, bu konu kısmen açıklanmıştır. Tanrı Nesnesi ile ilgili olmayabilir, ancak size biraz cephane verebilir.

3. Ayrıca, bu anti-paternin kullanılması , nesne yönelimli tasarımlarda tek sorumluluk ilkesini ihlal ettiğini;

   Her sınıfın tek bir sorumluluğu olmalı ve bu sorumluluk tamamen sınıf tarafından kapsanmalıdır. Tüm hizmetleri bu sorumlulukla dar bir şekilde hizalanmalıdır.

4. Decaying Kod günlüğü de bu bahsediyor ve bu konuda bir çözüm.

5. Nesne eşleşmesinden bahsetmeden tek sorumluluk ilkesinden bahsedemeyiz .

   [...] bağlanma veya bağımlılık, her program modülünün diğer modüllerin her birine dayanma derecesidir.

   Sıkıca bağlanmış bir sisteme sahip olması, assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.daha yüksek seviyede nesne bağlamaya neden olabileceği durumlarda , daha az uyum anlamına gelir ve bunun tersi de geçerlidir. Tanrı nesneleri, bilmeleri gerekenden daha fazlasını bildikleri için sıkı bağlantıya iyi bir örnektir, bu yüzden onları sorumlulukla yükler, böylece kodun tekrar kullanılabilirliğini büyük ölçüde sınırlar.

6. Karmaşık bir uygulama tasarlarken, basitlik akla gelmelidir. Büyük problemlerin yönetilmesi, test edilmesi ve belgelendirilmesi daha kolay olan daha küçük problemlere ayrılması gerekir. Bu, özellikle nesne yönelimli bir paradigmada geçerlidir.

   Bu argümanla, anti-patern argümanına geri dönüyoruz, ancak bu paradigma tamamen paternler, gerçek dünya nesne temsili ve sonuçta veri kapsülleme ile ilgili.

7. Bu “iyi uygulamaların” sınıflarda daha var olduğunu söylerken haklısınız. Ancak kolejde (ve bazı üniversitelerde) öğretmenlik tecrübem var ve bu ilkelerin üniversitelerde, özellikle mühendislik fakültelerinde öğretildiğini gördüm. Bu üzücü. Ancak, herhangi bir iyi uygulamada olduğu gibi, kendilerini daha iyi hale getirmek için çabalayanlar genellikle bazı temel tasarım kalıplarını öğrenirler ve nihayetinde eşleşme ve uyum arasında nasıl gidileceğini anlarlar.

   Ne genellikle öğrencilere öğretmek o, yani olabilir iyi programlama standartlarını benimsemek için daha fazla çaba gerektiren görünmektedir, ancak her zaman uzun vadede ödemek. İyi bir örnek, bir programlayıcıdan bir sıralama işlevi yazmasını isteyen biri olabilir. Programcının iki seçeneği vardır; 1) elemanların listesi büyüdükçe sürdürülebilir olmayacak hızlı bir kabarcık sıralama işlevi (5 dakikadan az) yazın veya 2) daha iyi ölçeklenecek daha karmaşık (aka optimize edilmiş) bir sıralama algoritması (hızlı sıralama vb.) Yazın daha büyük listelerle.

Oh işte gidiyorum, başka bir eski soruyu soracağım ama tahminimce bu tartışmayı kazanmadın ve işte bu yüzden.

Bir Kültür Sorunu Gibi Görünüyor

Sen onların menajeri sensin ama onların yerini alamazsın ve yapmaları gerektiğine inanmaları gereken şeyi yapmalarını sağlamak için menajerlerine gitmelisin ki bu durumda en azından tanrıya atacağım. ilerleyen nesneler. Bana doğduğu kültürü yansıtan klasik bir kod örneği gibi geliyor. Başka bir deyişle, tanrı nesnesi bu şirketin işleyişidir. Herhangi bir anlamlı değişiklik yapmak ister misiniz? Sonuçta her zaman aynı yere gideceksin, çünkü tüm kararların en üstte görünmesi gerekiyor.

Eski kod temizleme işlemlerinde ve kod ilkesi değişikliklerinde birden fazla başarısız denemeye özel davranmak artık, bu kültür hala sıkı bir şekilde yerleşikken veya en azından mücadele ettiğinde, ilk önce kodu mümkün kılan kültürle mücadele edemeyeceğinize inanıyorum. kültür çok zor bir yokuş yukarı bir slogan, kimsenin bana yeterince ödeme yapması ya da bir daha başarılı olması muhtemel olan değerli bir çaba gibi hissetmek için bana yeterince güç vermesi ihtimalinin düşük olması.

Değişim olmadan önce, değişmeye motive edilmeleri gerekir ve ne yazık ki Stack'ı okumak için yeterince şey veren programcılar olarak, herkesin aynı şeyler tarafından motive edilmediğini anlamamız zor. Deneyimlerimdeki rasyonel argümanların çoğunu kazandım, ancak günün sonunda, şirketin bir nedenden dolayı entelektüel olarak tembel düşmeleri yaşanıyor.

Belki de işle ilgili endişeler önümüzdeki hafta veya beş yıl sonra olmak yerine yalnızca yarın hakkında düşünmeye motive olmuştur (özellikle kıyamet durumunda Kuzey Kutbu'na tohum kasası kuran bir ülkeden gelen göçmenlerin çocuğuysanız, özellikle sinir bozucu bir senaryo). Belki de değişimden korkuyorlar. Belki de kıdem tazminatına, büyük bir ekip lideri ya da menajer getirmek için dışarıdan kiralamak zorunda kalsalar bile, komuta zincirinin anlamsız olduğu noktalarına aşırı değer veriyorlar çünkü tamamen kendi takımlarında yeteri kadar büyük bir ekip olmadı. orada (ya da söz konusu asansörler sorumlulukla ilişkili riski istemediği için). Ya da ve bunu gördüm, belki de kendini sıradan şampiyonluğun en gerçek ve iç karartıcı fenomenidir, çünkü içinde derinlerde olduğunu bilir.

Nihayetinde başarı için korku veya kırılan metriklere dayanan konularla nasıl savaşırsınız? Size şunu söyleyeyim, kararlı bir kalifiye ekipten bile çok daha fazlasını gerektiriyor ve bu Q'nun gönderildiği andaki sesten çok daha azına sahiptiniz.

İmkansız Değil Olayında Etkilenemeyen Bir Kültür Sorunu Değil ...

Şimdi üstteki insanların değişmeye çok açık olduklarını ve aslında bunu yapmak için size güvenmeye istekli olduklarını varsayarsak, gerçekten tüm argümanlarınızı para ve kaybedilen fırsatlarla noktalamalısınız.

Bu saçma kod temeli üzerinde yeni birisini eğitmek ne kadar zaman alırsa, bir şey üzerinde değişiklik yapmak veya yeni bir özellik eklemek her zaman daha uzun sürer, ne zaman ortak noktaları olmak istediğiniz bir şirketten bitiş noktalarını göstermek her zaman zorlaşır. , paraya mal oluyor. Bir sürü ucube para. En önemlisi, daha küçük, daha çevik bir yarışmacının içine girmesi için bir pencere açıyor, sizi yapabileceğiniz tek şeyin onlara çok yavaş tepki gösterebileceği bir pozisyona sokuyor ve sonunda hepsini elinizden alıyor.

Sadece inatçı ve aptal bir kültürün, şirketin gerçek fiziksel çatısı aslında ondan dolayı yanıyor olsa bile, statükoyu her ne pahasına olursa olsun koruyacağını kabul edin.

Gevşek bağlanma ve yüksek uyum gibi en temel OOP prensiplerinden bazılarına atıfta bulunabilirsiniz. Bir "Tanrı nesnesi" ilgisiz sınıfları eşleştiriyor gibi görünür ve düşük uyumu vardır.

Her zaman Bob Amca'nın kendisine sorabilirsin.

Mesele şu ki, herhangi bir anlamıyla insanlara hecelendirebiliyorlar, bir kez hecelendiklerinde, çok sayıda yazar tarafından yeniden referans alınması gerekmiyor. Sadece bir kaynağa ihtiyaç var.

Kaynakları ararken başlamak isteyebileceğiniz diğer terimler şunlardır:

• KATI
• Demeter Kanunu
• Büyük Çamur Topu

Bunların hepsi, aslında böyle adlandırılmasalar bile, geçerli referans kaynakları sağlayabilecek ilgili kavramları ifade ediyor.

Sonuçta olsa, patron sensin. Bunu yapmanın nedeni, böyle söylemenizdir ve iyi bir menajer olarak kabul edilmenize rağmen, kararlarınızı gerekçelendirmek için gerçekten hazırlıklı olmalısınız; Bunu yaptınız ve hala direnç varsa, ekibinizin söylendiği gibi yapması gereken doğru hareket tarzıdır.

“Tanrı” nesnelerinin yanlış olduğunu nasıl ispatlayabilir ya da ispatlayabilirim?

Yapamazsın.

Bu tür bir varsayım matematiksel kanıt için uygun değildir ve matematiksel kanıt, sağlam tek kanıttır.

"Yanlış" duygusal kelimesini tanrı nesnelerini kullanmanın etkilerinin ölçülebilir ölçüleriyle değiştirmeye çalışsanız bile, şunu bulacaksınız:

1. mevcut önlemler kaba,
2. Profesyonel programcılar tarafından üretilen kod için bu önlemlerin ölçüldüğü birkaç güvenilir çalışma yoktur.
3. Dil yapıları veya tasarım (anti-) kalıplarının bu önlemlere bağlandığı güvenilir çalışmaların sayısı çok azdır.

Ve bu, belirli bir nesnenin ne zaman "tanrı" nesnesi olduğuna karar verme konusunu görmezden geliyor.

En iyi ihtimalle, bu tür çalışmalar yalnızca ampirik bir korelasyon gösterebilirdi. Gerçek bir kanıt değil.

Yaptığınız şey, diğer insanların fikirlerini değiştirmek için “tanrı” nesnelerinin artılarını ve eksilerini ... ve sonra da kuruluşunuzun pratiğini tartışmak .

"Kanıt" gibi kelimeler kullanmayın ya da tartıştığınız insanlar yüzünüze gülmekle yükümlüdür.

84. haftanın gurusunu görmek isteyebilirsiniz . Her şey tanrı objeleriyle (monolith'ler) ve nasıl kötü olduklarıyla ilgili.

Ayıkla:

(Binbaşı) Sınıf içinde potansiyel olarak bağımsız işlevselliği izole ediyor [...] (Küçük) Sınıfı yeni işlevlerle genişletmeyi engelleyebilir [...]

Ekibiniz "Tanrı'nın yanlış olduğunu" kanıtlayan akademik bir kanıtla gerçekten ilgilenirse, hiç şüphem yok.

Psikolojik bakış açısına göre, yeniden yapılanma yaklaşımınız, ekibin yetkinliğine bir la: "takım kötü bir iş çıkardı" olarak programın beklendiği gibi çalışmasına rağmen yanlış anlaşılabilir.

Gerçekten yapmak istediğiniz şey "spagetti kodu" ve "Tanrı objeleri" nin olumsuz yan etkileriyle başa çıkmaktır: yan etkilerin neden olduğu artan hatalar nedeniyle yeni özellikler eklemek için araştırma maliyetleri.

Çok spesifik olmak ve cevap vermek yerine soru sormak daha yararlı olabilir:

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code