Bir programcının zaman zaman kendi kodları üzerinde% 100 netliğe sahip olmaması normal midir? [kapalı]

Uzman bir programcı değilim, bu yüzden bu olabilir, ancak karmaşık kod oluşturduğumda (yakın zamanda yaptığım bir Satranç oyunu gibi), programı çalıştırmak için doğru kodu yazabildiğimi fark ettim, bunu daha sonra - hatta birkaç saniye sonra bulsam da! - Sık sık duraklatmam ve düşünmem gerekir, bu nasıl çalışır?

Sadece bu değil, aynı zamanda kod hakkında düşünmek eğilimindedir ve bunun yerine sadece yazın. Örneğin, Satranç oyunumda, hamleleri işlemek için beş boyutlu bir dizi kullanmaya karar verdim ve bunu çok fazla bilinçli düşünmeden yapabileceğimi buldum. Ancak, durduğumda ve okuduğumda, başımı beş boyutlu kavramın etrafında döndürmeyi zor buldum ve ne yaptığımı ve kodun nasıl çalıştığını tam olarak anlamanız birkaç dakika sürdü.

Karmaşık kod yazarken programcıların yarısının ne yaptığını anlamaması normal midir?

Hayır, normal değil ¹ . En azından iyi programcılar için normal değil. Muhtemelen bir program öğrenme birisi için normaldir.

Yazma yazılımı, kod satırlarını çalışana kadar birlikte tokatlamak değildir. Kodun anlaşılmasını kolaylaştırmak için bilinçli olarak çalışmanız gerekir. Bir zamanlar çok saygı duyduğum bir programcı bana "kod yazıldığından daha fazla okunur" dedi . Bu tamamen açık olsa da, bana söyleyene kadar farkında olmadığım bir gerçekti. Kodunuzun çoğu yalnızca bir kez yazılır, belki bir veya iki kez daha yeniden yazılır, ancak yazılımın ömrü boyunca kodu sık sık okursunuz.

Kodu yazdıktan birkaç dakika sonra anlamakta zorlanıyorsanız, bu kodunuzun çok karmaşık olduğuna dair bir işarettir. Kod eklemeyi bırak ve daha iyi bir yol bul. Örneğin, beş boyutlu bir dizi neredeyse hiç iyi bir fikir değildir. Gerçekten bile, gerçekten akıllı programcılar böyle karmaşık bir veri yapısını anlamakta zorlanırlar.

Bana kod okunabilirliğinden bahseden aynı programcı "bana veri yapılarınızı gösterin ve size kodunuzun nasıl çalıştığını söyleyebilirim" dedi . Yani, iyi kod temiz, anlaşılır veri yapılarıyla başlar. Verilerinizi doğru tasarlarsanız, kod neredeyse ikincil bir konudur. Kuşkusuz, bu ifade biraz abartılıdır, çünkü yazılım açıkçası sadece verilerden daha fazlasıdır, ancak verilerle başlar . Bu nedenle, temiz, kolay anlaşılır veri yapıları yaratmaya çalışın ve kodun anlaşılması oldukça kolay olacaktır.

¹ Kesinlikle orada en akıllı programcılar tarafından bile çok karmaşık ve anlaşılması zor bir kod var. Bazı problemler doğal olarak karmaşıktır. Ancak, programcıların büyük çoğunluğu tarafından yazılan kodun büyük çoğunluğunun bu tür bir kod olmadığını söylemeye çalışacağım.

Bunun iki türü vardır: 1.) karışıklık 2.) mutlu cehalet

İlki kötüdür ve zaman ve deneyim ile kaybolabilir.

İkincisi, projeler büyürse iyi bir şeydir: Kodunuzla çalışabilmek için her uygulama detayını hatırlamanız gerekiyorsa, bununla ilgili bir sorun var (bkz. "Bilgi gizleme").

Her geliştirici, kodun nasıl çalıştığını unutacaktır, bu yüzden başka bir yeni geliştiricinin, programın kendisi tarafından bilinmeyen diğer bölümlerini kırmadan anlayabileceği ve koruyabileceği bir şekilde yazacaktır.

Yani "bilmemek" aslında yazılım geliştirmede sabittir - sadece nasıl ya da yönettiğiniz.

İnsanların itiraf etmeyi umduklarından daha yaygın olduğunu söyleyebilirim. Brian Kernighan bile bunu dile getirdi:

