Torvalds'ın iyi programcı hakkında teklifi [kapalı]

Yanlışlıkla Linus Torvalds tarafından şu alıntı üzerine tökezledim:

"Kötü programcılar kod için endişeleniyorlar. İyi programcılar veri yapıları ve ilişkileri hakkında endişeleniyorlar."

Son birkaç gündür bunu düşündüm ve hala kafam karıştı (ki bu muhtemelen iyi bir işaret değil), bu yüzden aşağıdakileri tartışmak istedim:

• Bunun ne yorumu mümkün / anlamlıdır?
• Bundan ne uygulanabilir / öğrenilebilir?

Torvalds’ın bundan önce söylediklerini düşünmeye yardımcı olabilir:

git aslında kararlı ve makul derecede iyi belgelenmiş veri yapıları ile basit bir tasarıma sahiptir. Aslında, kodunuzu veri etrafında, başka bir yoldan ziyade veri etrafında tasarlama konusunda büyük bir savunucuyum ve sanırım git'in oldukça başarılı olmasının sebeplerinden biri olduğunu düşünüyorum […] Aslında, fark olduğunu iddia edeceğim. Kötü bir programlayıcı ile iyi olanı arasında onun kodunu mu yoksa veri yapılarını daha mı önemli göreceği belirlenir.

Söylediği, iyi veri yapılarının kodu tasarlamayı ve sürdürmeyi çok kolaylaştırdığı, ancak en iyi kodun zayıf veri yapılarını oluşturamadığıdır.

Git örneğini merak ediyorsanız, birçok sürüm kontrol sistemi, yeni özellikleri desteklemek için veri formatlarını nispeten düzenli olarak değiştirir. Yeni özelliği elde etmek için yükseltme yaptığınızda, veritabanını da dönüştürmek için sık sık bir tür araç çalıştırmanız gerekir.

Örneğin, DVCS ilk defa popüler olduğunda, birçok insan dağıtılmış modelin merkezi sürüm kontrolünden çok daha temiz birleştirmeler yapmasının ne olduğunu çözemedi. Cevap dağıtık veri yapıları hariç hiçbir şey olduğunu vardı hiç çalışmıyor bir umut olması için çok daha iyi olması için. Merkezileştirilmiş birleştirme algoritmalarının o zamandan bu yana yakalandığına inanıyorum, ancak eski veri yapıları kullanabilecekleri algoritmaları sınırladığından ve yeni veri yapıları birçok mevcut kodu kırdığından, uzun zaman aldı.

Buna karşılık, git'teki özelliklerin patlamasına rağmen, temelindeki veri yapıları neredeyse hiç değişmedi. Önce veri yapıları hakkında endişeleniyorsanız, kodunuz doğal olarak daha temiz olacaktır.

Algoritmalar + Veri Yapıları = Programlar

Kod sadece algoritmaları ve veri yapılarını ifade etmenin yoludur .

Bu alıntı, Torvalds'ın Linux'u yaratması olan "Unix Programlama Sanatı" ndaki kurallardan birine çok aşina. Kitap burada çevrimiçi olarak bulunur

Kitaptan, Torvalds'ın söylediklerini açıklayan alıntı.

Temsil Kuralı: Bilgiyi verilere katlayın, böylece program mantığı aptal ve sağlam olabilir.

En basit prosedürel mantığı bile insanların doğrulaması zordur, ancak oldukça karmaşık veri yapılarının modellenmesi ve nedeni oldukça kolaydır. Bunu görmek için, elli düğmeli bir işaretçi ağacının (yani) bir diyagramının açıklayıcı ve açıklayıcı gücünü, elli satırlık bir programın akış şemasıyla karşılaştırın. Veya bir dönüşüm tablosunu ifade eden bir dizi başlatıcıyı eşdeğer bir switch ifadesiyle karşılaştırın. Şeffaflık ve netlikteki fark dramatik. Rob Pike'ın 5. Kuralına bakın.

Veriler program mantığından daha izlenebilir. Veri yapılarında karmaşıklık ile kodda karmaşıklık arasında bir seçim gördüğünüzde öncekileri seçin. Dahası: bir tasarımın gelişmesinde, karmaşıklığı koddan verilere kaydırmanın aktif yollarını aramalısınız.

Unix topluluğu bu görüşe dayanamadı, ancak birçok Unix kodu etkisini gösteriyor. C dilinin özellikle işaretçileri manipüle etme tesisi, çekirdekten yukarı doğru her kodlama seviyesinde dinamik olarak değiştirilmiş referans yapılarının kullanılmasını teşvik etti. Bu tür yapılardaki basit işaretçi takibi, diğer dillerdeki uygulamaların yerine daha ayrıntılı prosedürler uygulamak zorunda kalacağı görevleri yapar.

Kod kolaydır, karmaşık kodun arkasındaki mantıktır.

Eğer kod hakkında endişe duyuyorsanız, bunun anlamı henüz bu temelleri anlamadığınız ve komplekste kaybedilen (yani veri yapıları ve ilişkileri) demektir.

