Okunabilen kodu temizleyin, kodu okumak zor hızlı. Çizgiyi ne zaman geçmelisin?

Kod yazarken kodumu daima olabildiğince temiz ve okunabilir hale getirmeye çalışıyorum.

Her şimdi ve sonra daha hızlı hale getirmek için çizgiyi geçmeniz ve güzel temiz koddan hafif çirkin koda geçmeniz gereken bir zaman gelir.

Bu çizgiyi geçmek ne zaman uygundur?

Çizgiyi geçtiğinizde

• Sen var ölçülen kodunuzu olduğunu istenen kullanım için çok yavaş .
• Kodu almayı gerektirmeyen alternatif iyileştirmeler denediniz.

İşte gerçek dünyadan bir örnek: Çalıştığım deneysel bir sistem çok yavaş veri üretiyordu, çalışma başına 9 saatten fazla alıyordu ve CPU'nun sadece% 40'ını kullanıyordu. Kodu çok fazla karıştırmak yerine, tüm geçici dosyaları bellek içi dosya sistemine taşıdım. 8 yeni çirkin olmayan kod satırı eklendi ve şimdi CPU kullanımı% 98'in üzerinde. Sorun çözüldü; çirkinliğe gerek yok.

Bu sahte bir ikilik. Kodu hızlı ve kolay bir şekilde yapabilirsiniz .

Yapma şekliniz, özellikle olabildiğince basit bir veri yapısıyla, temiz bir şekilde yazmaktır.

Sonra zaman boşalmasının nerede olduğunu ( daha önce değil, yazdıktan sonra çalıştırarak) bulup tek tek düzeltin. (İşte bir örnek.)

Eklendi: Her zaman, zaman ve hafıza arasındaki bir tradeof veya hız ve sürdürülebilirlik arasındaki bir tradeoff gibi haksızlık mı duyuyoruz? Bu tür eğriler iyi mevcut olsa da, verilen herhangi bir programın eğri üzerinde veya hatta yakınında herhangi bir yerde olduğu varsayılmamalıdır .

Eğride bulunan herhangi bir program (belirli bir programlayıcıya vererek) kolayca hem daha yavaş hem de daha az bakım yapılabilir hale getirilebilir ve daha sonra eğri yakınında hiçbir yerde kalmaz. Böyle bir program daha sonra hem daha hızlı hem de daha iyi durumda olması için yeterli alana sahiptir.

Deneyimlerime göre, birçok programın başladığı yer burasıdır.

OSS varlığımda, performansa yönelik pek çok kütüphane çalışması yapıyorum; bu, arayanın veri yapısına (yani kütüphanenin dışına), gelen tasarımlara hiçbir zorunluluğu olmadan (tasarım gereği) bağlıdır. İşte bu yapmak için en iyi yol performant (I .NET-topraklarda olduğum beri) IL-yaydıkları anlamına gelir meta programlama vardır. Bu çirkin, çirkin bir kod, ama çok hızlı.

Bu şekilde, kütüphane kodunun uygulama kodundan daha "çirkin" olabileceğini , girdiler üzerinde daha az (ya da belki hiç) kontrolü olmadığını kabul ettim , bu yüzden farklı mekanizmalar yoluyla bazı görevleri başarması gerekiyor. Ya da geçen gün ifade ettiğim gibi:

"deliliğin uçurumunu kodlamak, böylece yapmak zorunda değilsin "

Şimdi, uygulama kodu biraz farklıdır, çünkü "normal" (akıllıca) geliştiricilerin tipik olarak işbirliği / profesyonel zamanlarının çoğuna yatırım yaptıkları; her birinin hedefleri ve beklentileri (IMO) biraz farklıdır.

IMO, yukarıdaki yanıtların hızlı ve kolay olduğunu gösteren cevaplar , geliştiricinin veri yapıları üzerinde daha fazla kontrole sahip olduğu ve meta programlama gibi araçlar kullanmadığı uygulama koduna atıfta bulunuyor . Bununla birlikte, farklı delilik seviyeleri ve farklı ek yük seviyeleri ile meta programlama yapmanın farklı yolları vardır. Bu arenada bile uygun soyutlama seviyesini seçmelisin. Ancak, aktif olarak, pozitif olarak, gerçekten beklenmedik verileri en hızlı şekilde ele almasını istersiniz ; iyi çirkin olabilir. Onunla başa çıkmak; p

Kodu profilden çıkardığınızda ve gerçekten önemli bir yavaşlamaya neden olduğunu doğruladığınızda.

Hızlı kod, hızlı çalışan kodla ilgili değildir. Normalde okunması zor bir kod yazılmıştır, çünkü daha hızlı çalıştığından değil, daha hızlı yazılmıştır.

