Kod incelemesi çok zor olduğunda ne yaparsınız?

Tamam, bu yüzden birçok kod incelemesi oldukça rutin. Ancak, zaman zaman mevcut karmaşık, kırılgan kodu geniş ölçüde etkileyen değişiklikler vardır. Bu durumda, değişikliklerin güvenliğini, gerilemenin yokluğunu vb. Doğrulamak için harcayacağınız zaman çok fazladır. Belki de geliştirmenin kendisi için geçen süreyi aştı.

Bu durumda ne yapmalı? Birleştirme ve hiçbir şeyin kaymadığını umalım mı? (Bunu savunmuyorsun!) En iyisi yapabilecek ve sadece herhangi bir açık noktayı tespit etmeye çalışacak mı (belki de en fazla kod incelemesi bu olabilir mi?) Kod incelemesinden daha iyi bir alternatif olarak daha ayrıntılı bir şekilde birleştirme ve test etme?

Bu, testin bir kod incelemesinin parçası olarak yapılması gerekip gerekmediği özel bir soru değildir. Bu, en iyi seçeneklerin açıklandığı gibi ne durumda olduğunu soran bir sorudur, özellikle son başvuru tarihi ile, kapsamlı bir birim test paketi mevcut değil veya değiştirilmiş parçalanmış kod için uygun olmayan birim testler.

EDIT: Şimdiye kadarki cevapların / yorumların bir kısmının "geniş ölçüde etkiledi" ifademden aldıkları ve muhtemelen değişimin çok sayıda kod satırı içerdiği anlamına geldiği izlenimini edindim. Bunun yorumlama olduğunu anlayabiliyorum, ama bu gerçekten benim niyetim değildi. "Genel olarak etki" derken, örneğin, kod tabanının birbirine bağlı olmasından ya da değişimin kendisinin büyük olmasından ziyade, çarpma etkilerinin kapsamı nedeniyle, regresyon potansiyelinin yüksek olduğunu kastediyorum. Örneğin, bir geliştirici, daha düşük seviyeli rutinlere yapılan çağrıları basamaklayan mevcut bir üst düzey yordamı çağırarak tek bir satırda bir hatayı düzeltmenin bir yolunu bulabilir. Hata düzeltmesinin çalıştığını test etmek ve doğrulamak kolaydır. Manuel olarak doğrulama (kod incelemesi yoluyla) tüm çalma etkilerinin etkisinin çok daha zordur.

Sorunun öncülü açıkçası şaşırtıcı. Kırılgan, karmaşık kodda büyük bir değişiklik olduğunu ve doğru bir şekilde incelemek için yeterli zaman olmadığını varsayalım . Bu inceleme için daha az zaman harcamanız gereken son koddur ! Bu soru, yalnızca kodunuzun kendisinde değil, aynı zamanda değişimi yönetme metodolojisinde de yapısal sorunlarınız olduğunu gösterir.

Peki bu durumla nasıl başa çıkılır? İlk başta girmeyerek başlayın:

• Karmaşıklık kaynaklarını belirleyin ve soyutlama seviyesini arttırmak için dikkatli, yoğun bir şekilde gözden geçirilmiş, doğru yeniden yapılandırmaları uygulayın. Kod, iş alanınız hakkında bir şeyler bilen, kolejden yeni çıkmış yeni bir çalışan tarafından anlaşılabilir olmalıdır.

• Kırılganlık kaynaklarını tanımlayın; Bu, kodun hata düzeltmelerinin geçmişini inceleyerek kodun kendisini incelemesi olabilir. Hangi alt sistemlerin kırılgan olduğunu belirleyin ve onları daha sağlam kılın . Hata ayıklama mantığı ekleyin. İddiaları ekleyin. Aynı algoritmanın yavaş ve açık bir şekilde doğru uygulanmasını sağlayın ve hata ayıklama yapınızda, her ikisini de çalıştırın ve kabul ettiklerini doğrulayın. Hata ayıklama yapınızda, daha nadir görülen durumlara neden olabilirsiniz. (Örneğin, her zaman yeniden tahsisatta bir bloğu hareket ettiren veya her zaman sayfanın sonunda veya her neyse bir bloğu ayıran bir bellek ayırıcısı yapın .) Kodu, bağlamında yapılan değişiklikler karşısında sağlam hale getirin. Artık artık kırılgan kodunuz yok; Şimdi hatalara neden olmak yerine hataları bulan kodunuz var.