Morons'un cevabını biraz genişletmek için fikir, kodun özelliklerini (sözdizimi ve daha az bir ölçüde yapı / mizanpaj) anlamak, bunu yapabilen araçlar oluşturabileceğimiz kadar kolaydır. Derleyiciler, işleyen bir program / kütüphaneye dönüştürmek için kod hakkında bilinmesi gereken her şeyi anlayabilir. Ancak bir derleyici programcıların yaptığı sorunları çözemez .

Argümanı bir adım öteye götürebilir ve "ancak kod üreten programlarımız var" diyebilirsiniz, ancak oluşturduğu kod neredeyse her zaman elle yapılan bir girdi türüne dayanır.

Bu nedenle, hangi rotaya giderseniz gidin: bir tür yapılandırma veya bir araç aracılığıyla kod üreten başka bir girişle veya sıfırdan yazıyorsanız önemli olan kod değildir. Önemli olan bu koda ulaşmak için gereken tüm parçaları eleştirel olarak düşünmek. Linus'un dünyasında büyük ölçüde veri yapıları ve ilişkileri var, ancak diğer alanlarda başka parçalar da olabilir. Fakat bu bağlamda Linus, "Kod yazıp yazamayacağın umrumda değil, uğraştığım sorunları çözecek şeyleri anlayabilmenizi umuyorum" diyor.

Linus bunun anlamı:

Bana akış şemalarını göster [kod], ve masalarını [şema] sakla, ben de gizemli olmaya devam edeceğim; bana tablolarını göster [şema] ve genellikle akış şemalarına [kod] ihtiyacım olmayacak: onlar açık olacak.

- Fred Brooks, "Efsanevi Adam Ayı", ch 9.

Genel üst düzey tasarımın (veri yapıları ve ilişkileri) uygulama detaylarından (kod) çok daha önemli olduğunu söylüyor. Bir sistemin tasarımını sadece sistemin detaylarına odaklananlar üzerinde tasarlayabilenlere değer veriyor.

Her ikisi de önemlidir, ancak büyük resmi elde etmenin ve ayrıntılarla ilgili sorunların diğer yollardan daha iyi olmasının genellikle daha iyi olduğu konusunda hemfikir olurum. Bu, büyük işlevleri küçük işlevlere bölme konusunda anlatmaya çalıştığım şeyle yakından ilgilidir .

Tamamen aynı fikirdeyim çünkü hepsi için endişelenmen gerekiyor. Ve bu konuda, programlama hakkında sevdiğim şeylerden biri, nano-saniye hakkında düşünmekten, aylarca düşünmeye ve tekrar tekrar düşünmeye hızla atlayan farklı soyutlama ve boyut seviyelerindeki anahtarlar.

Ancak, daha yüksek şeyler daha önemlidir.

Yanlış davranışa neden olan birkaç problemde bir kusur varsa, düzeltmesi çok zor değildir. Düşük performans göstermesine neden oluyorsa, muhtemelen önemi yoktur.

Bir alt sistemdeki veri yapısı seçiminde bir yanlış davranışa neden olan bir kusur varsa, bu daha büyük bir sorundur ve düzeltilmesi daha zordur. Düşük performans göstermesine neden oluyorsa, oldukça ciddi olabilir veya katlanılabilirse rakip bir yaklaşımdan kayda değer ölçüde daha az iyi olabilir.

Bir uygulamadaki en önemli veri yapıları arasındaki ilişkide yanlış davranışa neden olan bir kusurum varsa, önümde büyük bir yeniden tasarım yapıyorum. Düşük performans göstermesine neden oluyorsa, yanlış davranıyorsa neredeyse daha iyi olacağı kadar kötü olabilir.

Ve bu düşük seviyeli problemleri bulmayı zorlaştıran şey olacak (düşük seviyeli hataları düzeltmek normalde kolaydır, zor olabileceklerini bulmak).

Düşük seviyeli şeyler olduğunu önemli ve kalan önemi sıklıkla ciddi sade, ancak büyük şeyler ile karşılaştırıldığında soluk yok.

Şifreyi bilen biri "ağaçları" görür. Ancak veri yapılarını anlayan biri “ormanı” görür. Bu nedenle iyi bir programcı koddan ziyade veri yapılarına odaklanacaktır.

Verilerin nasıl akacağını bilmek önemlidir. Akışı bilmek, iyi veri yapıları tasarlamanızı gerektirir.

Yirmi yıl geriye giderseniz, bu, SmallTalk, C ++ veya Java kullanarak nesne yönelimli yaklaşım için en büyük satış noktalarından biriydi. Büyük adım - en azından C ++ ile ilk öğrendiğim şey buydu - sınıfı ve yöntemleri tasarlamaktı ve sonra diğer her şey yerine geçecekti.

Kuşkusuz Linus daha geniş bir terimden bahsediyordu, ancak kötü tasarlanmış veri yapıları genellikle başka problemlere de yol açabilecek ilave kod çalışmaları gerektiriyor.

