Kendi kodumu nasıl gözden geçiririm? [kapalı]

Yalnız bir proje üzerinde çalışıyorum ve kendi kodumu korumam gerekiyor. Genelde kod incelemesi kod yazarı tarafından yapılmaz, bu nedenle incelemeci yeni gözlerle koda bakabilir - ancak böyle bir lüksüm yok. Kendi kodumu daha etkin bir şekilde incelemek için hangi uygulamaları kullanabilirim?

Her şeyden önce, olabildiğince kontrol etmek için araçları kullanın. Testler (bazı makul kod kapsamı ile desteklenmiş), size kodun doğruluğu konusunda biraz güven verecektir. Statik analiz araçları en iyi pratik şeyleri yakalayabilir. Her zaman insan gözüne ihtiyaç duyduğunuz ve her zaman bir başkası olarak kendi işlerinizi gözden geçirme işi yapmazsınız, ancak yardımcı olmak için yapabileceğiniz bazı şeyler vardır.

• Testlerin var olup olmadığını kontrol edin ve başarılı olun (muhtemelen bir hedef test kapsamı vardır, ancak bazı durumlarda bunu kırmanız gerekebilir, ancak nedenini haklı çıkarmanız gerekebilir)
• Statik analizin geçtiğini kontrol edin (burada yanlış negatifler de olacak, ancak neden onları bastırmanın iyi olduğunu neden haklı gösterebildiğiniz sürece, sorun değil)
• İncelenmesi gereken başka şeylerin kontrol listesini bulundurun (eğer mümkünse bunu yeni statik analiz kuralları olarak ideal bir şekilde ekleyin) SA'nın kontrol edemediği herhangi bir şeyi kontrol ettiğinizden emin olun, örneğin, yorumlar hala geçerli, adlarının uygun olduğu Tabii ki, bilgisayar bilimi tarafından bilinen 2 zor problemden biri)
• eğer bir hata tanımlanırsa, nedenin sistemik olup olmadığını kontrol edin ve neden önceki testlerde veya incelemelerde bulunmadığına bakın.

Bu, elbette başkalarının kodlarını da incelerken kullanışlıdır.

İçine bir göz atın Kod İnceleme Stack Exchange sitesinde. Hakem incelemesi için üzerinde çalıştığınız projelerden kod paylaşmak içindir :

Kod İncelemesi Yığın Değişimi , kodunuzun meslektaş incelemesini arayan bir soru ve cevap sitesidir. Dünya genelinde programcıların becerilerini geliştirmek için çalışma kodunu alarak ve daha iyi hale getirerek birlikte çalışıyoruz.

Projenize ait belirli bir kod parçası hakkında aşağıdaki alanlarda projenizden geri bildirim almak istiyorsanız ...

• En iyi uygulamalar ve tasarım deseni kullanımı
• Güvenlik sorunları
• Verim
• Beklenmeyen durumlarda düzeltme

Ayrıca, belirli tür sorunları saptamak için kod statik analiz araçlarını da kullanabilirsiniz, ancak bazı durumlarda yanlış alarmlar üreteceklerdir ve tasarımın nasıl iyileştirileceğini öneremezler.

Kafamda tamamen farklı birkaç kişi geliştirdim. Bunlardan biri programcı bile değil! Sohbet ediyoruz, en son haberleri tartışıyoruz ve birbirimizin kodunu gözden geçiriyoruz.

Benim yaklaşımımı şiddetle tavsiye ediyorum.

ps Şaka yapmıyor.

Whit jk-s'nin, tek kişilik incelemenin 2 kişilik inceleme kadar verimli olmadığı görüşüne katılıyorum. ancak en iyisini yapmaya çalışabilirsiniz:

kısa süreli inceleme (kodun oluşturulmasından kısa bir süre sonra)

Git'i yerel bir depo olarak kullanıyorum. Ne zaman bir özelliği bitmiş ya da bir hatayı düzelttiğimde, değişiklikleri depoya aktarıyorum.

Giriş yapmadan önce kodumda neleri değiştirdiğimi karşılaştırıp yeniden düşün:

• değişken / yöntem / sınıf adları hala ne için kullanıldığını yansıtıyor mu?

uzun süreli inceleme (kodun üretilmesinden 6 ay sonra)

Kendime soruyorum:

• Bir cümle içinde bir sınıf / yöntem / değişkenin ne yaptığını açıklayabilir miyim?
• İzole bir sınıf (diğer sınıflara dokunmadan) kullanmak veya en iyisine yazmak ne kadar kolaydır?