"Kirli" kodun daha hızlı hale getirilmesi amacıyla yazılması tartışmasız bir durumdur, çünkü değişikliklerin gerçekten bir şeyleri geliştirdiğini kesin olarak bilmiyorsunuz. Knuth en iyisini koydu:

“Küçük etkinlikleri unutmalıyız, zamanın% 97'sini söyleyelim: erken optimizasyon tüm kötülüklerin köküdür . Ancak bu kritik% 3'teki fırsatlarımızı kaçırmamalıyız. Akıl yürütme, kritik koda dikkatlice bakmakta akıllıca olacaktır, ancak bu kod tanımlandıktan sonra . "

Başka bir deyişle, önce kodu temiz yazın. Ardından, sonuçta ortaya çıkan programın profilini görüntüleyin ve o bölümün gerçekte performans darboğazı olup olmadığını görün. Eğer öyleyse, bölümü gerektiği şekilde optimize edin ve optimizasyonları açıklamak için bol miktarda dökümantasyon yorumu (muhtemelen orijinal kod dahil) eklediğinizden emin olun. Ardından, gerçekte bir iyileştirme yaptığınızı doğrulamak için sonucu görüntüleyin.

Soru “ kodu okumak hızlı zor ” dediğinden , basit cevap asla değildir. Okumak zor bir kod yazmak için asla bir bahane bulamazsınız. Neden? İki sebep.

