Yaratıcı kodlamanın nesi kötü? [kapalı]

Bu akşam Bob Ross'un "mutlu ağaçları" boyamasını izliyordum ve son zamanlarda kodumla ilgili beni neyin strese soktuğunu anladım.

Buradaki ve Yığın Taşması ile ilgili olan topluluk, herhangi bir kusurlu kokuyu reddediyor gibi görünüyor. Amacım, becerilerimi geliştirerek saygın (ve bu nedenle de sürdürülebilir ve işlevsel) bir kod yazmak. Yine de yaratıcı bir şekilde kod yapıyorum.

"Yaratıcı kodlama" ile ne demek istediğimi açıklayayım:

• Bir projedeki ilk adımlarım genellikle oturmak ve bazı kodları silmek. Daha büyük şeyler için, burada biraz orada plan yapıyorum ama çoğunlukla dalıyorum.
• Projede başka parçalar yaratan başkalarıyla çalışmadığım sürece derslerimin hiçbirini çizemiyorum. O zaman bile, kesinlikle yaptığım ilk şey değil. Genelde büyük projeler üzerinde çalışmıyorum ve görseli çok kullanışlı bulmuyorum.
• Yazdığım ilk kod çevrimi, orijinal kesimi yeniden kullanılabilir, mantıklı ve verimli bir şeye dönüştürdüğümde, çoğu kez yeniden yazacak ve tekrar deneyecek.

Bu işlem sırasında hep temizliyorum. Kullanılmayan kodu kaldırıyorum ve açık olmayan herhangi bir şeyi yorumluyorum. Sürekli test ederim.

Sürecim, profesyonel geliştirici topluluğunda kabul edilebilir olanın grenine karşı geliyor gibi görünüyor ve nedenini anlamak istiyorum.

Kötü kodla uğraşmanın çoğunun, birisinin eski bir çalışanın karmaşasına sıkışmış olduğunu ve düzeltilmesi çok zaman ve paraya mal olduğunu biliyorum. Anladım. Anlamadığım şey, sonucumun her şeyi baştan planlamakla elde edeceğinize benzer olması koşuluyla sürecimin nasıl yanlış olduğu. (Ya da en azından bulduğum şey buydu.)

Konuyla ilgili endişem son zamanlarda o kadar kötüydü ki, üzerinde çalışmakta olduğum sorunu çözmek için her yöntemle ilgili olan her şeyi öğrenene kadar kodlamayı bıraktım. Başka bir deyişle, çoğunlukla kodlamayı tamamen bıraktım.

Konuyla ilgili görüşleriniz ne olursa olsun, girişinizi takdir ediyorum.

Düzenleme: Cevaplarınız için hepinize teşekkür ederim. Her birinden bir şey öğrendim. Hepiniz çok yardımcı oldunuz.

Kod testi-refactor-yinelemede yanlış bir şey yok, insanlara prototip yaptığınızı söyleyin.

Öte yandan, daha büyük projeler için, tasarımın ön kısmına verilen bazı düşüncelerin sizi çok fazla zaman kazandıracağını göreceksiniz!

Not: Diyagram teknikleri, siz hiç kimsenin diyagramlarınızı görmeseniz bile değerli olan görsel düşünme becerilerini öğrenmenize yardımcı olur.

Sınıf / arabirimin "ItemVisitor" (?!) Gibi desen adlarını içerdiği, görsel olarak sunulan, UMLed, tasarım desenli kodların her zaman net, okunabilir, basit kodlarını tercih ederim. Tasarım kalıpları, OO teknikleri ve diğer her şey kuralları resmileştirmektir. Bu kurallar sağduyudan gelir.

Bu formalizasyon olmadan çalışmak mümkün değildir (kendi projenizde yalnız çalışmadığınız sürece) ve aşırı formalizasyon proje maliyetlerini arttırır. Başkalarının kodunuzu anlama gereksinimlerini asla dikkate almayın. En iyi kod en basit olanıdır.

Asla kodunuzu tekrar yazmaktan çekinmeyin. Bunun için X'in aşağı oylarını (X> = 10) alacağım, ama bunu cesur kılacağım: kodun tekrar kullanılabilirliği en önemli şey değil .

