Kod işlemeden önce veya sonra gözden geçirin, hangisi daha iyi?

Geleneksel olarak taahhütten önce kod incelemesi yaptık, bugün meslektaşımla, karardan sonra kod incelemesini tercih eden bir tartışma yaptım.

İlk olarak, işte bazı arka plan

1. Bazı deneyimli geliştiricilerimiz var ve aynı zamanda neredeyse sıfır programlama deneyimi olan yeni elemanlarımız da var.
2. Ürünümüzü serbest bırakmak için hızlı ve kısa tekrarlamalar yapmak istiyoruz.
3. Tüm ekip üyeleri aynı sitede bulunur.

Karar vermeden önce kod incelemesinin avantajları öğrendim:

1. Mentor yeni işe alımlar
2. Geliştirme döngüsünün başında hataları, hataları ve kötü tasarımları önlemeye çalışın
3. Diğerlerinden öğrenin
4. Birisi çıkarsa bilgi yedekleme

Ama aynı zamanda bazı kötü deneyimlerim oldu:

1. Düşük verimlilik, bazı değişiklikler günler içinde gözden geçirilebilir
2. Özellikle yenidoğanlar için hız ve kaliteyi dengelemek zor
3. Bir takım üyesi güvensizlik hissediyordu

Taahhüt sonrası incelemeyle ilgili olarak, bu konuda çok az şey biliyorum, ancak en çok endişelendiğim konu inceleme eksikliği nedeniyle kontrolü kaybetme riski. Herhangi bir görüş?

GÜNCELLEME:

1. VCS için Performans kullanıyoruz
2. Aynı branşlarda kodlar ve taahhüt ederiz (ana hat veya hata tespit eden dallar)
3. Verimliliği artırmak için, kodu küçük değişikliklere bölmeye çalıştık. Ayrıca bazı canlı iletişim incelemelerini de denedik, ancak herkes kurallara uymuyordu. Bu olsa da başka bir sorundur.

Gibi Simon Whitehead onun yorumunda bahseder , bu dallanma stratejisi bağlıdır.

Geliştiricilerin geliştirme için kendi özel şubeleri varsa (ki çoğu durumda tavsiye ederim), bagaj veya ana depo ile birleşmeden önce kod incelemesini yaparım. Bu, geliştiricilerin geliştirme / test döngüleri sırasında istedikleri sıklıkta kontrol etme özgürlüğüne sahip olmalarını sağlar, ancak herhangi bir zaman kodu teslim edilen kodu içeren şubeye girerse gözden geçirilir.

Genel olarak, kod incelemeleriyle ilgili kötü deneyimleriniz, çözümleri olan inceleme sürecindeki bir sorun gibi görünmektedir. Kodu daha küçük, tek tek parçalarda inceleyerek, çok uzun sürmemesini sağlayabilirsiniz. İyi bir sayı, bir saat içinde 150 kod kod satırının gözden geçirilebilmesidir, ancak bu oran programlama dilini, geliştirilmekte olan sistemi veya sistemin kritikliğini bilmeyen insanlar için daha düşük olacaktır (kritik bir güvenlik daha fazla zaman gerektirir) - Bu bilgi verimliliği artırmak ve kod incelemelerine kimlerin katıldığına karar vermek için yararlı olabilir.

Henüz kimsenin alıntı yapmadığı bir mantra var: Erken ve sık check-in :

Uzun süre çalışmakta olan ve uzun süre boyunca çalışan geliştiriciler, bir günden daha fazla demek istediğim - kaynak kontrolünü kontrol etmeden, bazı ciddi entegrasyon baş ağrıları için kendilerini ayarlıyorlar. Damon Poole aynı fikirde :

Geliştiriciler genellikle kontrol etmeyi bıraktılar. Diğer insanları çok erken etkilemek istemedikleri ve yapıyı kırdıkları için suçlanmak istemedikleri için kapattılar. Ancak bu, işini kaybetme veya önceki sürümlere geri dönememe gibi diğer sorunlara yol açar.

Temel kuralm "erken ve sık check-in" yapmaktır, ancak özel versiyonlamaya erişiminiz olduğu konusunda uyarınız. Check-in anında diğer kullanıcılar tarafından görülebiliyorsa, o zaman olgunlaşmamış değişiklikleri uygulama ve / veya yapıyı bozma riskiyle karşı karşıya kalırsınız.