İlk önce, kodunuzu pratikte bir kenara koyun. Başka bir şey üzerinde çalışın, başka bir kod parçası. Bir gün sonra bile, bulacağınız şeye hayran kalacaksınız.

İkincisi, kodunuzu belgeleyin. Pek çok programcı kodlarını belgelemekten nefret eder, ancak kendiniz oturup belgelerinizi, kodun nasıl kullanılacağını ve nasıl çalıştığını yazmanızı sağlar. Kodunuza farklı bir şekilde bakarak hatalar bulacaksınız.

Bir konunun gerçek ustalığının, bir başkasına öğretme becerisi olduğu söylenir. Belgelendirme ile başkasına kodunuzu öğretmeye çalışıyorsunuz.

Bu hata ayıklama tekniğini bir kod inceleme tekniğine dönüştürün: http://en.wikipedia.org/wiki/Rubber_duck_debugging

Konsept sizi, sanki yeni sanki kodlarla çalışmak için uygun bir zihniyet haline getirme konusunda harikalar yaratıyor.

Diğer cevaplarda belirtilen faydalı araçlara ek olarak, kod incelemesi yaparken zihniyetinizi değiştirmenin yararlı olacağını düşünüyorum. Aptalca, ama kendime şunu söylüyorum: "Kod inceleme şapkamı giyiyorum". QA ile aynı şeyi yapıyorum.

O zaman kendini bu zihniyet ile sınırlamak önemlidir . Hem gözden geçiren hem de gözden geçiren sizsiniz, ikiniz de aynı anda olamazsınız. Bu yüzden bir gözden geçiren olarak, gözden geçirenle paylaşmak için objektif notlar alıyorum. Kodu incelerken değiştirmiyorum, bu bir gözden geçirenin yapması gereken bir şey değil.

Formalite zaman zaman biraz saçma hissediyor, ancak solo çalışırken sık sık birçok yöne doğru çekildiğimi biliyorum. Bu yüzden, inceleme döngüsünü başka bir şey ortaya çıkmadan önce kapatmamam gerekebilir - bu formalite (ve gerçekten, bir wiki aracında kaba notlar konuşuyorum), incelemenin yapıldığından emin olmak için kullanışlıdır. Aynı şekilde QA şapkam açıkken, onları düzeltmeden önce böceklere bilet ekliyorum.

Ortak görüşün kendi kendini gözden geçirmenin etkili olmadığı yönünde görünüyor. Katılmıyorum ve iyice yapılırsa kendini gözden geçirmenin birçok sorunu yakalayabileceğini düşünüyorum.

İşte benim birkaç yıllık tecrübemden bahseden ipuçları:

• Kullanışlı bir kontrol listesi hazırlayın. Bunlar, kodunuzu okurken işaretlemek istediğiniz şeyler.
• Kod incelemenizi çevrimdışı yapın. İşe yaramaz gelebilir, ancak ileri geri çevirip not alabileceğiniz ve çevirebileceğiniz veya daha sonra çevrimdışı duruma getirilen bir iPad ile senkronize edilen güzel vurgulanmış pdf'lerin dijital eşdeğeri olabilir. Masanızdan uzaklaşın, böylece yaptığınız tek şey kodunuzu dağıtmadan incelemek.
• Bir iş gününün sonundan ziyade sabahın erken saatlerinde yapın. Yeni göz çifti daha iyi. Aslında, gözden geçirmeden önce bir gün koddan uzakta olmanıza yardımcı olabilir.

Sadece bir FYI - bu kurallar birkaç yıl önce orada çalıştığım zaman Oracle’ın tavsiyelerinin bir parçasıydı; amaç kodun test edilmeden önce "yukarı akış" hataları yakalamaktı. Birçok geliştirici tarafından sıkıcı iş olarak kabul edilmesine rağmen, çok yardımcı oldu.

Çalışmanız ve ürünlerinizin kalitesi ile ilgili geçmiş verilere sahip olmasına rağmen, incelemeler için Kişisel Yazılım Süreci tekniği faydalı olabilir.

İş ürünlerinizle ilgili geçmiş verilerle, özellikle kusurların sayısı ve türleriyle başlarsınız. Bir PSP kursunda olduğu gibi, hataları sınıflandırmak için çeşitli yöntemler vardır . Kendinizinkini geliştirebilirsiniz, ancak fikir, yol boyunca hangi hataları yaptığınızı söyleyebilmeniz gerektiğidir.

