Birisine kötü kod yazdığını nasıl söylersiniz? [kapalı]

Eğlenmek için bir kodlama projesinde küçük bir grup insanla çalışıyorum. Organize ve oldukça uyumlu bir grup. Birlikte çalıştığım insanların programlama ile ilgili çeşitli beceri setleri var, ancak bazıları aşırı küresel değişkenler, kötü adlandırma kuralları ve diğer şeyler gibi eski veya açık yanlış yöntemler kullanıyor. İşler çalışırken uygulama zayıftır. Deneyimlerini ve / veya eğitimlerini sorgulama (ya da aşağılama) olmadan, kibarca daha iyi bir metodoloji kullanmalarını istemek veya tanıtmak için iyi bir yol nedir?

Yaptıklarının yanlış olduğunu anlamalarını sağlamak için sorular ekleyin. Örneğin, şu tür soruları sorun:

Neden küresel bir değişken yapmaya karar verdiniz?

Neden bu ismi verdin?

İlginç. Genellikle benimkini böyle yaparım çünkü [Daha iyi olmana neden ol

Bu şekilde çalışıyor mu? Genelde [Onların aptalca görünmesini nasıl sağlayacağınızı ekleyin]

Bence bu konuda en ideal yol, niçin belli bir şekilde kodlandıklarını sormaktır. Diğer yöntemlerin faydaları olduğuna inandıklarını görebilirsiniz. Kodlama stillerinin nedeninin yanlış bilgiden kaynaklandığını bilmiyorsam, iyi bir sebep olmadan yolumu asla daha iyi yargılamazdım. Bunu yapmanın en iyi yolu, onlara neden bu yolu seçtiklerini sormaktır; akıl yürütme ile ilgilendiğinizden emin olun, çünkü yetenekleri değil saldırmanız gereken şey budur.

Bir kodlama standardı kesinlikle yardımcı olacaktır, ancak her yazılım projesinin cevabı olsaydı, o zaman hepimiz cennetteki özel adalarımızda kokteyl yudumlardık. Gerçekte, hepimiz sorunlara eğilimliyiz ve yazılım projeleri hala düşük bir başarı oranına sahiptir. Bence problem çoğunlukla konvansiyonla ilgili bir problemden ziyade bireysel yeteneklerden kaynaklanacaktır, bu yüzden bir sorun çirkin başını duyduğunda problemler bir grup olarak çalışmayı öneririm.

En önemlisi, hemen yolunuzun daha iyi olduğunu varsaymayın . Gerçekte, büyük olasılıkla öyledir, ancak başka bir kişinin görüşünü ele alıyoruz ve onlara sadece tek bir çözüm var. Seni kendini beğenmiş bir kaybeden olarak görmelerini istemedikçe, yolunun bunu yapmanın daha iyi yolu olduğunu asla söylemeyin.

Kod incelemeleri yapmaya başlayın veya programlamayı eşleştirin.

Takım bunlar için gitmezse, haftalık tasarım incelemelerini deneyin. Her hafta, bir saat boyunca bir araya gelin ve bir kod parçası hakkında konuşun. İnsanlar savunmacı görünüyorsa, en azından başlangıçta kimsenin artık duygusal olarak bağlı olmadığı eski kodu seçin.

@JesperE'nin dediği gibi, kodlayıcıya değil, koda odaklanın.

Farklı olduğunu düşündüğünüz bir şeyi gördüğünüzde, ancak diğerleri aynı şekilde görmezse, eksikliklere yol açan soruları sormak yerine, onları işaret etmek yerine işe başlayın. Örneğin:

Globals : Sizce bunlardan birden fazlasına sahip olmak isteyeceğiz mi? Sizce buna erişimi kontrol etmek isteyeceğiz?

Değişebilir durum : Sizce bunu başka bir iş parçacığından değiştirmek isteyeceğiz?

Ben de faydalı odaklanmak bulmak benim insanlar rahatlamak yardımcı olabilir sınırlamalar. Örneğin:

uzun fonksiyonlar : Beynim tüm bunları bir anda tutacak kadar büyük değil. Ele alabileceğim daha küçük parçaları nasıl yapabiliriz?

kötü isimler : Açık kodu okurken kolayca karışabilirim; isimler yanıltıcı olduğunda, benim için umut yok.

Sonuç olarak, hedef ekibinize nasıl daha iyi kod yazacağınızı öğretmeniz değildir. Takımınızda bir öğrenme kültürü oluşturmaktır. Her insanın daha iyi bir programcı olma konusunda yardım için başkalarına baktığı yer.

Bir kod standardı fikrini tanıtın. Bir kod standardıyla ilgili en önemli şey, kod tabanında tutarlılık fikrini önermesidir ( ideal olarak , tüm kod bir oturuşta bir kişi tarafından yazılmış gibi görünmelidir), bu da daha anlaşılır ve sürdürülebilir bir koda yol açacaktır.

Yolunuzun neden daha iyi olduğunu açıklamalısınız .

Bir işlevin neden kesme ve yapıştırmadan daha iyi olduğunu açıklayın.

Bir dizinin neden $ foo1, $ foo2, $ foo3'den daha iyi olduğunu açıklayın.

Küresel değişkenlerin neden tehlikeli olduğunu ve yerel değişkenlerin hayatı kolaylaştıracağını açıklayın.

Sadece bir kodlama standardını kırıp "bunu yap" demek değersizdir çünkü programcıya neden bunun iyi bir şey olduğunu açıklamaz.

İlk olarak, çok hızlı karar vermemeye dikkat ediyorum. Neden böyle iyi nedenler olabileceğinden, bazı kodları kötü olarak çıkarmak kolaydır (örneğin: garip sözleşmelerle eski kodlarla çalışmak). Ama bir an için gerçekten kötü olduklarını varsayalım.

Ekibin girdisine dayanarak bir kodlama standardı oluşturmayı önerebilirsiniz. Ancak, sadece iyi kodun ne olması gerektiği konusundaki görüşünüzü dayatmakla kalmamak için fikirlerini dikkate almanız gerekir.

Başka bir seçenek de teknik kitapları ofise getirmek (Code Complete, Effective C ++, Pragmatic Programmer ...) ve başkalarına ödünç vermeyi teklif etmektir ("Hey, bununla işim bitti, herkes ödünç almak ister mi?") )