İş arkadaşlarımın ne yazdığı ne olursa olsun hiçbir fikrim olmadan uzun süreler kullanmak yerine periyodik olarak küçük parçaları kontrol etmeyi tercih ederim. Endişelendiğim kadarıyla , kod kaynak kontrolünde kontrol edilmemişse, mevcut değil . Sanırım bu bir daha Go Go-Dark'ın bir biçimi değil ; Kod, depoda bir şekilde var olana kadar görünmez.

... Erken check-in yapmayı ve sık sık check-in yaptırmayı öğrenirseniz, geri bildirim, entegrasyon ve gözden geçirme için yeterli zamanınız olur.

Bu konuda farklı yaklaşımları olan birkaç şirket için çalıştım. Biri derlemeyi engellemediği sürece izin verdi. Diğer hataları kontrol edersen diğeri çıldırırdı. İlki çok tercih edilir. Her şeyin daha sonra test edileceği anlayışıyla, halen devam etmekte olan şeyler konusunda diğer insanlarla işbirliği yapmanıza izin verecek bir ortamda gelişmelisiniz.

Jeff Atwood'un ifadesi de var: Bir şeyleri kırmaktan korkmayın :

Bir yazılım geliştiricisi olarak geliştirmenin en doğrudan yolu, kodunuzu değiştirme konusunda kesinlikle korkusuz kalmaktır. Kodlardan korkan geliştiriciler, asla profesyonellere erişemeyecek geliştiricilerdir.

Akran değerlendirmeleri için, birileri bir şeyi değiştirmenizi isterse, orijinal sürümünüzün kaynağında geçmişinin olması çok değerli bir öğrenme aracıdır.

Kısa bir süre önce içinde bulunduğum bir projede ön değerlendirme yapmaya başladım ve söylememeliyim ki ne kadar problemsiz olduğu konusunda çok şaşırdım.

Gördüğüm taahhüt sonrası incelemelerin en büyük dezavantajı, genellikle tek kişili bir haksızlık olduğu: Biri doğruluk kodunu gözden geçiriyor , ancak ciddi bir hata olmadığı sürece yazar genellikle yer almıyor. Küçük problemler, öneriler veya ipuçları genellikle yazara hiç ulaşmaz.

Bu aynı zamanda kod incelemelerinin algılanan sonuçlarını da değiştiriyor: herkesin (kodun yazarı ve yazarı) her zaman yeni şeyler öğrenebileceği bir şeyin tersine, yalnızca ek iş üreten bir şey olarak görülüyor.

İşleme öncesi kod incelemeleri o kadar doğal görünüyor ki, incelemeler bittikten sonra bilerek yapılabileceği hiç aklıma gelmedi. Sürekli bir entegrasyon perspektifinden bakıldığında, kodunuzu işlendikten sonra, ancak muhtemelen kötü yazılmış bir durumda değil, tamamlandıktan sonra yapmak istersiniz, öyle değil mi?

Belki de bunu ekiplerimde her zaman yapma şeklimiz, asenkron, kontrol odaklı, doküman tabanlı incelemeler değil, orijinal geliştirici tarafından başlatılan canlı iletişim kutusudur.

Günümüzde depoların çoğu iki aşamalı bir taahhüdü veya bir rafı (özel şube, çekme talebi, düzeltme eki gönderimi veya ne demek istersen) desteklemektedir; Bu araçları kullanmanın her zaman ön değerlendirme yapmanıza izin vereceğini söyleyebilirim.

Ayrıca, yerleşik bir kod incelemesi sağlamanın başka bir yolu olarak çift kodlamayı (junior ile üst düzey çiftler) düşünebilirsiniz. Araba devirmek yerine montaj hattında kalite kontrolü olarak kabul edin.

İkisinide yap :

• Önceden taahhütte bulunun - bu tür incelemeleri çok önemli bir şey olduğunda, çok tekrar kullanılabilir bir kod parçası veya büyük tasarım kararı gibi yapın.
• taahhütte bulunma - geliştirilebilecek bir kod parçası hakkında fikir edinmek istediğinizde bu tür bir inceleme yapın

Yapılandırma kontrolü altındaki kaynak dosyalar üzerinde herhangi bir resmi inceleme yapılmalı ve inceleme kayıtları dosyanın revizyonunu açıkça ifade etmelidir.

Bu, "son dosyaya sahip değilsin" türündeki argümanları önler ve herkesin kaynak kodun aynı kopyasını incelemesini sağlar.

Ayrıca, inceleme sonrası düzeltmeler yapılması gerektiğinde, tarihin bu gerçeğe açıklanabileceği anlamına gelir.

