Yapay zekadan makale özeti
- Kısa
- Ayrıntılı
- Bu video, bir grup yazılım geliştiricisi arasında geçen teknik bir sohbet formatındadır. Konuşmacılar arasında Uğur, Emre ve projede beş yıldır çalışan bir konuşmacı bulunmaktadır.
- Video, code review (kod incelemesi) konusunu kapsamlı şekilde ele almaktadır. Code review'un ne olduğu, faydaları, dezavantajları, ideal uygulama şekilleri ve iOS projelerinde dikkat edilmesi gereken noktalar detaylı olarak tartışılmaktadır. Ayrıca, git commit mesajlarının hazırlanması, commitlerin atomik olması gerektiği ve otomatik araçların kod kalitesini nasıl artırdığı gibi konular da ele alınmaktadır.
- Sohbet sırasında code review sürecindeki sorunlar, ideal kişi sayısı, anonim review olup olmaması, farklı teknolojilerden kişilerin review yapması ve review sürecindeki sorumluluk dağılımı gibi pratik konular da tartışılmaktadır. Ayrıca, kod kopyalama gibi kötü uygulamaların nasıl tespit edilebileceği ve önlenmesi gerektiği konusunda da fikirler paylaşılmaktadır.
- 00:08Code Review Nedir ve Avantajları
- Code review, kodun mertlenmeden önce takım arkadaşları tarafından incelenip puan verilmesi veya approve edilmesi, açık yorumlar yazıp fiksler düzenlenmesi sürecidir.
- Code review'un en büyük avantajlarından biri kod kalitesini artırmak ve hatalardan arındırmaktır.
- Code review, özellikle yeni başlayanlar için kodu daha iyi öğrenmeyi ve gelişimlerini etkilemeyi sağlar.
- 02:26Code Review'da İncelenen Alanlar
- iOS platformlarında code review'da daha çok business logic ve kullanıcıyı etkileyebilecek bariz hatalar incelenir.
- Enterprise şirketlerde belirlenen mimariye uyulup uymadığı ve exceptionlar yapıldığı kontrol edilir.
- Code review'da genellikle kodun nasıl yapıldığına bakılır, ancak doğru işi yapıp yapmadığına bakmak daha zordur çünkü bunun için projeyi çok iyi bilmek gerekir.
- 06:49Code Review Yaparken Dikkat Edilmesi Gerekenler
- Code review yaparken kafanızda soru işareti kaldıysa, detayını öğrenmeye yönelik araştırma yapmak gerekir.
- Code review yaparken süslü parantez gibi syntax detaylarından ziyade daha kaliteli bir inceleme yapılmalıdır.
- Code review onayı, "bu feature'a ve kodun kalitesine kefilim" anlamına gelir ve bu sorumluluk takım içinde netleştirilmelidir.
- 08:30Performans ve Kod Kalitesi
- Code review'da performans iyileştirmeleri de incelenebilir, örneğin tekrar tekrar yaratılan objelerin statik olarak kullanılması önerilebilir.
- Çok fazla for loop kullanımı gibi performans sorunları optimize edilmiş çözümlerle değiştirilebilir.
- Memory management konuları da code review kapsamında değerlendirilebilir, örneğin yanlış yerde çağrılan fonksiyonlar gibi durumlar kontrol edilebilir.
- 10:17Kod İnceleme (Code Review) Avantajları
- Kod incelemesi, özellikle database'de çalışırken dikkatli olmayı gerektiren karmaşık operasyonları loglan'a düşürmeye yardımcı olur.
- Farklı projelerde kod incelemesi yapmak, öğrenme hızını artırmaya ve farklı kod tarzlarını görmeye olanak sağlar.
- Dışarıdan bir göz, proje içinde yapılan kararları değerlendirebilir ve ileride ortaya çıkabilecek sorunları önceden tespit edebilir.
- 12:15Kod İnceleme'nin Dezavantajları ve Avantajları
- Kişinin kendi çalıştığı projede yaptığı kod ile başka projelerdeki kod arasında kalite farkı olabilir, çünkü kod incelemesi olmadan daha kolay kısa yollar ve hack'ler kullanılabilir.
- Kod incelemesi, hızlı geliştirme yapmak istediğimizde acil paketlerin çıkmasını engelleyebilir, ancak bu durum ekibin iletişim ve esnekliğiyle çözülebilir.
- Kod incelemesi yapma amacına bağlıdır; gelişmek istiyorsak önemlidir, ancak sadece denemek veya hızlı bir uygulama geliştirmek istiyorsak daha az önemlidir.
- 15:12Kod İnceleme İçin İdeal Kişi Sayısı
- Tek bir kişinin tüm kodları incelemesi pratik olmayan ve o kişide çok fazla bağımlılık yaratan bir yöntemdir.
- Kod incelemesinde kesin bir sayı kuralı olmamalı, takım içindeki anlaşma ve konsensus önemlidir.
- Belirli bir konuda hakim olan kişilere değişikliklerde inceleme yapmaları istenmelidir ve kodun bir an önce merge edilmesi yerine, inceleme listesinde güvenilir kişilerin onayını almak önemlidir.
- 17:45Code Review Sürecinde Kişi Sayısı ve Sorumluluklar
- Code review sürecinde kişi sayısı takıma göre değişebilir, ancak minimum kuralların olması ve en az bir ebru ihtiyacı olması gibi temel kurallar belirlenebilir.
- Kişilerin projeye verdiği değer ve inisiyatifine göre review yapma sorumluluğu belirlenebilir, ancak herkesin review yapması gerekmeyebilir.
- Projede çok fazla kişiye review yapma sorumluluğu vermek yerine, projeyi yeni başlayan kişilere yetki vermek de olumlu bir durum değildir.
- 19:01Code Review Sürecindeki Sorunlar ve Çözümler
- GitHub'ta puanlama sistemi yokken, bazı şirketlerde artı iki veren kişinin kodu onaylaması gibi bir sistem bulunmaktadır.
- Code review sürecinde herkesin review yapması yerine, sorumluluklar daha az sayıda kişiye verilmeli ve projede çok hiyerarşi oluşturulmamalıdır.
- Code review sürecinde sorumluluklar belirli kişilere verilmeli, herkesin aynı eşit derecede sorumlu olması gerekmektedir.
- 23:06Code Review Sürecinde Anonimlik ve İşbirliği
- Code review sürecinde kimin review yaptığı ve kodu kimin gönderdiği belli olmaması, önyargıların önüne geçmek için faydalı olabilir.
- Anonim review sisteminde, tecrübeli kişilerin verileri diğerlerinin kararlarını etkileyebilir, bu nedenle artı iki ve artı bir verenlerin görünmemesi de düşünülebilir.
- Code review sürecinde kullanılan araçların yetersiz olması durumunda, ekip içindeki kültür ve iletişim sorunları daha fazla etkili olabilir.
- 25:33Farklı Teknolojilerde Code Review
- Farklı teknolojilerden kişilerin code review yapması, aynı business lojiklerin üzerinden geçtiği için etkili olabilir.
- Projedeki kişiler, kod okuma bilgisi gerektirdiği için genellikle review yapabilirler, özellikle genel geçerli konulara odaklanabilirler.
- Productçılar bile, projenin model ve logic kısmını anlayarak code review yapabilirler.
- 27:33Code Review Atlanabilir mi?
- Code review, unit test gibi bazı süreçler atlanabilir, ancak atlanırsa ekip birbirinden haberdar olmayacak ve sorunlar çözülemeyecek.
- Code review atlanabilir, ancak minimum bir süre bile olsa yapılması gerekir; örneğin bir saat içinde otomatik olarak gerçekleşebilir.
- Code review genellikle atlanmamalı, ancak deadline durumlarında (özellikle gece saatlerinde) atlanabilir, ancak bu durum çok sık yaşanmamalıdır.
- 29:02Code Review Atlanmanın Sonuçları
- Gece yazılan kodlar genellikle sıfırdan tekrar yazılır veya yıllarca öyle devam eder ve sonraki geliştiriciler tarafından lanet edilir.
- Acil durumlarda (müşteri bekliyor, uygulama patlıyor) code review atlanabilir, ancak şirketin geliştiricilerin arkasında olması önemlidir.
- Gece veya mesai saatinden sonra feature yazılmalı, ancak acil bir fix yapılması durumunda code review atlanabilir.
- 30:34Code Review'un Dezavantajları
- Code review'un en büyük dezavantajı, yapılan işleri geciktirmesidir; geliştiricilerin vaktinin %10-20'si code review'a gider.
- Kısa vadede code review geliştirme sürecini yavaşlatır, ancak uzun vadede yaşanabilecek problemleri daha hızlı çözdüğü için toplam zaman zararını hesaplamak zordur.
- Code review sırasında basit konulardan çıkan tartışmalar efor kaybına neden olabilir, bu durum şirketin kültür ve iletişim stratejilerine bağlıdır.
- 33:52Code Review Optimizasyonu
- Code review tartışmalarını çözmek için code review guidelines oluşturmak önemlidir ve bu doküman sürekli güncellenmeli ve kolay erişilebilir bir yerde saklanmalıdır.
- Bazı konularda (örneğin compute variable kullanımı) esneklik bırakılmalı, herkesin kendi stilini uygulayabilmesi için.
- Code review sırasında kişisel ilişkilerle karıştırılmamalı, arkadaşlık ve profesyonel değerlendirme ayrılıp tutulmalıdır.
- 36:47Code Review ve Dezavantajları
- Code review sürecinde genellikle takım içindeki veya takım kültüründeki bozukluklardan veya code review yapılmamasından kaynaklı dezavantajlar oluşabiliyor.
- Code review yapılıyorken kod kalitesinde düşüklük olabilir, ancak bu durum genellikle olmuyor.
- Code review süreci, kod yazarının daha dikkatli olmasına neden olabilir çünkü daha sonra düzeltmek daha zor olabilir.
- 37:33Code Review ve Çalışma Ortamı
- Arkadaşlık ortamında çalışanlar, code review sürecinde özensiz davranabilirler çünkü arkadaşlarına iş atmış oluyor gibi hissedebilirler.
- Code review olmadan üç-dört saatte yazılabilen bir özellik, onbeş dakika-yarım saatte yazıp geçilebilir.
- Git story'lerin temiz tutulması önemli, aksi takdirde komitler düzeltmek için vakit harcanabilir.
- 38:40İyi Code Review İçin Gerekli Şartlar
- İyi bir code review için commit'ler atomik olmalı ve review sürecinde bitirilebilecek şekilde olmalı.
- Commit mesajları ve story'ler anlamlı olmalı, böylece geri döndüğünde istenen şey hızlıca görülebilsin.
- Code review için kod parçası güzel olmalı ve okuyan kişiye yeterli bilgi vermelidir.
- 39:27Commit Mesajları ve Revizyon Süreci
- Commit mesajlarında feature'ı yazmak, teknik olarak nasıl implement edildiğini belirtmek ve gerekirse screenshot eklemek faydalı olabilir.
- Commit'lerin atomik olması gerekiyor, böylece isteyenler commit-by-commit revizyon yapabilir veya podcast'e tek seferde bakabilir.
- Revizyon sürecinde, commit mesajları kötüyse ona da review yapılabilir ve geri döndürülebilir.
- 40:53Fix Commit'leri ve Atomiklik
- Fix commit'leri atarken özen gösterilmeli, çünkü özensiz düzeltmeler revizyon sürecini yorucu hale getirebilir.
- Fix commit'leri atarken de descriptive commit mesajları kullanılmalı, böylece ne için atıldığının anlaşılması kolaylaşır.
- Yeni kod yazıldığında fix commit ile birlikte gitmesi hoş olmaz, çünkü bu iki farklı işlemi karıştırır.
- 42:20Büyük Commit'ler ve Bölünme
- Bazı durumlarda çok büyük commit'ler gerekebilir, örneğin bir feature bin satır kod gerektirebilir.
- Büyük commit'lerde review süresini uzatmak ve herkesin bakmasını beklemek gerekir, ancak bu alışkanlık edinmek kötüdür.
- Büyük commit'lerde review oturumunu ara vermek ve parçalara bölmek faydalı olabilir.
- 43:35Atomik Commit'lerin Önemi
- Line sayısı arttıkça revizyonun verimliliği azalır, bu nedenle mümkün olduğunca atomik commit'ler atılmalı.
- Eğer bir kişi kodu atomik şekilde atamıyorsa, genellikle kod kopyalanmış olabilir ve süreç içinde yazılmamıştır.
- Büyük commit'lerde, içindeki değişikliklerin commit-by-commit bakılabilmesi önemli bir avantajdır.
- 48:02Kod Kalitesi ve Otomatik Araçlar
- Boşluk, parantez gibi manasız değişiklikleri otomatik araçlarla yapmak, insanların vakit kaybetmesini önler.
- Otomatik araçların zorunlu olması gerekir, aksi halde projelerde binlerce warning olabilir ve bu durum mantıklı değildir.
- Otomatik araçların en az CI sistemlerindeki sert kurallar kadar sıkı kurallarla çalışması kod kalitesini artırır.
- 49:31Kod Kalitesi ve Otomatik Kontrol
- Kod kalitesini kontrol etmek için otomatik araçlar kullanılmalı, manuel kontrolde bazı hatalar kaçırılabilir.
- Yeni bir proje oluşturulduğunda ilk yapılacak işlerden biri kod kalitesi araçlarının entegrasyonu olmalıdır.
- Otomatik kontrol araçları, süslü parantezlerden önce boşluk bırakma gibi detayları kontrol edebilir ve zaman kazandırır.
- 50:04Otomatik Kontrolün Faydaları
- Manuel kontrolde yüz satırda bir yerde bir boşluk veya parantez görmeyebilirsiniz, bu nedenle otomatik kontrol araçlarına güvenmek önemlidir.
- Otomatik kontrol araçları, süslü parantezli fonksiyonlar gibi detayları kontrol edebilir ve warning'leri kabul edilebilir seviyeye düşürebilir.
- Fonksiyon kontrolü, uzunluk kontrolleri ve fonksiyonu bir satır yapma uyarıları gibi anlamlı kontroller yapılabilir.
- 51:05Storyboard ve Memory Kontrolü
- Storyboard'lar otomatik kontrol edilmesi zor olabilir, belli bir deneyim ve tecrübeye ihtiyaç duyabilir.
- Memory kontrolü yapılabilir, kompletion gördüğünüz her yere weak referansları kontrol edilmiş mi diye bakılabilir.
- Delegate isimlerini otomatik kontrol eden yapılar ve dispatch ya da thread kullanımlarına dikkat edilmesi gerekebilir.
- 52:18Tasarım ve Değişiklik Kontrolü
- Büyük değişiklikler yapmamak genel olarak her platformda önemli, özellikle iOS'ta.
- Değişikliklere göz atmak önemlidir, bir değişiklik yapıldıktan sonra unutulup başka bir değişiklik yapılabilir.
- Proje dosyasında ilk kodun yaptığı değişiklikler olabilir, bunları takılmamak gerekir.
- 53:41UI ve Retain Cycle Kontrolü
- Storyboard'larda yerleşim hataları ve label'ların içinde default text olması gibi basit hatalar kontrol edilebilir.
- Retain cycle'lar kolay bir şekilde tespit edilebilir, Rio'da bunları çözmek kolay olsa da projeye soktuktan sonra çıkarmak zor olabilir.
- Proje izin gerektiren cihaz fonksiyonallıkları içeriyorsa, izin konfigürasyonlarına dikkat edilmelidir.
- 56:15Diğer Kontroller ve Projeyi Temizleme
- Proje dosyalarını düzenli tutmak sapıtmaları azaltabilir ve kodun okunmasını kolaylaştırır.
- Kullanılmayan değişkenler ve kod parçaları temizlenmelidir.
- Projeyi oluşturmak için tuğlalar gibi araçlar kullanılabilir, böylece ortada bir proje dosyası olmadığı için bazı sorunlar ortadan kalkabilir.