Mümkünse, kodlarını şahsen değil, eleştirdiğinizi anladıklarından emin olun .

Çatışmasız bir şekilde daha iyi bir alternatif önerin.

"Hey, bence bu şekilde de işe yarayacak. Siz ne düşünüyorsunuz?" [Ekranınızda daha iyi kod yazma hareketi]

Kod incelemeleri yapın ve SİZİN kodunuzu inceleyerek başlayın .

İnsanlara tüm kod inceleme sürecini rahatlatacaktır çünkü onların yerine kendi kodunuzu inceleyerek işleme başlıyorsunuz. Kodunuzla başlamak, onlara bir şeyler yapma konusunda iyi örnekler verecektir.

Tarzınızın da kokuştuğunu düşünebilirler. Tutarlı bir kodlama stili yönergeleri kümesini tartışmak için ekibi bir araya getirin. Bir şeye katılıyorum. Bunun tarzınıza uyup uymadığı önemli değildir, tutarlı olduğu sürece herhangi bir stile karar vermek önemlidir.

Örnek olarak. Onlara doğru yolu gösterin.

Ağırdan almak. Yarasadaki her küçük hata için onları atmayın, sadece gerçekten önemli olan şeylerle başlayın.

Kod standart fikri iyi bir fikirdir.

Ama düşünün değil , bu muhtemelen, ile, eğlence için, özellikle de hiçbir şey söylemeden sen arkadaş insanlar. Sadece kod ...

Gerry Weinberg'in "Bilgisayar Programlama Psikolojisi" kitabında gerçekten iyi tavsiyeler var - onun bütün "egoless programlama" kavramı, insanların kodlarının eleştirilerini kendi eleştirilerinden farklı olarak kabul etmelerine nasıl yardımcı olacağına dair.

Kötü adlandırma uygulamaları: Her zaman affedilemez.

Ve evet, her zaman yolunuzun daha iyi olduğunu varsaymayın ... Zor olabilir, ancak nesnellik korunmalıdır.

Ben işlevleri böyle korkunç adlandırma vardı bir kodlayıcı ile bir deneyim yaşadım, kod okunamaz daha kötü oldu. İşlevler yaptıklarıyla ilgili yalan söylediler, kod saçma oldu. Ve bir başkasının kodunu değiştirmesine karşı koruyucu / dirençliydi. çok kibarca karşı karşıya kaldıklarında, bunun kötü bir şekilde adlandırıldığını itiraf ettiler, ancak kodun sahipliğini korumak istediler ve geri dönüp "daha sonraki bir tarihte" düzelteceklerdi. Bu geçmişte kaldı, ama hatalarının ONAYLANMIŞ, ancak daha sonra korunduğu bir durumla nasıl başa çıkıyorsunuz? Bu uzun bir süre devam etti ve bu engeli nasıl aşacağımı bilmiyordum.

