Her ikisi de olamazsa kodum KURU veya okunabilir olmalı mı?


14

Basit bir şifreleme egzersizi için Ruby kodu yazıyorum ve bu ikilemde sık sık çalıştım (bilmeniz gerekiyorsa egzersiz bir solitaire şifresidir). Bu, mantığı, tekrarlamayı ortadan kaldıran ve / veya hata fırsatlarını en aza indiren özlü, hatta yoğun ifadeler yerine işlevi okunabilir hale getiren açıklayıcı değişkenler ve tek adımlı ifadelerle doldurup doldurmamam gerektiği sorusudur.

En son örneğim: Programım girdi alıyor ve katı biçim yönergeleri nedeniyle, girdinin şifrelenmesi veya şifresinin çözülmesi gerekip gerekmediğini kolayca belirleyebilir. Basitleştirmek için, şifreleme anahtarı ve mesajı uyumlu olacak şekilde dönüştürüldükten / oluşturulduktan sonra, istenen çıktıyı elde etmek için anahtarı şifrelenmiş mesajdan çıkarmak veya şifrelenmemiş bir mesaja anahtar eklemek meselesidir (anahtarı şifreleme olarak düşünün, mesaj + şifreleme = kod; kod - şifreleme = mesaj). NEM ALMA konumu bana şifrelenmiş iletimi şifrelenmemiş iletimden farklı bir şekilde dönüştürmem gerektiğini söylüyor, böylece şifreleme anahtarını alan ve iletiye uygulayan işlevin hiçbir zaman ayırt edilmesi gerekmez. Ben fonksiyon bazı ifadeler iç içe eğer gerekir anlamına gelir ama mantık sağlam görünüyor. Ancak bu kod kolayca okunamaz.

Öte yandan, uygulama şifreleme veya şifre çözme belirlediğinde ayarlanan bir bayrağa dayalı olarak adlandırılan iki farklı işlev yazabilirim. Bu, okunması daha kolay olur, ancak bir iletiye şifreleme anahtarının uygulanmasının üst düzey işlevini çoğaltır (şifrelenmesine veya şifresinin çözülmesine neden olur).

Okunabilir koda mı yoksa özlü koda mı dayanmalıyım? Yoksa bu işlevselliği elde etmenin ve her iki ilkeyi de yerine getirmenin başka bir yolunu kaçırdım mı? Bu, projenin amacını göz önünde bulundurması ve bu amaca hizmet etmek için en iyi kararları vermesi gereken bir ölçekte mi konum?

Şimdiye kadar, okunabilir kod üzerinde özlü, KURU kod vurgulamak eğilimindedir.


2
Önce kullanılabilir, KURU ikinci, Okunabilir üçüncü. Son derece kullanılabilir kod, DRY ve okunabilirliği daha kolay karşılayan son derece okunabilir tüketim koduyla sonuçlanır. Bu nedenle, daha iyi yapılamazlarsa, kötü karmaşıklıkları almak ve güzel bir API ile bir yere koymak istersiniz; en azından onlarla etkileşime giren kod, bu yaklaşımla da kötü olmaktan kaçınacaktır.
Jimmy Hoffa

4
bazı gerçek kod örnekleri yardımcı olabilir, ben kuru ve okunabilir kod
jk

2
Kopya değil. Kısa - okunabilir ve DRY - okunabilir çok farklı iki karşılaştırmadır. KURU olmak özlü olmamaktan çok daha tehlikelidir.
djechlin

Sadece çoğaltılmış kodun daha okunabilir olduğunu varsayarak tuzağa düşmeyin, çünkü tahmin edilebilir bir desene düşer. Bu şekilde düşünmenin kolay olabileceğinden şüpheleniyorum, o kadar çok çoğaltan bir sistemi muhafaza edene kadar, bir dalda diğer neredeyse aynı dallarda olmayan ince böcekler bulabilirsin.
KChaloux

"Mesaja şifreleme anahtarını uygulamanın üst düzey işlevi" ile ne demek istediğinizi anlamıyorum. Şifreleme ve şifresini çözme arasında çakışma olduğunu düşünüyorsanız, ortak kısımları hesaba katmak için özütleme yöntemini yeniden düzenleme yöntemini kullanmayı düşünün.
Aaron Kurtzhals