Hata ayıklama, kodu ilk etapta yazmaktan iki kat daha zordur. Bu nedenle, kodu olabildiğince akıllıca yazarsanız, tanımı gereği, hata ayıklamak için yeterince akıllı değilsinizdir.

Mağazaya giderken, pedalların ve direksiyon simidinin konumlarında bir dizi ayrıntılı ayar yaparız. Şu anda bu çok kolay. Şimdi, bu ayarlamaları kağıda kaydettiğinizi ve bunları mağazaya yönlendirilmesi gereken bir arkadaşınıza verdiğinizi düşünün.

Benzer şekilde, bir soyutlama düzeyinde kod yazmaktan hoşlanırız, ancak bunu daha yüksek soyutlama katmanlarında okumak isteriz. Kod yazmanın ve okumanın tercih ettiğimiz yolu bu nedenle çelişkilidir. Bu, kodun okunmasını kolaylaştırmak, genellikle farklı becerilere sahip ayrı ve bilinçli bir adımdır.

İyi bir programcı yapan şey, az önce yazdıklarını okumakta zorlandıklarında, o noktada bir soyutlama yaratırlar. Daha iyi bir programcı bunu defalarca yapar ve her seferinde piknik yapar. Sonunda, deneyimli programcılar süreç boyunca daha da başlarlar, ancak yeni yazdıklarını okuduktan sonra hala iyileştirme için yer görebilirler.

Bence bu tecrübeyle ortadan kalkacak bir şey.

Karmaşık sistemler yazıyorsanız, hem gelecekte hem de gelecekte başkalarının anlayabileceği temiz, sürdürülebilir bir kod yazma yeteneğine sahip olmanız gerekir. Yani, özünde, şu anda yaptığınız şey ölçeklenebilir değil.

6 ay önce yazdığınız bir koda baktığınız ve "burada ne oluyor?" Diye düşündüğünüz birçok anınız olacak, ancak kodu yazdıktan bir gün sonra gerçekleşirse, 'temiz' kod 'daha fazla.

Kaynak: 5 boyutlu dizi kullanmadım :)

"Normal" çok özneldir, bu yüzden diyorum ki: çok yaygındır, ancak kaçınılmalıdır.

"İyi kod" (böyle bir şey var duydum) özelliklerinden biri açıklıktır: altta yatan sorunlar olmasını sağlar gibi açık olmalıdır. Sorun karmaşık, kod yanı karmaşık olacaktır, ama bu doğasında aksine, karmaşıklık kazara (Ben ilk bu ayrım duymuş karmaşıklığı Zengin Hickey konuşma ) MIS- tarafından tanıtılan veya sağ araçları, desen, teknikler kullanılarak değil ve uygulamaları.

Sorun çok karmaşık olmasa bile netlik eksikliğinin kabul edilebilir olduğu durumlar vardır , örneğin, pazarlama kampanyası devam ettiği sürece süreceğini bildiğiniz bir tanıtım sitesi yazarsanız. Bu, sürdürülmesi gereken bir atma kodu. Diğer (ve çoğu) durumda, kabul edilemez, çünkü böyle bir kodun korunması çok maliyetli olacaktır. Ancak, yaygındır.

İlişkili:

• Anlamak Yeniden Yazmak demektir - kodu anlama sorunu hakkında makale.
• Etkili ML - ML / OCaml arasında, "okuyucular" (yani koruyucular) için kodun nasıl yazılacağı hakkında uzun bir konuşma: "Okuyucuları yazarlara tercih edin." Hangi dili kullanırsanız kullanın bunu izlemenizi tavsiye ederim.

Bunun normal olduğunu düşünmüyorum, ancak bahsettiğiniz satranç programı gibi çok karmaşık programlar için kesinlikle mümkün olduğunu düşünüyorum.

Yıllar önce, ilkokuldan çıktığımda (bu yüzden hala büyük programlar yazarken nispeten deneyimsizdim), ilk gerçek derleyicimi yazdım. Ayrıştırma basitti, ancak daha sonra dört farklı mikroişlemci komut seti için hedeflemem gerekiyordu. Derleyiciyi kendi dilinde yazmayı amaçladım, bu yüzden ilk önce sadece kesinlikle ihtiyacım olan dilin özelliklerini kullandım, ilk kod üreticisini montaj dilinde yazdım ve dilin alt kümesi için doğru kod ürettiğini test ettim. Daha sonra derleyiciyi o andan itibaren derlemek ve kalan özellikleri eklemek ve bunları derleyicinin kendisinde kullanmak mümkün oldu.