Küresel değişkenler: Ben kendim küresel değişkenlerden hoşlanmıyorum, ama kendileri gibi bir sürü mükemmel programcı tanıyorum A LOT. Öyle ki, pek çok durumda aslında o kadar da kötü olmadıklarına, netlik ve hata ayıklama kolaylığı sağladıklarına inanmaya başladım. (lütfen beni alevlendirmeyin / düşürmeyin :)) Aşağı iniyor, küresel değişkenleri (benim tarafımdan koyma!) kullanılan çok iyi, etkili, hatasız kod ve çok fazla hata gördüm, uygun kalıpları titizlikle kullanan kodu okumak / korumak / düzeltmek imkansız. Belki orada IS bir yerde küresel değişkenler için (belki küçülen rağmen)? Kanıta dayalı olarak konumumu yeniden düşünmeyi düşünüyorum.

Bazı wiki yazılımlarını kullanarak ağınızda bir wiki başlatın.

Sitenizde "en iyi uygulamalar" veya "kodlama standartları" gibi bir kategori başlatın.

Herkesi işaret edin. Geri bildirime izin ver.

Yazılımın sürümlerini yaptığınızda, işi kodun üzerine koymak olan kişiyi geliştiricilere geri göndererek, üzerindeki Wiki sayfalarına yönlendirin.

Bunu kuruluşumda yaptım ve insanların Wiki'yi kullanmaya başlaması gerçekten birkaç ay sürdü, ancak şimdi bu vazgeçilmez kaynak.

Gevşek bir kodlama standardınız bile varsa, buna işaret edebilmek veya doğru format olmadığından kodu takip edemeyeceğinizi belirtmek faydalı olabilir.

Bir kodlama formatınız yoksa, şimdi bir tane almak için iyi bir zaman olacaktır. Bu sorunun yanıtları gibi bir şey yardımcı olabilir: /programming/4121/team-coding-styles

Her zaman 'Yapacağım şey' çizgisiyle devam ediyorum. Onları anlatmaya çalışmıyorum ve onlara kodlarının çöp olduğunu söylemiyorum ama sadece umarım onlara biraz daha temiz bir şey gösterebilecek alternatif bir bakış açısı verin.

Söz konusu kişi (ler) e, yazdıkları temsili bir modülün kodunda grubun geri kalanına bir sunum hazırlamasını isteyin ve Soru-Cevap bölümünün ilgilenmesine izin verin (bana güvenin, öyle olacak ve eğer iyi bir grupsa, çirkin bile olmamalı).

Aşk kodunu yapıyorum ve hayatımda bilişim ile ilgili herhangi bir şey hakkında hiç dersim olmadı, çok kötü başladım ve örneklerden öğrenmeye başladım, ancak "Dörtlü Çete" kitabını okuduğumdan beri her zaman hatırladığım ve aklımda tuttuğum şey :

"Herkes bir makine tarafından anlaşılan kod yazabilir, ancak herkes bir insan tarafından anlaşılan kod yazamaz"

bunu göz önünde bulundurarak, kodda yapılacak çok şey var;)

Sabrı yeterince vurgulayamıyorum. Bu tür şeylerin tamamen ters teptiğini gördüm, çünkü birisi değişikliklerin ŞİMDİ olmasını istiyordu. Oldukça az sayıda ortam devrim değil, evrimin faydalarına ihtiyaç duyar. Ve bugün değişimi zorlayarak herkes için çok mutsuz bir ortam yaratabilir.

Buy-in anahtardır. Ve yaklaşımınızın içinde bulunduğunuz ortamı da hesaba katması gerekiyor.

Kulağa çok "bireysellik" olan bir ortamda olduğunuz anlaşılıyor. Yani ... bir dizi kodlama standardı önermem. Bu "eğlenceli" projeyi almak ve onu son derece yapılandırılmış bir çalışma projesine dönüştürmek isteyeceksiniz (oh harika, sırada ne var ... fonksiyonel belgeler?). Bunun yerine, bir başkasının söylediği gibi, bununla bir ölçüde uğraşmanız gerekecek.