Yanıtlar:


20

KURU bir rehberdir, bir din değildir. Her şeyden önce DRY noktasına götürenler onu çok ileri götürdüler.

İlk ve en önemlisi, kullanılabilir kod çok önemlidir. Kod kullanışlı ve kullanışlı değilse, ... değildir ve ilk etapta yazmanın bir anlamı yoktur.

İkincisi, bir gün, birinin kodunuzu koruması gerekir. Kodunuz korunamazsa, adınızı lanetlerken "güzel" yoğun, özlü, KURU tasarımınızı kırarlar. Bunu yapma. Ben o kişi oldum ve kod ek açıklamasında belli bir isim gördüğümde titriyorum.

"Açıklayıcı değişkenler" içermeyen yoğun kod oluşturmak ve her şeyi herhangi bir dokümantasyon olmadan lambdalarla iç içe üçlü ifadelere yapıştırmak akıllıca olur. Yapabileceğini bilmek güzel - ama yapma. Akıllı kod hata ayıklamak çok zordur. Akıllı kod yazmaktan kaçının .

Yazılımda geçirilen çoğu zaman yazılımın bakımında harcanır - ilk kez yazılmaz. Kodu (veya bir başkasının) hataları hızlı ve kolay bir şekilde düzeltebilmeniz ve birkaç ideal tasarım kırma değişikliği ile gerektiği gibi özellikler ekleyebilmesi için yazın.


Sezgisel ya da değil, göz ardı ettiğim bir sorunla karşılaştınız. Bu egzersiz için olabildiğince 'akıllı' kod yazıyorum, sadece yapabileceğimi bilmek için, ki bunu bilmek güzel, ama burada seninle kötü bir uygulama olduğu konusunda hemfikirim. Şimdi, yapmam gereken çok şey var.
lutze

1
@lutze Ben perl ve bazen yakut kodlayıcı ve kesinlikle orada akıllı kod yazma cazibesini anlayabiliyorum. Bu cevabın bir ön yazı versiyonu, Larry Wall'den hubris üzerine bir alıntı içeriyordu - bunun bir gün korunacak kodla çalışırken çok önemli bir erdem olduğuna inanıyorum. Dillerin olası tersliği nedeniyle, zeki yoğun kodları denemek yerine daha fazla kod yazma avantajına sahip olmak bazen zor olabilir.

17

DRY'yi anladığınız soruya dayanarak emin değilim. DRY kodu kısa ve öz değildir. Çoğu zaman tam tersi olur.

Burada, bu örnek için önemli olan şeyin ne olduğundan emin değilim. Şifrelemek için bir işlev, şifresini çözmek için bir işlev, ortak işlevsellik için yardımcılar (bayt bayt) ve giriş almak ve şifrelemek / şifresini çözmek için basit bir ön uç yapın ...

Bununla birlikte, genel olarak, kodun korunmasına ve genişletilmesine yardımcı olmak için hem DRY hem de okunabilirlik mevcuttur. Tüm senaryolar eşit değildir, küçük bir tekrarı kaldırmak için büyük bir okunabilirlik iyi değildir ve küçük bir okunabilirlik eklemek için bir sürü çoğaltma da değildir.

Basılırsa okunabilirliği tercih ederim. Yinelenen kod hala test edilebilir - okunamayan kod yanlış şeyi yapmanıza (ve test etmenize) neden olur.


Harika noktalar, gerçekten DRY ilkesini özlü kodun amacı ile birleştirdim.
lutze

12

Özel durumunuzu bilmiyorum, ancak bazı genel yönergeler verebiliriz.

Hem okunabilirliğin hem de KURU'nun amacı sürdürülebilirliktir .

Sürdürülebilirlik, çoğu durumda kodu yazmaktan daha fazla zaman harcayacağınız için önemlidir. Kod yazmanın özel bir bakım türü olduğunu düşünüyorsanız bu özellikle doğrudur.

Ne yazık ki, DRY genellikle yanlış anlaşılmaktadır. Bu kısmen çok basit göründüğü için, ancak birçok basit şey gibi, iyi ... karmaşık olabilir.

