Programcılar neden dolaylı koddan kaçınmalı?
Bu makale, dolaylı kodla bozulan okunabilirliği tartışmaktadır.
Yazar | Matthew Rocklin
Çevirmen | Crescent Moon, sorumlu editör | Guo Rui
Üretildi | CSDN ( İD: CSDNhaberler)
Aşağıdaki çeviridir:
Sık sık bazı kod yazarlarının ayrıntıları soyutlama için harici bir işleve koyduğunu görüyorum. Lütfen aşağıdaki örneğe bakın.
Dolaylı kodu eklemeden önce:
# main.py eğer x.startswith ("foo"): do_something_with (x)Dolaylı kodu ekledikten sonra:
# main.py is_foolike (x) ise: do_something_with (x) # utils.py def is_foolike (x): return x.startswith ("foo")Bu yaklaşımın nedenleri şunları içerebilir:
-
Kod birçok kez tekrarlanırsa, bu soyutlama kodu daha kompakt hale getirebilir;
-
Kod birden çok kez tekrarlanırsa, bu mantığı merkezi olarak yönetmek için bir yer bulmalısınız, böylece gelecekte onu merkezi olarak değiştirebilirsiniz;
-
Bu soyutlama, düzyazıdaki dipnotlar gibi, işlevin ana noktalarıyla hiçbir ilgisi olmayan ayrıntıları gizler;
-
Bu soyutlama, bir işlem kümesini adlandırmak için satır içi belgeler olarak işlev adlarını kullanır;
-
Kod daha temiz ve daha soyut görünüyor.
Okul öğretmeninin bize öğrettiği buydu - bazı işlevleri bulun, bunları soyutlayın ve devam edin.
Dolaylı durumlardan kaçının
Ancak bu dolaylı kod ekleme davranışının da bir bedeli vardır. Başkaları bu kodu okuduğunda, birden çok dosyada tanımlanan birden çok işlev arasında geçiş yapmaları gerekir. Doğrusal olmayan bu okuma süreci okuyucu için daha fazla enerji tüketir.
Kod yazma sürecinde bu dolaylı kodun eklenmesinde sorun yoktur.Kodu yazan kişinin, kodu yazan kişinin zihninde oluşturulmuş soyut bir modeli vardır.Bu nedenle bu soyutlamayı koda yazmak mantıklı ve iyi hissettirir. Bununla birlikte, başkalarının bir kod parçasını hızlı bir şekilde kontrol etmesi ve anlaması gerektiğinde, büyük sorunlarla karşılaşırlar. Bu iki önemli durumda olur:
1. Kod gözden geçirme süresi boyunca. Başkalarının, ana projeyle birleştirilmeden önce kodun makul olup olmadığını kontrol etmesi gerektiğinde. Bu gözden geçirenlerin harcaması gereken zaman, kod yazmak için zamanın yaklaşık onda biridir.
2. Gelecekte hata ayıklama. Kodda herhangi bir sorun varsa, gelecekte tamamen yabancı olan geliştiricilerin bu koda bakması ve kodun içeriğini bulması gerekecektir. Bu kodu birkaç dakika içinde anlamalı ve ilgili içeriği belirlemelidirler. Kodun arkasındaki tüm düşünme sürecini anlamak için zamanları yoktur ve dolaylı kod, Çok Anlama sürecini yavaşlatın.
Orijinal geliştirme süreciyle karşılaştırıldığında, modern topluluk kodunda inceleme ve hata ayıklama genellikle bir darboğazdır. Bu nedenle, geliştiricileri genellikle soyutlamadan kaçınmaya ve kodun içine işlev tanımları yazmaya teşvik ediyorum.
Hala işlevi kullanmalıyız
Açık olması gereken şey, karmaşık mantığı birden çok işleve bölmek için birçok nedenimiz var, özellikle tekrarlanan kodla karşı karşıya kaldığımızda veya gelecekte bazı önemli politikalar değişebileceğinde. Bu nedenle bir denge bulmamız gerekiyor.
Umarım çoğu durumda kod yazarları, orijinal yazara ek olarak, kodu okuyan herkesin dolaylı kodun ek maliyetini hissedeceğini anlayacaktır.
orijinal: http : // matthewrocklin .com / blog / work / 2019/06/23 / kaçınma-indirection
Yazar: Matthew Rocklin, özellikle verimli ve ölçeklenebilir bilgi işlemle ilgili olarak çoklu kitaplık ekosistemlerini ve koordinasyon Python figürlerini koruyor.
Bu makale bir CSDN çevirisidir, lütfen yeniden basımın kaynağını belirtin.
SON