Kod incelemesinin kendisi için oyum, taahhüt sırasında 'oy verme' içindir.

Gerrit veya yonca gibi bir sistem (bence) bir değişiklik yapabilir ve daha sonra gözden geçirene kaynak kontrolüne (git içinde itme) karar vermesini sağlayabilir. Her iki dünyanın da en iyisi bu.

Bu pratik değilse, taahhüt ettikten sonra en iyi uzlaşma olduğunu düşünüyorum. Eğer tasarım iyi ise o zaman sadece en genç geliştiriciler, daha önce işlenmesini istemediğiniz kadar kötü şeylere sahip olmalıdır. (Onlar için ön değerlendirme yapınız).

Bu, tasarım incelemesine yol açar - kod inceleme zamanında (veya müşteri dağıtım zamanında bu konuda) yapabileceğiniz halde, tasarım sorunlarının daha önce yapılması gerekir - kod gerçekten yazılmadan önce.

Hakem incelemesinde kontrolün kaybedilmesi riski çok düşüktür. Her zaman iki kişi aynı kod hakkında bilgi sahibi olur. Zaman zaman geçiş yapmaları gerekir, bu yüzden kodu takip etmek için her zaman dikkatli olmaları gerekir.

Birlikte çalışan yetenekli bir geliştirici ve bir acemi sahip olmak mantıklı. İlk bakışta bu verimsiz görünüyor, ama değil. Aslında, daha az hata var ve bunları düzeltmek için daha az zaman alıyor. Ayrıca, yeni başlayanlar çok daha hızlı öğrenecekler.

Kötü tasarımın önlenmesine gelince, kodlamadan önce bu yapılmalıdır. Kayda değer bir değişiklik / iyileştirme / yeni tasarım parçası varsa, kodlama başlamadan önce gözden geçirilmelidir. Tasarım tamamen geliştiğinde, yapacak çok şey kalmaz. Kodu incelemek daha kolay olacak ve daha az zaman alacaktır.

Yalnızca, daha önce becerilerini kanıtlamış olan deneyimli bir geliştirici tarafından üretildiyse, taahhüt vermeden önce kodu incelemenin gerekli olmadığını kabul ediyorum. Ancak yeni başlayanlar varsa, söz vermeden önce kod gözden geçirilmelidir: hakem geliştiricinin yanına oturmalı ve her değişiklik veya iyileştirmeyi açıklamalıdır.

İncelemeler hem ön hem de sonraki komisyonlardan yararlanır.

Ön inceleme taahhüdü

• Hakemlere, yazarın son revizyonunu gözden geçirdikleri konusunda güven verir.
• Herkesin aynı kodu incelemesine yardımcı olur.
• Gözden geçirme öğelerinden yapılan revizyonlar tamamlandıktan sonra karşılaştırma için referans verir.

Gözden Geçirme Sırasında Çalışan Taahhüdü Yok

Atlassian araçlarını kullandım ve inceleme sırasında çalışan komisyonların oluştuğunu gördüm. Bu yorumcular için kafa karıştırıcı, bu yüzden karşı tavsiye ederim.

İnceleme Sonrası Revizyonlar

Gözden geçirenlerin geri bildirimlerini sözlü veya yazılı olarak tamamladıktan sonra, moderatör yazarın istenen değişiklikleri yapmasını sağlamalıdır. Bazen gözden geçirenler veya yazar bir gözden geçirme maddesini bir hata mı, öneri mi yoksa bir soruşturma olarak mı belirleyeceği konusunda hemfikir olabilir. Anlaşmazlıkların giderilmesi ve soruşturma maddelerinin doğru şekilde temizlendiğinden emin olmak için, inceleme ekibi moderatör kararına bağlıdır.

Yaklaşık 100 kod incelemesiyle ilgili deneyimim, hakemler net bir kodlama standardına atıfta bulunabilirken ve çoğu mantık ve diğer programlama hataları için inceleme sonuçlarının genel olarak kesinti olduğu yönündedir. Nadiren nitelemeyle ilgili bir tartışma vardır ya da bir stil noktası tartışmaya yol açabilir. Ancak, moderatöre karar verme yetkisi, çıkmazdan kaçınır.

İnceleme Sonrası Komisyon

• Moderatör ve diğer hakemlere ön inceleme kararıyla karşılaştırması için bir veri noktası verir.
• Kusur giderme ve kod iyileştirmedeki incelemenin hem değerini hem de başarısını değerlendirmek için ölçütler sağlar.