Hangi hataları yaptığınızı öğrendikten sonra, inceleme sırasında kullanabileceğiniz bir kontrol listesi oluşturabilirsiniz. Bu kontrol listesi, bir incelemeye en iyi şekilde yakalanabileceğini düşündüğünüz en önemli hataları (başka bir araç kullanmak yerine) kapsayacaktır. Bir iş ürününü her incelediğinizde, kontrol listesini kullanın ve bu hataları veya hataları arayın, belgelendirin ve düzeltin. Kodunuzdaki gerçek ve ilgili sorunlara odaklandığınızdan emin olmak için zaman zaman bu kontrol listesini düzenli aralıklarla gözden geçirin.

Ayrıca anlamlı olduğunda araç desteğini kullanmanızı tavsiye ederim. Statik analiz araçları bazı kusurları bulmanıza yardımcı olabilir ve hatta bazıları tutarlılığı ve iyi kod stilini zorlamak için stil kontrolünü destekleyebilir. Kod tamamlama ve sözdizimi vurgulamasıyla bir IDE kullanmak, ayrıca "yapı" seçeneğini tıklatmadan önce bazı sorunları önlemenize veya algılamanıza yardımcı olabilir. Birim testleri mantık problemlerini kapsayabilir. Eğer projeniz yeterince büyük veya karmaşıksa, sürekli entegrasyon bunların hepsini düzenli aralıklarla gerçekleştirebilir ve sizin için güzel raporlar oluşturabilir.

Solo çalışmak, sizin adınıza kodu gözden geçirmek için yabancılara güvenmediğiniz sürece, kod kalitesini korumak için yazılımınızı yazma biçiminize bakmanız gerektiği anlamına gelir.

Birincisi ve en önemlisi, kodunuzun gereksinimleri karşıladığından emin olmak için bir araca sahip olmalısınız ve ikincisi, daha sonra yanlış bir şeyler yaptığınıza karar verirseniz kodunuzun değiştirilmesinin kolay olacağını gösterir. Önerim , aşağıdaki nedenlerden dolayı Behavior Driven Development yaklaşımını uygulamak olacaktır :

1. BDD, önce kod testi yazma anlamına gelir. Bu, tüm kodunuzun testlerle kapsanmasını sağlar.
2. BDD aslında TDD'dir, ancak biraz farklı odak ve "dil" ile. Bunun anlamı, üzerinde çalıştığınız sırada sürekli olarak kodunuzu yeniden gözden geçirmeniz ve kodunuzu yeniden tanımlamanızın devam etmesini sağlamak için testlerinizi kullanın.
3. BDD dili, testleri temel olarak birim testleri olarak kodlayan ifadeler biçiminde yazılmasını teşvik eder.

Bu yüzden, buradaki fikir, testlerinizi geçtikten sonra bile sürekli kod yeniden düzenlemenizin, kendi kodunuzu etkili bir şekilde gözden geçirdiğiniz ve birim testlerinizi kodunuzun yapmadığından emin olmak için "ekstra göz çifti" olarak kullandığınız anlamına gelir. t Testlerde kodlanan gereksinimlerden sapma. Ayrıca, gereksinimlere dayalı yüksek test kapsamı, gelecekte gereksinimlerinizi karşılamadan kodunuzu değiştirebilmenizi sağlar.

Sizin için asıl mesele, kodunuzda yeniden yönlendirici ihtiyacı olduğunu belirten olası sorunları tespit edip edemeyeceğiniz olacaktır. Piyasada, bu konuda size yardımcı olabilecek birkaç kodlama aracı ve ayrıca kod kalitesi ölçümleriyle ilgilenen birkaç araç vardır. Bunlar genellikle kod incelemelerinin kaçırabileceği birçok şeyi söyleyebilir ve kendi başınıza projeler geliştirirken bir zorunluluktur. Bununla birlikte, gerçekte, tecrübe anahtardır ve bir kez yeniden yapılanmada acımasız olma alışkanlığınız varsa, muhtemelen kendi kodunuz için çok daha kritik bir hale geleceksiniz. Henüz yapmadıysanız, Martin Fowler's Refactoring kitabını bir başlangıç ​​noktası olarak okumanızı ve birlikte çalışmayı seçtiğiniz dilde sizin için işe yarayacağını düşündüğünüz iyi bir BDD API aramanızı öneririm .

