Kod incelemesi için gönderilen kod çok karmaşık görünüyorsa ne yapmalı?

Kodun takip edilmesi zor ancak en azından yüzeysel testlerle (çoğunlukla) iyi çalışıyor gibi görünüyor. Burada ve orada küçük hatalar olabilir, ancak daha derin sorunların veya basit düzeltmelerin semptomları varsa kodu okuyarak anlatmak çok zordur. Kod düzeltmesi yoluyla manuel olarak genel doğruluğu onaylamak, ancak mümkün olsa bile çok zordur.

Bu durumda en iyi eylem şekli nedir? Do-üstünde ısrar mı? Kısmi devralma? İlk önce faktoring mi? Sadece hataları düzeltip teknik borcu kabul etmek ? Bu seçenekler üzerinde bir risk değerlendirmesi yapın ve sonra karar verin? Başka bir şey?

İncelenemezse incelemeyi geçemez.

Kod incelemesinin hata bulmak için olmadığını anlamalısınız. QA bunun için var. Kod incelemesi, kodun gelecekteki bakımının mümkün olmasını sağlamaktır. Şimdi kodu bile takip edemiyorsanız, özellik geliştirmeleri ve / veya hata düzeltmeleri yapmak üzere atandığınızda altı ay içinde nasıl başlayabilirsiniz? Şu an böcek bulmak sadece bir yan yarar.

Çok karmaşıksa, bir ton SOLID ilkesini ihlal ediyor . Refaktör, refaktör, refaktör. Çok daha az, daha basit, doğru adlandırılmış işlevlere ayırın. Temizleyebilirsiniz ve test durumlarınız doğru çalışmaya devam etmesini sağlayacaktır. Test vakaların var değil mi? Değilse, onları eklemeye başlamalısınız.

Bahsettiğiniz her şey bir kod incelemesinde belirtmek için tamamen geçerlidir.

Bir kod incelemesi aldığımda testleri inceliyorum. Testler yeterli kapsam sağlamazsa, dikkat edilmesi gereken bir şey var. Testlerin, kodun istenen şekilde çalışmasını sağlamak ve değişikliklerde amaçlandığı şekilde çalışmaya devam etmesini sağlamak için faydalı olması gerekir. Aslında, bu kod incelemesinde aradığım ilk şeylerden biri. Eğer kodunuzun gereklilikleri karşıladığını kanıtlamadıysanız, zamanımın içine bakmak için yatırım yapmak istemiyorum.

Bir kez kod için yeterli testler yapılırsa, kod karmaşıksa veya takip etmesi zorsa, bu aynı zamanda insanların bakması gereken bir şeydir. Statik analiz araçları bazı karmaşıklık ölçütlerine işaret edebilir ve aşırı karmaşık yöntemleri işaretleyebilir, ayrıca koddaki potansiyel kusurları bulabilir (ve bir insan kodu incelemesinden önce çalıştırılmalıdır). Ancak, kod insanlar tarafından okunur ve korunur ve önce bakım için yazılmalıdır. Sadece daha az bakım gerektirebilen kod kullanmanın bir nedeni varsa, bu şekilde yazılmalıdır. Karmaşık veya sezgisel olmayan bir kodun olması gerekiyorsa, kodun neden bu şekilde olduğu ve gelecekteki geliştiricilerin kodun neden ve ne yaptığını anlamalarına yardımcı olacak yorumlarının olması gerektiği belgelenmelidir.

İdeal olarak, uygun sınamaları olmayan veya aşırı karmaşık bir kodu olan kod incelemelerini iyi bir neden olmadan reddedin. İlerlemeniz gereken ticari nedenler olabilir ve bunun için riskleri değerlendirmeniz gerekir. Kodla teknik borcu ileriye götürürseniz, neyin değişmesi gerektiğinin ayrıntıları ve onu değiştirmek için bazı önerilerle birlikte derhal hata izleme sisteminize biletleri koyun.

Kod düzeltmesi yoluyla manuel olarak genel doğruluğu onaylamak, ancak mümkün olsa bile çok zordur.

Uzaktan kod incelemesinin amacı bu değil. Bir kod incelemesini düşünmenin yolu, kodda bir hata olduğunu ve onu düzeltmeniz gerektiğini hayal etmektir. Bu zihniyet ile, kodu gözden geçirin (özellikle yorumlar) ve kendinize sorun: "Sorunu daraltmak için neler olup bittiğinin büyük resmini anlamak kolay mı?" Eğer öyleyse, bu bir pas. Aksi takdirde, bu bir başarısızlık. En azından daha fazla belgeye ihtiyaç var ya da kodu makul derecede anlaşılır hale getirmek için yeniden düzenlemeye gerek var.