• Bir takım otomatik testler yaz. Açıkçası.

• Geniş değişiklikler yapmayın. Her biri doğru görülebilecek bir dizi küçük, hedeflenmiş değişiklik yapın.

Fakat temelde, senaryonuz “kendimizi bir teknik borç çukuruna kazdık ve her karmaşık, gözden geçirilmemiş değişiklik bizi daha derine sokuyor; ne yapmalıyız?”. Kendini o delikte bulduğunda ne yaparsın? Kazmayı bırak . Birbirinizin kodunu gözden geçirme gibi temel işleri yapamayacak kadar borcunuz varsa, daha fazla borç vermeyi bırakmalı ve ödemeleri için zaman harcamanız gerekir.

Bir kod incelemesinin öncelikli amaçlarından biri kaliteyi artırmak ve sağlam kodlar sunmaktır . Sağlam, çünkü 4 göz genellikle 2'den daha fazla sorun görüyor. Ayrıca, ek kodu yazmamış olan gözden geçiricinin (potansiyel olarak yanlış) varsayımlara karşı çıkma olasılığı daha yüksek.

Hakem değerlendirmelerinden kaçınmak, sizin durumunuzda yalnızca kodunuzun kırılganlığını arttırmaya katkıda bulunur. Tabii ki, sağlam ve tekrarlanabilir bir test takımıyla takviye testleri kesinlikle kaliteyi artırabilir. Ama inceleme, peer to tamamlayıcı olmalıdır değil bir yedek .

Karmaşıklığın anlaşılması ve ustalaştırılması gerektiğini düşünüyorum ve akran incelemesinin tamamı bilgiyi paylaşma ve bunu başarma zamanıdır. Kırılgan kodun gücünü ve zayıflığını anlama konusunda daha fazla insanın sahip olması için yaptığınız yatırım, zaman içinde daha iyi hale getirmenize yardımcı olacaktır.

Sonuç olarak alınacak bir teklif:

"Hızlı gitmek istiyorsan, yalnız git. Uzaklara gitmek istiyorsan, birlikte git"

Eski yazılım geliştirme dünyasına hoş geldiniz.

Yüzbinlerce, milyonlarca, 10 milyonlarca kod satırınız var.

Bu kod satırları, gelir akışı ürettikleri ve değiştirilmelerinin olanaksız olması nedeniyle değerlidir.

İş modeliniz bu kod tabanından yararlanmaya dayanıyor. Yani ekibiniz küçük, kod tabanı büyük. Kişilere kodunuzun yeni bir sürümünü almalarını sağlamak veya mevcut müşterileri mutlu etmek için özellik eklemek gerekir.

Mükemmel bir dünyada, devasa kod tabanınız wazoo'da test edilmiş bir ünitedir. Mükemmel bir dünyada yaşamıyorsun.

Daha az kusursuz bir dünyada, teknik borcunuzu düzeltme bütçesine sahipsiniz - kodunuzu birim test edilebilir parçalara ayırın, kapsamlı entegrasyon testi yapın ve yineleyin.

Ancak bu, yeni özellikler üretmeden borcunu ödedi. Hangi "yükseltme için teşvik üretmek amacıyla değiştirirken mevcut koddan kar elde etme" durumuyla uyuşmuyor.

