Gözden geçirmeyi beklerken ne yapmalıyım?

Sorumu sormadan önce durumu açıklamalıyım.

Küçük yazılım mühendisi olarak bir şirkette çalışıyorum. Yaşlılardan biri, gelişimimi tamamladığımda ve taahhüt etmek istediğimde beni durduruyor.

Her zaman onu incelemesi için beklememi ister. Bu sorun değil, çünkü genellikle bazı hatalar bulur ve bazı optimizasyonlar yapar.

Ancak son tarihten önce kodumu vermeliyim. İşim bitince onu aradım ve bittiğini söyledim. Genelde geç gelir. Yani benim kodum da geç.

Sorum şu, ne yapmalıyım? Bir inceleme için onu beklemeli miyim?

EDIT: soruya eklenmesi. Bir sorun daha merak ediyorum.

Kodlama yaparken özgür olmak istiyorum. Gelişme özgürlüğü güvenini nasıl kazanabilirim?

_{Bazı açıklamalar: Onunla bunun hakkında konuştum. Ama yardımcı olmadı. Zaten bir sorun izleyici kullanıyoruz, ancak incelemeler için herhangi bir görev yok. Sadece geliştirme ve test görevleri var.}

Yani benim kodum da geç.

Hayır, sizin kodunuz değil , sizin ve yaşlıların kodudur . Takım olarak çalışıyorsunuz, ortak bir sorumluluğunuz var ve ikiniz de son teslim tarihini kaçırdığınızda, bu ikinizin de suçu. Son başvuru tarihini belirleyen kişinin bunu fark ettiğinden emin olun. Eğer o kişi bunu bir problem olarak görürse, kesinlikle sizinle ikinizle konuşacaktır - bu sizinle birlikte çalışan bir tek konuşmadan daha çok yardımcı olabilir.

Ve EDIT'inize:

Kodlama yaparken özgür olmak istiyorum. Kalkınma özgürlüğü için nasıl güven kazanabilirim?

Kodları incelemek en önemli kalite koruyuculardan biridir. 20 yıldan fazla programlama tecrübesi olsa bile, ikinci bir çift göz olmadan mükemmel bir kod yazmak neredeyse imkansız. Bu yüzden iyi bir takımda herkesin kodu sürekli gözden geçirilmelidir - kıdemli kodunuz ve kodunuz. Bunun şahsen size karşı güvensizlikle ilgisi yoktur (veya en azından olmamalıdır). İkinci bir çift göz olmadan "serbest kodlamanın" daha iyi olduğuna inandığınız sürece, hala küçük bir programcısınız.

İyi bir takımda, bir sorun izleyicide size atanmış bir geliştirme görev sırası olmalıdır .

Bu şekilde, bir gözden geçireni beklerken, sırada bekleyen bir sonraki görev üzerinde çalışmanız gerekir ( gerekir ). Bu şekilde çalışmaya alışmaya başladığınızda, bu değişikliklerin "partiler" te incelenmesini sağlayarak gecikmeleri azaltacaktır.

• ^{Eğer böyle bir "sıranız" yoksa, bunu yöneticinizle veya daha iyisi inceleme uzmanıyla görüşün. Ekibiniz böyle şeyler için makul bir sorun izleyiciye sahip değilse, daha iyi bir ekip bulmak için iş kurullarını veya şirket içi iş fırsatlarını incelemeyi düşünün (bunu ayrıca müdür / gözden geçirenle de tartışabilirsiniz, ancak bunun yardımcı olmasını beklemeyin - eksik iyi bir sorun izleyici genellikle bir takımda ciddi bir şekilde kırılan bir şeyin belirtisidir).}

Kodlama yaparken özgür olmak istiyorum. Kalkınma özgürlüğü için nasıl güven kazanabilirim?

Bunu anlamak için önce kod incelemelerinin amacını anlamanız gerekir. Sen söz güveni iyi "yaklaşım", ama tamamen doğru değil - bir.