1. Bu gece eve giderken bir otobüse çarptığınızda ne olur? Veya (daha iyimser ve daha tipik olarak) bu projeden ayrıldı ve başka bir şeye atandı mı? Karışık kod karışıklığınızla yaptığınız küçük yarar, başka hiç kimsenin anlayamadığı gerçeğinden tamamen etkilenir . Bunun yazılım projelerine getirdiği risklerin üstesinden gelmek zor. Bir zamanlar büyük bir PBX ile çalıştımüretici (bir ofiste çalışıyorsanız, muhtemelen telefonlarından birini masanızda bulunduruyorsunuz). Proje yöneticileri, bir gün bana standart bir Linux kutusunu tam özellikli bir telefon alışverişine dönüştüren özel yazılım olan çekirdek ürünlerinin şirket içinde "blok" olarak bilindiğini söyledi. Artık kimse anlamadı. Her yeni bir özellik uyguladılar. derlemeye çarptılar, sonra geriye yaslandılar, gözlerini kapattılar, yirmiye kadar saydılar, sonra işe yarayıp yaramadıklarını görmek için parmaklarını dikizlediler. Hiçbir işletme artık kontrol etmedikleri bir çekirdek ürüne ihtiyaç duymuyor, ancak korkutucu derecede yaygın bir senaryo.
2. Ama optimize etmem gerek! Tamam, bu soruya verilen diğer cevaplarda mükemmel tavsiyelere ulaştınız: kodunuz performans test durumlarında başarısız oluyor, dikkatle profilini belirlediniz, tıkanıklıkları tespit ettiniz, bir çözüm buldum ... biraz bit bükülmeyi içerir . İyi: şimdi devam et ve optimize et. Ama işte sır (ve bunun için oturmak isteyebilirsiniz): kaynak kodunun boyutunda optimizasyon ve küçültme aynı şey değil. Yorumlar, beyaz boşluklar, parantezler ve anlamlı değişken isimleri, derleyici bunları çöpe atacağı için size kesinlikle hiçbir maliyeti olmayan okunabilirlik için büyük yardımlardır. (Veya JavaScript gibi derlenmemiş bir dil yazıyorsanız - ve evet, JavaScript'i optimize etmek için çok geçerli nedenler var - bunlar bir kompresör tarafından ele alınabilir .) Uzun satırlar halinde sıkışık, minimalist kod Burada yayınlanan ) optimizasyon ile ilgisi yok: bu, mümkün olduğunca az karaktere kod yazarak ne kadar akıllı olduklarını göstermeye çalışan bir programcı. Bu akıllıca değil, aptalca. Gerçekten zeki bir programcı, fikirlerini açıkça başkalarına iletebilen bir programcıdır.

Fırlatma kodu olduğunda. Bunu gerçekten demek: Eğer bir kerelik hesaplama veya görevi gerçekleştirmek ve böyle bir kesinlikle bilmek bir senaryo yazarken sen 'rm kaynak-dosya' çekinmeden, ki yine bu eylemi yapmak zorunda asla o seçebileceğiniz çirkin yol.

Aksi taktirde sahte bir ikiliktir - daha hızlı yapmak için çirkin yapman gerektiğini düşünüyorsanız, yanlış yapıyorsunuz. (Ya da iyi kodun ne olduğu konusundaki ilkelerinizin gözden geçirilmesi gerekir. Soruna en uygun çözüm olduğunda goto kullanımı aslında oldukça şıktır. Ancak, nadiren olur.)

Piyasadaki düşük performansın tahmini maliyeti, söz konusu kod modülünün tahmini kod bakım maliyetinden büyük olduğunda.

İnsanlar hala elle kodlanmış SSE / NEON / etc bükülmüş. Bu yılın popüler CPU yongası üzerinde bazı rakiplerin yazılımlarını denemek ve yenmek için montaj.

Unutmayın, okunması zor kodları uygun belgelerle ve yorum yaparak kolayca anlaşabilirsiniz.

Genel olarak, istenen işlevi yapan kolay okunur kod yazdıktan sonra profil. Darboğazlar daha karmaşık görünmesini sağlayan bir şey yapmanızı gerektirebilir, ancak bunu kendiniz açıklayarak düzeltin.

Bana göre stabilite oranı (betonda çimentolu, fırında pişmiş, taşa konmuş, kalıcı mürekkeple yazılmış). Kodunuz ne kadar kararsız olursa, gelecekte onu değiştirmeniz gerekme olasılığı ne kadar yüksek olursa, üretken kalabilmek için ıslak kil gibi olması o kadar kolay bir şekilde bükülebilir olmalıdır. Ayrıca esnekliği ve okunabilirliği vurgulamıyorum. Bana göre kod değiştirme kolaylığı, okuma kolaylığından daha önemli. Kod okunması kolay ve değiştirilebilecek bir kabus olabilir ve eğer değişecek bir kabussa, uygulama ayrıntılarını ne şekilde okuyabilir ve kolayca anlayabilir? Bu sadece akademik bir alıştırma olmadıkça, tipik olarak bir üretim kod tabanında kodları kolayca anlayabilmenin amacı, gerektiğinde daha kolay bir şekilde değiştirebilme niyetindedir. Değiştirilmesi zorsa, sonra okunabilirliğin faydalarının birçoğu pencereden dışarıya çıkıyor. Okunabilirlik sadece esneklik bağlamında faydalıdır ve esneklik sadece kararsızlık bağlamında yararlıdır.

Doğal olarak, okunması ne kadar kolay ya da zor olursa olsun, akla gelebilecek bir kodu bulundurmak zor olsa bile, değiştirmesi için hiçbir neden yoksa, yalnızca onu kullanmayın. Ve böyle bir kaliteye ulaşmak, özellikle performansın çoğu zaman saymaya meyilli olduğu düşük seviyeli sistem kodu için mümkündür. Hala 80'lerin sonlarından beri değişmeyen düzenli olarak kullandığım C kodum var. O zamandan beri değişmesi gerekmedi. Kod titiz, biraz garip günlerde yazılmış ve ben zar zor anlıyorum. Yine de bugün hala uygulanabilir ve uygulamadan bol miktarda faydalanabilmek için anlamam gerekmiyor.

İyice testleri yazmak istikrarı artırmanın bir yoludur. Bir diğeri dekuplajdır. Eğer kodunuz başka bir şeye bağlı değilse, değişmesi için tek nedeni değişmesi gerekip gerekmediğidir. Bazen, az miktarda kod çoğaltması, kararlılığı önemli ölçüde iyileştirmeye yarayan bir takas mekanizması olarak işlev görebilir; bu durumda, karşılığında, şu anda tamamen başka bir şeyden bağımsız olan bir kod alırsanız. Şimdi bu kod dış dünyadaki değişikliklere karşı hassastır. Bu arada, 10 farklı dış kütüphaneye bağlı olan kod, gelecekte değişmesi için 10 kat daha fazla nedene sahiptir.

Pratikte bir başka yararlı şey, kütüphanenizi kod tabanınızın dengesiz parçalarından ayırmak, hatta üçüncü şahıs kütüphaneleri için yapabileceğiniz gibi muhtemelen ayrı ayrı inşa etmektir. takım). Sadece bu tür bir organizasyon, insanların buna müdahale etmesini önleyebilir.

Bir diğeri minimalizmdir. Kodunuz ne kadar az şey yapmaya çalışırsa, ne yaptığını da o kadar iyi yapabilir. Monolitik tasarımlar neredeyse kalıcı bir şekilde dengesizdir, çünkü onlara ne kadar fazla işlev eklenirse, o kadar eksik görünürler.

Mikro ayarlı paralelleştirilmiş SIMD kodu gibi, kaçınılmaz olarak değiştirilmesi zor olan bir kod yazmayı hedeflediğinizde kararlılık birincil hedefiniz olmalıdır. Kodu değiştirme zorunluluğunu ortadan kaldırarak kodu değiştirmek zorunda kalmayacağınız olasılığını en üst düzeye çıkarırsınız ve bu nedenle gelecekte de sürdürmek zorunda kalmazsınız. Bu, kodun bakımı ne kadar zor olursa olsun bakım maliyetlerini sıfıra indirir.