Çok büyük kod parçalarını alabilir ve daha modern teknikler kullanarak yeniden yazabilirsiniz. Ancak mevcut kodla etkileşime girdiğiniz her yerde olası kırılma noktalarına maruz kalacaksınız. Sistemdeki bu kesmek, aslında yeniden yazmadığınız bir alt sistemdeki bir tuhaflığı telafi etti. Her zaman.

Ne yapabilirsiniz yapmak dikkatle hareket olduğunu. Kodun gerçekte anladığınız, sistemin davranışları ve etkileşimi iyi anlaşıldığı bir kısım bulabilirsiniz. Bunu, birim testleri ekleyerek ve davranışını daha da netleştirerek modernleştirebilirsiniz.

Sonra uygulamanın geri kalan kısmının esas olarak kendisiyle etkileşime giren kısımlarını bulun ve bunlara birer birer saldırın.

Siz bunu yaparken, müşterilerin ödemek istedikleri özellikleri ekleyerek alt sistemi iyileştirebilirsiniz.

Kısacası, bu, iş vakasını sağlayan şeyleri parçalamadan değişiklik yapma olasılığının sanatıdır.

Ama bu senin sorunun değil. Sorunuz, "Çok büyük bir şey yapıyorum ve işleri kırma olasılığı var ve en iyi uygulamaları nasıl takip ederim?"

Büyük bir şey yaparken, eğer güvenilir bir şekilde yapmak istiyorsanız, hataları bulmak ve yazmaktan daha fazla çaba harcamanıza neden olacağınız doğrudur. Yazılım geliştirmenin genel kuralı budur: yazı yazmak kolaydır, kusursuz çalışması zor.

Muhtemelen başınıza sarkan bir iş vakanız vardır, bu büyük değişimin yaşanacağı bazı paydaşlara söz verdiniz. Ve bu "bitti" derken, "hayır, bu bitmedi, sadece görünüyor" beğendim "

Gücünüz ve bütçeniz varsa, aslında değişimin işe yarayacağına veya sadece değişikliği reddettiğinize güven veren çabayı harcarsınız. Bu derece meselesi olacak, kibar değil.

Çok fazla gücünüz yoksa, ama hala bazılarınız varsa, yeni sistemin birimin test edilebildiği konusunda ısrar etmeye çalışın . Bazı alt sistemleri yeniden yazarsanız, yeni alt sistemin iyi tanımlanmış davranışlara sahip küçük parçalardan ve bunların etrafındaki birim testlerinden oluşması konusunda ısrar edin.

Sonra en kötü durum var. Daha derine borçlanıyorsun. Özelliği çıkmak için kırılgan ve daha çok hata daha kod sağlayarak programın gelecekteki tehlikelere ödünç şimdi ve sonuçlarına lanet olası. En kötü sorunları bulmak için QA tarama işlemini gerçekleştirir ve gerisini görmezden gelirsiniz. Bu aslında şu anda en ucuz olduğu gibi bazen işletme açısından doğru cevap. Kâr elde etmek için borca ​​girmek geçerli bir iş stratejisidir, özellikle borcu iflas yoluyla temizlemek (kodu terk etmek) masada.

Büyük bir sorun, nadiren, şirket sahiplerinin karar vericiler ve programcılar ile uyumlu teşvikler olmasıdır. 'Teslim etme' için çok fazla baskı olma eğiliminde olup, bunu yapmak için neredeyse görünmez (üstlerinize) teknik borç oluşturarak yapmak çok kısa ve bazen orta vadeli bir stratejidir. Hatta üstlerine eğer / paydaşlar iyi hizmet olacağını değil tüm bu borç yaratır.

Kod incelemesinin çok zor olmasına neden olan daha büyük sorunları çözün.

Şimdiye dek tespit ettiklerim:

1. Ünite test takımı yok
2. Karmaşık kod, daha mantıklı kod yapısı ve kodlama görevlerinin delegasyonu tarafından önlenebilecek birleştirme
3. İlkel mimarinin belirgin bir eksikliği

