Ekibimi daha küçük sınıflar / yöntemler kullanmaya nasıl ikna edebilirim?

Feragat: Ben yeni gelen biriyim (bu benim üçüncü iş günüm) ve takım arkadaşlarımın çoğu benden daha deneyimli.

Kodumuza baktığımda, aşağıdaki gibi bazı kod kokuları ve kötü mühendislik uygulamaları görüyorum:

• Biraz tutarsız adlandırma kuralları
• Mümkün olduğunda salt okunur olarak işaretlenmemiş özellikler
• Büyük sınıflar - Yüzlerce uzatma yönteminden oluşan bir yardımcı sınıf olduğunu fark ettim (birçok tür için). 2500 çizgiden uzun oldu!
• Büyük yöntemler - 150 satır uzunluğunda bir yöntemi yeniden denemeye çalışıyorum.

Son iki gerçek bir sorun gibi görünüyor. Takım arkadaşlarımı daha küçük sınıflar ve yöntemler kullanmaya ikna etmek istiyorum. Ama bunu yapmalı mıyım? Eğer evet ise, o zaman nasıl?

Takımım ana takımdan bir mentorluk yaptı (biz bir uydu takımıyız). Önce ona gitmeli miyim?

GÜNCELLEME : Bazı cevaplar proje hakkında sorulduğundan, lütfen bunun çalışan bir proje olduğunu bilin. IMHO, bu büyüklükteki dev sınıflar / yöntemler her zaman kötüdür.

Neyse, asla takımımı kızdırmak istemiyorum. Bu yüzden sordum - Bunu yapmalı mıyım ve evetse, o zaman bunu nasıl nazikçe yapmalıyım?

GÜNCELLEME : Kabul edilen cevaba dayanarak bir şeyler yapmaya karar verdim: çünkü ben yeniyim, bu yüzden "yeni gözler" içindeki her şeyi görüyorum, bulduğum tüm kod kokularını not edeceğim (pozisyon, neden kötü, nasıl yapabiliriz? daha iyi, ...), ama şu anda, sadece ekibimden saygı duymaya çalışıyorum: "daha iyi kod" yaz, insanları tanı, neden bunu yaptığımızı biliyor ... Zaman doğru olduğunda deneyeceğim ekibime bazı yeni kod politikaları (adlandırma kuralları, daha küçük sınıflar, daha küçük yöntemler, ...) ve mümkünse bazı eski kodları yeniden sormak için sormak. İşe yaramalı, IMHO.

Teşekkür ederim.

Kodu taze gözlerle görme avantajına sahipsiniz. Kötü uygulamaları keşfettiğinizi belgelemek için notlar alın. Ardından ekiple anlaşmaya başlarken, notlarınızı yeniden düzenleme zamanı geldiğinde olduğu gibi uygun bir anda notlarınızı çekin.

Code Complete, Steve McConnell tarafından, konuştuğunuz konuda tonlarca iyi istatistik içeriyor. Tüm sayıları hatırlamıyorum, ancak daha uzun yöntem / sınıflarla böcek sayısının nasıl arttığını, hata ayıklamanın ne kadar sürdüğünü, vb.

Kitabın bir kopyasını alabilir ve arkadaşlarınıza bazı çalışmaların istatistiklerini gösterebilirsiniz ... istatistikler (her zaman yalan söyleseler de) insanları ikna etmeye meyillidir.

Feragatname: Yeni bir gelenim (bu benim üçüncü iş günüm) ve ekibimin çoğu benden daha deneyimli.

Çok fazla değişiklik önermeden önce biraz yavaşlamak, dinlemek ve ekibinizden öğrenmek isteyebilirsiniz. Kodun olduğu gibi yapılandırılmasının iyi sebepleri olabilir veya olmayabilir, ancak ilk önce dinlemek ve öğrenmek için zaman ayırmak yalnızca yardımcı olabilir.

Bundan sonra yapabileceğiniz herhangi bir öneri kesinlikle daha olumlu görülecektir ve daha az dirençle karşılanacaktır.

Öncelikle iş arkadaşlarınızın saygısını kazanırsanız veya en azından saygısını yitirmezseniz, başarılı bir şekilde değişim getirme şansınız büyük ölçüde artar.

Nasil gidiyor? “İki kere ölçün bir kez kesin ..” Bunun gibi bir şey.