Takımının makyajına bağlı. Küçük, sıkça yapılan taahhütler konusunda iyi olan nispeten deneyimli bir ekip için, daha sonra sadece kodun ikinci bir çiftini görmek için inceleme sonrası değerlendirme yapılır. Daha büyük, daha karmaşık taahhütler ve / veya daha az deneyimli geliştiriciler için, daha önce sorunları çözmeden önce düzeltmek için incelemelere önceden karar vermeden daha tedbirli görünmektedir.

Bu hatlar boyunca, iyi bir CI sürecine ve / veya girişli girişlere sahip olmak, taahhütte bulunmadan önce gözden geçirme ihtiyacını azaltır (ve tartışmasız da çoğu için taahhütte bulunur).

Ben ve meslektaşlarım son zamanlarda bu konuda bazı bilimsel araştırmalar yaptık, bu yüzden oldukça eski bir soru olmasına rağmen içgörülerimizden bazılarını eklemek isterim. Çevik bir Kanban gelişim süreci / ekibinin simülasyon modelini oluşturduk ve çok sayıda farklı durum için (farklı takım üyeleri, farklı beceri düzeyleri, ...) ön taahhüt ve sonrasındaki incelemeleri karşılaştırdık. 3 yıllık (simüle edilmiş) geliştirme süresinden sonra sonuçlara baktık ve verimlilik (bitmiş hikaye puanları), kalite (müşteriler tarafından bulunan hatalar) ve döngü süresi (bir kullanıcı hikayesinin başlangıcından teslimatına kadar geçen süre) arasındaki farkları aradık. . Bulgularımız aşağıdaki gibidir:

• Verimlilik ve kalite açısından farklılıklar birçok durumda önemsizdir. Olmadıklarında, taahhüt sonrası inceleme, kalite açısından bazı avantajlara sahiptir (diğer geliştiriciler bir şekilde "beta-test edici" olarak hareket eder). Verimlilik için, görevlendirme sonrası küçük ekiplerde bazı avantajlar sağlar ve ön işlemelerin büyük veya vasıfsız ekiplerde bazı faydaları vardır.
• Taahhüt öncesi inceleme, bağımlı görevlerin başlamasının incelemede geciktiği bir durum olduğunda daha uzun döngü sürelerine yol açabilir.

Bunlardan aşağıdaki sezgisel kuralları türetdik:

• Belirlenmiş bir kod inceleme süreciniz olduğunda, değiştirme zahmetine girmeyin, muhtemelen bu çabaya değmez
  • Döngü süresi ile ilgili problemleriniz yoksa =
  • Veya kaymış sorunlar, geliştiricilerinizi çok sık bozar => Pre'e Geçin
• Henüz inceleme yapmıyorsanız
  • Bu avantajlardan biri sizin için geçerliyse ön taahhüt kullanın
    • Taahhüt öncesi inceleme, açık kaynaklı projelere katkıda bulunma taahhüdüne sahip olmayan yabancılara izin verir
    • Eğer araç-temelli ise, ön değerlendirme gözden geçirme aksi taktirde işleme bağlılığı olan takımlarda bazı inceleme disiplinlerini zorlar
    • Taahhüt öncesi inceleme, gözden geçirilmeyen değişikliklerin teslim edilmesini kolayca önler, bu da sürekli dağıtım / çok kısa sürüm döngüleri için temizdir
  • Ekibiniz büyükse ve döngü süresinde sorunları yaşayabilir veya önleyebilirsiniz.
  • Aksi taktirde (örneğin küçük, yetenekli endüstriyel ekip) görev sonrası
• Her iki dünyanın da faydalarını sağlayan kombinasyonları arayın (bunları resmi olarak çalışmadık)

Araştırma belgesinin tamamına buradan ulaşabilirsiniz: http://dx.doi.org/10.1145/2904354.2904362 veya web sitemde: http://tobias-baum.de

Bence, kod emri incelemesi taahhüt sonrası yapılırsa en iyisidir.

Dallanma stratejinizi ayarlamanızı tavsiye ederim. Bir geliştirici şubesi veya özellik şubesi kullanmanın, birçoğunun işlem sonrası kod incelemelerini kolaylaştırmayan pek çok avantajı vardır.

Pota gibi bir araç inceleme sürecini yumuşatır ve otomatikleştirir. Gözden geçirmeye dahil etmek için bir veya daha fazla taahhüt edilen değişiklik kümesi seçebilirsiniz. Pota, seçilen değişiklik setlerinde hangi dosyalara dokunduğunu gösterecek, her gözden geçiricinin hangi dosyaları okuduğunu (genel olarak% bir tam gösteriliyor) izleyecektir ve hakemlerin kolayca yorum yapmasına izin verecektir.