DRY'nin amacı her işlevsellik biriminin tek bir yerde mevcut olmasıdır. İlke takip edilirse, bu işlevselliği değiştirmek veya doğrulamakla görevli kod bakıcısı kodla bir kerede ilgilenebilir. KURU takip edilmezse, işlevselliğin bazı kopyalarının düzgün bir şekilde muhafaza edilmemesi çok gerçek bir tehlikedir.

DRY'nin en şiddetli ihlali, tüm kod bloklarının kod tabanında tekrarlanan şekilde kopyalandığı kopyala yapıştırma kodlamasıdır. Bu benim deneyimimde şaşırtıcı bir şekilde yaygındır ve okunabilirliğe katkıda bulunmaz. Bu nedenle, ortak bir yöntem sunmak için kodu yeniden düzenlemek DRY uyumluluğunu ve okunabilirliğini her zaman artırır.

İkinci en şiddetli ihlal ise "kopyala-yapıştır ve biraz değiştir". Yine, parametrelerle bir comon yöntemini tanıtmak veya bir işlevi adımlara ayırmak ve ortaklıkları soyutlamak neredeyse her zaman okunabilirliği arttırır.

Daha sonra, işlevselliklerin çoğaltıldığı ancak kodun farklı olduğu daha ince ihlaller var. Bu her zaman kolay değildir, ancak ortak kodu tek bir yönteme / sınıfa / işleve çekmeyi gördüğünüzde ve bu kod daha önce olduğundan daha kolay okunabilir.

Son olarak, tasarımın tekrarlanması durumları vardır. Örneğin, durum şablonunu kod tabanınızda birkaç kez kullanmış olabilirsiniz ve bu tekrarı ortadan kaldırmak için yeniden düzenleme yapmayı düşünüyorsunuz. Bu durumda dikkatli olun. Daha fazla soyutlama seviyesi sunarak okunabilirliği azaltabilirsiniz. Aynı zamanda, işlevselliğin kopyalanmasıyla değil, soyutlamanın kopyalanmasıyla gerçekten ilgileniyorsunuz. Bazen buna değer ... ama çoğu zaman buna değmez. Yol gösterici ilkeniz "bunlardan hangilerinin daha sürdürülebilir olduğunu" sormak olacaktır.

Bu karar çağrılarını her yaptığımda insanların kodu korumak için ne kadar zaman harcayacaklarını düşünmeye çalışıyorum. Kod temel iş işlevselliği ise, muhtemelen daha fazla bakıma ihtiyaç duyacaktır. Bu durumlarda kodu, kod tabanını ve ilgili soyutlamaları bilen kişiler için sürdürülebilir hale getirmeyi amaçlıyorum. Tekrarlamayı azaltmak için biraz daha soyutlama getirmekten mutlu olurum. Buna karşın, nadiren kullanılan ve nadiren sürdürülen bir komut dosyasının, çok fazla soyutlama içeriyorsa, bakımcılar için kavranması daha az kolay olabilir. Bu durumda tekrar tarafında hata yapardım.

Ayrıca ekibimin diğer üyelerinin deneyim düzeyini de göz önünde bulunduruyorum. Deneyimsiz geliştiricilerle "süslü" soyutlamalardan kaçınırım, ancak daha olgun gruplarla tanınmayan tanınmış tasarım desenlerinden yararlanırım.

Sonuç olarak, sorunuzun cevabı, kodunuzu en sürdürülebilir hale getiren şeyi yapmaktır. Senaryonuzda bunun ne anlama geldiğine karar vermek size kalmış.


Sanırım sorunlardan birini tam olarak çiviledin. Çoğaltmamaya çalıştığım işlevsellikte verdiğim örnek, soyutlamanın çoğaltılmasıdır.
lutze

+1. Şu anda kopyalama ve yapıştırma işlemlerini kötüye kullanan bir sistemle uğraşıyorum. Bir dışarı Faktoring tek benim sınıfların bugün 400 hattı üzerinden kaldırıldı kopya / yapıştırılan koddan yöntemi. Ne yazık ki, 900 hat yönteminde buldum ...
KChaloux

