Ekibinize Sağlıklı Bir Kod İnceleme Zihniyeti Getirme

Bir 'kod incelemesi', geliştirme sürecinde sizin (geliştirici olarak) ve iş arkadaşlarınızın birlikte çalıştığınız ve yeni bir kod parçası yayınlanmadan önce içindeki hataları aradığınız bir andır. Böyle bir anda, kod yazarı veya gözden geçirenlerden biri olabilirsiniz.

Bir kod incelemesi yaparken, aradığınızdan emin olamayabilirsiniz. Öte yandan, bir kod incelemesi gönderirken neyi bekleyeceğinizi bilemeyebilirsiniz. İki taraf arasındaki bu empati eksikliği ve yanlış beklentiler, talihsiz durumları tetikleyebilir ve her iki taraf için de tatsız bir deneyimle bitene kadar süreci hızlandırabilir.

Bu makalede, bir kod incelemesi sırasında zihniyetinizi değiştirerek bu sonucun nasıl değiştirilebileceğini paylaşacağım:

• takım olarak
• yazar olarak
• yorumcu olarak

Takım Olarak Çalışmak

İşbirliği Kültürünü Destekleyin

Başlamadan önce, kodun neden gözden geçirilmesi gerektiğinin değerini anlamak esastır. Bilgi paylaşımı ve ekip uyumu herkes için faydalıdır, ancak kötü bir zihniyetle yapılırsa, bir kod incelemesi hoş olmayan sonuçlarla çok büyük bir zaman tüketicisi olabilir.

Ekip tutumu ve davranışı, başka birinin deneyiminden bağımsız olarak, ortak öğrenme ve paylaşma hedefiyle , yargılayıcı olmayan bir işbirliğinin değerini benimsemelidir.

Tahminlerinize Kod İncelemelerini Dahil Edin

Tam bir kod incelemesi zaman alır. Bir değişikliğin yapılması bir hafta sürdüyse, kod incelemesinin bir günden az sürmesini beklemeyin. Sadece böyle çalışmıyor. Bir kod incelemesini aceleye getirmeye çalışmayın ve buna bir darboğaz olarak bakmayın.

Kod incelemeleri, gerçek kodu yazmak kadar önemlidir. Ekip olarak, iş akışınıza kod incelemeleri eklemeyi ve bir kod incelemesinin ne kadar sürebileceğine ilişkin beklentileri belirlemeyi unutmayın, böylece herkes senkronize olur ve çalışmalarından emin olur.

Yönergeler ve Otomasyon ile Zaman Kazanın

Tutarlı katkıları garanti etmenin etkili bir yolu, projeye bir Çekme Talebi şablonu entegre etmektir. Bu, yazarın eksiksiz bir açıklama ile sağlıklı bir PR göndermesine yardımcı olacaktır. Bir PR açıklaması, değişimin amacının ne olduğunu, arkasındaki nedeni ve nasıl yeniden üretileceğini açıklamalıdır. Ekran görüntüleri ve referans bağlantıları (Git sorunu, tasarım dosyası vb.), açıklayıcı bir gönderim için son dokunuşlardır.

Tüm bunları yapmak, gözden geçirenlerin daha fazla ayrıntı isteyen erken yorumlarını önleyecektir. Kod incelemelerini daha az titiz göstermenin bir başka yolu, bir gözden geçiren bile dahil olmadan kod biçimlendirmesini ve kod kalitesi sorunlarını bulmak için linter kullanmaktır. İnceleme sürecinde tekrarlayan bir yorum gördüğünüzde, onu en aza indirmenin yollarını arayın (daha iyi yönergeler veya kod otomasyonu ile).

Öğrenci Kal

Herkes kod incelemesi yapabilir ve kıdem düzeyi ne olursa olsun herkesin bir kod incelemesi alması gerekir. Herhangi bir geri bildirimi, öğrenmek ve bilgiyi paylaşmak için bir fırsat olarak minnetle alın. Herhangi bir geri bildirime savunmacı bir tepki olarak değil, açık bir tartışma olarak bakın . Ryan Holiday'in dediği gibi:

“Bir amatör savunmacıdır. Profesyonel, öğrenmeyi (ve hatta bazen ortaya çıkmayı) eğlenceli bulur; meydan okunmaktan ve küçük düşürülmekten hoşlanırlar ve eğitime sürekli ve sonsuz bir süreç olarak katılırlar. (...)”

— Ryan Holiday, Ego Düşmandır

Alçakgönüllü kalın çünkü öğrenci olmayı bıraktığınız an bilginiz kırılgan hale gelir.

Eleştirmenleri Seçme Sanatı

Bence ekip olarak etkili ve sağlıklı bir kod incelemesi için en önemli kararlardan biri hakem seçimidir.

Diyelim ki meslektaşınız bir kod incelemesi gönderiyor ve “herkesi” etiketlemeye karar veriyor çünkü farkında olmadan süreci hızlandırmak, mümkün olan en iyi kodu sunmak veya kod değişikliğinden herkesin haberdar olmasını sağlamak isteyebilir. Gözden geçirenlerin her biri bir bildirim alır, ardından PR bağlantısını açar ve gözden geçiren olarak etiketlenmiş birçok insan görür. “Başkası yapacak” düşüncesi akıllarına gelir ve bu da kod incelemesini görmezden gelip bağlantıyı kapatmaya yol açar.

İncelemeye henüz kimse başlamadığından, meslektaşınız inceleme yapanların her birine bunu yapmasını hatırlatacak, yani üzerlerinde baskı oluşturacaktır. Gözden geçirenler bunu yapmaya başladığında, gözden geçirme süreci sonsuza kadar sürer çünkü herkesin kendi görüşü vardır ve ortak bir anlaşmaya varmak bir kabustur. Bu arada, kodu gözden geçirmemeye karar veren kişi, daha sonra tüm inceleme yorumlarıyla birlikte zilyonlarca e-posta bildirimi ile spam gönderilir ve böylece üretkenliklerinde gürültü yaratır.

Bu, istediğimden daha fazla gerçekleştiğini gördüğüm bir şey: İnceleyen olarak etiketlenen ve ironik bir şekilde üretken olmayan bir kod incelemesinde biten bir grup insanla İstekleri Çekin.

Gözden geçirenleri seçerken bazı yaygın etkili akışlar vardır: Olası bir akış, koda aşina olan iki ila üç meslektaşı seçmek ve onlardan gözden geçiren olmalarını istemektir. Gitlab ekibi tarafından açıklanan başka bir yaklaşım, yazarın en az iki gözden geçirenin kodla aynı fikirde olana kadar başka bir gözden geçiren seçtiği bir gözden geçireni seçtiği zincirleme bir gözden geçirme akışına sahip olmaktır. Seçtiğiniz akış ne olursa olsun, çok fazla gözden geçirene sahip olmaktan kaçının . Etkili ve sağlıklı bir kod incelemesi yürütmenin anahtarı, iş arkadaşlarınızın kodunun yargısına güvenebilmektir.

Empati yap

Geliştirilecek kod parçalarını tespit etmek, başarılı bir kod incelemesinin yalnızca bir parçasıdır. Aynı derecede önemli olan, meslektaşlarınıza empati göstererek bu geri bildirimi sağlıklı bir şekilde iletmektir.

Yorum yazmadan önce kendinizi başkalarının yerine koymayı unutmayın. Yazarken yanlış anlaşılmak kolaydır, bu yüzden göndermeden önce kendi kelimelerinizi gözden geçirin. Bir konuşma çirkinleşmeye başlasa bile, bunun seni etkilemesine izin verme - her zaman saygılı ol. Başkalarıyla iyi konuşmak asla kötü bir karar değildir.

Uzlaşmayı Bilin

Bir tartışma çabucak çözülmediğinde, onu kişisel bir görüşmeye veya sohbete götürün. Mevcut değişiklik talebini felç etmeye değer bir konu olup olmadığını veya başka bir konuda ele alınıp alınamayacağını birlikte analiz edin.