1. Kod incelemesini geri gönderebilir ve geliştiriciye daha küçük, daha küçük değişiklik gruplarına bölmesini ve daha küçük bir kod incelemesi göndermesini isteyebilirsiniz.

2. Kod kodunu, kalıpları ve anti-kalıpları, kod biçimlendirme standartlarını, SOLID ilkelerini vb. Mutlaka kodun her detayını incelemeden kontrol edebilirsiniz.

3. Tüm değişiklik setinin genel amacını anlamak zorunda kalmadan, doğru giriş doğrulama, kilitleme / iş parçacığı yönetimi, olası işlenmemiş istisnalar vb. İçin yine de detaylı bir taktik kod incelemeleri gerçekleştirebilirsiniz.

4. Koddan etkilenebileceğini bildiğiniz genel risk alanlarının bir değerlendirmesini sağlayabilir ve geliştiriciden bu risk alanlarının birim test edildiğini onaylamasını isteyebilir (veya otomatik birim testleri yazmasını isteyip istemediklerinizi de inceleyebilirsiniz.). ).

Bu durumda, değişikliklerin güvenliğini, gerilemenin yokluğunu vb. Doğrulamak için harcayacağınız zaman çok fazladır.

Kod incelemeleri öncelikle doğruluğu hedeflememelidir. Kod okunabilirliğini, sürdürülebilirliğini ve ekip standartlarına uyumu geliştirmek için buradalar.

Bir kod incelemesi sırasında doğruluk hatalarını bulmak, bunları yapmanın güzel bir yan ürünüdür, ancak bir geliştirici, incelemeye göndermeden önce kodlarının (regresyon olmayanlar dahil) mükemmel çalıştığından emin olmalıdır .

Doğruluk başlangıçtan itibaren yapılmalıdır. Eğer bir geliştirici bunu başaramazsa, programla eşleştirmelerini veya tüm ekiple bir plan oluşturmalarını sağlayın, ancak bunu daha sonradan ekleyebileceğiniz bir şey olarak değerlendirmeyin.

Kod incelemesinin çok zor olduğunu düşünüyorsanız, kırmadan değiştirmesi neredeyse imkansız olan kırılgan kodu değiştirdiğinden, bir sorun yaşarsınız. Ancak sorun kod incelemesinde değildir. Problem ünite testlerinde de geçerli değildir, çünkü kırılgan kod ünite testinde kullanılamaz! Eğer kodunuz test edilebilir bir cihaz olsaydı, küçük, bağımsız birimlere bölünmüş, her biri test edilebilecek ve birlikte iyi çalışacaktı ve tam olarak sahip olmadığınız şey buydu!

Öyleyse çöp kodunuz (aka "teknik borç") var. Yapabileceğiniz en kötü şey, bu çöp kod yığınını düzeltmeye başlamak ve işi bitirmemek çünkü bu şekilde çöp kodundan daha da büyük bir yığın elde edersiniz. Yani ilk şey yönetimi bunu tamir etmek için satın almak için ve işi bitirmek için. Yoksa yapmazsın. Bu durumda sadece ona dokunma.

Düzeltdiğinizde, bir birimi koddan ayıklayın, iyi tanımlanmış ve iyi belgelenmiş davranışa sahip bir şey haline getirin, o birim için birim sınamaları yazın, kod gözden geçirin ve hiçbir şeyin kırılmaması için dua edin. Ve sonra bir sonraki ünite ile aynı şeyi yaparsınız, vb.

Bu zor bit hataların karşılaştığında geliyor. Sıçanlarınız kod yuvalarında bazı durumlarda yanlış şeyler yapar, çünkü işler çok kırılgan ve karmaşıktır, işler ters gidecektir. Birimleri çıkardıkça, kalan kod daha net hale gelecektir. (Bazı yeniden yapılandırma işlemlerinden sonra, "if (condition1 && condition2 && condition3) crash ();" işlevinin başladığı, "ref (condition1 && condition2 && condition3) crash ();" ile başlayan bir durum vardı; bu, refactoring işleminden önce tam olarak davranışıydı, ancak daha netti. Sonra o satırı sildim :-) açıkça tuhaf ve istenmeyen davranışlar, böylece düzeltebilirsiniz. Öte yandan, sen orası olmalı varolan kodun davranışını değiştirmek, böylece) dikkatli yapılması gerekmektedir.

