Hangi kodu inceleyeceğimi nasıl seçerim?

Küçük bir yazılım şirketinde yedi geliştiriciden oluşan bir ekibin parçasıyım ve düzenli grup kodu ve tasarım incelemeleri sunmaya çalışıyorum. Geçmişte bazı incelemeler yaptık, ama ara sıra oldu. Daha düzenli bir şey yapmak istiyorum.

Ben Kod Komple ve benzeri diğer kaynakları okuyun ve onlar mekaniği hakkında konuşmak nasıl kod değerlendirmeleri yürütmek için ama nasıl seçileceği ile ilgili herhangi iyi uygulamaları bulmak geçiremedi neyi gözden geçirmek. Sekiz yaşından büyük ve çeşitli dilleri kapsayan bir kod tabanımız var, bu yüzden bakılabilecek çok şey var.

Seçimi etkileyebileceğini düşündüğüm bazı faktörler şunlardır:

• Dil: C, Java, SQL, PL / SQL
• Kod yaşı: Yeni kod ve eski kod
• Kod kullanımı: Sık kullanılan kod vs (etkin) ölü / az kullanılan kod
• Kod önemi: Kritik kod ve kritik olmayan kod
• Geliştirici: Junior developer code vs Senior developer code

Bunun kesin bir cevabı olan bir soru olmadığını anlıyorum, ancak herhangi bir rehberlik faydalı olacaktır.

Çevresel olarak ilgili bazı sorular:

• Kod inceleme yaklaşımları (Kritik bölümleri ve yeni geliştirici kodunu gözden geçirmenin gerekçesi)
• Tüm kodumuzu gözden geçirmeye çalışmalı mıyız?

Genel olarak, her şeyi gözden geçirmelisiniz . Yeni bir başvuruda 2000 LOC varsa, 2000 LOC'nin tümü gözden geçirilmelidir.

Bu yüzden neyin gözden geçirileceğinin nasıl seçileceğine dair en iyi uygulama yoktur .

Daha önce hiç incelenmemiş bir büyük kod tabanına yaklaşırsanız, varolan büyük bir kod tabanını yeniden yazmanız ve nereden başlayacağınızı seçmeniz aynı şeydir . Kesinlikle bağlıdır:

• kod tabanında (tek bir monolitik kodun yeniden yazılması / gözden geçirilmesi, bir dizi ayrı bileşenden, vb. daha zordur),