Bundan ne uygulanabilir / öğrenilebilir?

Eğer yapabilirsem, son birkaç haftadaki deneyimim Önceki tartışmalar sorumun cevabını netleştirdi: "Ne öğrendim?"

Bazı kodları yeniden yazdım ve görmeye devam ettiğim sonuçları yansıttım ve "yapı, yapı ..." derken neden bu kadar dramatik bir fark vardı. Şimdi tüm fark yaratan veri yapısı olduğunu görüyorum . Ve hepsini kastediyorum .

• Orijinal teslimatımı test ettikten sonra iş analisti işe yaramadığını söyledi. "30 gün ekle" demiştik, ancak ne demek istediğimizi "bir ay ekle" ( sonuç tarihindeki gün değişmiyor) demiştik. Ayrık yıllar, aylar, günler ekleyin; örneğin 18 ay boyunca 540 gün değil.

• Düzeltme: veri yapısında tek bir tamsayı yerine birden çok tamsayı içeren bir sınıf koyun, yapısındaki değişiklik bir yöntemle sınırlıydı. Gerçek tarih aritmetik ifadelerini değiştirin - bunların ikisi.

Kazanç

• Yeni uygulama daha fazla işlevselliğe sahipti ancak algoritma kodu daha kısa ve açıkça daha basitti.

Kod davranışını / sonuçlarını düzeltme bölümünde:

• Veri yapısını değiştirdim, algoritmayı değil.
• NO kontrol mantığına kodun herhangi bir yerinde dokundu.
• API değiştirilmedi.
• Veri yapısı fabrikası sınıfı hiç değişmedi.

Milyonlarca rastgele ve mükemmel kitap içeren, güzel bir kütüphanede çok zeki bir kütüphaneci ekibi hayal etmeyi çok isterim.

Linus ile daha fazla aynı fikirde olamaz. Verilere odaklanmak, verilen soruna basit ve esnek bir çözümü büyük ölçüde damıtmaya yardımcı olur. Git'in kanıtlanmış bir örneği - gelişim yıllarında desteklenen pek çok özellik vererek, çekirdek veri yapısı büyük ölçüde değişmeden kalıyor. Bu sihir! --2c

Bunun sayısız alan olduğunu gördüm.

İş analizi hakkında düşünün ... Diyelim ki Colgate gibi bir tüketici ürünleri pazarında Pazarlama'yı desteklemenin en iyi yolunu analiz ediyorsunuz. Fantezi pencerelerle veya en son teknolojiyle başlarsanız, işe önce işletmenin veri gereksinimlerini düşündüğünüz gibi işinize yardımcı olmaz ve daha sonra sunum yapmak için endişelenmezsiniz. Veri modeli sunum yazılımını geride bırakıyor.

Bir web sayfası yapmayı düşünün. Önce göstermek istediklerinizi (HTML) düşünün ve sonradan stil (CSS) ve komut dosyası (aracınızı seçin) hakkında endişelenmek daha iyidir.

Bu, kodlamanın da önemli olmadığını söylemez. Sonunda ihtiyacın olanı elde etmek için programlama becerilerine ihtiyacın var. Bu veri temelidir. Kötü bir veri modeli, aşırı karmaşık veya düşünülmemiş bir iş modelini yansıtır.

Kendimi yeni fonksiyonlar yazarken ve mevcut olanları güncellerken veritabanı şemama yeni sütunlar veya tablolar eklemek zorunda kalmayacağımdan daha sık buluyorum. Bu muhtemelen iyi tasarlanmış tüm sistemler için geçerlidir. Şemanızı her değiştirdiğinizde kodunuzu değiştirmeniz gerektiğinde, bunun açık bir işareti olduğu çok kötü bir geliştiricidir.

kod göstergesinin kalitesi = [kod değişiyor] / [veritabanı şeması değişiyor]

"Bana akış çizelgelerini göster ve masalarını gizle, ben de gizemli olmaya devam edeceğim. Bana senin masalarını göster, ve genellikle akış çizelgelerine ihtiyacım olmayacak; açık olacaktır." (Fred Brooks)

Bu fikrin çeşitli programlama türlerinde çeşitli yorumları vardır. Sistem gelişimi için de geçerlidir ve aynı zamanda işletme gelişimi için de geçerlidir. Örneğin, etki alanı odaklı tasarımda odakta odağa keskin bir kaymanın veri yapılarına ve ilişkilere odaklanmaya çok benzer olduğu söylenebilir.

İşte benim yorumum: Veri yapıları oluşturmak için kod kullanıyorsunuz, bu yüzden odak ikincisi olmalı. Bir köprü inşa etmeye benziyor - çekici görünen bir binadan ziyade sağlam bir yapı tasarlamak için yola çıkmalısınız. Öyle ki, iyi yazılmış veri yapıları ve köprüler, verimli tasarımlarının bir sonucu olarak iyi görünüyor.