Meslektaşlarımın hepsi anlamadığı halde meta-programlama kullanmak uygun mudur?


102

Tekrarlayan görevleri önlemek ve daha güvenli kullanım için soyutlamalar oluşturmak için çok fazla meta programlama kullanıyorum.

Geçenlerde daha büyük bir takımda çalıştığım yeni bir işe taşındım ve bu bazı meslektaşlarımı endişelendiriyor, çünkü anlamadılar.

Her zaman dilin potansiyelinden tam olarak yararlanmaya çalışıyorum, ancak meslektaşlarımdan bazıları (hepsi değil) bunu bir risk olarak görüyor (bazıları yaklaşımı memnuniyetle karşılıyor).

Takımda başka kimsenin anlayamadığı bir kod yazmanın bir sorun olduğunu kabul ediyorum. Öte yandan, hepimiz profesyonel C ++ geliştiricileriyiz ve bence sınıflara C yazmaktan daha yüksek bir standarda heveslenmeliyiz.

Sorum şu, kim haklı, ne yapmalıyım?

Açıklama: Dilin potansiyelinden tam olarak yararlanmaya çalışmak, her soruna TMP attığım anlamına gelmiyor. C ++ bir araç kutusudur ve bana göre C ++ uzmanlığı kutudaki tüm araçları kullanabilmek ve belirli bir iş için doğru olanı seçmekle ilgilidir.


38
Bu sonuçta görüşe dayalı. Şahsen, C ++ şablon metaprogramlaması gibi, yanlışlıkla Turing-complete olan özellikleri karmaşık kullanmama kuralını yapıyorum.
Kilian Foth

24
@KilianFoth şablonları "yanlışlıkla" Turing-tamamlandı değildir. Her zaman güçlü soyutlama araçları olmaları amaçlandı
Caleth

73
Hiç kimsenin anlayamadığı kod daha yüksek bir standart değildir.
gburton

37
@Caleth Herb Sutter yanlışlıkla onları Turing-tamamlandı diyor . Elbette, güçlü soyutlama özellikleri olmaları amaçlanıyordu, ancak Turing-eksiksizliğinin sağladığı gibi yaylı, kararsız yapılara izin vereceklerini sanmıyorum. Ve şüphesiz, onların sözdizimleri gerekli meta-programlamayı daha az şeffaf hale getirmek için tasarlanmamıştır.
leftaroundabout

26
Yanlış ikilemi. "Daha yüksek standartta" programlama yapabilir ve sınıfları ile C'yi geride bırakabilir, modern C ++ 'ı benimseyebilir, şablonları (örneğin STL) ve const, no () döküm, işaretçi aritmetiği, değer semantiği, iyilik, yön vermeden kullanabilirsiniz ibnto TMP. Sınıflar ile C ve TMP arasında gün ışığı görmüyorsanız, o zaman yanlış yaparsınız.
Kate Gregory

Yanıtlar:


185

Metaprogramming tamamdır. Yapmaya çalıştığın şey tamam değil.

İşimde her zaman metaprogramlama kullanıyorum. Bir çok şeyi daha okunaklı ve bakımı kolay bir şekilde yapmak için kullanılabilecek güçlü bir araçtır. Aynı zamanda orada programlama stillerini kavramak en zorlarından biri, bu yüzden gerçekten kalıcılığını kazanması gerekiyor. 1000 kod satırı 50'ye düşürdüğümde hoşuma gidiyor, ancak sınırlandırmayı deniyorum.

Sorun metaprogramlama değil, bu:

Öte yandan, hepimiz profesyonel C ++ geliştiricileriyiz ve bence sınıflara C yazmaktan daha yüksek bir standarda heveslenmeliyiz.

Başın belaya girdiği yer burası. Bir fikrin var. Meta programlamanın iyi olduğu fikrine sahip olmak iyidir. Hepimizin daha iyi C ++ geliştiricileri olmak istediğimize dair bir fikrimiz olması iyi.

Sizin Meslektaşlarımız hem zorlamak iyi değil ve size görüşünü kabul etmek yazdığı kod korumak zorunda kalacaktır gelecek işe alımlar. Patronunun işi bu. Patronunuz, uzun vadede kodunuzun korunmasını sağlamakla ilgilenmesi gereken kişidir. Onlar (umarım) çok daha fazla iş tecrübesi yaşarlar, çünkü ideolojik bir karar değil, bir iş kararı olduğunu söylediğimde bana inanın.

