# Kod İncelemeleri Kod incelemeleri yapmalısınız. Niye? Çünkü bunlar *kod kalitesini* artırır ve *hata oranını azaltır*. Ama mutlaka düşündüğünüz nedenlerden dolayı değil. Daha önce incelemelerle ilgili bazı kötü deneyimler yaşamış olabileceğinden, birçok yazılımcı kod incelemelerini sevmeme eğilimindedir. Üretime dağıtılmadan önce tüm kodların resmi bir incelemeden geçmesini gerektiren kuruluşlar gördüm. Bu incelemeyi genellikle mimar veya baş geliştirici yapar, *mimar her şeyi gözden geçirir* olarak da tanımlanabilir. Bu, yazılım geliştirme süreci kılavuzlarında belirtilmiştir, bu nedenle yazılımcılar buna uymak zorundadır. Böyle katı ve resmi bir sürece ihtiyaç duyan bazı kuruluşlar olabilir, ancak çoğu böyle değildir. Çoğu organizasyonda böyle bir yaklaşım ters etki yapar. Gözden geçirenler, şartlı tahliye kurulu tarafından yargılandıklarını hissedebilirler. Gözden geçirenlerin hem kodu okumak için zamana hem de sistemin tüm ayrıntılarını güncel tutmak için zamana ihtiyaçları vardır. Gözden geçirenler bu süreçte hızla tıkanabilir ve süreç kısa sürede dejenere olur. Koddaki hataları basitçe düzeltmek yerine, kod incelemelerinin amacı *bilgiyi paylaşmak* ve ortak kodlama yönergeleri oluşturmak olmalıdır. Kodunuzu diğer yazılımcılarla paylaşmak, toplu kod sahipliğini sağlar. Rastgele bir ekip üyesinin, ekibin geri kalanıyla birlikte *kodu incelemesine* izin verin. Hata aramak yerine kodu öğrenmeye ve anlamaya çalışarak gözden geçirmelisiniz. Kod incelemeleri sırasında nazik olun. Yorumların *yapıcı, yakıcı değil* olduğundan emin olun. Ekip üyeleri arasında kurumsal kıdemin kod incelemesini etkilemesini önlemek için inceleme toplantısı için farklı *inceleme rolleri* tanıtın. Rol örnekleri arasında, bir gözden geçirenin belgelere, diğerinin istisnalara ve üçüncü bir kişinin de işlevselliğe odaklanması sayılabilir. Bu yaklaşım, inceleme yükünü ekip üyeleri arasında dağıtmaya yardımcı olur. Her hafta düzenli bir *kod incelemesi* yapın. Bir inceleme toplantısında birkaç saat geçirin. İncelenen kişiyi her toplantıda basit bir tekrarlı deneme düzeninde döndürün. Her gözden geçirme toplantısında ekip üyeleri arasında rolleri değiştirmeyi de unutmayın. *Yeni başlayanları* kod incelemelerine dahil edin. Deneyimsiz olabilirler, ancak taze üniversite bilgileri farklı bir bakış açısı sağlayabilir. Deneyimleri ve bilgileri için *uzmanları dahil edin*. Hataya açık kodu daha hızlı ve daha doğru bir şekilde tanımlayacaklar. Ekip, araçlar tarafından kontrol edilen *kodlama kuralları* varsa, kod incelemeleri daha kolay akacaktır. Bu şekilde, kod inceleme toplantısında kod biçimlendirme asla tartışılmayacaktır. *Kod incelemelerini eğlenceli hale getirmek* belki de başarıya en önemli katkıdır. İncelemeler, inceleme yapan kişilerle ilgilidir. Gözden geçirme toplantısı acı verici veya sıkıcıysa, insanları motive etmek zor olacaktır. Bunu, asıl amacı ekip üyeleri arasında bilgi paylaşımı olan *gayri resmi bir kod incelemesi* yapın. Alaycı yorumları dışarıda bırakın ve bunun yerine bir pasta ya da kahverengi çantalı öğle yemeği getirin. [Mattias Karlsson](http://programmer.97things.oreilly.com/wiki/index.php/Mattias_Karlsson) Tarafından --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/tr/thing_14.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.