Kodlama bakan önce sen gerektiğini kullanım-durumlarda dikkate kod uygulamaya gidiyor. Çünkü yazılım kullanılmalı ve geliştirilmemelidir. Kullanılabilirlik, kullanışlılık en önemli iki hedeftir ve bu yazılımı kimin kullanacağı önemli değildir - projenin bağımlı kısımlarının başka bir geliştiricisi veya son kullanıcı.

Ben de aynı şekilde. Diğer insanlar size kendileri için işe yarayan şeyleri anlattıklarında dinleyin, ancak "ahlaki" bir zorunluluk varmış gibi yapması gerektiğini söyleyenleri görmezden gelin. İşinize yarayacak bir şey bulursanız, devam edin. Demek istediğim, sonuçta önemli olan bu değil mi? Oraya gitmek için attığın yolu gerçekten kim önemsiyor?

Unutma: insanlar farklı . Bu iyi birşey. Sizi onlardan hoşlanmaya çalışan insanları dinlemeyin ve başkalarının da sizin gibi olmasını sağlama dürtüsüne direnmeyin.

Öyle görünüyor:

1. En iyi yaklaşımı bulmak için malzeme denemek (deneme, artımlı tasarım)
2. Kodu daha temiz hale getirmek için yeniden yazma (yeniden düzenleme)
3. Sürekli yazma testleri (test odaklı geliştirme)

Yaptıkların harika! Mükemmel bir şekilde yapıyorsunuz gibi görünüyor, özellikle kendiniz çözdüyseniz ve (çevik) bir programlama kitabından öğrenmediyseniz. Açıkçası bundan daha fazlası var, ancak değerleri çivilenmiş. Sadece kodu eklerken yeniden tasarlamayı ve tasarımı geliştirmeyi unutmayın; bir BDUF'a gerek kalmaz .

Her seferinde bir küçük özelliğe odaklanmayı ve her bir özellik tamamlandıktan sonra bırakmayı düşündünüz mü ? Bu, uğraştığınız herhangi bir analiz probleminden kurtulmanıza yardımcı olabilir ve işvereninize gerçek bir ilerleme gösterdiğini gösterir.

Ayrıca, ne hakkında "profesyonel gelişim topluluğu" hakkında konuştuğunuzu da bilmiyorum, ama siz olsaydınız onlara fildişi kulelerine dönmelerini söylerdim, böylece işinize devam edebilirsiniz!

Brad, yalnız değilsin. Senin tarif ettiğin gibi çalışan çok iyi programcılar biliyorum. :)

Eğer kodunuzu temizlerseniz ve onu nasıl verimli ve okunaklı hale getireceğinizi biliyorsanız, o zaman kesinlikle nasıl temiz ve verimli bir kod yazacağınızı da hissettiniz.

Ayrıca, hiçbir şey önceden tam olarak planlanamaz ve inceliklerini keşfetmenin en kısa yolu genellikle kodu çalıştırmak ve gözden kaçan ayrıntıları anlamaktır.

Bence gayet iyi yapıyorsunuz ve tarif ettiğiniz programlama tarzının tamamen geçerli olduğunu düşünüyorum.

Yukarıda verilen cevapları, yaygın olarak "SICP" olarak bilinen ve "Bilgisayar Programlarının Yapısı ve Yorumlanması" adlı tanınmış MIT kitabının önsözünden Alan J. Perlis'in verdiği bir alıntıyla tamamlamaya değeceğini düşünüyorum:

Her bilgisayar programı akılda taranmış, gerçek ya da zihinsel bir işlem modelidir. İnsani deneyimlerden ve düşüncelerden kaynaklanan bu süreçler sayıca çok büyük, ayrıntılı olarak karmaşık ve herhangi bir zamanda sadece kısmen anlaşılmış. Bilgisayar programlarımız tarafından nadiren kalıcı memnuniyetimize modellenmiştir. Dolayısıyla, programlarımız özenle el yapımı ayrı sembol koleksiyonları, birbirine kenetleme fonksiyonlarının mozaikleri olmasına rağmen, sürekli evrim geçirir: Model algımız derinleştikçe, genişlediğinde, model sonuçta başka bir modelin içinde hala kullanılabilir bir yere gelene kadar genelleşir. mücadele ediyoruz. "