Metaprogram istemek iyidir. Başkalarına metaprogramı öğretmeyi istemek iyidir. Ama aynı zamanda başkalarının metaprogramlamayı öğrenmemeyi seçmesinin iyi olduğunu ve iktidarda olana kadar geçerli olacağını anlayın. (ve bir endüstri sırrı olarak: nihayetinde lider bir geliştiriciyseniz, bir güç konumunda, hiç bir güç konumunda değilsiniz. İktidarda olan riskleri kontrol eden biri var).

Metaprogramming ile tamam olmalarını teşvik etmek istiyorsanız , küçük başlayın . enable_ifAPI'nin okunmasını kolaylaştıracak bir single ile başlayın . Ardından günışığını bunun dışında yorumlayın . O zaman belki bir şablon metafonksiyonunun 10 büyük tekrarlayan sınıfı 10 küçük yardımcı ile 1 sınıfa dönüştürdüğü bir durum bulabiliriz. Çekmeyi yorumla. Geri bildirim almak. İnsanların bu konuda ne düşündüğünü bulun. Yapmamanı söylerlerse iyi olun. Meta programlamanın o kadar iyice kazandığı bir niş bulun, meslektaşlarınızın hepsi (yalvarmadan) iş için doğru araç olduğuna karar verdiler.

Kısa bir hikaye olarak, bir zamanlar geniş metaprogramming kullanarak güzel bir kütüphane yazdım. Başka hiçbir yaklaşımın uzaktan yaklaşamadığı zamanlarda tam da ihtiyacımız olan şeyi yaptı. Aslında yazdığım uygulamanın yönünü değiştirdi. Ama metaprogramlama yapıyordu. Şirketimin tamamında yalnızca bir veya iki kişi okuyabilirdi.

Daha sonra meslektaşım soruna bir kez daha karar verdi. Gerekenleri tam olarak yapmak için metaprogramlamayı kullanmak yerine, metaprogramlamanın gerekli olmadığı şekilde soruna getirilen kısıtlamaları gevşetmek için liderlikle çalıştı. Belki de daha doğru bir şekilde, metaprogramlamaya daha az ihtiyaç vardı. Bunu metaprogramming'in en iyi yaptığı şeyle sınırlandırabilirdi.

Sonuçta ortaya çıkan kütüphane şimdi oldukça geniş bir pazarda kullanılabilecek bir konumdadır ve bu yeni kodun daha geniş bir geliştirici grubu tarafından korunabilmesi nedeniyle kesinlikle küçük bir bölüm değildir. Metaprogramming ile yolu açmaktan gurur duyuyorum, ancak bu daha geniş kitlelere ulaşacak olan meslektaşımın kodu ve bunun için iyi sebepler var.


72
"Metaprogramlamayı" başka bir stil, teknik, teknoloji, kütüphane ile değiştirin ve cevap hala harika!
Andrejs

4
Patronunuz, uzun vadede kodunuzun korunmasını sağlamakla ilgilenmesi gereken kişidir. Çoğu patron kod korumanın ne olduğunu bile bilmiyor. Neredeyse teknik bilgi sahibi değiller, bu yüzden kararlarını politik karakterli olanlara güvenmezdim.
t3chb0t

4
@ t3chb0t: Deneyimli bir patron, müşteri hizmetlerine ne kadar para harcanması gerektiğini (örn. hata onarımı ve yeni özellikler) ve bu maliyeti nasıl en aza indireceğini bilir. Bakım, bu amaç için en güçlü araçtır. Bu patron teknik detayları bilmeyebilir, ancak bu noktada güvenilir olabilecek bir takım oluşturabilmelidir.
mouviciel

25
@DDrmmr Standartları yükseltmek için programcıların metaprogramlama kullanması gerektiğine inanan birisinin tonunu belirledim. En az vasıflı ekip üyesinin koruyabileceği yere aptal olması gerektiğini sanmıyorum. Takımın bakımını yapabileceği yere dökülmeli ve belki de daha güçlüsü takımın siz olmadan bakımını yapabileceği yere dökülmelidir . Aksi halde biri kendine bir iş yazar.
Cort Ammon

15
@Joshua Bulduğum şey, "bakıma ihtiyacı olmayan kod" diye bir şey bulunmadığı.
Cort Ammon

39

Öncelikle ve en önemlisi, bu takımın sorunudur ve bunu takımla birlikte çözmek zorundasınız. Takımdan belirli elemanları ve yapıları kullanarak programlama yapmak için yedeğiniz varsa, bunu yapın; eğer değilse, onlarla konuşun ve onları ikna edemiyorsanız ve "yaklaşımınızın" neden daha iyi olduğunu vurgulayan güçlü bir dava açamıyorsanız, kullanmamakta daha iyi olursunuz.

