Altbilgi içeriğine atla
Iron Academy Logo
C# Yaygın Sorunlar

50 Satır Kodu Okumak mı Yoksa Extract Method Refactoring mi Kullanmak? - Derek Comartin'den İçgörüler

[[academy-video-youtube({"vid": "MtVqasDREkg", "start_time": "0", "title": "50 satır okumaktansa 'Extract Method' Yeniden Düzenlemesi", "creator": "Derek Comartin", "length": "9m 16s"})]]

Yazılım geliştirme dünyasında, yeniden düzenleme esastır. En yaygın ve teşvik edilen tekniklerden biri, kodun okunabilirliğini ve tekrar kullanımını iyileştirmek için büyük bir kod parçasını daha küçük, yeniden kullanılabilir yöntemlere ayırmak olan Extract Method Yeniden Düzenlemesidir. Bu, teoride mükemmel gibi görünse de, Derek Comartin, '50 satır okumaktansa Extract Method Yeniden Düzenlemesi' adlı videosunda taze ve eleştirel bir bakış sunuyor.

ayrıntıları

Örnek: Bir Sohbet Sisteminde Kullanıcı Kaydı

Video başında, Derek bir örnek sunuyor: bir sohbet sistemi için bir kayıt özelliği. Bu, yaklaşık 50 satırdan oluşan, birden fazla görevi yerine getiren kompakt ama gerçekçi bir kod bloğudur:

  • Kullanıcı adının boş olmadığını kontrol eder

  • Kullanıcı adının zaten alınmış olup olmadığını doğrular

  • Yaş sınırına sahip kanalları ele alır

  • Yeni kullanıcı nesnesini kaydeder

  • Bir aktivasyon bağlantısıyla bir e-posta gönderir

Bu kod, tek bir işlevde bulunur ve ilk bakışta, extract method yeniden düzenlemesi için harika bir aday gibi görünebilir. Ama Derek, etkisini anlamadan körü körüne yeniden düzenlemenin aslında netliği bozabileceği konusunda uyarıyor.

Yeniden Düzenlemeye Başlama: Extract Method'u Seçme

Derek, birçok geliştiricinin yaptığı gibi başlar - kod parçasını daha küçük parçalar haline getirir. Çoğu IDE veya kod düzenleyicisinde, Extract Method'u sunduğu gibi, bağlam menüsü veya bir klavye kısayolu yoluyla nasıl seçeceğini gösteriyor.

Şunları çıkarır:

  • kullanıcıAdınıDoğrula, kullanıcı adının boş olmadığını doğrular

  • mevcutKayıtBekleyenAktivasyon, etkinleştirilmeyen bir hesabı kontrol eder

  • mevcutKullanıcıyıDoğrula, tüm mevcut kullanıcı kontrollerini ele alır

  • yaşaGöreSınırlıKanallarıSüz, 18 yaş altı kullanıcılar için kanalları işler

  • e-postaGönder, karşılama e-postasını gönderir

Her yeni işlev, temiz kod uygulamalarında sıkça önerilen ipuçlarından biri olan anlamlı bir ad alır. Ama bu yeni versiyonlardan geçtikçe, Derek mantıksal çatlakları, işlevsellikte değil, okunabilirlik ve kontrol akışında görmeye başlar.

Sorun 1: Gizli Uygulama Detayları

Derek'in ortaya çıkardığı ilk tehlike sinyallerinden biri, uygulama detaylarının şimdi çıkarılan metotların arkasında gizlenmiş olduğunu belirtir.

Örneğin, kullanıcıAdınıDoğrula ve mevcutKullanıcıyıDoğrula yöntemleri aslında istisnalar fırlatır. Ancak yeniden düzenlenmiş kodu okuyan bir geliştirici olarak, iç mekanlarını incelemedikçe bunun farkında olmazsınız.

Bu türden bir yeniden düzenleme, kontrol mantığını gizleyebilir ve hatalara veya atlanan doğrulamalara yol açabilir. Kapsam ve akış artık net değildir. Kodu daha açık hale getirmek yerine, mantığın aslında orijinal olarak yazıldığı formda artık görünür olmayan istisnalar veya değiştirilmiş değişkenler gibi yan etkilerin bulunduğu soyutlamalar labirenti yaratıyorsunuz.

Sorun 2: Yönlendirme ve Zincirleme Çıkarım

Sonra, Derek yönlendirme sorunu üzerinde durur - bir çıkarım metot başkalarını çağırdığında ve böylece devam ettiğinde. mevcutKullanıcıyıDoğrula yönteminin kendi içinde mevcutKayıtBekleyenAktivasyon'dan oluştuğunu gösteriyor.

Artık yukarıdan aşağıya doğru okunan düz bir kod bloğu okumuyorsunuz. Gerçekten ne olduğuna dair izlemek için yöntemler, dosyalar ve sınıflar arasında geziniyorsunuz. Ve editör bu akışı yönlendirmeye yardımcı olsa da, okuyucunun bilişsel yükü üzerinde bir yük haline gelir.

Bu, yeniden düzenlemenin birden fazla dosya veya bileşen üzerinden yayıldığı daha büyük sistemlerde daha da acı verici hale gelir. Aniden, 'temiz kodunuz' aslında orijinal 'karışık' 50 satırdan daha zor takip edilir hale gelir.