Ne yazık ki, başka bir fincan kahve almak dışında kod inceleme noktasında yapabileceğiniz pek bir şey yok. Bu sorunun asıl çözümü biriktirdiğiniz teknik borcu ele almaktır: kırılgan tasarım, test eksikliği. Umarım, en azından bir çeşit fonksiyonel KG'nız olur. Eğer buna sahip değilseniz, her zaman bazı tavuk kemiği için dua edin.

Eğer arabası / çalışmayan yazılımı ile gemi ve daha sonra bunu düzeltmek için içerik değilseniz, o zaman V & V çaba GEREKEN geliştirme çabası daha uzun!

Eğer mevcut kod kırılgansa, ilk soru "onu değiştirmelisiniz bile mi?" Yönetim, bu kodu yeniden tasarlama ve yeniden uygulama maliyetinin / riskinin, titrek önemsiz yığınını düzeltme maliyetinden / riskinden daha büyük olup olmadığı konusunda bir çağrı yapmalıdır. Eğer bir kereye mahsussa, onu düzeltmek daha kolay olabilir. Gelecekte daha fazla değişiklik yapılması muhtemelse, gelecekte daha fazla acı çekmemek için isabet almak daha iyi bir karar olabilir. Bunu yöneticinizle birlikte yükseltmeniz gerekiyor, çünkü yöneticilerinize iyi bilgi vermek işinizin bir parçası. Bu kararı vermeleri gerekiyor, çünkü bu sorumluluk seviyenizin üstünde bir stratejik karar.

Tecrübelerime göre, söz konusu sistemde herhangi bir değişiklik yapılmadan ÖNCE, kodunuzu hem birim hem de entegrasyon olarak adil bir miktar testle örtmenizi şiddetle tavsiye ederim. Günümüzde, bu amaç için çok iyi sayıda araç olduğunu, geliştirdiğiniz dilin önemli olmadığını hatırlamak önemlidir.

Ayrıca, entegrasyon testlerinizi yaratmanız için tüm araçların aracı da var. Evet, konteynerlerden ve özellikle Docker ve Docker Compose'dan bahsediyorum . Altyapı (veritabanı, mongodb, kuyruk sunucuları vb.) Ve uygulamalarla karmaşık bir uygulama ortamını hızla kurmanın bir yolunu sunar.

Araçlar mevcut, onları kullanın! :)

Henüz neden bahsedilmediğini bilmiyorum ama bu 2 en önemli parça:

• Değişimciyi, birbiri ardına gözden geçireceğiniz, daha küçük değişmezler haline getirdiniz. *
• Bir changelistin incelemesi, changelistin iyi göründüğü kararına yol açmazsa, açıkçası değişikliği reddedersiniz.

* Örnek: A kütüphanesini B kütüphanesiyle değiştiriyorsunuz. Bir değişmez kütüphane B'yi tanıtıyor, çeşitli farklı değişmezler A'nın B parçalarını parça parça (örneğin, modül başına bir değiştirici) ve son değişmez kütüphane A'yı siliyor.

Elinden gelenin en iyisini yapın ve yalnızca herhangi bir açık noktayı tespit etmeye çalışın (belki de bu, yine de hedeflemesi gereken en fazla kod incelemesidir)?

Kod revizyonlarının potansiyel değerini küçümsemeyin. Hata tespitinde iyi olabilirler:

• Test olsa da tespit edilmesi zor olabilecek hataları bulun
• Test ederken tanımlanması / düzeltilmesi zor olan hataları bulun

Ayrıca başka nedenlerle de kullanışlıdırlar:

• Ekip üyelerinin çapraz eğitilmesinde yardım
• Kodun diğer kalite ölçütlerini karşıladığından emin olmak için yardım;

Bu durumda ne yapmalı?

En iyi / ideal durumda, kod denetimini geçmek sadece "bariz hata yok" anlamına gelmez: "bariz hata yok" anlamına gelir (elbette siz de test etmek istersiniz).

Yeni kod tabanını kod denetimi yoluyla doğrulayamıyorsanız, daha kapsamlı bir "kara kutu" testi gerekir. Denetlemeden geçtikten sonra üretime kod koyduğunuz bir geliştirme döngüsüne alışmış olabilirsiniz ancak denetimden geçemezse, "üretime geçiremezsiniz" ve daha uzun bir döngüye ihtiyaç duyar: örneğin entegrasyon testleri , sistem testleri, alfa testleri, kabul testleri, beta testleri vb.

değiştirilen parçalı kod için kapsamlı bir birim test paketi mevcut değil ya da birim testler uygulanamaz

Peki ya entegrasyon, sistem ve kabul testleri?

Her neyse, büyük olasılıkla proje yöneticisine ve ürün yöneticisine, kodun bilinmeyen sayıda hatayla birlikte neredeyse kesinlikle hatalı olduğunu; ve sadece "beklediklerini" almak yerine "teftiş ettiklerini" elde edeceklerdir - yani kod kalitesinin testlerinden daha iyi olmadığı (çünkü kod kalitesi test edilemediğinden ve garanti edilemediğinden) .

Muhtemelen bu mesajı müşteriye ya da kullanıcılara iletmelidirler, bu nedenle beta testi yaparlar (erken evlat edinmeye istekliyseler) ya da yeni sürümü beta dışı olana kadar eski sürümü kullanırlar (eğer değilse).

Uygun kod incelemesi yapılmadan bol miktarda kod yazılır ve birleştirilir. İşe yarayabilir. Kod kokusunun "bozuk kod" değil ya da bunun için bir şey olmasının bir nedeni var. Kod incelemesinin eksikliği bir kıyamet habercisi değil, bir uyarı işaretidir.

Bu sorunun çözümü, bir StackExchange tarzı cevapta toplayabileceğimiz tüm vakalara uyacak tek bir çözüm bulunmamasıdır. Yazılım geliştirme topluluğunun güçlü fikir birliği, kod incelemesinin çok önemli bir "en iyi uygulama" olduğu ve bu durumda atlandığı. Gelişiminiz artık "tüm en iyi uygulamaları takip etme" nin bu dar kanalında değil. Kendi yolunu bulman gerekecek.

Zaten "en iyi uygulama" nedir? Bunu hemen anladığınızda, insanların genellikle kodu daha iyi hale getirdiğini düşündüğü bir dizi uygulama. Kodu doğru mu yapıyorlar? Heck hayır! İnternet, "en iyi uygulamaları" izleyen ve kendilerini zorlayan şirketlerden gelen hikayelerle doludur. Belki de "en iyi uygulamalar" ın daha iyi bir bakış açısı, yazılım dünyasının "ateş ve unut" çözümleri olduğudur. Şirketiniz, projeniz, ekibiniz hakkında hiçbir şey bilmiyorum ve size yardımcı olacak şeyler olarak "en iyi uygulamaları" ortadan kaldırabilirim. Bunlar genel "zarar verme" tavsiyesidir.

Bu plandan açıkça saptınız. Neyse ki, onu tanıdın. Aferin! Bilginin savaşın yarısı olduğunu söylüyorlar; öyleyse, farkındalık bunun yarısından fazlasıdır! Şimdi bir çözüme ihtiyaç var. Açıklamanızdan, içinde bulunduğunuz iş ortamının, "kod incelemesini yapın, en iyi uygulama" nın sıkıcı tavsiyelerinin kesmeyeceği bir noktaya geliştiği açıktır. Bunun için, yazılım en iyi uygulamalarına gelince kullandığım bir anahtar kural öneririm:

Hiçbir yazılım geliştirme en iyi uygulama bir iş ihtiyacını aşmaz.

Açıkçası, maaşınızı ödüyorlar ve işin hayatta kalması tipik olarak yazılımın kalitesinden çok daha önemli. Kabul etmekten hoşlanmıyoruz, ancak mükemmel bir şekilde yazılmış yazılımı sürdürme çabalarından dolayı bir şirketin bünyesinde sıkışıp kalması durumunda, mükemmel bir şekilde yazılmış bir yazılım kullanışsızdır.

Peki nereye gidiyorsun? Güç izini takip et. Belirsiz bir nedenden ötürü, bazı görevler için bir kod incelemesinin yapılmasının makul olmadığını belirttiniz. Tecrübelerime göre, bu sebep her zaman geçicidir. Her zaman ya "yeterli zaman" ya da "zaman harcadığınızda maaşların akmasını sağlamak için yeterli para" değildir. Bu iş; sorun değil. Kolay olsaydı herkes yapardı. Güç izini yukarı doğru takip edin ve kod incelemesinin neden bir seçenek olmadığını anlamanıza yardımcı olacak konumda bulun . Dil zordur ve çoğunlukla bir kararname üst yönetimden ayrılır ve çarpıtılır. Sorununun çözümü bu çarpıtmada gizlenmiş olabilir.

Bunun cevabı, mutlaka belirli bir vaka senaryosudur. Bir madeni para atmanın kafa mı yoksa kuyruk mu olacağını tahmin etmeye çalışmak gibi. En iyi uygulamalar 100 kez çevirdiğini söyler ve beklenti yaklaşık 50 kafa ve 50 kuyruk olacaktır, ancak 1 kez çevirmek için zamanınız yok. Durumunuzun detayları burada önemlidir. Bir madalyonun tipik olarak, zamanın yaklaşık% 51'inden attığı aynı yönde ineceğini biliyor muydunuz? Madalyonun fırlatılmadan önce ne şekilde olduğunu gözlemlemek için zaman ayırdınız mı? Bir fark yaratabilir.

Kullanabileceğiniz genel bir çözüm, kod inceleme sürecini çizmenin bir yolunu bulmaya çalışmak ve çok düşük maliyetli bir çaba göstermektir. Bir kod inceleme sürecinin maliyetinin büyük bir kısmı, herkesin kod incelemesine% 100 oranında adanmış olmasıdır. Durum böyle olmalı, çünkü kod incelemesi yapıldıktan sonra kod kutsanmış olur. Belki de kodu farklı bir şubeye koyabilir ve ana bagajdaki gelişmeye paralel olarak kod incelemesini yapabilirsiniz. Veya yazılımın sizin için testi yapması için bile ayarlayabilirsiniz. Belki de müşterilerinizin eskisine paralel "yeni" kodları çalıştırabilecekleri ve sonuçları karşılaştırabilecekleri bir iş ortamındasınızdır. Bu, müşterileri bir sürü kullanım çantası yaratma cihazına dönüştürür.

Tüm bu çalışan "maybes" in bir anahtarı, kodunuzu kolayca parçalara ayırmak için çaba göstermeniz gerektiğidir. Kritik projelerde daha az görev kullanarak bunları kullanarak resmi bir kod incelemesine dayanmadan kodun parçalarını "ispatlayabilirsiniz". Değişiklikler daha küçük parçalarda ise, toplamları akran incelemesi için çok büyük olsa bile, bunu yapmak daha kolaydır.

Genel olarak, projenize, şirketinize ve ekibinize özgü çözümleri arayın. Genel amaçlı cevap "en iyi uygulamalar" idi. Bunları kullanmıyorsunuz, bu kez bu soruna özel uyarlanmış çözümler aramalısınız. Bu iş. Her şey her zaman beklediğimiz gibi olsaydı, halka arzlar değer atamak çok daha kolay olurdu, değil mi!