C ++ 'ta şablon meta-programlama kullanmanın daima bir kazanç olduğunu unutmayın: elbette, bir uygulamanın belirli bölümlerini daha DRY tasarlamaya yardımcı olabilir ve kesinlikle yüksek verimli ve yeniden kullanılabilir kütüphaneler oluşturmak için kesinlikle yardımcı olabilir.

Öte yandan, bu avantajları belli bir ücret karşılığında gelir: Kod genellikle daha soyut olur çok sert okumak için çok hata ayıklamak zor ve çok bakımı zordur. Bu, uygulama programlamasında meta-programlamanın yararını sıklıkla sorgulanır hale getirir. Dolayısıyla, bir sonraki STL'yi yaratmayacağınızı varsayarak, meta-programlamayı her kullanmaya karar verdiğinizde, bu dezavantajların gerçekten buna değer olup olmadığını kendinize sorun. Emin değilseniz, kod incelemesi sırasında bunu meslektaş yorumcunuzla görüşün.


Kabul ediyorum, ancak QA ile koduna koymadan önce tartış. Reddedilecek bir şey yaratmanın anlamı yok.
shawnhcorey

8
Peki ya: “Katılıyorum. Ama ...“ Onu “olarak” değiştirmek anlamını tamamen değiştiriyor. Kişi, zaman geçirmeden önce KG ile olağandışı bir şeyi tartışmalıdır. Bu tartışmanın, zaman harcandıktan sonra kod incelemesinde yapılması gerektiğini söylediniz.
shawnhcorey

@ shawnhcorey: Kuruluşunuzdaki "KG" kodlama standartlarından sorumluysa elbette. Bununla birlikte, bu IMHO'nun tipik bir “KG” rolü değil - bildiğim çoğu kuruluşta “KG” terimi, bir programlama dilinin hangi unsurlarından sorumlu değildir diye kara kutu şeklinde kalite güvencesi yapan bir grup insanı ifade eder. kullanılmalı ve kullanılmamalıdır. Bu insanlar programlamada nadiren bu tür ayrıntıları tartışmak için yeterli niteliktedirler.
Doktor Brown

2
@ shawnhcorey: Bu tam olarak benim açımdan, QA rolü farklı organizasyonlarda büyük ölçüde değişir. Birçok kuruluşta, KG çalışanları programlama konusunda hiçbir fikre sahip değildir, bu nedenle muhtemelen böyle bir konuyu tartışmak için doğru olanlar değildir.
Doktor Brown,

2
@ shawnhcorey: bir yandan "QA genel bir terimdir" yazmışsınız - bir yandan da çok özel bir QA rolünüz ve sorumluluğunuz var - aklıma biraz geliyor.
Doktor Brown,

18

Genel fikrim: aşağıdaki gibi üç seçenek arasında sık sık olduğu gibi bir seçeneğiniz varsa:

  • El ile tekrar tekrar birçok önemsiz kod yapısı yazın;
  • Kod oluşturmayı otomatikleştirmek için C ++ şablon metaprogramlamasını kullanın;
  • C ++ kaynak dosyaları oluşturmak için makrolar veya başka bir programlama dili gibi başka bir kod oluşturma mekanizması kullanın

Daha sonra, uygun şekilde yapılan şablon metaprogramlaması, üç seçeneğin en okunaklı ve bakımı mümkün olacaktır. Eğer pozisyonunda olsaydım, takıma yapacağım argüman bu. Gerçek kod örnekleri, onları ikna etmeye yardımcı olur.

Tekrarlamayı önlemek için Şablon Meta Programlama'yı ( TMP ) kullandığınızda, doğru müşteri kodunu yazmayı kolaylaştıran TMP kodu içindeki karmaşıklığı yerelleştiren iyi belgelenmiş, dikkatlice test edilmiş soyutlamalar oluşturmak için kullanmanız gerekir. Bu, C ++ standart kütüphanesinin tasarımıdır.

Yazmaya çalıştığınız kodun bir örneğini görmeden kimin doğru ya da yanlış olduğuna karar verebileceğimizi sanmıyorum.


2
Ayrıca elle yazmak yerine copy + paste kullanabilirsiniz ;-)
Pa Elo Ebermann

4
@ PaŭloEbermann: Heck no!
Joshua