Daha sonra her mikroişlemci için arka uç kod üreteçlerini yazdım ve hepsinin doğru kod ürettiğini test ettim, ancak doğru olsa da çok uygun değildi. Bu yüzden her kod üreticisi için optimize ediciler yazmaya başladım.

Tüm optimizasyonları ekledikten sonra kod üreticilerinin çıktısını test ederken, derleyicinin ürettiği koda sık sık şaşırdım. Genellikle kodu elle yazmamın yolu değildi, ama doğru ve oldukça özlü.

Kod üretecinin yaptığı kodun bazılarını nasıl ürettiği bana belli olmadığında, mantığı elle takip etmeye çalıştım ama sadece vazgeçtim. Çok fazla iz çıktısı eklemiş olsaydım bunu takip edebilirdim, ancak üretilen kod tatmin edici olduğundan ve diğer projelere girmem gerektiğinden rahatsız etmedim.

Burada çok iyi cevaplar var.

Bunu bir kaç kez ele alacağım.

Birincisi, kodunuzun neden işe yaradığını görmüyorsanız, o zaman a) muhtemelen (muhtemelen sadece işe yaramış gibi görünüyor ) ve b) sorunlu etki alanını yeterince iyi anlamadınız kodlamaya başladı veya sorun etki alanını başlamadan önce daha küçük, basitleştirilmiş birimlere bölmedi.

Bu konudaki diğer düşüncem, asıl anahtarın kodunuzda sağduyulu kalıpları ve kuralları kullanmaktır. Bu, küçük bir gönderinin ele alabileceğinden çok daha büyük bir konu. Ancak, "Kod Tamamlandı" ve "Katı Kod Yazma" kitapları gibi bazı eski standbysler de dahil olmak üzere, konuyla ilgili iyi literatür arayın.

Uygulama ayrıntıları değişir. Tek gerçek sabit kodun işlevsel amacıdır. Birden fazla işlev yazarsanız, zaman içinde belirli, ayrıntılı uygulama ayrıntılarını unutacaksınız. Ancak parçaları oluştururken kesinlikle nasıl çalıştığını ve bütünün bir diyagramını çizebilmeli ve parçaların birlikte nasıl çalıştığını anlayabilmelisiniz.

Kalıpları kullanır ve sağduyu kurallarını uygularsanız, koda tekrar baktığınızda belirli uygulama ayrıntılarını geri almak çok daha kolay olacaktır. Veya daha önce kodu hiç görmemiş biri ilk kez ona baktığında. Ayrıca, zaman içinde bu konvansiyonları ve kalıpları takip etmek, uygulama detaylarının konvansiyonlardan ve kalıplardan ayrılacağı anlamına gelecektir, bu da kodun anlaşılmasını kolaylaştıracak başka bir faktördür.

Yazılımla uğraştığımız sorunların çoğu doğası gereği karmaşıktır. Yazılım tasarımı karmaşıklığı yönetme alıştırmasıdır.

Ben normal demezdim , ama kesinlikle olabilir. Söz konusu kod parçasını yazdıktan kısa bir süre sonra size kalırsa, ya kodunuzun gereksiz yere karmaşık olduğunu ve basitleştirilmesi gerektiğini ya da kolayca dikkatinizin dağıldığını tahmin ediyorum. :)

Ancak kodunuzu kaldırırsanız, diğer projelere yoğunlaşırsanız ve haftalar, aylar hatta yıllar sonra geri dönerseniz, hepsini tekrar anlamanız çok şaşırtıcı değildir.

Ama bu konuda yapabileceğiniz bir şey var. Söylediklerinize göre, yazarken kodunuz hakkında yeterince düşünmüyorsunuz ve böylece gelecekteki kendinizin neler olduğunu anlamasını zorlaştırıyorsunuz. Bu bilgiyi kendi yararınıza kullanın: Bu, iyi yapılandırılmış, iyi belgelenmiş, anlaşılabilir bir kod üretmek için en iyi motivasyon. İlk elden deneyimlerden, kodunuzun kalitesine dikkat etmezseniz ne olacağını bilirsiniz. Bunun uzun vadede daha iyi bir programcı olması gerektiğini bilmek. Yazılım projelerinde işbirliği yaptığınızda, iş arkadaşlarınız anlaşılabilir kod ürettiğiniz için teşekkür eder. Kodunuzun hata oranı da artacaktır.