Ne zaman kendinizle aynı durumda olsam, kod inceleme / metrik araçlarını kullanarak “nesnel olarak incelemek için koda çok yakın olma” sorununu çözmeye çalıştım. Bir takımın deneyimli bir gözden geçiren ile aynı değeri veremeyeceği söylenemez, ancak bunları kötü tasarım alanlarını tam olarak belirlemek için kullanabilirsiniz.

Bu konuda oldukça faydalı bulduğum bir araç SourceMonitor idi . Bu biraz basittir, ancak bir sınıftaki yöntemlerin sayısı ve her yöntemin karmaşıklığı gibi kodunuz hakkında iyi bir orta düzey fikir verir. Her zaman bu tür bir bilginin (daha önemli olmasa da) kodlama stillerinin StyleCop, vb gibi araçlar yoluyla (önemli olan, ancak çoğu zaman en büyük sorunların kaynağı olmadığı) uygulanmasının önemli olduğunu hissettim. Bu araçları normal sorumluluk reddelerinde kullanın: ne zaman bir kuralın ne zaman ihlal edileceğini bilin ve bir kod ölçüm aracında yeşil renkte olan bir şey otomatik olarak iyi kalitede değildir.

Size bir kod denetleyicisine bir şeyler açıklamaya başladığımı söyleyemem ve kafamdaki ampul yanar ve "Hey bir dakika bekleyin" der. Bu nedenle, kod incelemesinde diğer kişilerin göremediği kendi hatalarımı sıklıkla buluyorum. Böylece bunu deneyebilirsiniz, sadece kodu yanınızda oturan ve ne yaptığınızı ve nedenini anlamaya çalışan bir kişi varmış gibi açıklamaya başlayın.

Kod incelemelerinde sıkça bulduğum bir diğer şey, geliştiricinin gerçekte gereksinimi karşılamadığıdır. Yani kodunuzu ve gerçek gereksinimi ne yaptığını karşılaştırmak iyi bir kontrol.

Yapısal ihtiyaçlara sahip SSIS paketleri gibi sık sık işler yapıyoruz - kod incelemeleri için kontrol edilmesi gereken bir kontrol listesi geliştirdim (konfigürasyon doğru mu, günlük kaydı ayarlandı, meta veri veritabanını kullanıyor mu, standart konumdaki dosyalar, vb.). Bir kod incelemesinde de her zaman kontrol etmek için kullanışlı olabilecek bazı şeyler olabilir. Oturun ve kod incelemenizi kontrol etmek istediğinizden emin olmak istediğiniz şeylerin kontrol listesine ne koyacağınızı düşünün (İlk madde, gereksinimin karşılandığından emin olun, sonraki öğenin bindirme ve kayıt hatalarıyla ilgisi olabilir). Hatalar yaptığınız ve bunları düzelttikten sonra listeye başka öğeler ekleyebilirsiniz (şöyle bir şey söyleyin, bir döngüdeki bir sonraki kayda mı geçiyorum yoksa aynı ilk öğeyi sonsuz bir şekilde tekrarlayacağım mı? bunu aramayı öğret!).

3 ay verin, sonra geri dönün ve kodunuza bakın. Size söz veriyorum, yanlış bir şey bulamazsanız (ya da bu çöplüğü yazan soru!) Siz benden daha iyi bir insansınız!

Genelde tüm kodlarımı basarım ve sessiz bir ortamda otururum ve okurdum, birçok yazım hatası, sorun, refactor için şeyler bulurum, bunu yaparak temizlerim. Herkesin yapması gerektiğini düşündüğüm bir iyi kontrol.

Üniversiteye döndüğümde yazma öğretmeniydim. Kesinlikle, birçok geliştiricinin asla düşünemeyeceğini düşündüğüm kodlama konusunda bazı görüşler verdi. En önemlilerinden biri kodunuzu yüksek sesle okumaktır. Kulağa pek benzemiyor ama herkesin ilişki kurabileceğini düşündüğüm mükemmel bir örnek vereceğim.

Hiç bir e-posta ya da kağıt yazdınız mı, doğru olduğundan emin olmak için defalarca tekrar okudunuz, sonra sadece göze çarpan bir yazım hatası, yazım hatası veya dilbilgisi hatası olduğunu bulmak için yolladınız mı? Bunu dün müşteriden shift tuşu yerine "bok" tuşuna basmasını istediğimde yaptım. Kafanda okurken ne görmek istediğini görüyorsun.