2
@ PaŭloEbermann adlı bir mağazada bu yaklaşıma, "start-mark-bug, son-mark-bug, kopya-bug, kopya-bug, kopya-bug."
Kelly S. French,

12

Yazılım geliştiriciler, çalışan, açıkça çalışan, test edilebilecek, gözden geçirilebilecek, hata ayıklanabilecek ve değişiklik gerektiğinde uyarlanabilen kod yazmayı hedeflemelidir. Eğer "C ile sınıf" yazmak bunu başarırsa, sorun değil.

Ve bunlar da kodunuzu ölçmeniz gereken standartlardır. Özellikle: Açıkça çalışıyor mu, test edilebilir mi, gözden geçirilebilir mi, hata ayıklanabilir mi ve gerektiğinde uyarlanabilir mi?


9

Şefkatten çıkan bir argüman:

İşiniz öğrenme için boş zaman veriyor mu, yoksa alternatif olarak, patronlarınızı bu dil özelliklerini öğrenmek için birkaç saat ayırmaya ikna edebilir misiniz?

Olmazsa, bunları kullanmak aslında onlara ekstra ücretsiz iş veriyor. Bir C ++ programcısının tüm dili veya böyle bir şeyi bilmesi gerektiğini düşünebilirsiniz , ancak akademik bir nokta, onlara uygulayacağınız yükü azaltmaz. Meslektaşlarınızın çocukları, hasta ebeveynleri, hasta eşleri veya cehennemi, C ++ öğrenmeyi içermeyen makul bir sosyal hayatı var. Teklifinizin daha sesli karşıtı rakibi tembel olabilir - ya da zorlu bir zaman geçiriyor olabilirler ve şu an hayatlarında fazladan bir boka ihtiyaç duymazlar.


8

Kod ilk önce insanların okuması için yazılmalı ve sadece derleyicinin ayrıştırması için rastlantısal olarak yazılmalıdır.

Şimdi önemsiz olmayan TMP hakkında hatırlanması gereken şey, bu kodu okuyabilen insanların sayısını kısıtladığınızdır, geçerli bir tradeoff olabilir, ancak iddia ediyorum ki, kütüphanelerde ve böyle bir yerde bulunduğunuzda çok daha makul bir tradeoff olduğunu iddia ediyorum. uzmanların küçük uzman ekibi daha sonra daha büyük bir uygulamada.

Kitaptaki tüm hileleri çıkardığınızda, istismar ettiğiniz tüm avukatlık köşesi davaları da dahil olmak üzere dili anlamaları gerektiği için herkese maliyetler getirir, ayrıca çıtayı yükseltmiş olmanızın işe alınmasına bir maliyet koyarsınız. uygulama üzerinde yararlı bir şekilde çalışmak, şimdi belki buna değer, ancak maliyetleri izlemekten ....

Benim için biraz daha tipik, belki biraz kod çoğaltması bile olabilir, ancak modifikasyona ihtiyaç duyduğunda "C sınıfı ve artı STL" nin önüne koyabildiğimde, modifikasyona ihtiyaç duyduğumda çok daha kullanışlı bir şeydi. (Ve bu yüzden sonsuza kadar sürecek). Ayrıca, sınıfları olan C'nin konu uzmanı olabileceğini ve bu uzmanlığın dil avukatı olmasından çok daha değerli olduğunu unutmayın.

Kimin söylediğini unuttum ama "Herkes hata ayıklamanın zor olduğunu biliyor, sonra ilk etapta yazıyor, eğer mümkün olduğunca zekice programlarsanız, nasıl hata ayıklayacaksınız?".

Gerçekten orada modern C ++ yazsam bile, genellikle tercih etmemeyi tercih ederim, bu bakım programlamasından daha az yapmam gerektiği anlamına geliyor.


7

Hayır yapmamalısın. Bir spesifikasyonu yerine getiren kodu üretmek için kullanılır. Bu kodun bir ego gezisi değil bakımı yapılabilir olması gerekir. Yarın otobüsle kontrol altına alınabilirsin, o yüzden birinin kodunu alıp eldeki görevi ilerletmesi gerekiyor. Bununla birlikte, işverenlerinizi yeni teknikleri programlama standartlarına dahil etmeye ikna etmeye çalışmanız olumludur.


3
Bir spesifikasyonu yerine getiren kodu üretmek için kullanılır. evet, ama bunu en iyi bilgiyi de unutuyorsun .
t3chb0t

2