http://www.atlassian.com/software/crucible/overview

Kullanıcı / özellik dallarının diğer bazı yararları:

• Geliştiriciler, sistemi herkesin kırması konusunda daha az endişe duydukları için sürüm kontrolünün (değişiklikleri yedekle, geçmişi geri yükle, değişiklik değişiklikleri) faydalarından yararlanır.
• Kusurlara neden olan veya zamanında bitmeyen değişiklikler, gerektiğinde geri alınabilir, yeniden önceliklendirilebilir veya rafa çekilebilir.

Deneyimsiz geliştiriciler için, bir danışman ve / veya çift programlamaya düzenli danışmak iyi bir fikirdir, ancak bunun bir "kod incelemesi" olduğunu düşünmüyorum.

Her ikisi de. (Türü.)

Kabul etmeden önce kendi kodunuzu özetlemelisiniz. Git'te evreleme alanının harika olduğunu düşünüyorum. Değişikliklerimi düzenledikten sonra git diff --cached, sahnelenen her şeyi görmek için koşuyorum . Bunu ait olmayan herhangi bir dosyayı kontrol etmediğimden (yapı, günlükler vb.) Kontrol etmediğimden ve hata ayıklama kodum olmadığından veya yorum yaptığım önemli bir kod olmadığından emin olmak için bir fırsat olarak kullanıyorum dışarı. (Teslim etmek istemediğimi bildiğim bir şey yapıyorsam, genellikle tüm başlıklara bir yorum bırakarım, böylece sahneleme sırasında tanıyacağım.)

Bir akran kodu incelemenizin genellikle bir konu dalında çalıştığınızı varsayarak, taahhüt ettikten sonra yapılması gerektiğini söylemiştiniz. Bu, diğer herkesin doğru olanı gözden geçirdiğinden emin olmanın en kolay yoludur ve büyük sorunlar varsa, o zaman şubenizi düzeltmek veya silmek ve yeniden başlamak önemli bir şey değildir. Zaman uyumsuz olarak kod incelemeleri yaparsanız (yani Google Code veya Atlassian Crucible kullanarak), o zaman birkaç gün boyunca incelemekte olduğunuz tüm farklı yama / farklarınızı ayrı ayrı takip etmek zorunda kalmadan şubeleri kolayca değiştirebilir ve başka bir konuda çalışabilirsiniz.

Bir konu dalında çalışmıyorsanız, yapmanız gerekir . Stresi ve zahmeti azaltır ve serbest bırakma planlamasını çok daha az stresli ve karmaşık hale getirir.

Düzenleme: Ayrıca, testten sonra kod incelemesi yapmanız gerektiğini de eklemeliyim; bu, ilk önce kod işleme lehine olan bir başka argümandır. Test grubunuzun tüm programcılardan düzinelerce yama / farkla uğraşmasını istemez, ardından yanlış yamayı yanlış yere uyguladıkları için hataları doldurmazsınız.

% 100 eşleştirilmiş programlama (ne kadar yaşlı olduğunuzu düşünürseniz düşünmeyin) çok sayıda küçük komisyon ve EVERY üzerine kurulu bir CI sistemi (birimler, entegrasyon ve mümkün olan her yerde işlevsel olan otomatik testler ile) ile gerçekleştirin. Büyük veya riskli değişiklikler için taahhüt sonrası incelemeler. Bir çeşit kapılı / ön taahhütlü inceleme yaptırmanız gerekiyorsa, Gerrit çalışır.

Giriş sırasında kod incelemesi (arkadaş kontrolü) avantajı, büyük kod parçaları tamamlanmadan hemen önce gelen geri bildirimdir.

Kod incelemesinde check-in işleminin dezavantajı, uzun kod genişletmeleri tamamlanıncaya kadar kişilerin check-in yapmasını engellemesidir. Bu olursa, avantajı tamamen olumsuzlar.

Bunu zorlaştıran şey, her geliştiricinin aynı olmamasıdır. Basit çözümler tüm programcılar için işe yaramaz . Basit çözümler:

• Arkadaşınızın hemen yanında olduğu için sık sık yapılan girişlere izin veren zorunlu çift programlama. Bu, çift programlamanın her zaman herkes için işe yaramadığını görmezden gelir. Düzgün bir şekilde yapıldığında, çift programlama da gerçekten yorucu olabilir, bu nedenle mutlaka tüm gün yapılacak bir şey değildir.

