Kod incelemelerinde, gözden geçirici her zaman sorunlar için bir çözüm sunmalı mı? [kapalı]

Kodları incelerken, normal olarak sorunların nasıl çözüleceği konusunda özel önerilerde bulunmaya çalışırım. Ancak gözden geçirmek için harcayabileceğiniz sınırlı süre nedeniyle, bu her zaman iyi sonuç vermez. Bu durumlarda geliştirici bir çözüm bulursa daha verimli buluyorum.

Bugün bazı kodları inceledim ve bir sınıfın açıkça iyi tasarlanmadığını gördüm. Yalnızca belirli nesnelere atanan ve diğerleri için boş bırakılan bir dizi isteğe bağlı özelliği vardı. Bunu çözmenin standart yolu sınıfı ikiye bölmek ve miras almaktır. Ancak bu özel durumda, bu çözüm işleri aşırı karmaşık hale getirdi. Bu yazılımın geliştirilmesine kendim dahil değildim ve tüm modüllere aşina değilim. Bu yüzden belirli bir karar verebilecek kadar bilgili hissetmedim.

Birçok kez yaşadığım bir başka tipik durum da açıkça anlamsız ve hatta yanıltıcı bir işlev, sınıf veya değişken isim bulmam ama kendimle iyi bir isim bulmam.

Genel olarak, bir eleştirmen olarak, "bu kod hatalı çünkü ..., farklı mı?" Demek için bir sorun mu var yoksa özel bir çözüm bulman gerekiyor mu?

Gözden geçiren kişi olarak, işiniz inceleme öncesinde kararlaştırılmış olan belirli hedeflere uyup uymadığını kontrol etmektir.

Bu hedeflerden bazıları, amacın yerine getirilip getirilmediğine dair genellikle bir karar çağrısını içerecektir. Örneğin, kodun korunabilir olması gerektiği hedefi tipik olarak bir karar çağrısı gerektirir.

Gözden geçiren kişi olarak, hedeflere ulaşılmadığını belirtmek sizin işinizdir ve çalışmalarının gerçekte hedeflerine uygun olduğundan emin olmak yazarın işidir. Bu şekilde, düzeltmelerin nasıl yapılması gerektiğini söylemek sizin işiniz değildir.

Öte yandan, sadece yazara “bu kusurlu. Düzelt” diyerek takımda olumlu bir atmosfere yol açmaz. Olumlu bir atmosfer için, en azından gözlerinizde neden bir şeylerin kusurlu olduğunu belirtmek ve eğer varsa bir tane daha iyi bir alternatif sunmak iyidir.
Bunun yanı sıra, "yanlış" görünen bir şeyi gözden geçiriyorsanız, ancak gerçekten daha iyi bir alternatifiniz yoksa, "Bu kod / tasarım benimle iyi uyuşmuyor," açık bir alternatifi yok. Bunu tartışabilir miyiz? " ve sonra birlikte daha iyi bir şeyler elde etmeye çalışın.

Burada bazı iyi cevaplar, ancak bence önemli bir nokta eksik. Kodunu incelediğiniz, o kişinin ne kadar deneyimli olduğu ve bu önerileri nasıl ele aldığı büyük bir fark yaratıyor. Takım arkadaşınızı iyi tanıyorsanız ve "bu kod hatalı olduğu için ..., farklı şekilde yapın" gibi bir not beklerseniz, daha iyi bir çözüm bulması yeterli olacaktır, o zaman böyle bir yorum iyi olabilir. Ancak, kesinlikle böyle bir yorumun yeterli olmadığı ve kodlarının nasıl iyileştirileceğinin tam olarak söylenmesi gereken kişiler var. Yani IMHO bu, sadece bireysel dava için yapabileceğiniz bir yargı çağrısıdır.

Genel olarak, bir eleştirmen olarak, "bu kod hatalı, farklı mı?" Demek için sorun yok mu, yoksa belirli bir çözüm bulmanız gerekiyor mu?

İkisinden hiçbiri ideal IMO değil. Yapılacak en iyi şey, yazarla konuşmak ve sorunu işbirliği içinde düzeltmektir.

Kod incelemelerinin zaman uyumsuz olması gerekmez. Bunları bürokratik bir süreç olarak görmeyi bırakıp canlı iletişim için biraz zaman ayırırsanız, birçok sorun ortaya çıkar.

Kod incelemelerinde, gözden geçirici her zaman sorunlar için bir çözüm sunmalı mı?

Hayır. Eğer bir inceleme yapmıyorsanız, bir sonraki kodlayıcı sizsiniz.

Kod incelemelerinde, gözden geçiren konular için asla bir çözüm sunmamalı mı?