• Bağlamınız (üzerinde çalıştığınız her şeyi durdurabilir ve yalnızca yeniden yazma / inceleme için üç ay (üç yıl) harcayabilir misiniz?

• yaptığınız inceleme türü (gözden geçirilecek şeylerin bir kontrol listeniz var mı? Kontrol listesindeki öğelere bağlı olarak, önce bazı bölümleri incelemek isteyebilirsiniz).

Ben olsaydım, yapardım:

• bağlandığınız ikinci sorunun ilk yorumunda belirtilen% 80 -% 20 ilkesini takip edin.

• İdeal olan% 100'ün belki de buna değmeyeceğini dikkate alın. Ünite testleri için% 100 kod kapsamı gibidir, ancak bu kod kapsamı çoğunlukla imkansız veya aşırı pahalıdır.

• kodun en çok kullandığınız ve en önemli kısımlarıyla başlayın. Kod temeli, kurumsal web sitenizde yeni kullanıcıların kimliğini doğrulayan ve kaydeden bir kitaplığa sahipse, bilgisayar korsanlarının yapmadan önce kesinlikle güvenlik açıkları bulmak istediğiniz için önce onu gözden geçirin.

• nelerin gözden geçirilmesinin daha önemli olduğunu belirlemek için mevcut metrikleri kullanın. Kod tabanının bir bölümünde birim testi yoksa, aynı derecede önemli olan başka bir bölümde% 85 kod kapsamı varsa, ilk kısmı gözden geçirerek başlayın. Kod tabanının bir kısmı, deneyimsiz olduğu ve meslektaşlarından herhangi birinden daha fazla hata getirdiği bilinen bir geliştirici tarafından yazılmışsa, önce kodunu gözden geçirerek başlayın.

Kodda yaptığınız tüm değişiklikleri gözden geçirerek başlayın; bu da sorunun daha da kötüleşmesini engelleyecektir. Ardından değişiklik sıklığına göre kodu incelemeye başlayın; bunlar 'sorun' alanları olacaktır.

Kodunuzun inceleme kapsamını diğer endişelere göre analiz edebilmeniz için bir kod bölümünü incelediğinizi izlemenin bir yolunu bulmak istersiniz.

Hangi kodun testlerinizin kapsamına girmediğini belirleyebiliyorsanız , bu inceleme için daha yüksek bir öncelik haline gelir.

Üretime geçmeden önce yapılan tüm yeni değişiklikleri gözden geçirin. kurulum komut dosyaları, kaynak kodu, veritabanı değişiklikleri, her şey! Kod incelemesinin tüm amacı, kötü kodun üretime geçmesini durdurmaktır. Kötü bir organizasyon şeması veya basitçe tanıtılan bir hata olsun çünkü bir şey kaçırıldı.

Üzerinde çalıştığınız kodun yeniden düzenlenmesi, kod incelemesi ile el ele gider. Örneğin, kodu incelerken, geliştirici bu kodu düzeltmede değiştirmemiş olsa bile, bir hata düzeltmesi içeren bir sınıfta yinelenen kod varsa, bunu geçmezdim. Onları geri gitmek ve yinelenen kodu kaldırmak olurdu.

Eğer acımasızca refactor, o zaman kod inceleme yararlı olur. Aksi takdirde zaman kaybıdır.

Kod inceleme sürecini geliştirme sürecinize adım olarak dahil ederseniz, kod tabanı zaman içinde daha iyi hale gelecektir. Daha da iyisi, kod inceleme birikimi boş olana kadar geliştiricilerin yeni özellik çalışmaları veya hata düzeltmeleri yapmalarına izin vermemelisiniz. Bu, kod incelemesinin yapılmasını sağlar.

Yeniden düzenlenmesi gereken bilinen alanlar varsa, ancak bunların yapılması uzun zaman alacaktır (yani 1 hafta veya daha fazla). Ardından, bu yeniden düzenleme için tek başına bir çalışma öğesi oluşturun ve üzerinde çalışılacak öğe olarak ekleyin.

Tüm yeni kodları ve mevcut koddaki değişiklikleri gözden geçirerek başlayın.

Mevcut kodda yapılan değişiklikleri incelerken, geliştirici boyscout kuralını izlemelidir. Kodu bulduğundan daha iyi bırakın.

Bu, tüm dosyayı mükemmel olması için düzeltmeniz gerektiği anlamına gelmez. Ama karışıklığa katkıda bulunmamalı, biraz daha iyi yapmalı. Belki de değişiklikleri uygun şekilde yapılandırılmış yeni sınıflara taşıyarak ve orijinal kod dosyasının geri kalanını olduğu gibi bırakarak (sonuçta, 'çalışıyor).

Geliştiriciler olarak, tüm yeni kodları ve değişiklikleri gözden geçirerek kodu geliştirmeye başladığınızda, uygulamanın hangi alanlarının en fazla değişiklik gerektirdiğini bilmelisiniz. Sonra bunları gözden geçirin, nasıl geliştirilebileceklerini yavaş yavaş tartışın.

10 yıl önce yazılan kodun gözden geçirilmesi, gözden geçirme uğruna anlamsızdır, geliştiricinin bu 10 yıl içinde gelişmesi gerekirdi. Yani, sadece bildiklerinizi öğrenmek için onu gözden geçirmenin bir anlamı yok.

Kod incelemelerinin amacı, şu anda yaptığınız hataları iyileştirmek ve düzeltmek ve bu bilgileri ekip arasında paylaşmaktır.

Projemde, herhangi bir ödev / kullanıcı hikayesi / hata geliştirilmek için çoğu durumda olması gereken kod incelemesini ekliyoruz. Scrum / çevik süreçleri kullanıyoruz ve birim testleri yazılana ve kod incelemesi tamamlanana kadar bilet / hikaye inşa edilmedi (KG için bir biriktirme listesi).

Bu amaçla JIRA + SVN ile entegre Pota kodu incelemesi ile Atlassian FishEye analizini kullanıyoruz .

Geliştirici belirli bir hikaye için kodu kontrol ettiğinde, FishEye'de incelemeyi yapmak için ekibin diğer üyelerini seçtiği yeni bir kod incelemesi oluşturur.

Kod incelemesi tamamlandıktan sonra (araç gönderilen değişiklikleri vurgular ve belirli kod satırı için yorum bırakmaya izin verir) geliştirici belirtilen sorunları düzeltir / önerilen iyileştirmeleri uygular ve bileti JIRA'daki Dahili sütuna taşır - bu hikaye test edilmeye hazırdır ve bu iş öğesi için başka kod değişikliği beklenmemektedir.

Bu aynı zamanda KG'nin kod gözden geçirildikten sonra kodu yeniden düzenlerken değiştirilebilecek ve muhtemelen kırılabilecek hiçbir şeyi test etmemesini sağlar .

Özetle, tüm kodların gözden geçirilmesi gerekir - bu, kodun daha iyi bir tasarım, okunabilirlik, sürdürülebilirlik ve test edilebilirliği ile sonuçlanan ve uzun vadede geliştirme performansını artıran yüksek kod kalitesini destekler.