Ekibinizin kod yazma şeklini elden geçirmenin özel bir niyetiyle işe alınmadıkça, ciddi revizyonlar için duyduğunuz coşkuyu ölçmek isteyebilirsiniz. Çoğu çalışma kodu bir nedenden dolayı çalışır :) ne kadar çöp olursa olsun, ve bazen sert revizyonlar bu sinir bozucu köşe kasalarını bile daha çirkin yapar.

Bence daha küçük kod yazmanın en kolay yolu geliştiricilerden birim testine odaklanmalarını ister . Hiçbir şey, test etmesi istenecek gibi özlü bir kodu zorlamaz ; geliştiricilerin nasıl aniden küresel veri yapılarına karşı bir tiksindirmek, çok fazla nesneyi çok fazla katmana derinlemesine geçirmek, hepsi için testler yazmaları gerektiğini bildikleri şaşırtıcı.

TDD büyük bir hayranıyım değilim ama do onlar testleri yazmak istiyorum nasıl dikkate geliştiriciler zorlar gerçeğini seviyorum. Ve o kod aslında ilgili değil bazı büyü, neden daha iyi olduğunu sık sık olan testler. (Daha sonra değişiklik yaptığınızda emin olacağınız kesin.)

İyi şanslar.

Takımını ikna etmemelisin. Yeni gelen biri olarak, ciddiye alınmayacaksınız - bu yüzden zamanınızı boşa harcıyorsunuz.

Bunun yerine, devam edin ve küçük ve temiz kodları kendiniz yazın. O zaman umarım, bir süre ve bazı kod incelemelerinden sonra, bazı takım arkadaşları tarzınızı taklit etmeye başlayabilir.

Olmazsa, daha üretken olacaksınız ve sıkı çalışmanız sonunda sizi bu kuralların bazılarını uygulamaya başlayabileceğiniz daha yüksek bir pozisyona getirecektir.

Ve evet, elbette, Code Complete'ten herkese bir şeyler gösterin.

İşte birkaç püf noktası:

• Takımın şu anki durumunu ve tarihini öğrenin - akıl hocaları gibi görünüyor, mentorun ne kadar etkisi var? Ayrıca, mentor ne kadar yeni ve akıl hocası olmadan uzun bir zaman geçti mi? Sorun kodu ne zaman kaynaklanıyor? Mevcut ekibin bebeğini eleştirmek, hiç kimsenin yazmayı hatırlamadığı bazı eski kodları eleştirmekten çok farklı olabilir.

• Her seferinde bir şey - bir takım toplantısında tüm düşüncelerinize bomba atmayın. Özel bakış açınızdan gelen bazı geçici sorularla başlayın. Örneğin - "Hey, yeni adam olarak, bazı faydalı sınıfların gerçekten büyük olduğunu fark ettim , bunun bir nedeni var mı?"

• Bebek adımlarını önerin - derhal toplam revizyon yapmak neredeyse mümkün değildir, bu nedenle herkesin bunun iyi bir plan olduğunu kabul etmesi durumunda önermek için bazı başlangıç ​​adımları uygulayın.

• Gelecekteki önleme mekanizmaları önerin - örneğin, ekip en büyük birkaç sınıfa asla ekleyemeyeceği, ancak daha fazla büyümeye ihtiyaç duyulduğunda toparlanmayacağı bir hedefe katılabilir.

• Risk hakkındaki endişeleri dinleyin. Bu gerçekten eski bir kodsa, yeniden yapılanmanın aşırı riskli olduğu konusunda yeterince bilinmeyen ve bağımlılık olabilir. Bu yeniden yapılanmayı önlemek için bir neden olmayabilir, ancak gerçek tekrar işleme ile mücadele etmeden önce daha iyi test stratejilerine veya riski azaltmak için başka bir yola ihtiyacınız olabileceği anlamına gelebilir.

• Beden diline dikkat edin ve yavaş gidin. Çok fazla deneyime sahip olmadığınız bir kod tabanında bir sorun ortaya çıkarıyorsunuz. Şu anda bazı saf sorular sorabileceğiniz ve yararlı cevaplar alabileceğiniz yeni bir pencereniz var ve bu soruları ekibin kendi tasarım seçimlerini göz önünde bulundurmak için sorgulamak için kullanabilirsiniz. Fakat her iki yoldan da geçiyor - yeni çocuk olarak, henüz bir ton "alacağınız" yok, bu yüzden yavaş gidin ve kapalı yüzlerin veya duruşların farkında olun. İnsanlar kapanmaya başlarsa, kararları geciktirmenin bir yolunu önerin ve onları kazanmanın yollarını arayın.