Hayır. İşiniz konuyu elinizde iletmektir. Bir çözüm sunmak sorunu açıklığa kavuşturursa, o zaman yapın. Sadece çözümünüzü takip etmemi beklemeyin. Burada yapabileceğin tek şey bir şey ifade etmek. Uygulamayı dikte edemezsiniz.

Bir gözden geçiren konular için ne zaman bir çözüm sunmalıdır?

Bu iletişim kurmanın en etkili yolu. Biz İngilizler değil, kod maymunlarız. Bazen kodun berbat olduğunu göstermenin en iyi yolu ... optimalden daha azdır ... onlara daha az berbat kod göstermektir ... daha çok tercih edilir ... ah ne demek istediğimi biliyorsun.

Asıl mesele, eğer insanlar kodu nasıl daha iyi yazacaklarını bilselerdi, genellikle bunu ilk başlarda yaparlardı. Bir eleştirinin yeterince belirgin olup olmadığı yazarın deneyimine çok bağlıdır. Çok deneyimli programcılar "bu sınıf çok karmaşık" gibi bir eleştiri alabilir ve çizim tahtasına geri dönüp daha iyi bir şeyler bulabilirler, çünkü baş ağrıları nedeniyle kapalı bir gün geçirdiler veya özensiz oldukları için telaş içerisinde.

Genellikle, yine de, en azından komplikasyonun kaynağını tanımlamanız gerekir. Diyerek şöyle devam etti: "Bu sınıf çok karmaşık çünkü her yerinden Demeter Yasasını çiğniyor." "Bu sınıf sunum katmanını ve kalıcılık katman sorumluluklarını birleştiriyor." Bu nedenleri belirlemeyi ve bunları kısaca açık bir şekilde açıklamayı öğrenmek, daha iyi bir gözden geçiren olmanın bir parçasıdır. Çözümler hakkında çok fazla ayrıntıya girmek zorunda kalmazsınız.

İki tür kötü programcı vardır: standart uygulamaları takip etmeyenler ve "sadece" standart uygulamaları takip edenler.

Sınırlı iş bağlantım olduğunda / birine geri bildirimde bulunduğumda, "Bu kötü bir tasarım" demezdim. ama "Bu sınıfı bana açıklayabilir misiniz?" Bunun iyi bir çözüm olduğunu keşfedebilirsiniz, dev, elinden gelenin en iyisini yaptığını, hatta bunun kötü bir çözüm olduğunu kabul etmesini sağladı, ama yeterince iyi.

Cevabınıza bağlı olarak, her duruma ve kişiye nasıl yaklaşılacağı konusunda daha iyi bir fikriniz olacak. Sorunu hızla tanıyabilir ve düzeltmeyi kendi başlarına keşfedebilirler. Yardım isteyebilirler veya sadece kendi başlarına gidip çözmeye çalışacaklar.

İşimizde önerilen uygulamalar var, ancak neredeyse hepsinin istisnaları var. Projeyi ve ekibin ona nasıl yaklaştığını anlarsanız, kod incelemesinin amacını ve endişeleri nasıl gidereceğinizi belirleme bağlamı bu olabilir.

Bunun, probleme açık bir çözümden çok bir yaklaşım olduğunun farkındayım. Tüm durumları kapsayacak kadar fazla değişkenlik olacak.

Kodları incelerken yalnızca çok az bir çaba ile başarabilirsem, belirlediğim sorunlar için bir çözüm sunarım. Sorunun ne olduğunu düşündüğüm konusunda spesifik olmaya çalışıyorum, mümkün olan hallerde mevcut belgelere geri dönüyorum. Bir gözden geçiriciden, belirlenen her soruna bir çözüm sunmasını beklemek, ters bir teşvik yaratır - gözden geçirene sorunları işaret etmesini engeller.

Kanımca, birçok nedenden dolayı, çoğu durumda kod sağlama yönünde daha güçlü bir yol izleniyor:

• Eğer açıklama tek başına yeterli değilse, düşündüğünüzden her zaman bir örnek isteyebilirler.
• Uzun zamandır dokunmadığınız bazı kodları tanımaya çalışarak zamanınızı boşa harcamazsınız, sadece biraz değiştirmek için, birileri zamanını böyle yaparak harcadı.
• Zaten bir kod parçasına aşinalarsa ve siz bilmiyorsanız, yalnızca geri bildirimde bulunmak, yazdığınızdan daha iyi kodla sonuçlanabilir. Birine hazır bir çözüm vermek, daha fazla geliştirmeyi düşünmeden, sadece kullanmalarına neden olur.
• Her zaman bir çözüm sağlamak küçümseme konusunda sınırlayıcıdır. Birisiyle çalışıyorsun, umarım işe alınacak kadar iyilerdir. Bir şeyin neden kötü bir fikir olduğunu öğrenmeyi başardıysanız, neden geri bildirimleri dinleyerek ve kendileri yaparak öğrenmediler?
• Her zaman bir çözüm sunmak sadece garip. Kendi masasında çift programlama yaptığınızı hayal edin: harika olmadığını düşündüğünüz birkaç satırı tamamladılar. Onlara ne gördüğünü ve nedenini söylüyorsun ya da klavyesini alıp versiyonunu hemen gösterdin mi? Çözümünüzü her zaman başkalarına karşı hissedebileceğiniz şey budur.
• Bunun yerine ne yazacağınızı her zaman söyleyebilirsiniz, aslında yazmak için zaman harcamadan. Bunu, sorudaki ilk sorunu tarif ederken yaptınız.
• Yiyecekleri dağıtmayın, balık tutmayı öğretin;)