İyi Zeki ve Kötü Zeki.

İyi Zekice - zeki kod satırları arasında zekice olmayan bir alternatifin satırları arasındaki yüksek oran. Sizi 20000'den kurtarabilmenizi sağlayan 20 kod satırı, Son derece İyidir. İyi Zeki, kendini işe almakla ilgili.

Zayıf Zeki - yazılı kod satırları arasında kaydedilen düşük kod oranları arasındaki oran. Beş satırlık kod yazmanızı engelleyen akıllı kod satırı Bad Clever'dir. Kötü zeki "sözdizimsel mastürbasyon" hakkında.

Sadece not etmek gerekirse: Kötü Zeki neredeyse hiç "Kötü Zeki" olarak adlandırılmaz; sık sık "güzel", "zarif", "özlü" veya "özlü" takma adları altında seyahat eder.

İş akışınızı tarif ettiğiniz şekilde kendimi kesinlikle tanıyabilirim. İşte size bir şey var: bir grup ortamında çalışmaya başladığımda, NAD'nin değişmesi gereken neredeyse hepsi.

Yaklaşık 8 aydır çalıştığım iş gerçekten bir geliştirici ekibinde tek bir projede çalışmak konusundaki ilk deneyimim. Şimdiye kadar, kelimenin tam anlamıyla benim tüm kariyerim ekip çalışmasıyla gelen her şeyle uğraşmak zorunda kalmayan bir kurt adam kodlayıcısıydı. Bir grupta çalıştığım zaman bile, her zaman oldukça sessiz bir iş oldu - benim MINE olan projemi ya da bunun bir kısmını da MINE vb. Yaptım. Gerçekten işbirlikçi ekip çalışma ortamı.

İşte anladığım en önemli şey: ne yaptığınız kanlı değilse, muhtemelen bir meslektaşınızın bir sonraki baş ağrısını yazıyorsunuzdur. Burada gördüğünüz "süreç odaklı" sıkıntıların çoğu, çoğumuzun baş ağrısı meslektaşı OLDUĞU gerçeğiyle ilgilidir. Ve çoğu yazılım süreç yönetimi teorisi bu baş ağrısını en aza indirgemeyle ilgilidir.

Dolayısıyla, önceden kararlaştırılmış bir plan planlamak gibi şeyler, vs.… Gemide ve senkronize bir ekip kurmakla ilgili. Eğer takımsanız, kendiniz ile zaten senkronize olursunuz ve bu gerçekten gerekli değildir.

Yaratıcı bir sanat formu olarak yaklaşımınızda yanlış bir şey yok. Kişisel çıkarlar için gelişiyorsanız ve yaptıklarınız sizin için çalışıyorsa ve zevkli buluyorsanız, ürünün kendisi kadar nihai sonuç kadar önemlidir.

Profesyonel bir çalışma ortamında, eğer proje zaman ölçekleriniz kısa olabilirse, belki de 2-3 hafta veya daha azsa, yaklaşımınıza hızlı prototipleme denir ve gelecekteki görevlere oldukça uygundur.

Ancak, daha uzun projelerde, kendi başınıza çalışırken bile, böyle bir yaklaşım muhtemelen işvereniniz için pahalı bir lüks. Proje bütçesinin birkaç gününü ön mimari tasarım için harcayarak mimariyi test etmenin neye göre değiştirmeye karar vermesi halinde test edilmesi normalde iyi zaman harcanır ve daha değerli bir programcı / mimar olma becerilerinizi geliştirir. Kariyerinde

İki bakış açısı:

1. Kimse bir resim yapmak zorunda değildir.

2. Bob Ross'un bir tabloyu boyamasını izleyen herkes, resimlerin bir yapıya sahip olduğunu bilir. Bob Ross'tan bir ders alacak olsaydınız, önceden plan yapmak ve düzenli bir şekilde çalışmak, sürecin sorunsuz ilerlemesini ve basit görünmesini sağlardı.