Sabırlı olun ve başkalarını kendi yönünüzde eğitmeye çalışmak. Kenarlarla başlayın (kodunuzun başkalarıyla etkileşime girdiği noktalar) ve kodlarıyla etkileşim kurarken, oluşturdukları arayüzü tartışmak için bir fırsat olarak almaya çalışın ve değiştirildiyse kendileriyle iyi olup olmayacağını sorun ( siz veya onlar). Ve değişikliği neden istediğinizi tam olarak açıklayın ("alt sistem özniteliklerinin değiştirilmesiyle daha iyi başa çıkmasına yardımcı olur" veya her neyse). Nit-pick yapmayın ve yanlış olarak gördüğünüz her şeyi değiştirmeye çalışmayın. Kenardaki diğer insanlarla etkileşime girdikten sonra, kodlarının temelinde onlara nasıl fayda sağlayacağını görmeye başlamalıdırlar (ve yeterli momentum alırsanız, daha derine inin ve modern teknikleri ve kodlama standartlarının faydalarını tartışmaya başlayın). Eğer hala görmezlerse ... belki sen

Sabır. Evrim, devrim değil.

İyi şanslar.

Bir toga yapmam ve bir kutu sosyal yöntem açtım.

Sokratik Yöntem Klasik Yunan filozofu Sokrates adını, sorgulayıcı, rasyonel düşünme ve aydınlatmak fikirleri teşvik etmek, başkalarının pozisyonların etkilerini araştırmaktadır hangi felsefi sorgulama biçimidir. Bu diyalektik yöntem genellikle bir bakış açısının savunmasının diğerine karşı çekildiği bir karşıt tartışma içerir; bir katılımcı diğerinin sorgunun kendi noktasını güçlendirerek bir şekilde kendisiyle çelişmesine yol açabilir.

Buradaki cevapların çoğu, günümüzde özellikle ilgili olmayan kod biçimlendirme ile ilgilidir, çünkü çoğu IDE, kodunuzu seçtiğiniz stilde yeniden biçimlendirecektir. Asıl önemli olan kodun nasıl çalıştığıdır ve poster global değişkenlere bakmak, kodu kopyalamak ve yapıştırmak ve evcil hayvanım, adlandırma kurallarına bakmak için haklıdır. Kötü kod diye bir şey var ve formatla ilgisi yok.

İyi yanı, çok iyi bir nedenden dolayı çoğunun kötü olması ve bu nedenlerin genellikle ölçülebilir ve açıklanabilir olmasıdır. Yani, çatışmacı olmayan bir şekilde, nedenlerini açıklayın. Birçok durumda, sorunların belirginleştiği yazar senaryolarını bile verebilirsiniz.

Projemdeki baş geliştirici değilim ve bu nedenle kodlama standartları uygulayamıyorum, ancak kötü kodun genellikle daha sonradan daha erken bir soruna neden olduğunu ve daha temiz bir fikir veya çözümle orada olduğumda buldum.

O zaman araya girip daha doğal bir yaklaşım benimsemekle liderliğe daha fazla güven duydum ve sık sık fikirler için bana yöneliyor ve beni proje için kullanılan mimari tasarım ve dağıtım stratejisine dahil ediyor.

Kötü kod yazan insanlar sadece cehaletin bir belirtisidir (bu aptal olmaktan farklıdır). İşte bu insanlarla başa çıkmak için bazı ipuçları.

• İnsanların kendi deneyimleri, söyleyeceğiniz bir şeyden daha güçlü bir izlenim bırakır.
• Bazı insanlar ürettikleri kod hakkında tutkulu değildir ve söylediklerinizi dinlemezler
• Eşleştirilmiş Programlama, fikirlerin paylaşılmasına yardımcı olabilir, ancak kimi sürdüğünü değiştirir, yoksa yalnızca telefonlarındaki e-postaları kontrol ederler
• Onları çok fazla boğmayın, Sürekli Entegrasyonun bile bazı eski geliştiricilere birkaç kez açıklanması gerektiğini buldum
• Onları tekrar heyecanlandırın ve öğrenmek isterler. Bir gün boyunca programlama robotları kadar basit bir şey olabilir
• TAKIMINIZA GÜVENİN, kodlama standartları ve bunları derleme zamanında kontrol eden araçlar genellikle asla okunmaz veya sinir bozucu değildir.
• Kod Sahipliğini Kaldır, bazı projelerde insanların kodumu söylediğini ve değiştiremeyeceğiniz kod silolarını veya karınca tepelerini göreceksiniz, bu çok kötü ve bunu kaldırmak için eşleştirilmiş programlama kullanabilirsiniz.

Kod yazmalarını sağlamak yerine, kodlarını korumalarını sağlayın.