• ^{Örneğin, son projelerimden birinde, ben ve meslektaşımın küçük bir ekibi tarafından gelişme kaydedildi. Tamamen karşılıklı güvendik ve birbirimize saygı duyduk - ancak buna rağmen kodun% 100'ünü inceledik. Bunu yapıyorduk, çünkü bu bazı hataları bulmamıza ve hızlıca düzeltmemize izin verdi ve bu da çok önemli, çünkü incelemeler çok zaman almadı ve çalışmalarımızı engellemedi.}

Gördüğünüz gibi, belirli riskleri önlemek için harcanan çabalar bakımından kod incelemelerini düşünmek daha doğru olacaktır . İyi bir takımda, bunun "nasıl düzgün bir şekilde dengelenmesi" konusunda ortak bir anlayış anlayışı bekleyebilirsiniz. Tek bedene uyan tüm uygun dengenin olmadığını unutmayın, bu büyük ölçüde bir projeye bağlıdır - kritik bir yazılımda hataların riski ve etkisi doğal olarak kritik olmayan uygulamalardakinden farklıdır.

Örneğinizi kullanarak, incelemeciniz tarafından yatırılan çabalar , kodunuzu vermeden önce düzeltilmesi gereken daha iyi düzeltilen hatalar ve iyileştirmeler bularak haklı olduğu sürece "incelemeleri engellemeyi" bekleyebilirsiniz .

Muhtemelen uygulamalarda ve incelemelerde edinilen kılavuzlarla kodlamada daha iyi olacağınızı, böylece taahhütte bulunmadan önce düzeltmeye değer daha az sorun bulabileceklerini umuyorlar. En kısa sürede onlar kod az hantal "Risk önleme tedbirleri" izin vermek "güvenli yeterince" var olduğunu fark gibi, sen örneğin değişim süreci, beklenebileceğini tamamlamak sonra değerlendirme .

Bir projeye bağlı olarak, bir noktada kodunuzun değerlendirmeleri gözden geçirecek kadar güvenli olduğu düşünülebilir, böceklerin keşfedilmesi test edicilere bırakılır (ancak bu mutlaka gerçekleşmez, yukarıdaki örneğime bakın).

Sorununuzun tam olarak ne olduğuna bağlı olarak, burada birkaç olası cevap vardır.

• En büyük endişeniz "Son tarihleri ​​özlüyorum" ise, hayır. İkiniz birlikte ortak teslim tarihleriniz eksik. (Güvenle) "Bir saat içinde çalışacağım, kod incelemesini yapabilir miyiz" diyebilir misiniz? Bu yeterli olabilir. Son başvuru tarihinden bir gün önce kodu tamamlayabilir misiniz? Bu bol miktarda tampon olmalı. "Lütfen gözden geçirin" ile son tarih arasında çok fazla arabellek ile kodunuzu mu dolduruyorsunuz? İkincisi, ortak bir hata bile olmazsa, derdim.

• Kod her zaman gözden geçirilmelidir. Hiçbir şey (en azından) ikinci bir göz seti ve "tamam" olan bir başka insan olmadan kontrol edemiyorum. Bu, benim öncü programcı olduğum projeler için olduğu kadar normalde katkıda bulunmadığım projeler için de geçerlidir (ama beni düzeltmek istediğimde bir hata bulmayı başardı). Ancak, bir incelemenin kesinliği çok güvene dayanıyor. Kod göndermek isteyen kişinin kod tabanını iyi bildiğine güveniyorsam, kişinin kod tabanını ne kadar iyi bildiğini bilmediğim kadar katı olmayacağım.

Sorum şu, ne yapmalıyım? Bir inceleme için onu beklemeli miyim?

Hayır, sadece boşta oturmamalısın. Her zaman yapacak bir şeyler vardır. Gnat’ın önerdiği gibi , bir görev sırası olmalı. Veya, çevik bir geliştirme yönteminde, geçerli yineleme için size verilen görevlerin bir listesi. Boşta oturursanız, şirketinizin veya ekibinizin organizasyonunda yanlış bir şey var.

Başka bir şey var: kıdemli amiriniz yaptığınız her kod parçasını gerçekten kontrol ediyor mu? Eğer evet ise, çift programlama da yapabilirsiniz.

Kodlama yaparken özgür olmak istiyorum. Kalkınma özgürlüğü için nasıl güven kazanabilirim?

Yaşlıların gençlerin çalışmalarını kontrol etmesini gerektiren bazı düzenlemeler var (bence tıbbi iso 62304 bunu gerektiriyor). Öyleyse, hiçbir şey yapamazsınız.

Değişebildiğiniz şey, kıdemli öğrenciden kelimenin tam anlamıyla her şeyi kontrol etmemesini istemek. Kod inceleme işlemini ayarlayabilir ve önemli şeyleri kontrol edebilirsiniz.

Git yerel olarak kullanın, değişikliklerinizi bir şubeye yapın ve beklerken görev 2'ye başlayın. Ardından, işi bittiğinde, değişikliklerini yeni işinizde birleştirebilirsiniz ve bir sonraki görevdeki eğrinin çoktan ilerisindesiniz.

Bunu yeterince uzun ve çok yakında yapın, bir oturuşta 2 veya daha fazla şeyi gözden geçirebilir. Çatışmaları en aza indirgemek için çizgilerin üst üste binme olasılığı olmayan şeyleri seçin.

Bunun bir çözümü, üst düzey geliştiricinin işinizdeki Pair Programming ile daha önce ilgilenmesini sağlamak olabilir .

Çift Programlama için Wikipedia sayfası

Sizin için en göze çarpan avantaj, incelemenin süreçte çok daha erken gerçekleşmesiydi, bu nedenle artık kıdemli geliştirici için beklemeniz gerekmez.

Bunun yanı sıra, kıdemli geliştiricinin düşünce süreçlerini ve tekniklerini kodu yazarken görebilecek ve bundan öğreneceksiniz.

Üst düzey geliştiricinin problemini sizinle eşleştirmek istemeyebilirsiniz. Bu zor olabilir, ancak kendi deneyimim, hem üst düzey hem de küçük geliştiricilerin çift programlamasından çok fazla deneyim kazanmalarıdır.

Aynı zamanda, iki geliştiricinin aynı iş üzerinde çalışmasını sağlayarak üretkenliği yarı yarıya düşüreceğiniz endişesi de vardır. Verimlilik üzerindeki etkinin Çift Programlama ile ne olduğunu ölçmek zordur, duyduğum en yaygın cevap, eş yapan ve aynı olmayan takımların verimliliğinin olduğu. (Herhangi biri bu konuda iyi bir araştırma yaparsa, duymak isterim)

Tek başına tam bir cevap değil, sadece mükemmel cevaplara bir ek ...

Giriş yapmadan önce kendi kodunuzu inceliyor musunuz? En eğlenceli olmadığını biliyorum, ama çoğu zaman kendimi yapmaya çalışıyorum. 20 yıldır profesyonel olarak programlama yapıyorum (toplam 34 yıl), ancak genellikle en az bir hata ve / veya unuttuğum bir şey buldum ya da en azından daha iyisini yapabilirim. Kodunuzun her zaman gözden geçirilmesi gerektiği ve ikinci bir göz grubunun bir çiftten daha iyi olduğu fikrine katılıyorum. Fakat aynı çifti bile kodun iki kez üzerinden geçmesi bir kereden daha iyidir.

Kodunuz için birim testleri yazıyor musunuz? Birim testlerine ek olarak, şahsen yaptığım en yaygın hataları arayan küçük bir kabuk betiğim de var. Bazıları İngilizce gramer ve imla, bazıları ise derleyicinin yakalayamadığı kodlama sorunlarındandır. Büyük değişiklikleri kontrol etmek için aşağı akıştaki herkese nezaket olarak çalıştırıyorum.

Normalde insanların kodlarını yazmalarına izin veririm ve zaman zaman bundan şikayet ederler, ancak her check-in'i incelemem. Bir keresinde kodunu gözden geçirmek zorunda kaldığım ve genelde geri alması gereken çok küçük bir programcı ile çalıştım çünkü çok fazla hata yaptılar. Bu iyi bitmedi. Doğru zamanda yapılmasının daha önemli olduğu bir meslektesiniz. Hatalarından ders alırsan, çok ileri gideceksin.

İnceleyicinizin kodunuzda yapması gereken değişiklik sayısını en aza indirebilirseniz, her zaman bu kadar dikkatli bir şekilde gözden geçirilmesi gerekmeyen kod yazma konusunda size güvenebilecekleri şansı en üst düzeye çıkarırsınız. İncelemelerden kurtulmak istiyorsanız, kendi çıktılarınızın kalitesi için maksimum sorumluluğu alın.

Bu önerilerin bir kısmı veya tamamı, başka birinin kodunuzu incelemesini beklerken yapılabilir.

Bence manuel kod incelemeleri yapmak ... iyi ... 80'ler. Evet, belki 90'lı.

Sürekli entegrasyon ve çevrimiçi kod inceleme sistemlerinin bu modern çağında, “kaynak kontrolünü kırabileceğinden” korktuğunuz için herhangi bir kodu taahhüt etmek istemezsiniz.

Hadi millet. Değişiklik kümesi (veya değişiklik listeleri) bunun için var. Programcılarınıza kaynak kontrol sisteminizin aç testerelerini beslettiriyorsunuz. Ardından, sürekli entegrasyon sunucunuz, hedeflenmiş yapıların bir likideti ile başlıyor (umarım, sadece günlük yapı, ama bazılarımız taşınır). Herhangi bir şey kırılırsa, maymun maymunu kupasını (genellikle birinin Lucky Charms tahıl kutusundan bulduğu plastik bir oyuncak) failin masasına koyar ve kırılma değişiklik listesini geri alırsınız. Pekâlâ, bazı sürekli entegrasyon sistemleri, yapı / departman / organizasyondaki herkese, yapıyı bozmuş olan herkesi göstermek için şık bir köprüyle birlikte e-posta / IM / masaüstü bildirimlerini otomatik olarak patlatır. Şimdi bu tatsız programcı '

Bu işlem devam ederken, kod inceleme sistemi devreye girer (yine, check-in tarafından tetiklenir). Nitelikli ekip üyelerine bir liste kaynak kontrolüne bağlı değişiklik listesinden haberdar edilir, inceleme sisteminde bir inceleme başlatılır ve herkes değişiklik listesindeki değişikliklere açıklama eklemeye başlar. Umarım herkes "LGTM" diyecektir. Programcı akıllı ise, dua / rüşvet / saklanmayı hatırlayacaktır. Ciddi sorunlar varsa, hakemler bir hata yaratabilir (hata izleme sistemine bağlanabilir), hatta değişimin geri çekilmesini bile isteyebilir. Evet, yedeklenen değişiklikler sadece egoya değil, zihnine de zarar veriyor. Genç geliştiriciler üzerinde, reddedilen değişiklik listelerini yeniden birleştirmek için iyi bir baharattır.

Geliştirme ortamınızda bir CI veya bir kod inceleme sistemi yoksa, bunları ciddi şekilde araştırmalısınız. Birkaç bağlantı size yardımcı olabilir:

Atlassian Potası
JetBrains TeamCity
reitveld
Hız Kontrol

Bir CI sunucusu alacaksanız, birim test çerçevelerini de ciddi olarak düşünmelisiniz. Eğer bir C # dev iseniz, başlamak için NUnit gibi bir şeye bakın .

Ona kodunuzun ne zaman hazır olacağını, ne zaman yapıldığını değil, önceden söyleyin . Bunu yakl. bir hafta ileride. Bu, incelemeyi her iki planınıza da uyması için hazırlaması ve planlaması için ona zaman verir.