Hemen hemen aynı şekilde kodladım. Ben sadece yazmaya başlayacağım ve ortaya çıkan kalıpları gördüğüm gibi, yeniden düzenleyeceğim. Kendinizi bu şekilde bir köşeye boyayabilirsiniz, ne zaman arkana oturacağınızı ve bir problemi düşüneceğinizi bilmeniz gerekir, ancak bazen sorunu gerçekten anlamak için bir bıçak atarsınız .

Ama bunu merak ediyorum:

Buradaki ve Yığın Taşması ile ilgili olan topluluk, herhangi bir kusurlu kokuyu reddediyor gibi görünüyor. [..] Sürecim, profesyonel geliştirici topluluğunda kabul edilebilir olanın grenine karşı geliyor gibi görünüyor ve nedenini anlamak istiyorum.

Yığın Taşması'ndaki herhangi biri işleminizi nasıl bilebilir ? Ve "reddetmek" ile ne demek istiyorsun? Doğal olarak, bir programlama topluluğuna gönderilen kod eleştirel bir şekilde incelenecektir. Ancak eğer biri kodunuzun geliştirilebileceği alanlar görürse, bu sadece iyi bir şey olabilir, değil mi?

Umarım, Stackframe'e bir soru gönderirken, kodunuzu temizlersiniz ve okuyucularınıza saygılı olmaktan kaçınmak için kodunuzu temizler ve mümkün olan en basit şekle indirmeyi denersiniz (bazen kendi sorununuzu sadece başkalarına karşı duyarlı hale getirmeye çalışırken) Herhangi bir geri bildirim iyi durumda. Kötü olduğunu bildiğiniz bir kod gönderiyorsanız ve neden göndermeden önce neden kötü olduğunu biliyorsanız , insanlar kötü olduğunu fark ederse kişisel olarak almamalısınız .

Ben de yaklaşımını kullanıyorum. Benim için daha iyi çalışır, çünkü aşırı mühendislik riskini azaltır.

Çok sık yaptığım, muhtemelen gereksiz bir bağımlılığa veya diğer tasarım sorunlarına yol açan, muhtemelen mümkün olan en az kodla bir sorunu çözmek. Sonra çalışma kodunu güzel bir kodda yeniden tanımladım.
Örneğin, farklı modüller arasındaki bağımlılıkları azaltmak için arayüzleri özlüyorum ve her modül sadece diğer modüllerin minimalist soyutlamalarına dayanana kadar hangi verilerin tutulması gerektiği sorusunu sorguluyorum. Hangi modülün hangi sorumluluğa sahip olması gerektiğini son kararı erteleyebilirim diyebilirsiniz. Soyutlamayı erteledim.
Bir problemi farklı sorumluluklara, farklı soyutlamalara ayırmaya çok fazla düşünce koymak iyi değildir. Yaptığınız soyutlamaları uyacak şekilde uygulamanızı bükmeye zorlayacaktır. Kod, istediğiniz sonuçları üretirse ve bakımı yapılabilirse çalışır. İyi bir kodla uygulayabilirsiniz eğer bir tasarım çalışır. Kod işe yaramazsa, değiştirirsiniz. Ergo, bir tasarım işe yaramazsa, onu da değiştirmeniz gerekecek. Bir tasarımın işe yarayıp yaramadığını ancak uyguladıktan sonra görebilirsiniz.

Dolayısıyla aklınıza basit bir taslak çizmek, onu hayata geçirmeye başlamadan önce bir tasarım kadar yeterli. Gerektiği gibi yeniden tasarlayın, özetleyin ve yeniden düzenleyin .

Eğer programlamada iyi olacaksanız, en azından bazen eğlenceli olması gerektiğini düşünüyorum ve bu yaratıcı olmak demektir.

Elbette, gruplar halinde programlama yaparken, "ahlaki" nedenlerden dolayı değil, uygulandıklarında pratik olanlar için takip edilmesi gereken en az asgari standartlar vardır.