Dumanı tüten spagetti yığınlarını korumak zorunda kalana kadar, kodlamada ne kadar kötü olduklarını asla anlamayacaklar.

Kimse işlerinin berbat olduğunu söyleyen birini dinlemekten hoşlanmaz, ancak aklı başında herhangi biri akıl hocalığı ve gereksiz işlerden kaçınmanın yollarını memnuniyetle karşılardı.

Bir öğretim okulu bile hataları belirtmemeniz gerektiğini, doğru yapılanlara odaklanmanız gerektiğini söylüyor. Örneğin, anlaşılmaz kodu kötü olarak belirtmek yerine, kodlarının nerede okunmasının özellikle kolay olduğunu belirtmelisiniz. İlk durumda, diğerlerini berbat programcılar gibi düşünmeye ve harekete geçmeye hazırlıyorsunuz. Sonraki durumda, yetenekli bir profesyonel gibi düşünmeye hazırsınız.

Ben çalışıyorum çocuklar ile benzer bir senario var .. Onlar benim kadar kodlama maruz kalma yok ama onlar hala kodlama yararlı.

Benden ziyade istediklerini yapmasına izin ver ve geri dön ve her şeyi düzenle. Genellikle onları oturup iki şey yapmanın yollarını gösteriyorum. Onların yolu ve Benim yolum, Bundan her yöntemin profesyonel ve eksilerini tartışıyoruz ve bu nedenle daha iyi bir anlayışa ve programlama hakkında nasıl gitmemiz gerektiğine dair daha iyi bir sonuca varıyoruz.

İşte gerçekten şaşırtıcı kısım. Bazen cevaplarım bile olmayan sorular bulurlar ve araştırmadan sonra hepimiz daha iyi bir metodoloji ve yapı kavramı elde ederiz.

1. Tartışır.
2. Onlara Nedenini Göster
3. Her zaman haklı olduğunu bile düşünme ... Bazen sana yeni bir şey öğretecekler.

Eğer ben olsaydım ne yaparım: D

Muhtemelen etkiden biraz sonra, ancak kabul edilen bir kodlama standardı iyi bir şeydir.

Açıkçası, birinin kodunu değiştirmek, hata ayıklamak, gezinmek, anlamak, yapılandırmak, test etmek ve yayınlamak daha kolay olduğunda daha iyi olduğuna inanıyorum (whew).

Birine ilk önce ne yaptığını ya da daha sonra kimsenin onu nasıl geliştirmesi gerektiğini (yeni işlev oluşturma ya da hata ayıklama gibi) açıklamadan önce kodunun kötü olduğunu söylemenin imkansız olduğunu söyledi.

Ancak o zaman zihinleri kapanır ve herkes bunu görebilir:

• Global değişkenler değer değişiklikleri neredeyse her zaman izlenemez
• Büyük işlevlerin okunması ve anlaşılması zordur
• Kalıplar kodunuzu geliştirmeyi kolaylaştırır (kurallarına uyduğunuz sürece)
• ( vb...)

Belki bir çift programlama oturumu hile yapmalıdır. Kodlama standartlarını uygulamak için - yardımcı olur, ancak gerçekten iyi kodun ne olduğunu tanımlamaktan çok uzaktırlar.

Muhtemelen iyi ya da kötü bir stil olup olmadığına dair öznel fikriniz olarak reddedilebilecek şeylerden ziyade, kötü kodun etkisine odaklanmak istersiniz .

Özel olarak "kötü" kod segmentlerinden bazılarını gerçekten makul olma olasılığına göz atın kod (ne kadar yatkın olursanız olun) veya belki de hafifletici koşulların varlığına . Hala kodun sadece kötü olduğuna ve kaynağın aslında bu kişi olduğuna ikna olduysanız, sadece uzaklaşın. Birkaç şeyden biri olabilir: 1) kişi fark eder ve bazı düzeltici eylemler yapar, 2) kişi hiçbir şey yapmaz (umursamaz veya sizin kadar umursamaz).

# 2 olursa veya # 1 sizin bakış açınızdan yeterli gelişmeyle sonuçlanmazsa ve projeyi incitiyorsa ve / veya sizi yeterince etkiliyorsa, içinde standartlar oluşturmak / uygulamak için bir kampanya başlatmanın zamanı gelmiş olabilir takım. Bu yönetimin satın alınmasını gerektirir, ancak en çok ot köklerinden kışkırtıldığında etkilidir.

Bunda iyi şanslar. Acını hissediyorum kardeşim.