Esnek ama pragmatik olun ve verimlilik (teslim etme) ile etkililik (kalite) arasında nasıl denge kurulacağını bilin. Takım olarak yapılması gereken bir uzlaşmadır. Bu anlarda, bir kod incelemesini nihai bir çözümden ziyade bir yineleme olarak düşünmeyi seviyorum. Bir sonraki turda her zaman iyileştirme için yer vardır.

Şahsen Kod İncelemeleri

Yazar ve hakemi ikili programlama tarzında bir araya getirmek oldukça etkili olabilir. Şahsen, kod incelemesi karmaşık değişiklikler içerdiğinde veya büyük miktarda bilgi paylaşımı için bir fırsat olduğunda bu yaklaşımı tercih ederim. Bu çevrimdışı bir kod incelemesi olmasına rağmen, özellikle toplantıdan sonra değişiklik yapılması gerektiğinde, yapılan tartışmalar hakkında çevrimiçi yorumlar bırakmak iyi bir alışkanlıktır. Bu, diğer çevrimiçi gözden geçirenleri güncel tutmak için de yararlıdır.

Kod İnceleme Sonuçlarından Öğrenin

Bir kod incelemesi çok fazla değişikliğe uğradığında, çok uzun sürdüğünde veya çok fazla tartışmaya girdiğinde, ekibinizi bir araya toplayın ve nedenleri ve bundan hangi önlemlerin alınabileceğini analiz edin. Kod incelemesi karmaşık olduğunda, gelecekteki bir görevi daha küçük görevlere bölmek , her bir kod incelemesini kolaylaştırır.

Deneyim farkı büyük olduğunda, ikili programlamayı benimsemek, yalnızca bilgi paylaşımı için değil, aynı zamanda çevrimdışı işbirliği ve iletişim için de inanılmaz sonuçlara sahip bir stratejidir. Sonuç ne olursa olsun, her zaman beklentileri net olan sağlıklı ve dinamik bir ekibi hedefleyin.

Yazar Olarak

Bir yazar olarak bir kod incelemesi üzerinde çalışırken ana kaygılardan biri, kodu ilk kez okurken gözden geçirenin şaşkınlığını en aza indirmektir. Bu, öngörülebilir ve sorunsuz bir kod incelemesinin ilk adımıdır. İşte bunu nasıl yapabileceğiniz.

Erken İletişim Kurun

Çok fazla kodlamadan önce gelecekteki eleştirmenlerinizle konuşmak asla kötü bir fikir değildir. Dahili veya harici bir katkı olduğunda, çözümleri tartışmak için geliştirmenin başında birlikte bir iyileştirme veya biraz eşli programlama yapabilirsiniz.

İlk adım olarak yardım istemekte yanlış bir şey yok. Aslında, inceleme dışında birlikte çalışmak, erken hataları önlemek ve ilk anlaşmayı garantilemek için ilk önemli adımdır. Aynı zamanda, gözden geçirenleriniz gelecekte yapılacak bir kod incelemesinden haberdar olurlar.

Yönergeleri Takip Edin

İncelenmek üzere bir Çekme İsteği gönderirken, bir açıklama eklemeyi ve yönergeleri izlemeyi unutmayın. Bu, gözden geçirenleri yeni kodun içeriğini anlamak için zaman harcamaktan kurtaracaktır. Eleştirmenleriniz ne hakkında olduğunu zaten biliyor olsalar bile, bu fırsatı yazma ve iletişim becerilerinizi geliştirmenin bir yolu olarak da değerlendirebilirsiniz.

İlk Yorumcunuz Olun

Kendi kodunuzu farklı bir bağlamda görmek, kod düzenleyicinizde özleyeceğiniz şeyleri bulmanızı sağlar. Meslektaşlarınıza sormadan önce kendi kodunuzun bir kod incelemesini yapın. Bir gözden geçiren zihniyetine sahip olun ve gerçekten her kod satırını gözden geçirin.

Şahsen, gözden geçirenlerime daha iyi rehberlik etmek için kendi kod incelemelerime açıklama eklemeyi seviyorum . Buradaki amaç, olası bir dikkat eksikliği ile ilgili yorumları önlemek ve katkı yönergelerine uyduğunuzdan emin olmaktır. Tıpkı bir tane almak istediğiniz gibi bir kod incelemesi göndermeyi hedefleyin.