Bir yönetici ve ekip üyesi olarak söyleyebilirim, New Guy Insights'a sevindim. Yeni bir ekip üyesinin bana verdiği her yapıcı yorumu kabul etmedim, ancak eleştirinin dürüst bir endişe ve merak olarak dile getirilip söylenmediğini ve bir ders olarak verilip verilmeyeceğini dinlemek için genellikle istekliydim. Yeni adama saygı işareti içgörüleri ortaya koyduğu zaman gider ve sonra geri çekilir ve ne olursa olsun onu ele alır - kararlarınız duyulduğunda ve alındığında iyi hissetmek kolaydır, takım size "hayır" derken zorlaşır. Hala haklı olabilirsin, püf nokta sonra ne yapılacağını bulmaktır ... genellikle biraz beklemek ve daha fazla bilgi aramak bu durumlarda iyi bir adımdır.

Ekibimi daha küçük sınıflar / yöntemler kullanmaya nasıl ikna edebilirim?

Yapma.

Kendine bir Resharper lisansı satın al ve örnek olarak liderlik et. [' Ekstraksiyon Yöntemi ' refactoring'i üzerine yoğun şekilde yaslan.]

Zamanla, diğerleri gerektiğini sizin daha okunabilir kod takdir ve aynı şekilde yapmaya ikna gelir. *

• Evet - ikna edilmeme ihtimalleri var ; ama bu hala senin en iyi seçeneğin.

IMO - Takım arkadaşlarınızı daha iyi programcılar olmaya ikna etmeye çalışmak için hecelerinize değmez, ' Kod Tamamlandı'yı okuyun , @ Bob Amca'yı izleyin. 'nin SOLID ilkeleri ve henüz ikna edilmediyse daha iyi programcılar haline gelir.

Unutmayın: Birini ilk etapta girmek için mantık kullanmadıkları bir konumdan savunarak mantığı kullanamazsınız.

Bu, teknik sorudan çok bir yönetim sorusu gibi görünüyor. Tek söylediğiniz geçerlidir, ekibinizin gerçekte ihtiyaç duyduğu şey, herkesin tek bir tasarım modeline uyum sağladığından ve onu uygulayabildiğinden emin olabilen iyi bir mimar, ekibin sürekli ve düzenli olarak kodu değiştirmesi gerekiyor.

Bununla birlikte, başka bir “ona ihtiyacınız olmayacak” ilkesi var, eğer var olanı oldukça uzun bir süre çalışırsa, ne kadar çirkin olursa olsun, onu değiştirmek her zaman iyi bir fikir değildir. Bunun yerine, ekibinizin her şeyi yeniden inşa etmesi veya bir kısmını yeniden inşa etmesi gerekirse, kodlamayı uygulamadan önce kötü uygulamalar ve sorunlar için bir belge toplayın.

Bazı takımlar kod için herhangi bir kalite kontrol yapmazlar çünkü bunun için doğru araçları bilmezler. Bir takım kodunu daha iyi yapmanıza yardımcı olacak birçok araç var.

Visual Studio, adlandırma kurallarına yardımcı olabilecek "Kod Analizi" ne sahiptir.

Ayrıca, kodlu metrikler, döngüsel karmaşıklık gibi kullanılabilir. Bu, çok karmaşık olan sınıfları ve yöntemleri göstermeye yardımcı olur.

Kayıt tutmak da iyi bir fikirdir. Ekip üyeleri ne yapılması gerektiğini sözlü olarak ifade ederse, o zaman insanlar unutmak zorundadır. İnsanların çok zayıf hatıraları var! =)

Bu konuda çok fazla gürültü yapmam… Bir programcının geliştirme ekibi kendi ailesi gibidir ... Hatalara dikkat ederseniz, insanlar size kızabilirler. Bu tür bir kültür değişimi sadece çok fazla kodlama gerektirmekle kalmaz, aynı zamanda insanlarla hassas bir dokunuş da gerektirir.

Bir yönetici olarak sadece eklemek istiyorum, ekibimin ilk defa iyi kod yazmasını istiyorum. Kod incelemeleri, TDD ve hepsi. Fakat bir kez prodüksiyona girip çalıştığında, geri dönmemiz için güçlü bir dava açmanız gerekir.