İşvereninizin peşinde olduğundan emin olmadığınız sürece, mükemmeliyetçi olmamanız önemlidir. Kodların çoğu, her seferinde daha okunaklı bir şekilde kolayca tekrar tekrar 10 kez tekrar kırılabilecek kadar berbattır. Ancak işvereniniz muhtemelen dünyanın en okunaklı koduna sahip olmak için ödeme yapmak istemiyor.

Kod düzeltmesi yoluyla manuel olarak genel doğruluğu onaylamak, ancak mümkün olsa bile çok zordur.

Yıllar önce, tam olarak öğrencilerin ödevlerini puanlayarak bunu yapmak benim işimdi. Ve birçoğu burada ve orada bir hata ile makul bir kalite sunarken, öne çıkan iki kişi vardı. Her ikisi de her zaman hata olmayan bir kod gönderdi. Biri yüksek hızda yukarıdan ve aşağıdan okuyabildiğim ve sıfır çabayla% 100 doğru olarak işaretlediğim bir kod gönderdi. Diğeri, birbiri ardına bir WTF olarak gönderilen, ancak bir şekilde herhangi bir hatadan kaçınmayı başardı. İşaretlemek için mutlak bir acı.

Bugün ikincisi kodunu bir kod incelemesinde reddetti. Doğruluğu onaylamak çok zor ve zaman alıyorsa, bu kodla ilgili bir sorundur. İyi bir programcı bir problemin nasıl çözüleceğini (zaman alır X) ve bir kod gözden geçiricisine vermeden önce bunu sadece işi yapmak için yapmaz, tabii ki işi yapar. Bu, zamanla X'ten çok daha az zaman alır ve gelecekte çok zaman kazandırır. Genellikle bir kod inceleme aşamasına geçmeden önce hataları açığa çıkararak. Daha sonra kod incelemesini çok daha hızlı hale getirerek. Gelecekte de her zaman kodun uyarlanmasını kolaylaştırarak.

Başka bir cevap, bazı kişilerin kodlarının 10 kez yeniden düzenlenebileceğini ve her seferinde daha okunaklı olabileceğini söyledi. Bu sadece üzücü. Farklı bir iş araması gereken bir geliştirici.

Bu eski kod biraz değişti mi? (10000 satırlık bir kod satırında 100 satır kod değişti hala küçük bir değişiklik.) Bazen zaman kısıtlamaları var ve geliştiriciler eski ve uygunsuz bir çerçevede kalmaya zorlanıyor, çünkü tam bir yeniden yazma daha uzun sürüyor ve bütçe dışı kalıyor . + Genelde yanlış değerlendirildiğinde milyonlarca dolara mal olabilen risk vardır. Eski kodsa, çoğu durumda onunla yaşamak zorunda kalacaksınız. Kendi başınıza anlamıyorsanız, onlarla konuşun ve ne dediklerini dinleyin, anlamaya çalışın. Unutmayın, sizin için takip etmek zor olabilir, ancak diğer insanlar için gayet iyi. Onların tarafını tut, onların sonundan bak.

Bu yeni kod mu? Zaman kısıtlamalarına bağlı olarak, mümkün olduğunca refactor'a destek vermelisiniz. Gerekirse kod incelemeleri için daha fazla zaman harcamak uygun mudur? 15 dakikaya kadar zaman zamanını ayarlamamalısın, fikrini bul ve devam et. Yazar bir şeyi yazmak için bir hafta harcadıysa, incelemesi için 4-8 saat harcamak tamamdır. Buradaki amacınız onlara yeniden yöneltici yardımcı olmaktır. Sadece "refactor. Now" yazan kodu geri göndermiyorsunuz. Hangi yöntemlerin kırılabileceğini görün, yeni sınıflar tanıtmak için fikirler bulmaya çalışın vs.

Çoğu zaman, "karmaşık" yamalar / değiştiriciler, aynı anda birçok farklı şey yapanlardır. Yeni kod, silinen kod, yeniden düzenlenmiş kod, taşınan kod, genişletilmiş testler var; büyük resmi görmek zorlaşıyor.

Yaygın bir ipucu ipucu, yamanın büyük olduğu, ancak tanımının küçük olduğu: "Uygulama $ FOO".

Böyle bir yamayı ele almanın makul bir yolu, bir dizi daha küçük, kendi kendine yeten parçaya bölünmesini istemek. Tek sorumluluk ilkesinin, bir işlevin sadece bir şeyi yapması gerektiğini söylediği gibi, bir düzeltme ekinin de sadece bir şeye odaklanması gerekir.

Örneğin, ilk yamalar tamamen işlevsel değişiklik yapmayan tamamen mekanik yeniden yapılandırmalar içerebilir ve daha sonra son yama (lar) $ FOO'nun daha az dikkat dağıtması ve kırmızı topaklarla gerçek uygulamasına ve test edilmesine odaklanabilir.