1
İki kod yapılar halen aynı şeyi, ama birindeki değişiklik genellikle olursa değil / kopyalama, diğer bir değişiklik anlamına daha iyi faktörlü ortak işlevsellik daha uzun olabilir yapıştırın. Kod, karakter için iki karakter özdeş yöntem kullanıyorsa, aynı şeyi farklı amaçlar için yapıyorsa ve yöntem seçimini sürekli olarak gerekli amaca dayandırıyorsa, daha sonra bu amaçlardan biri için biraz daha yapılması gerekiyorsa, sadece uygun olanı değiştirerek yöntemi yalnızca etkilenmesi gereken davranışları etkiler. Tek bir ortak yöntem kullanmak değişikliği daha zor hale getirebilirdi .
supercat

7

DRY yapmaya çalıştığınızda işlevleriniz daha karmaşık ve daha uzun (böylece daha az okunabilir) hale gelirse, yanlış yaparsınız. Bir işleve çok fazla işlevsellik koymaya çalışıyorsunuz, çünkü bunun aynı kod parçalarını ikinci bir işlevde tekrar etmekten kaçınmanın tek yolu olduğunu düşünüyorsunuz.

Kodu KURU yapmak neredeyse her zaman daha küçük işlevler için ortak işlevselliği yeniden düzenlemek anlamına gelir. Bu işlevin her biri orijinal işlevden daha basit (ve dolayısıyla daha okunabilir) olmalıdır. Orijinal işlevdeki her şeyi aynı soyutlama düzeyinde tutmak için, bu, başka bir yerde kullanılmayan ek parçaları yeniden düzenlemek anlamına da gelebilir. Orijinal işleviniz daha sonra küçük işlevleri çağıran bir "yüksek düzey işlev" haline gelir ve bu da küçülür ve daha basit hale gelir.

Bunu yapmak sonuç olarak kodunuzda farklı düzeylerde soyutlamalara yol açar - ve bazı insanlar bu tür kodların daha az okunabilir olduğuna inanır. Deneyimlerime göre, bu bir yanılgıdır. Buradaki kilit nokta, daha küçük işlevlere iyi adlar vermek, ikinci bir kişi tarafından kolayca kavranabilecek iyi adlandırılmış veri türleri ve soyutlamalar sunmaktır. Bu şekilde "KURU" ve "okunabilirlik" yalnızca çok, çok nadiren çatışmaya girmelidir.


2

Buradaki soruna neyin sebep olduğundan tam olarak emin olmasam da, deneyimim DRY ve okunabilirliği çeliştiğinde bir şeyi yeniden düzenleme zamanı geldiğini söylüyor.


0

Haftanın her günü DRY yerine okunabilir (= sürdürülebilir) seçerdim. Gerçekte her ikisi de çoğu zaman aynı hizadadır, DRY kavramını alan biri genellikle (çoğunlukla) okunabilir kod üretir.


2
hiçbir açıklama yapmadan, başka birinin aksi görüş bildirmesi durumunda bu cevap işe yaramayabilir. Örneğin, birisi "haftanın herhangi bir gününün okunması yerine DRY (= sürdürülebilir) 'i seçerim" gibi bir talep gönderirse, bu cevap okuyucunun iki karşıt görüş seçmesine nasıl yardımcı olur? Düşünün düzenlemek daha iyi bir şekle ing
tatarcık

0

Kariyerimde çok çok çok çok çok az kez DRY'ye karşı okunabilirliği gösteren meşru bir dava buldum. Önce okunabilir yapın. Şeyleri iyi adlandırın. Gerekirse kopyalayıp yapıştırın.

Şimdi geri çekil ve kendi resmine bakmak için geri adım atan bir sanatçı gibi yarattığın bütünlüğe bak. Artık tekrarı doğru bir şekilde tanımlayabilirsiniz.

Tekrarlanan kod ya kendi yöntemine göre yeniden düzenlenmeli ya da kendi sınıfına çekilmelidir.

Tekrarlanan kod son çare olmalıdır. Önce okunabilir VE KURU, tekrarlanan kodun kapsamını sınırlarsanız okunamaz hale gelir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.