Bob Amca'nın tavsiyelerine her zaman bulduklarından daha iyi kod bırakmalarını izliyorum. Bu yüzden düzeltmemiz gereken hatalarımız veya küçük geliştirmelerimiz varsa, temizlemenin bir kısmını yaptığımızı umuyorum.

Bu haliyle Fakat iş gerçekten saatler 's parasını. Onlara yeniden düzenlemenin, ekibime zaman ve kaynakları vermeleri için onlara yeterince yarar sağladığına dair bir dava açmak zorunda kalacağım. Sadece kodun görünüşünü beğenmemek yeterli değil.

Bu nedenle, eğer çalışırsa, nefret ettiğiniz kadarıyla, onu yalnız bırakmak zorunda kalabilirsiniz.

Şimdi yeni kod, bu farklı. Bu iyi bir kod olmalı.

150 satır olan yöntemler ... 10.000 satır kodlu yöntemler gördüm.

Sorunlarınızın ikisi harici araçlarla çözülebilir :

• Biraz tutarsız adlandırma kuralları
• Özellikler mümkün olduğunda salt okunur olarak işaretlenmemiş

C # Resharper'da her iki sorunu da kontrol edebilirsiniz. Yönergelerinize uymayan isimler hata olarak işaretlenir. Salt okunur olarak işaretlenmemiş özellikler de hata olarak gösterilir. FxCop da bir yardım olabilir.

Bu araçlar aynı zamanda yeniden yapılanma sayesinde devasa yöntemlerin daha küçük olanlara bölünmesine de yardımcı olabilir.

Büyük sınıfların iyi adlandırılmış yöntemlerle iyi yapılandırılmışlarsa hep o kadar da kötü olduklarını bilmiyorum. Eclipse'i IDE'im olarak kullanıyorum, bu yüzden "ana hat" görünümü adı verilen bir şey var, ki bu tüm IDE'lerin farklı bir isme sahip olduğu bir şey, büyük olasılıkla, sınıf içindeki her yönteme isim ve bağlantı sağlayan, alfabetik olarak sıralayabilirsiniz. , vb. Kullanırken büyük bir sınıfta gezinmek kolay, onun gerçekten uzun yöntemlere sahip olması kötü olurdu, bence gerçekten aşina olmadıkça, bu yöntemle akıllıca gezinmek daha zor. Uzun sınıfları savunmuyorum ama bazı durumlarda yönetilebilir olduklarını düşünüyorum ve mutlaka birden fazla sınıfa ayrılmaları gerekmiyor.

Konuyu bazı takım üyelerinizle görüşün ve yöntemlerin boyutu hakkında görüşlerini alın. Sizinle aynı fikirde olduklarını görünce şaşırabilirsiniz. Gördüğünüz şey kötü önceki uygulamaların sonucu olabilirdi, eski geliştiriciler artık şirkette değil ya da bu bölüm aceleci bir işti ve şimdi yeniden işlemek için zamanı olan birini işe aldılar;)

Sen hala yeni adamsın. Zorlu görevler üstlenerek bunları hızlıca ve hatasız bir şekilde tamamlayarak bir miktar itibar kazanın. Meslektaşlarınızın saygısını kazanmadan önce bir şeyleri değiştirmeye başlarsanız, satın almak için daha zor bir zaman geçirebilirsiniz (ve muhtemelen iş arkadaşlarınızı yabancılaştırın).

Gelişme süresini nasıl azalttığını ve daha sağlam çözümler ürettiklerini etkili bir şekilde gösteren kendi işinizde daha iyi kodlama alışkanlıklarını tanıtmanın yollarını bulabilirseniz, bunun nasıl başarıldığını görmek için size gelmelerini bile sağlayabilirsiniz.

Tüm diğer büyük cevaplara ek olarak, belki iki taşı bir taşla öldürebilir ve kod bazını anlamaya yönelik bir proje olarak bazı kod temizleme işlemleri yapabilirsiniz. Bunu sizin için bir öğrenme fırsatı olarak ekibinize / yöneticinize satabilir ve kötü tasarım sorununu çözmek için sizi en iyi yaklaşımınıza yönlendirecek olan değişikliklerinizi incelerken arkadaşlarınızdan geri bildirim alabilirsiniz.