Bir kod incelemesini değiştirmek bir mücadele ise, kod incelemesinde işe yaradığı kanıtlanmış bir kod parçası olmadığına dikkat edin. * Tüm kod incelemeleri, size kod konusunda güven vermek ve düzeltmeler yapmak için bir fırsattır. Onlar bir problem haline gelmeden önce. Bir kod yorum bu değerli ürünlerin ikisi de olabilir başka yollarla elde edilebilir. Kod incelemesi, özellikle bu konuda iyi olduğu için tanınmış bir değere sahiptir.

* Neredeyse: L4 mikro çekirdeği bir süre önce bir kod incelemesi aldı, bir uyumlu C ++ derleyicisi tarafından derlenirse, kodunun tam olarak ne yapacağını kodunu ispatlayan otomatik bir kontrol sistemi tarafından.

@EricLippert'in mükemmel cevabına işaret ettiği gibi, bu tür bir değişimin daha az değil, daha fazla dikkat gerektirmesi gerekir . Üzerinde çalıştığınız bir değişikliğin böyle bir değişiklik olacağının farkına varırsanız, yardımcı olabilecek birkaç strateji vardır:

• Sık sık sürüm kontrolüne geçin. İnceleme, taahhüt bazında ilerleme sağlayabilir ve daha küçük kararlarınız olduğunda daha anlaşılabilir olabilir.
• Her değişikliğin nedenlerini mümkün olduğunca net bir şekilde yorumladığınızdan emin olun.
• Mantıklıysa, bu tür bir değişiklik için çift programlama kullanın. Bu konuda 2 yerine üç göze sahip olmak, normal olarak gözden kaçabilecek sorunlardan kaçınmaya yardımcı olabilir ve çalışırken bir çiftin olması , bariz olduğunu düşündüğünüz ancak daha az belirgin olduğu düşünülen kodla ilgili yorumları geliştirmenize yardımcı olabilir inandıktan sonra, daha sonra gözden geçirene daha sonra yardım edecek. (A) gelişim sırasındaki hataları azaltma ve (b) iyileştirilmiş dokümantasyon yardımı , daha fazla insanın dahil olmasına rağmen, buna daha az adam saati harcanması anlamına gelebilir .

Daha fazla cevap bu noktaya nasıl ulaştığınızı ele alıyor. Birçoğu durumu düzeltmek için bazı önerilerde bulunuyor, ancak kısa cevabı vermek için cevabımı vermek istiyorum.

Kod incelemeleri "çok zor" olduğunda ne yapmalı?

1. Ana satır kod dalına geri dönün
2. Etkilediğiniz işlevsellik için testler yaz
3. Geçecek testleri al
4. Testleri "test etmesi zor" olan bir kodda birleştirin
5. Testler hala başarılı mı?

Evet

Siz geliştiriciler harikaydınız! Herkes için geri kediler!

(veya ABD televizyonunda " The Simpsons " ı izleyerek büyümemiş olanlar için : Testler geçiyorsa, farklılıklara bakmaya çalışın ve geliştiricinin sizi bir değişiklik turunda size yönlendirmesini isteyin)

Hayır

Testleri geçinceye kadar yeniden düzenlemeye ve test kapsamı eklemeye devam edin .

Bir çarpma gibi, kod incelemesi sıfıra uygulandığında sıfır sonuç verir. Bu durumda değeri artırmaz, diğer durumlarda ise bunu arttırır.

Çalışmanız gereken kod, daha fazla geliştirme sırasında kod inceleme sürecinden yararlanmak için çok kötü bir şekilde tasarlanmıştır. Yeniden incelemek veya yeniden geliştirmek için kod inceleme işlemini kullanın.

Ayrıca, kod hala katlanılabilir olabilir ama görev iyi değil. Çok geniş ve daha küçük artışlarla yapılmalıydı.