Çok sayıda yeni kod gerektiren işlevsellik için, yeni kod genellikle, ürünün davranışını değiştirmeyen test edilebilir parçalara tanıtılabilir; serideki son yama aslında yeni kodu çağırır (bayrak çevirme).

Bunu titizlikle yapmak için, genellikle sorunum olarak söylüyorum ve yazarın yardımını istiyorum: “Burada olan her şeyi takip etmekte zorlanıyorum. birlikte?" Küçük adımlar için özel önerilerde bulunmak bazen gerekli olabilir.

"Implement $ FOO" gibi büyük yama aşağıdaki gibi bir dizi yamaya dönüşür:

1. Bir çift yineleyiciyi alan yeni bir Frobnicate sürümü tanıtın çünkü $ FOO'yu uygulamak için vektör dışında dizilerle çağırmam gerekecek.
2. Yeni sürümü kullanmak için mevcut tüm Frobnicate arayanlarını değiştirin.
3. Eski Frobnicate'i silin.
4. Frobnicate çok yapıyordu. Refrumple'ı kendi yöntemine uygulayın ve bunun için testler ekleyin.
5. Zerzify'ı testlerle tanıtın. Henüz kullanılmamış, ancak $ FOO için buna ihtiyacım var.
6. Zerzify ve yeni Frobnicate açısından $ FOO uygulayın.

1-5 arasındaki adımların üründe hiçbir işlevsel değişiklik yapmadığını unutmayın. Doğru testlerin yapılmasını sağlamak da dahil olmak üzere gözden geçirme konusunda önemsizler. 6. adım hala "karmaşık" olsa bile, en azından $ FOO'ya odaklandı. Ve kayıt kütüğü doğal olarak size $ FOO 'nun nasıl uygulandığı (ve Frobnicate'in neden değiştiği) hakkında daha iyi bir fikir verir.

Diğerlerinin de belirttiği gibi, kod incelemesi gerçekten hataları bulmak için tasarlanmamıştır. Kod incelemesi sırasında hata buluyorsanız, bu muhtemelen yeterli otomatik test kapsamına sahip olmadığınız anlamına gelir (örn. Ünite / entegrasyon testleri). Varsa kod gerekiyordu yapar beni ikna etmeye yeterli kapsama değil , ben genellikle daha fazla test için sormak ve ben arıyorum test olguların türlü işaret ve genellikle yeterli kapsama sahip olmayan kod temeli haline koduna izin vermez .

Eğer üst düzey mimari çok karmaşıksa veya anlam ifade etmiyorsa, genellikle birkaç ekip üyesiyle bir toplantıyı bunun hakkında konuşmak için çağırırım. Kötü bir mimaride yinelenmek bazen zor. Eğer dev acemiyse, genellikle kötü bir çekme isteğine tepki vermek yerine , önceden düşündüklerinin ötesine geçtiğimizden emin olurum . Sorunun muhtemel olarak belirlenecek olandan daha belirgin bir çözümü yoksa, bu genellikle daha tecrübeli geliştiriciler için bile geçerlidir.

Karmaşıklık, tekrarlı olarak ve iyi otomatikleştirilmiş testlerle düzeltilebilen yöntem seviyesine göre yalıtılırsa.

Son bir nokta. Bir gözden geçiren kişi olarak, kodun karmaşıklığının temel mi yoksa yanlışlıkla mı karmaşıklığa bağlı olduğuna karar vermeniz gerekir . Temel karmaşıklık, yazılımın yasal olarak çözülmesi zor olan bölümleriyle ilgilidir. Kaza sonucu ortaya çıkan karmaşıklık, yazdığımız kodun sebepsiz yere çok kolay ve kolayca sadeleştirilebilecek diğer tüm kısımlarını ifade eder.

Genelde, temel karmaşıklığa sahip kodun gerçekten olduğundan ve daha da basitleştirilemediğinden emin olun. Ayrıca, bu kısımlar için daha fazla test kapsamı ve iyi belgeler sunmayı amaçlıyorum. Kazara karmaşıklık, çekme isteği işlemi sırasında hemen hemen her zaman temizlenmelidir, çünkü bunlar ele aldığımız kodun büyük kısmıdır ve kısa vadede bile bakım kabusuna kolayca neden olabilir.

Testler nasıl? İdeal olarak sadece bir iddia ile okunması kolay, basit ve okunması kolay olmalıdır. Testler amaçlanan davranışı açıkça belgelemeli ve kodun vakalarını kullanmalıdır .

İyi bir şekilde test edilmezse, incelemeye başlamak için iyi bir yer.