Sabırlı ol

Bir kod incelemesi gönderdikten sonra, doğrudan gözden geçirenlerinizden “bir göz atmalarını, yalnızca birkaç dakika sürmesini” isteyen ve dolaylı olarak o başparmak emojisi için can atan yeni bir özel mesaja atlamayın. İş arkadaşlarınızı işlerini yapmaları için acele etmeye çalışmak sağlıklı bir zihniyet değildir. Bunun yerine, iyi bir kod incelemesi göndermeniz konusunda size güvendikleri için iş arkadaşlarınızın iş akışına güvenin. Bu arada, müsait olduklarında size geri dönmelerini bekleyin. Yorumcularınıza darboğaz gözüyle bakmayın. Sabırlı olmayı unutmayın çünkü zor şeyler zaman alır.

Dinleyici Olun

Bir kod incelemesi gönderildiğinde, yorumlar gelecek, sorular sorulacak ve değişiklikler önerilecektir. Buradaki altın kural, herhangi bir geri bildirimi kişisel bir saldırı olarak almamaktır. Herhangi bir kodun dışarıdan bir bakış açısıyla yararlanabileceğini unutmayın.

Yorumcularınıza düşman gözüyle bakmayın. Bunun yerine, bu anı egonuzu bir kenara bırakmak için ayırın, hata yaptığınızı kabul edin ve bir dahaki sefere daha iyi bir iş yapabilmek için iş arkadaşlarınızdan öğrenmeye açık olun.

Yorumcu Olarak

Zamanınızın Önünde Plan Yapın

Sizden bir eleştirmen olmanız istendiğinde, işleri hemen bölmeyin. Bu her zaman gördüğüm yaygın bir hata. Kodu gözden geçirmek, tüm dikkatinizi gerektirir ve kod bağlamlarını her değiştirdiğinizde, odağınızı yeniden ayarlamak için zaman harcayarak üretkenliğinizi düşürürsünüz. Bunun yerine, kod incelemeleri yapmak için gününüzün zaman dilimlerini ayırarak önceden plan yapın.

Şahsen, diğer görevlerimi seçmeden önce sabah ilk iş veya öğle yemeğinden sonra kod incelemeleri yapmayı tercih ederim. Benim için en iyi olan şey bu çünkü beynim, kapatılacak önceki bir kod bağlamı olmadan hala taze. Bunun yanı sıra, incelemeyi bitirdiğimde, yazar geri bildirime dayalı olarak kodu yeniden değerlendirirken ben kendi görevlerime odaklanabilirim.

Yardımcı ol

Bir Çekme Talebi katkı yönergelerine uymadığında, özellikle yeni gelenler için destekleyici olun. Bu anı, yazara katkısını geliştirmesi için rehberlik etmek için bir fırsat olarak değerlendirin. Bu arada, yazarın ilk etapta neden yönergelere uymadığını anlamaya çalışın. Belki de daha önce farkında olmadığınız iyileştirmeler için yer vardır.

Şubeyi Kontrol Edin ve Çalıştırın

Kodu gözden geçirirken, özellikle kullanıcı arayüzleri içeriyorsa, kendi bilgisayarınızda çalışmasını sağlayın. Bu alışkanlık, yeni kodu daha iyi anlamanıza ve tarayıcıda gözden geçirme kapsamınızı değiştirilen kodla sınırlayan varsayılan bir fark aracı kullandıysanız (kod düzenleyicinizdeki gibi tam bağlama sahip olmadan) kaçırabileceğiniz şeyleri tespit etmenize yardımcı olacaktır. .

Varsaymadan Önce Sor

Bir şeyi anlamadığınızda, söylemekten ve soru sormaktan çekinmeyin. Soru sorarken, önce çevreleyen kodu okumayı ve varsayımlarda bulunmaktan kaçınmayı unutmayın.

Soruların çoğu şu iki tür kategoriye uygundur:

1. “Nasıl” Soruları
   Bir şeyin nasıl çalıştığını veya ne yaptığını anlamadığınızda, kodun yeterince açık olup olmadığını yazarla birlikte değerlendirin. Basit kodu cehaletle karıştırmayın. Okunması zor kod ile farkında olmadığınız kod arasında fark vardır. Henüz derinlemesine bilmiyor olsanız bile, yeni bir dil özelliğini öğrenmeye ve kullanmaya açık olun. Ancak, yalnızca kod tabanını basitleştiriyorsa kullanın.
2. “Neden” Soruları
   “Nedenini” anlamadığınızda, özellikle bir Edge durumu veya bir hata düzeltmesi ise, kodu yorumlamayı önermekten korkmayın. Ne yaptığını açıklamaya gelince, kod kendi kendini açıklayıcı olmalıdır. Yorumlar, belirli bir yaklaşımın arkasındaki nedeni açıklamak için bir tamamlayıcıdır. Konu sürdürülebilirlik olduğunda bağlamı açıklamak son derece değerlidir ve birisini işe yaramaz olduğu düşünülen bir kod bloğunu silmekten kurtaracaktır. (Şahsen, daha sonra unutma konusunda kendimi güvende hissedene kadar kod hakkında yorum yapmayı seviyorum.)

Yapıcı eleştiri

Geliştirilmesi gerektiğine inandığınız bir kod parçası bulduğunuzda, her zaman yazarın projeye katkıda bulunma çabasını takdir etmeyi ve kendinizi açık ve şeffaf bir şekilde ifade etmeyi unutmayın.

• Açık tartışmalar.
  Geri bildiriminizi “Yapmalısın…” veya “Unuttun…” gibi bir emir veya suçlama olarak resmileştirmekten kaçının. Geri bildiriminizi zorunlu bir istek yerine açık bir tartışma olarak ifade edin. Yazara değil, koda yorum yapmayı unutmayın. Yorum kodla ilgili değilse, kod incelemesine ait olmamalıdır. Daha önce de söylediğim gibi, destekleyici olun. Pasif bir ses kullanmak, çoğul konuşmak, soruları veya önerileri ifade etmek, yazarla empatiyi vurgulamak için iyi yaklaşımlardır.
  

“Bu yöntemi buradan çıkar…” yerine “Bu yöntem çıkarılmalı…” veya “Bu yöntemi çıkarma hakkında ne düşünüyorsunuz…” seçeneğini tercih edin.

• Açık ol.
  Bir geri bildirim, özellikle bir gerçeği veya kılavuzu paylaşmaya karşı bir fikri ifade etmeye gelince, kolayca yanlış yorumlanabilir. Her zaman yorumunuzda bunu hemen temizlemeyi unutmayın.

Belirsiz: "Bu kod şöyle olmalıdır..."

Görüş: “Bu kodun olması gerektiğine inanıyorum…”

Gerçek: "[Yönergelerimize] göre, bu kod şöyle olmalıdır...".

• Sebebini açıkla.
  Sizin için bariz olan başkaları için olmayabilir. Geri bildiriminizin arkasındaki motivasyonu asla çok fazla açıklamaz, bu nedenle yazar yalnızca bir şeyi nasıl değiştireceğini değil, aynı zamanda bunun faydasının ne olduğunu da anlar.

Görüş: “Bu kodun olabileceğine inanıyorum…”

Açıklama: "Bu kodun (…) olabileceğine inanıyorum çünkü bu okunabilirliği artıracak ve birim testlerini basitleştirecektir."

• Örnekler sağlayın.
  Yazarın aşina olmadığı bir kod özelliğini veya kalıbı paylaşırken, önerinizi kılavuz olarak bir referansla tamamlayın. Mümkün olduğunda, MDN belgelerinin ötesine geçin ve mevcut kod senaryosuna uyarlanmış bir pasaj veya çalışan bir örnek paylaşın. Bir örnek yazarken çok karmaşıksa, destekleyici olun ve yüz yüze veya görüntülü arama yoluyla yardım teklifinde bulunun.