Bu, başkalarının yapmış olduğu 'sadece bir gün veya bir hafta veya bir ay bekle' önerileri için bir kestirme yoldur. Yüksek sesle okursanız aynı şeyleri yakalarsınız. Neden bu kadar etkili olduğunu bilmiyorum ama yüzlerce öğrenciyle oturduktan ve sesli okuduktan sonra söyleyebileceğim tek şey işe yaradığı.

İnsanların çoğu, kodlarını kendi bebekleri olarak görme eğilimindedir ve onları gerçeklikten çok ego ile besler. Diğer kod incelemelerinde olduğu gibi, başka birinin kodunu gördüğünüz gibi inceleyin. Tamamen bir şey yazdığınızı unutun. Kodun her satırını gözden geçirin. Bir kontrol listesi kendi kodunu gözden geçirme konusunda estetik olması için yardımcı olacaktır. Kod incelemesi için otomatik araçlar bir dereceye kadar yardımcı olabilir. Klocwork (ticari yazılım) gibi bazı araçlar kullandım , Büyük projelerde çalışırken ve bunun için birkaç geliştirici çalışırken bu oldukça kullanışlıdır. Her zaman düzeltme yerine kusur saptamaya odaklanın.

Ancak, en iyi uygulama, kendinizi gözden geçirin ve daha sonra seçkin rollerle gözden geçirilmesi için en az iki kişiyi içermesi olacaktır.

Kendi başına bir Fagan incelemesi yapmayı düşünün - süreci uyarlamak zorunda kalacaksınız çünkü kendi başınızasınız, ancak bundan oldukça değer elde edebilmelisiniz. İşin püf noktası, kodunuzu solo bir aygıt olarak değerlendirmek için doğru "kural" ı bulmak ve ardından her zaman eleştirel, analitik, acımasız bir çerçevede bu soruları sorma disiplinine sahip olmak olacak. Başlamak için 4-5 önemli sorunuzu beyin fırtınası yapmak isteyebileceğinizden ve zaman içinde geliştireceğinizden şüpheleniyorum. Bazı insanlar resmi denetimlere karşıdırlar, çünkü çok pahalı olduklarına karar vermeden önce çok yoğun gözüküyorlar, denetimleri yapmanın aslında proje süresini kısalttığına dair tüm istatistiksel kanıtları akılda tutunuz. İşte daha fazla araştırmaya başlayabileceğiniz bir Wikipedia bağlantısı:

http://en.wikipedia.org/wiki/Software_inspection

Birkaç kitap da vardı, örneğin Strauss ve Ebenau tarafından "Yazılım İnceleme Süreci" için Google.

Diğer bir seçenek de önemli bir projeyi incelemesi için birine ödeme yapmak - ya da belki de tüm kodunuzu kontrol etmek için arada sırada ödeme yapmaktır. Bu adam bayağı iyi, yeni devlerimizi eğitmek için birkaç kez onu uçurduk:

http://www.javaspecialists.eu/

Kod incelemesi için tüm önerilerin yanı sıra, kodunuz için birinci derece akıl yürütme düzeyini yapmak için PMD ve findBug gibi araçları kullanabilirsiniz.

Bu aslında henüz bir cevaba yerleştirilmedi (fakat mevcut bir cevaba yorum olarak eklendi).

İyi bir gece uykusundan sonra kodunuzu gözden geçirin; örneğin, önceki gün yazdığınız kodu gözden geçirerek güne başlayın.

Bu elbette size bir ekibin ortak deneyimini vermeyecek, ancak kodu yeni bir bakış açısıyla gözden geçirmenize olanak sağlayacaktır.

Örneğin, kötü bir saldırıya sahip bir kod parçası bıraktıysanız, kodunuzu derhal gözden geçirirseniz düzeltmek için çok meyilli olamazsınız. Sonuçta, kodunuzu incelemeye başladığınızda, bu hack'in varlığını zaten biliyorsunuz ve kabul ettiniz. Ancak, iyi bir gece uykusu geçirdiyseniz, daha iyi bir çözüm bulmak için muhtemelen daha fazla motive olursunuz.

Uyuduğumuzda, beyin aslında sahip olduğumuz problemler üzerinde çalışmayı bırakmaz, bu yüzden aslında orada bir çözüm bulursunuz, bu çözümler bazen garip şekillerde ortaya çıkabilir .