Sorun 3: Yerel Değişkenler ve Değişen Durum

Bu videodaki en önemli derslerden biri, yerel değişkenlerin ve durum değişikliğinin ele alınmasından gelir.

Derek, yaşaGöreSınırlıKanallarıSüz yöntemine dikkat çeker. Bir sonuç döndürmez - gönderilen kanallar listesini doğrudan değiştirir. Bu, yerel durumu başka bir yöntem içinden değiştiriyorsunuz anlamına gelir ve yöntemi yakından incelemezseniz, bu değişiklik gizlidir.

Bu, bir işlevin ya saf bir işlem olduğunu ya da bir şeyi değiştirdiğini açıkça belirttiği beklentisini bozar. Mantığı bir değer döndürmeyen ama bunları içsel olarak değiştiren yeni bir yöntemle değiştirdiğinizde risk ve kafa karışıklığına neden oluyorsunuz.

Derek'in Yeniden Düzenlenmiş Alternatifi

Peki Derek eski kodunu nasıl gerçekten düzenler?

Çok daha basit bir yaklaşım öneriyor:

  1. Açıklayıcı mantığı yerinde tutun. Boş bir kullanıcı adı için yapılan ilk kontrol, ana yöntemde kalır, çünkü anlaşılması kolaydır ve kod tabanını karıştırmaz.

  2. Sonuçları döndürmek yerine değiştirmeyin. Kanallar listesini değiştirmek yerine, yaşaUygunKanallarıSüz işlevi şimdi filtrelenmiş bir liste döndürüyor. Bu, veri akışını netleştirir ve beklenmeyen yan etkileri önler.

  3. Basit, öngörülebilir çıkarım yöntemlerini kullanın. Diğer tek çıkarımlı yöntem, açıkça bir boolean döndüren ezŞuAnkiKullanıcıZatenEtkinleştirildi mi yöntemidir. Ayrıntıları saklamadan mantığı kapsüllendirir.

  4. E-posta gönderimi gibi satır içi yan etkilerden kaçının. Derek, e-posta mantığını gösterim için yerinde bırakır, ancak gerçek bir sistemde bunun ayrı bir işlem veya iş parçacığında bir olay yoluyla ele alınması gerektiğini önerir - kullanıcı formu gönderimine doğrudan bağlı bir şey değil.

Toplamda, Derek yalnızca iki çıkarım metodunu kullanır ve geri kalan mantığı yerinde bırakır - çünkü bu daha okunabilir, mantığı anlaşılabilir ve kontrol edilebilir hale getirir.

Extract Method Yeniden Düzenleme Üzerine Son İpuçları

Derek'in videosu, extract method yeniden düzenlemeyi etkili bir şekilde kullanmak için bazı pratik rehberlikler sunuyor:

  • Yöntemin tam olarak ne yaptığına dair anlam ifade eden isimler kullanın.

  • Durum değişikliği veya istisna fırlatma gibi yan etkilerden kaçının, eğer bunlar açık değilse.

  • Giriş parametrelerini değiştirmek yerine değer döndürün.

  • Mantığı birden çok soyutlama katmanının arkasına saklamayın.

  • Bir yöntem orijinal formunda okunabilir görünüyorsa, sadece yeniden düzenlemek için onu çoklu fonksiyonlara zorlamayın.

Bazen, en iyi soyutlama hiç soyutlama yapmamaktır - özellikle netlik ve kapsam farkındalığının bedeli söz konusu olduğunda.

Sonuç

Derek Comartin'in yaklaşımı, yeniden düzenlemenin her zaman kodu iyileştirdiği fikrine meydan okuyor. Extract method yeniden düzenleme durumunda, daha az genellikle daha fazladır. Mantığınızı küçük dilimlere ayırmak için seçili Extract Method'u aşırı kullanmak yerine, neyin değer kattığını, neyin kodunuzu daha anlaşılır hale getirdiğini ve neyin önemli detayları sakladığını değerlendirin.

Gerçek dünyadaki kodlar üzerinde net örnekler ve doğrudan içgörülerle, Derek videosunda bazen tek bir metodda 50 satırın, kod tabanınızda yayılmış on küçük metoddan daha iyi olduğunu gösteriyor.

Yeni bir metod oluşturmak için klavye kısayoluna ulaştığınızda, Derek'in tavsiyesini hatırlayın: duraklayın, değerlendirin ve yeniden düzenlemenin okuyucuya hizmet ettiğinden emin olun - sadece IDE'ye değil.

Hero Worlddot related to 50 Satır Kodu Okumak mı Yoksa Extract Method Refactoring mi Kullanmak? - Derek Comartin'den �...
Hero Affiliate related to 50 Satır Kodu Okumak mı Yoksa Extract Method Refactoring mi Kullanmak? - Derek Comartin'den ...

Sevdiğiniz Şeyleri Paylaşarak Daha Fazla Kazanın

.NET, C#, Java, Python veya Node.js ile çalışan geliştiriciler için içerik oluşturuyor musunuz? Uzmanlığınızı ek gelire dönüştürün!

Iron Destek Ekibi

Haftada 5 gün, 24 saat çevrimiçiyiz.
Sohbet
E-posta
Beni Ara