Bunun dışında, orada ne bulunabileceğini görmek için sınırları araştırmak ilginç ve eğlenceli. Bir kez montaj dilinde bir Mini üzerinde çalışırken, 1 talimatla birinden diğerine geçebilecek ortak rutinleri yapabileceğinizi keşfettim. Sonra, iki adım ileri, bir adım geri, vb. Gidebilecek öz-bir rutinin nasıl yapıldığını öğrendim. Şüpheliyim. Konu o değil.

Bir zamanlar Edsger Dijkstra'nın bir konuşmasını duydum, programlamada yaratıcılıktan bahsettim. Bir öğrencinin n-bit kelimesini n-bit döndürmenin bir yolunu nasıl bulduğunu anlattı. 3 bit bit ile yapıldı. Önce n bitlerini değiştirirsiniz, sonra m bitlerini değiştirirsiniz, sonra n + m bitlerini değiştirirsiniz. İşe yarar? Hayır. Zeki mi? Evet.

Aklı başında hiç kimsenin yapamayacağı şeyleri denemekte özgürsünüz.

Bu, "tek beden herkese uymuyor" durum olabilir. Tarzınızı üzerinde bulunduğunuz projeler için çalıştınız, peki bununla kim tartışacak? Ancak, burada ve SO'da okuduğunuz eleştiriler, daha büyük projeler üzerinde veya ekip üyeleri arasında karmaşık koordinasyon gerektiren projeler üzerinde çalışıyor olabilir.

Birden fazla geliştirici arasında işbirliğini içeren daha büyük projelere dahil olsaydınız, gelişim tarzınız bir problem haline gelebilirdi. Bunu programlamak zor, ilerlemenizi takip etmek zor ve programcı arkadaşlarınızın işlerinin birazını, işinizin ne yaptığını bilmenize bağlı olarak planlamanıza imkân yok.

Büyük bir proje sizinkine benzer bir geliştirme stili benimsediğinde neler olabileceğini görmek için Code Dreaming okumakla ilgilenebilirsiniz .

Metodunuzun yanlış olmadığına dair çok fazla güvence, ancak bazı kişisel deneyimlerimi eklememe izin verin. Yolunuza başladım, ancak bu arada genel yapının en azından bir kısmını önceden planlamanın faydasını öğrendim ve bunun birkaç nedeni var:

• en büyük ilave, biraz çalışıldığında hangi kodun tekrar kullanılabileceğini görmenin daha kolay olmasıdır. Genellikle yazarken, ekranımın yanında asılı kaldığım genel şemada başka bir bölüm için aniden yararlı görünen bir kod parçası yazarım (sadece benim için okunabilir bir tarzda kağıda çizilir).

• Bir şemaya sahip olmak, sadece kodu değil aynı zamanda şeması da yeniden denetlemenizi sağlar. Bazen, aniden programın diğer bölümleri için de yararlı görünen bir sınıf yazmakla meşgulüm. Sonuç olarak, proje çalıştığında program daha da basitleşir.

• Her zaman bu şemayı, gerekli girdi ve işlev / yöntemlerin çıktısını ve sınıflardaki mevcut yuvaları da güncellediğimde güncellerim. Bu, bitlerin tekrar kullanımı için daha hızlı gider: Neyin tam olarak neyin girip neyin girdiğini kontrol etmek için her seferinde koda dalmam gerekmez. Yorumlarda olsa bile, yorumları almak için göz atmam gerekiyor

Aslında, yöntemini de kullanıyorum. Sadece başladım, deniyorum, yeniden ateşledim, tekrar deniyorum, başka bir parçayı değiştirdim, ama döngünüm de şemayı içeriyor. Ve bu bittiğinde, bu kod üzerinde çalışan bir sonrakinin bilgilerini ekliyorum.

Dikkat et, bu yalnız çalıştığım projeler için. Aynı kod üzerinde daha fazla kişiyle çalışıyorsanız, önceden planlama yapmak yalnızca mantıklı değil, aynı zamanda önemlidir. Ama sanırım bunu zaten biliyorsun.

Diğerlerinin de dediği gibi: bu benim yöntemim, kilometreniz değişebilir.