Bu soruyu bağlam içinde yanıtlamanın tek yolu, belirli sorunlara ve bunları meta programlama ile çözdüğünüz özel yollara bakmaktır. Buraya kod göndermediğiniz sürece, sizin için eğlenceli olan gereksiz bir komplikasyona maruz olup olmadığınızdan emin olamayız; ya da dilin tüm gücünü kullanarak başka yollarla bulunmayan basit ve zarif bir çözüm yazmak için kullanıp kullanmadığınız.

İkincisi ise, ekibinizle birlikte yapmaya devam etmenizi tavsiye ederim .Her iyi ekip, sadece stil sorunlarını değil aynı zamanda programcının çözümünün en iyi yaklaşımı kullanıp kullanmadığını, uygun dil özelliklerini kullanıp kullanmadığını, bakım yapılabilir ve test edilebilir olduğunu vb. Anlatan anlamlı kod incelemeleri yapmalıdır. Öğleden sonra. Yaklaşımınızı reddeden programcılar alternatifler belirlemeli (perl ile kod oluşturma, kod çoğaltma vb.) Ve çözümünüzle karşılaştırıldığında belirtilen kriterlere göre nasıl bir performans gösterdiğini göstermelidir. İşiniz, onların argümanındaki arkadaş canlısı "rakibi" olarak, işin hızlı bir şekilde yapılmasının bir yolu olduğunu, bakımın kolay olduğunu, test etmenin kolay olduğunu ve zorlukların üstesinden geldiğinizde kodun gerçekten okunabilir olduğunu göstermektir. komik gramer ayrıştırma.

Çoğu programcı tembeldir ve zarif, küçük çözümlerin tadını çıkarır. Sizinki bir ise, özellikle gösterilen alternatiflerin yetersiz kalması durumunda, onları ikna edebilirsiniz.


0

Bu sorunun tek bir doğru cevabı yoktur.

Çünkü kendinize sormanız gereken ilk şey: işinize hangi durumdasınız? Bazı insanlar gerçekten özellikleri kodlamak için kod maymunu olarak çalışıyor, bazıları takım oyuncusu olarak, bazıları da bilgi çalışanı veya uzmanı olarak çalışıyor.

Tek sabit hat, işvereninizin bakış açısından bakmanız gerektiğidir, çünkü esasen bu bir çalışan olmak anlamına gelir. Bazen, iş arkadaşınızın gerçekten daha iyi olması ve meslektaşlarınızın daha iyi olma ve gelişmiş tekniklere hakim olma konusunda dürtüklenmesi söz konusudur. Yine de farklı bir durumda, birçok sorun ve sorumluluk yaratabilir ve dahil olduğunuz projelerin başarısını tehlikeye atabilirsiniz.


-4

Asıl soru, meta-programlamanın iyi olup olmadığı değil, takımdaki diğerlerinden daha iyi olup olmadığına ilişkin değil, bu yüzden burada nasıl gördüğüme dair birkaç tartışmalı nokta var.


Geçenlerde daha büyük bir takımda çalıştığım yeni bir işe taşındım ve bu [meta-programlama] bazı meslektaşlarımı endişelendiriyor, çünkü anlamadılar.

Onlardan daha iyi olduğun için endişeleniyorlar. Bu iyi. Yeni uzman olacaksın. Onların statüko dünyasını daha yeni yok ettin.


Her zaman dilin potansiyelinden tam olarak yararlanmaya çalışıyorum, ancak meslektaşlarımdan bazıları (hepsi değil) bunu bir risk olarak görüyor (bazıları yaklaşımı memnuniyetle karşılıyor).

Elbette, hiç kimse diğerlerinden daha az yetenekli olmaktan hoşlanmaz, bu yüzden onlar için çok karmaşık teknikleri kullanmanızı engellemeye çalışıyorlar. Ya anlayamıyorlar ya da gitmiyorlar, çünkü şimdi kendilerini güvende hissediyorlar.


Takımda başka kimsenin anlayamadığı bir kod yazmanın bir sorun olduğunu kabul ediyorum.

Yapmıyorum. Sanırım uzmanlığını gösteriyor.


Sorum şu, kim haklı, ne yapmalıyım?

Yazabildiğiniz en iyi kodu yazmak için tüm becerilerinizi kullanmalı ve anlamayanlara bakmamalısınız. Aksi takdirde seviyelerinde sıkışıp kalacaksınız ve sıradan bir kodlayıcı olacaksınız. Diğerlerinden daha iyi olmak için iyi bir şey ve onlardan daha iyi olmak için gayret etmek iyi bir şey. Yeni bir şey kullanmayacağınız ya da farklı şeyler yapmazsanız, asla yeni bir deneyim edinmeyeceksiniz.