Elbette, belirli bir alternatif düşünmeyi düşündüğünüz bazı durumlar var ve buna değmeye değer. Ama bu benim deneyimimde gerçekten nadir. (çok sayıda inceleme, büyük projeler) Özgün yazar, gerektiğinde sizden bir örnek isteyebilir.

O zaman bile, 3. nedenden dolayı, bir örnek verirken, örneğin x.foo()tam bir çözümden ziyade "kullanımı daha basit hale getirir " demeye değer olabilir - ve yazarın yazmasına izin verin. Bu aynı zamanda zaman kazandırır.

İncelemeleri kodlamanın anahtarının, incelemeden önceki kurallar üzerinde anlaşmak olduğunu düşünüyorum.

Açıkça bir kurallar diziniz varsa, bir çözüm sunmanıza gerek kalmaz. Siz sadece kurallara uyulduğunu kontrol ediyorsunuz.

Bir alternatifin sorusunun ortaya çıkacağı tek zaman, orijinal cihazın kurallara uyan bir özelliği uygulamak için bir yol düşünememesiydi. Performans gereksiniminiz olduğunu söyleyin, ancak birkaç optimizasyon denemesinden sonra bu özellik eşiğinizden daha uzun sürer.

Ancak! Kuralların öznel ise, "İsimler benim tarafımdan onaylanmalı!" öyleyse, evet, kendinize yeni bir şef seçtiniz ve kabul edilebilir isimlerin listeleri için istekler beklemelisiniz.

Kalıtım (isteğe bağlı parametreler) örneğiniz belki daha iyidir, int uzun yöntemleri ve 'çok fazla' işlev parametresini yasaklayan kod inceleme kurallarını gördüm. Ancak normalde bunlar bölünerek önemsizce çözülebilir. Nesnenizin izinsiz olduğu ve belki de gerekçelendirme veya alternatif bir çözüm gerektirdiği "bu çözüm aşırı karmaşık görünüyordu" bölümüdür.

Potansiyel bir çözümün hızlı ve kolay bir şekilde yazılması durumunda, akran incelememe yorumuma eklemeye çalışıyorum. Değilse, en azından endişelerimi ve neden bu maddeyi sorunlu bulduğumu listeliyorum. Daha iyi bir şey düşünemediğiniz değişken / fonksiyon isimleri söz konusu olduğunda, genellikle daha iyi bir fikrim olmadığını kabul ediyorum ve yorumu birisinin açık uçlu bir soru şeklinde sonlandırdığını kabul ediyorum. . Bu şekilde kimse daha iyi bir seçenek bulamazsa, inceleme gerçekten yapılmaz.

Mesela, sorunuza verdiğiniz örnek, kötü tasarlanmış bir sınıf. Overkill gibi gözükse de, kalıtımın, kodun çözmeye çalıştığı sorunu çözmenin en iyi yolu olacağı ve bu konuda bırakacağım bazı yorumlar bırakacağım. Bunun bir gösteri durdurucu olmadığını ve düzeltmek isteyip istemediğine bağlı olarak geliştiricinin takdirine bağlı olduğunu ifade etmeye çalışacağım. Ayrıca, kodun bu kısmına özellikle aşina olmadığınıza dair bir onay vereceğim ve bu şekilde yapılmasının bir nedeni olup olmadığını açıklamak için daha bilgili geliştiriciler ve / veya yorumcular davet ediyorum.

Git ve kodunu incelediğin kişiyle konuş. Onlara dostane bir şekilde anlamanızı biraz zor bulduğunuzu söyleyin ve onlarla nasıl daha net hale getirilebileceğini tartışın.

Yazılı iletişim, büyük miktarda boşa harcanan zamanın yanı sıra, kızgınlık ve yanlış anlamalara yol açar.

Yüz yüze, bant genişliği çok daha yüksek ve düşmanlıktan kaçınmak için duygusal yan kanal var.

Aslında adamla konuşursanız, çok daha hızlı olur ve yeni bir arkadaş edinir ve her ikinizin de işinizden daha çok zevk aldığını görebilirsiniz.