“Filtre kullanmak [motivasyon] için bize yardımcı olacaktır” gibi bir şey söylemenin yanı sıra, “Bu durumda şöyle bir şey olabilir: [kod parçası]. [Finder.js'deki bir örneği] kontrol edebilirsiniz. Herhangi bir şüpheniz varsa, bana Slack'te ping atmaktan çekinmeyin.

• Mantıklı ol.
  Aynı hata birden çok kez yapılırsa, sadece bir yorum bırakmayı tercih edin ve yazarın başka yerlerde de incelemesini unutmayın. Gereksiz yorumlar eklemek yalnızca gürültü yaratır ve ters etki yapabilir.

Odaklanmayı Koru

Geçerli kodla ilgisi olmayan kod değişiklikleri önermekten kaçının. Bir değişiklik önermeden önce, o anda kesinlikle gerekli olup olmadığını kendinize sorun. Bu tür geri bildirim özellikle refactorlarda yaygındır. Bu, ekip olarak yapmamız gereken verimlilik ve etkililik arasındaki birçok ödünleşimden biridir.

Yeniden düzenleyiciler söz konusu olduğunda, kişisel olarak, küçük ama etkili iyileştirmeleri tercih etme eğilimindeyim. Bunları gözden geçirmesi daha kolaydır ve şubeyi hedef şubeyle güncellerken kod çakışmaları olma olasılığı daha düşüktür.

Beklentileri Belirle

Bir kod incelemesini yarım bırakırsanız, yazara bunu bildirin, böylece zaman beklentileri kontrol altında olur. Sonunda, yeni kodu kabul edip etmediğinizi veya daha sonra yeniden gözden geçirmek isteyip istemediğinizi de yazara bildirin.

Bir kod incelemesini onaylamadan önce, gelecekte bu koda dokunma olasılığı konusunda rahat olup olmadığınızı kendinize sorun. Cevabınız evet ise, bu başarılı bir kod incelemesi yaptığınızın işaretidir!

Bir Kod İncelemesini Reddetmeyi Öğrenin

Kimse kabul etmese de bazen bir kod incelemesini reddetmeniz gerekir. Bir kod incelemesini kabul etmeye karar verdiğinizde ancak acele etmeye çalıştığınızda, ekibinizin zihniyeti kadar projenin kalitesinden de ödün verilir.

Başka birinin kodunu gözden geçirmeyi kabul ettiğinizde, o kişi sizin yeteneklerinize güvenir - bu bir taahhüttür. Eleştirmen olmak için zamanınız yoksa, iş arkadaşlarınıza hayır demeniz yeterli. Gerçekten onu kastediyorum; iş arkadaşlarınızın asla yapılmayacak bir kod incelemesini beklemesine izin vermeyin. İletişim kurmayı ve beklentileri net tutmayı unutmayın . Takımınıza ve hatta daha da iyisi kendinize karşı dürüst olun. Seçiminiz ne olursa olsun, sağlıklı bir şekilde yapın ve doğru yapın.

Çözüm

Yeterli zaman ve deneyim verildiğinde, kod incelemeleri yapmak size teknik bilgiden çok daha fazlasını öğretecektir. Başkalarından geri bildirim almayı ve vermeyi öğrenecek ve üzerinde daha fazla düşünülerek kararlar vereceksiniz.

Her kod incelemesi, topluluk olarak ve bireysel olarak büyümek için bir fırsattır. Kod incelemeleri dışında bile, size ve iş arkadaşlarınıza doğal olarak gelene kadar sağlıklı bir zihniyet geliştirmeyi unutmayın. Çünkü paylaşmak bizi daha iyi yapan şeydir!

SmashingMag'de Daha Fazla Okuma :

• Birlikte Çalışmak: Tasarımcılar ve Geliştiriciler Daha İyi Projeler Oluşturmak İçin Nasıl İletişim Kurabilir?
• Tasarımcıları Kod İnceleme Sürecine Getirerek Daha İyi İşbirliği
• Web Tasarımcıları ve Geliştiricileri Hangi Podcast'leri Dinlemeli?
• Mükemmel Web Geliştirici Özgeçmişi Nasıl Hazırlanır?