• Geliştirici şubeleri, kodları incelendiğinde ve bitince ana şubede kontrol edilir. Bazı geliştiricilerin gizlilik içinde çalışmaya eğilimli oldukları ve bir hafta sonra daha önce tespit edilebilecek temel problemler nedeniyle incelemeyi geçebilecek ya da geçmeyecek bir kod bulmuşlardır.

• Sık sık yapılan incelemeleri garanti eden her check-in incelemesi. Bazı geliştiriciler unutkandır ve çok sık yapılan girişlere güvenirler, bu da diğerlerinin her 15 dakikada bir kod incelemeleri yapmaları gerektiği anlamına gelir.

• Check-in işleminden sonra belirli bir zamanda gözden geçirin. Son teslim tarihinin sıkışıklığı söz konusu olduğunda değerlendirmeler daha da zorlanacaktır. Zaten işlenen ancak henüz gözden geçirilmemiş kodlara bağlı olan kod işlenecektir. İncelemeler sorunları işaretleyecek ve sorunlar "daha sonra" düzeltilmek üzere biriktirme durumuna getirilecektir. Tamam, yalan söyledim: Bu basit bir çözüm değil, bir çözüm değil. Check-in yapıldıktan sonra belirli bir zamanda gözden geçirin, ancak belirtilen saatin ne olduğuna karar vermeniz gerektiğinden daha az basittir.

Uygulamada, bu işi aynı anda daha da basit ve daha karmaşık hale getirerek yaparsınız. Basit kurallar koyarsınız ve her geliştirme ekibinin bir takım olarak bu kurallara uyması için ne yapmaları gerektiğini bulmasını sağlarsınız. Bu tür kılavuzlara bir örnek:

• Bir günden az sürmesi gereken işlerde iş bozulur.
• Kod (eğer varsa) teslim edilmemişse, görev bitmedi.
• Kod (eğer varsa) incelenmemişse, görev bitmedi.

Bu tür kılavuzların birçok alternatif formu mümkündür. Gerçekte ne istediğinizi odaklayın (meslektaş tarafından gözden geçirilmiş kod, gözlenebilir iş ilerlemesi, hesap verebilirlik) ve ekibin size ne istediklerini nasıl verebileceklerini öğrenmelerine izin verin.

aslında LedgerSMB'de bir melez yapıyoruz. Taahhütçiler daha sonra gözden geçirilmek üzere değişiklik yaparlar. Müteahhit olmayanlar, daha önce gözden geçirilmek üzere müteahhitlere değişiklikler yaparlar. Bu, iki inceleme aşaması anlamına gelme eğilimindedir. İlk önce sizi incelemek ve mentor olmak üzere bir mentor bulun. Daha sonra, bu mentor, kodu imzaladıktan ve geri bildirim yayınlandıktan sonra ikinci kez tekrar gözden geçirir. Yeni müteahhitler genellikle ilk başta diğer kişilerin taahhütlerini gözden geçirmek için çok zaman harcıyorlar.

Oldukça iyi çalışıyor. Yine de bir inceleme sonrası, genellikle daha önce yapılan bir incelemeden daha elverişlidir, bu nedenle incelemenin kendileri kanıtlamış olanlara ayrıldığından emin olmak istersiniz. Ancak, yeni millet için iki aşamalı bir incelemeniz varsa, bu sorunların yakalanma ve tartışmaların daha muhtemel olduğu anlamına gelir.

Nerede olmalısın? İş yapmak için yarattığım bir dal var. Ne zaman istersem o şubeye bağlı kalırım. Kimsenin işi değil. O zaman bir noktada bu dal bir kalkınma dalına entegre edilir. Ve arada bir yerde bir kod incelemesi.

Benim yorumcusu şubeme taahhüt ettikten sonra açıkça gözden geçirir. O benim masada oturan değil, o yüzden taahhüt önce onu gözden olamaz benim şube. Ve o değerlendirmeleri önce birleştirme ve geliştirme dalında taahhüt.

Sadece kod incelemeleri yapma. Geliştiricilerinizin iyi kod yazabildiğine inanıyorsunuz veya onlardan kurtulmalısınız. Mantıktaki hatalar otomatik testleriniz tarafından yakalanmalıdır. Hataların tarz olduğu tüy bırakmayan ve statik analiz araçları tarafından yakalanmalıdır.

İnsanların otomatik süreçlerin ne olması gerektiğine karışması sadece israftır.