"Temiz kod bir aldatmacadır!"
Ne tür bir kod temiz koddur ve ne tür kod değildir? -Aslında temiz kod büyük bir yalan, kimse temiz kod yazamaz.
Yazar | Chad Befus
Çevirmen | Crescent Moon, sorumlu editör | Guo Rui
Aşağıdaki çeviridir:
"Temiz Kod" kitabını seviyorum ve nefret ediyorum.
Bu kitabı yıllarca verdiğim profesyonel bir yazılım mühendisi kursunda kullandım. Bu kitabı bir düzineden fazla kez okudum ve her defasında yeni sonuçlar alıyorum. Bununla birlikte, kitaptaki içeriğin yarısının yanlış olduğunu buldum. Bu kitaptan, diğer kişilerden, akıl hocamdan ve kendi deneyimlerimden öğrendiğim dersleri işlemek istiyorum, ancak ne tür bir kodun "temiz kod" olduğu ile başlamak istiyorum; daha doğrusu, Kod "temiz kod" değildir.
Ne tür bir kod düzensizdir?
Kodun temiz olup olmadığına karar vermedeki sorun, bu amacın tamamen öznel olmasıdır. Yedi deneyimli ve başarılı yazılım mühendisinin temiz kodu tanımlamasına izin verirseniz, sonunda size yedi farklı tanım verecektir. "Temiz Kod" kitabının 7. bölümü bu noktayı kanıtladı.
Öte yandan, kirli kod çok nesneldir. Bir kod parçası yazabilirim ve gördüğüm her mühendis bu kodun bir karmaşa olduğunu kabul eder.
Bu, kirli koddan düzgün koda kadar bir aralık olduğu, bir ucunun nesnel olduğu ve diğer ucunun nesnel olmadığı anlamına gelir. Aşağıdaki şekil bunu kısaca açıklamaktadır.
Yukarıdaki resimde, bir grup mühendis birkaç kod örneğini derecelendirdi. Ardından, her numuneyi ortalama puana göre sıralayın. Belirli bir seviyedeki anlaşma derecesini belirtmek için hata payını kullanırız. Gördüğünüz gibi ortalama puan arttıkça puanın sapması da artıyor.
Temiz kod öznelse, kod yazmak için daha gerçekçi başka hedeflerimiz var mı? Kod dağınıklığını azaltmak bir hedef mi?
Kirli tanımı
Karmaşık kodu açıkça tanımlamadan önce, ilk olarak kodun gerçek kullanımını etkileyen faktörlerin önceliği üzerinde anlaşmalıyız. Aşağıdakilerin belirli bir sıra olmadan önemli yönlerden bazıları olduğunu düşünüyorum.
-
Verimli: İşi tamamlamak için en az kaynağı (zaman, bellek vb.) Kullanın.
-
Sağlam: Giriş yanlış olsa bile makul bir şekilde ele alınabilir.
-
Teslimat: Teslimat süresini en aza indirin.
-
Doğru: İyi girdi alırken, doğru çıktıyı döndürün.
-
Ölçeklenebilir: Yeni özellik eklemenin zorluğu minimum düzeydedir.
-
Çalıştırılabilir: Kodun çalıştırılabilir bir duruma ulaşması için gereken işi en aza indirin.
-
Esnek: Kodun çalışma şeklini değiştirmenin zorluğu minimum düzeydedir.
-
Güvenilir: Kodu değiştirirken herhangi bir hata olmayacağından eminiz.
-
Okunabilir: Başka bir mühendisin kodu anlaması için gereken süreyi en aza indirin.
Bunlar, insanların temiz kodu tanımlarken sıklıkla tartıştıkları alanlardır. Bu faktörlerin önceliğini zihninizde düşünebilirsiniz.
Bu yönler için belirli bir öncelik sıralaması olmadığını söylememe rağmen, öyle değil.Yukarıdaki sıra, aklımdaki öncelik sırasının tam tersi. Kod okunabilirse, tüm mühendisler kodu anlayabilir, bu da diğer yönleri kolayca uygulayabilecekleri anlamına gelir. Aslında, "eski kodu okumak için harcanan zamanın oranı 10: 1'den fazladır. Her yeni kodu yazdığımızda, eski kodu okumamız gerekir." Kodun anlaşılması kolaysa, test etmek, değiştirmek ve çalıştırmak kolaydır. Bu nedenle genişletmek, onarmak, yerleştirmek ve iyileştirmek de kolaydır. Son olarak, gerçek müşterilere teslim edilirse, bazı yerlerde sağlamlığı ve verimliliği artırabilir.
Bu nedenle önceliğimiz dört seviyeye ayrılabilir:
Okunabilir. Güvenilir, esnek ve operasyonel. Ölçeklenebilir, doğru ve teslim edilebilir. Sağlam ve verimli.
Her katman, bir sonraki katmanın gerçekleştirilmesine hizmet eder. Bunun ışığında, dağınık kodu okunması zor kod olarak tanımlayabiliriz.
Kodun okunabilirliği kişiden kişiye değişir, çünkü her geliştiricinin farklı bir deneyim düzeyi vardır ve tanıdık yazılım paradigması, programlama dili, kod tabanı, derleyici, işletim sistemi vb. De farklıdır. Ve en önemlisi, kod okuyucu ile yazar arasında asla tam olarak aynı kültür ve kelime dağarcığı yoktur. Çoğu kişiye okuması en kolay kodu sağlamaya çalışıyoruz.
Dr. Suess'in "Şapkadaki Kedi" adlı kitabı, bu nedenle James Joyce'un "Ulysses" inden (Ulysses) daha fazla okuyucusuna sahiptir. İlki daha geniş bir kitleye sahip olduğu için okumak daha kolay. Elbette hangi şaheserin daha büyük olduğunu tartışabiliriz, ancak hangi kitabın okunmasının daha zor olduğunu tartışmayacağız.
Bence aptallar kodu gözden geçirmede dahilerden daha iyidir (bu yüzden kod incelemelerinde iyi olduğumu düşünüyorum). Bir aptal, akıllı, beklenmedik, yan etkileri olan ve anlaşılması kolay olmayan bir kod parçasıyla karşılaştığında, sıkıntıya girecek ve bu nedenle bu sorunlara işaret etmekten çekinmeyeceklerdir. Ve bir dahi bu kodu okuduğunda, beyni hızlı çalışacak ve tüm kodu kısa sürede sindirecektir. Bir aptal, bir sorunla karşılaştığında bir sorunu nasıl çözeceğini bilemeyebilir, ancak sorunun var olup olmadığını belirlemek, kod inceleme sürecindeki kritik ilk adımdır.
Bu nedenle, aptalların ve dahilerin kendi dezavantajları vardır. Neyse ki, hangisini tercih ederseniz edin, bir şeyi iyi yapmakta ısrar edebilirsiniz: kendinizi ve kod yazma becerinizi sürekli olarak geliştirin.
İşçilik
Tac Mahal'i mimarlık okumanın ilk gününde kimse inşa edemez. Nerede olursan ol, gidecek uzun bir yol var. Açıkça söylemek gerekirse, herkes mükemmellikten uzaktır.
Bir yazar olarak, tıklamaları dolandıran makaleler yazmakla anlamlı makaleler yazmak arasında önemli bir fark vardır. Bu iki yazar türü, Büyük Bin Dünyada nadir değildir ve tıklamaları aldatabilecek makaleler gerçekten daha fazla tıklama alabilir. Ama hangisi olmak istiyorsun?
Bir zanaatkar olarak, insanların övgüleri veya nihai sonucu ölçmenin standardı konusunda endişelenmenize gerek yok. Bağlılığınızla gurur duymalısınız. Ek olarak, teknik becerilerinizi de sürekli geliştirmeniz gerekir.
Zanaatkarların çalışmaları, sektördeki diğer kişiler tarafından övülecek ve nasıl yapılacağını bilmeyenler genellikle onu görmezden gelir. Usta işin kalitesine önem verir, kod yazmak için kodun okunabilirliğidir. Kodunuz mükemmel olmayabilir, ancak karışıklığı en aza indirmeye çalışmalısınız. Ayrıca geçmişin bilgisizliğinden dolayı kendinizi affetmelisiniz. En önemlisi, yeteneklerinizi anlamayan aptallar dahil herkesten bir şeyler öğrenmelisiniz.
Hız önemlidir
Ürün ve proje yöneticileriniz hızınıza önem verecek. Kaliteye önem vermek sizin işiniz. Mükemmel bir yönetici, mühendisliğin zaman ve para açısından kod yazma sürecinin en pahalı kısmı olduğunu anlar, bu nedenle kaynakların bu bölümünü optimize etmek parasal açıdan da mantıklıdır. Yüksek kaliteli, okunabilir kod, sıkıcı kod borcunu en aza indirebilir ve hızı artırabilir. Ancak, naif yöneticilerin yalnızca mevcut sprint veya üç aylık sprintin faydalarına değer vermesi daha yaygındır.
Vergileri idare edecek bir şirket bulduğunuzu hayal edin. Şirket müdürünüz gibidir ve personelin en yüksek kârı elde etmelerini sağlamak için mümkün olan en kısa sürede çok sayıda vergi değerlendirmesini tamamlayacağını umar. Ancak, vergi uzmanlarının işinin kalitesi iyi değilse, şirket davalara, itibar hasarına ve uzun vadeli başarısızlığa maruz kalacaktır. İş kalitesini sağlamak ve bu tür riskleri önlemek vergi görevlilerinin görevidir. Bu her meslek için geçerlidir. Avukatlar ve hizmet şirketleri, doktorlar ve hastaneler, mekanikçiler ve mağazalar. Önceden belirli bir çalışanın iş kalitesine bağlı kalmayacağını biliyorsanız, yine de onları işe almaya istekli misiniz? Yazılım mühendisleri istisna değildir.
Esnaf, işinin kalitesinden ödün vermeden en kısa sürede ürün teslim etmelidir ve bu konuda sağlam bir duruşa sahiptir. Öyleyse, sorumuz, yüksek kaliteli (okunabilir) kod yazma ile yöneticilerin tahammül edebileceği teslim hızı arasında nasıl bir denge kurabiliriz? Benim için en iyi dengeyi bulmanın yolu: Önce sorunu çözmek ve anlamak için kod yazın, ardından okunabilirlik için optimize edin ve son olarak kodu teslim edin. Genellikle, kodumda hala iyileştirme alanı olduğunu biliyorum, ancak teknik seviyem söz konusu olduğunda, bu gelişmeler açıksa, kodu ikinci kez iyileştireceğim. Ve bundan sonra, kodu her değiştirdiğimde veya yeni özellikler eklediğimde tekrarlanan iyileştirmeler yapacağım.
Daha az dağınık kod yazın
İnternette nasıl daha iyi kod yazılacağı konusunda kitaplar, bloglar, videolar vb. Gibi birçok medya tartışması var. Genellikle uymanız gereken bir dizi kuralı sıralarlar. Ancak sorun, bu kuralların genellikle birbiriyle çatışmasıdır. Birçok insan bu kuralların yararsız olduğunu veya göz ardı edilebileceğini düşünüyor. Aslında, yazılım geliştirmede her kuralın istisnaları olabilir, ancak bunları her zaman takip edemeyeceğiniz için mümkün olduğu kadar takip etmeniz gerektiğini inkar edemezsiniz.
Bu alanda birçok kural var, nereden başlamalıyız? benim Önermek aşağıdaki gibi:
1. Basit kurallar ve karmaşık kurallar vardır. Önce basit kuralları öğrenin. Bunlar sizin temelinizdir, bu yüzden bu basit kuralları doğru anladığınızdan emin olun.
2. Her önceliğin çeşitli kuralları vardır: Önce okunabilirlik kurallarını öğrenmeli, sonra ikinci önceliğin kurallarını öğrenmelisiniz.
3. Bazı kurallar sık sık kullanılabilir ve bazı kurallar yalnızca belirli durumlar için geçerlidir.Lütfen önce ilkini öğrenin.
4. Bazı kurallar yanlıştır. Daha basit, daha önemli ve daha pratik birçok kuralla çelişiyorsa, şimdilik göz ardı edilebilir.
Son olarak, çelişen kurallar ne olacak? Bir teknisyen olarak bu sorun kaçınılmazdır ve çözmeniz gereken soruna göre daha yüksek öncelikli bir kural seçmelisiniz.
Gelecekte ne yapmalıyım?
Yavaş yavaş kendi kural kümenizi oluşturun ve kod yazarken bu kuralları izleyin. Bu kurallara uymak bile temiz kod yazmanızı garanti etmeyebilir, ancak en azından kodun dağınıklığını azaltabilir.
Orijinal: https: // hackernoon .com / daha az kirli-kod-2c27321g
Bu makale bir CSDN çevirisidir, lütfen yeniden basımın kaynağını belirtin.