Reddedileceğimi biliyorum, ama öyle gözüküyor. Takımdaki diğerlerinden daha iyi olmak suç değil ve yeteneklerini kullanmak suç değil. Sadece herkes itiraf etmekten korkuyor ... çünkü onlar yeteneksiz taraftalar ve yeni adamın aniden yapamadıkları bir şeyi yapabilmesinden nefret ediyorlar. Zeki olsaydı, sizden yardım ve tavsiye ister ve kodunuzu anlaşılmaz olduğu için eleştirmezlerdi.


DÜZENLE

Bu soru hakkında çok fazla kafa karışıklığı var gibi görünüyor. Yorumlar gösteriyor ki birçok kişi bunun genel kod okunabilirliği ile ilgili olduğunu düşünüyor. Hayır değil. Belli dil özelliklerinin / yapılarının yasaklanıp yasaklanmaması gerektiği, çünkü bazı ekip üyeleri bunları anlamıyor.

Cevabım hayır . Yasaklanmamalılar. Bir şeyi yasaklamak istiyorsan, bunu nasıl yaparsın? Takım üyelerinizin neler yapabileceğini ve neler yapamayacağını bulmak için bir tür anket hazırlamanız gerekir - ya da tüm dil özelliklerinin bir yerde yararlı olduğunu düşündüğümden öğrenmek istemiyorum, bu yüzden onları tanımak ve kullanabilmek her zaman iyi ve ne kadar çok şey bilirseniz o kadar iyi kod yazabilirsiniz. Hangi özelliklerin başlangıç, ara veya ileri özellikler olduğunu belirlemek için bir skalaya da ihtiyacınız olacaktır.

Bu kadar kısıtlamaların ne kadar saçma olduğunu göstermek için, gerçekten basit bir örnek alalım: bir yazılım mühendisi olarak işe alınacaksınız ancak gelecekteki patronunuz size do/whiledöngü kullanmanıza izin verilmeyeceğini çünkü birkaç kişi olduğu için onları daha önce hiç kullanmayan ve gitmeyecek olan ekip, her zaman fordöngüleri kullandıkları için do/whiledöngüleri kafa karıştırıcı buluyorlardı .

Şimdi bunun aptalca ve delice olduğunu düşünüyorsun, değil mi? Ancak diğer özellikleri de yasaklıyor. Bazı insanlar onları kullanabilir, bazıları onları öğrenmek istemez.

Aynı şeyi çok daha az çabayla yapmanıza izin veren bir şey olduğunu ve bununla birlikte çok daha okunaklı bir sonuç elde edebileceğinizi biliyorsanız neden daha kötü kodlar üretmelisiniz?

Ve sadece temel dil özelliklerini veya gelişmiş özelliklerini kullanmanızın bir önemi yoktur, ikisini de aynı derecede anlaşılmaz ve anlaşılmaz bir kod üretmek için kullanabilirsiniz, bu yüzden bu tamamen farklı bir konudur.


10
Bu cevap korkunç. Meta-programlama üstünlük ve tersi anlamına gelmez
polfosol

9
Tecrübelerime göre, ekibinin geri kalanından önemli ölçüde daha yüksek bir uzmanlık seviyesine sahip olduğunu kuvvetli bir şekilde hisseden herkes aslında Dunning-Kruger etkisine kurban gitti. Yani bazı insanlar olmadığını söylemek değil çok daha yetenekli diğerlerinden daha fazla veya çok bu durumda , takımın geri kalanı aslında beceriksiz değil ... ama gerçek bir uzman daima basit kod ve büyük resme odaklanacak sadece stil noktaları için programlama yapmak yerine mühendislik (zaman içinde takım etkilerini hesaba katmak dahil).
Daniel Pryden

3
Başkalarının okuyamadığı bir kod yazmak, onlardan daha iyi olduğunuzu kanıtlamaz. Okunabilir kod yazamayacağınızı kanıtlar.
Stig Hemmer,

3
@StigHemmer görünüşe göre soruyu anlamadın ve konuyu değiştiriyorsun. Bu, okunamayan kodlar hakkında değil, bilgi eksikliği nedeniyle başkaları için anlaşılamayan kodlar hakkındadır.
t3chb0t

4
@ t3chb0t Demek istediğim, bu ikisinin aynı şey olmasıydı.
Stig Hemmer,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.