it-swarm.asia

“Zeki” kod yazmamak için kendinizi nasıl eğitebilirsiniz?

Bu yeni numarayı Expressions ile göstermek veya üç farklı prosedürü genelleştirmek için sadece ihtiyaç hissettiğinizi biliyor musunuz? Bu Mimari Astronot ölçeğinde olmak zorunda değildir ve aslında yardımcı olabilir, ancak yardım edemem ama başka birinin aynı sınıfı veya paketi daha açık, basit (ve bazen sıkıcı) uygulayacağını fark ettim ) tavır.

Sıklıkla problemi abartarak , bazen kasten bazen de can sıkıntısı çeken programlar tasarladığımı fark ettim. Her iki durumda da, tam tersine kanıt görene kadar çözümümün berrak ve zarif olduğuna inanıyorum ama genellikle çok geç. Ayrıca benim bir parçam var tercih ediyor kod çoğaltması için belgelenmemiş varsayımlar ve basitliğe akıllılık.

Ne yapmalıyım “zekice” kod yazma dürtüsüne karşı koyabilirim ve ne zaman zili çalmalı Yanlış Yapıyorum ?

Şimdi deneyimli geliştiricilerden oluşan bir ekiple çalıştığım için sorun daha da zorlaşıyor ve bazen akıllı kod yazma girişimlerim zarafet yanılsamasını dağıttıktan sonra kendime bile aptal gibi görünüyor.

76
Dan

Şimdi deneyimli geliştiricilerden oluşan bir ekiple çalıştığım için sorun daha da zorlaşıyor ve bazen akıllı kod yazma girişimlerim zarafet yanılsamasını dağıttıktan sonra kendime bile aptal gibi görünüyor.

Çözümünüz burada yatıyor. Bu bağlamda "deneyimli" ifadesinin "sizden daha deneyimli" anlamına geldiğini varsayıyorum. En azından onlara açıkça saygı duyuyorsun. Bu değerli bir öğrenme fırsatıdır - egonuzun isabet alabileceğini varsayarsak. (Irksome şeyler, egolar. Onlara çok ihtiyacımız var.)

Bu kişilerle kod incelemeleriniz var mı? Eğer öyleyse, zaten yapmıyorlarsa, açıkça onlardan sizi saçmalıklarınızla aramalarını isteyin. Basit bir pençe çekiç fazlasıyla yeterli olduğunda, aşırı tasarım yapmaya, titizlikle tasarlanmış bir hat üstü pnömatik kırıcıya (tercihen bir tür otomatik yol işçisi Android tarafından kullanılır) kullanma eğiliminde olduğunuzu belirtin. .

Kod incelemeleri sırasında yüzünüz kırmızıya dönerken genellikle kendinizi koltuğunuzda kıvranırken bulabilirsiniz. Tahammül et. Öğreniyorsun.

Sonra, bunlardan birkaçını kemerinizin altına aldıktan sonra, muhtemelen aşırı tasarım yaptığınızdan şüphelendiğiniz anlara dikkat edin. O anlar geldiğinde, kendinize şu soruyu sorun: "Birisi kod incelemesi sırasında beni bu konuda çağırırsa, çözümümü mevcut en iyi çözüm olarak savunabilir miyim? Yoksa terk ettiğim daha basit bir çözüm var mı?"

Bazen, akran incelemesi kendi işinize iyi bir göz atmanın en iyi yoludur.

54
BlairHippo

Yapılacak en iyi şey Brian Kernighan'ın maksimasını aklınızda bulundurmaktır:

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

20
Daniel Roseman

Yazılım sorunlarına genellikle herhangi bir öneme sahip en az üç çözüm vardır: bariz yol, bariz olmayan karmaşık bir yol (akıllı) ve bariz olmayan basit bir yol (zarif). Yazarlar hakkında bir alıntı burada geçerlidir:

Kafanıza gelen her şeyi bırakın ve sonra bir yazarsın. Ancak yazar, kendi şeylerinin değerini acımasız olarak değerlendirebilen ve çoğunu yok edebilen bir yazardır. - Colette

Yazık olmadan kendi kodunuzun değerine karar verene ve çoğunu yok edene kadar zarif kod yazamazsınız. Zarif kodu nihai sonuca göre değerlendirirseniz, aldatıcı bir şekilde kolay görünüyor, ancak yavaşlatılması, birçok taslaktan geçmesi, başkalarının tavsiyesini alması ve sayfada bulunmayanları eksize etmesi gerekiyor. Bu, kodunuz mükemmel bir şekilde çalışsa bile, kendinize veya bir iş arkadaşınıza cevaptan memnun olana kadar bir şeyin neden doğru hissetmediğini sorarsınız. Belki çok uzun veya tekrarlayıcı hissediyor veya derleyicinin belirli bir tür hatayı yakalayabilmesi gerektiğini hissediyorsunuz. Bir modicum deneyimi olan çoğu programcı tanımak yetersiz kod kolayca. İşin püf noktası: neden.

Daha zarif kod yazmanın yöntemsel yolu budur. Ayrıca, bir soruna yeni bir şekilde bakmanıza yardımcı olan bir bakış açısı gerektirir. Bunu elde etmek daha zordur, ancak kodlamaya başlamadan önce yavaşlamaya ve sadece bir problem hakkında düşünmeye yardımcı olur. İyi bir çözüm bulduğunuzda, daha iyi bir çözüm arayın. Diğer kodu okumak yardımcı olur. Ders almak veya en iyi uygulamalar hakkında kitap okumak yardımcı olur. Diğer programlama paradigmalarını öğrenmek yardımcı olur. Koduna hayran olduğunuz meslektaşlardan tavsiye istemek yardımcı olur.

15
Karl Bielefeldt

Mevcut cevaplara eklerdim, TDD tarzında geliştiririm, bu yüzden önce kodunuzun ne yapması gerektiğine dair testler yazarsınız ve daha sonra testlerinizi yeşil hale getirmek için uygularsınız. Bu şekilde, yalnızca testlerin uyguladığı gereksinimleri yerine getirmiş olursunuz. Testi yazacağınız için, geliştirmeye kendi disiplinli bir yaklaşımının iyi bir yoludur.

9
Matteo Mosca

Birçok farklı beceri setine ve yıllara yayılan geniş ve dinamik bir ekip için çalışırken, geliştirme, ekibin şu anki veya tarihsel olarak en muhafazakar veya entelektüel açıdan eksik olan en düşük üyesinin seviyesine "daldırma" yönünde doğal bir ilerlemeye sahiptir.

Bu kötü bir şey olmayabilir çünkü akıllı kod hata ayıklaması daha zor olabilir, teknik bir şartnamede iletilmesi daha zor olabilir ve daha uzun sürebilir ve geliştirme süresini yavaşlatabilir.

Akıllı kodun önemli olduğu zamanlar vardır; örneğin akıllı kod, performansın bir gereksinim haline geldiği zaman yazılımın vade döngüsünde daha sonra etkinlik ve performans kazancı verir.

Akıllı kod ayrıca yeni bir dil özelliğine veya kütüphane çağrısına maruz kalmayabilecek bir ekibe daha hızlı, daha okunabilir ve anlaşılır bir kod iletme yoluna sahiptir. Örneğin, küçük bir geliştirici tarafından Linq ile ilk tanıştığımda, gereksiz, hata ayıklaması, aptalca ve "zeki" olarak derhal tiksinti duydum. Onunla oynadıktan ve Linq sorgularının ne kadar yararlı ve güçlü olabileceğini keşfettikten sonra, bunu öğrenmek için zaman harcadım ve DAL kodum hiç bu kadar temiz ve okunabilir olmamıştı, hata ayıklama ve genişletme daha kolay olmamıştı.

Daha önce açık fikirli olmadığım için pişmanım ve böylesine "zeki" bir genç geliştirici için bu kadar sert olmasaydım.

Demek istediğim "akıllı" kod şüpheli OLMALIDIR, ancak yaratıcılığa ve yeniliğe engel olabileceği için buna karşı bir haçlı seferi yapmamalıyız.

EDIT: Sorunuza tam olarak cevap vermediğimi fark ettim. Projenizde çok kolay bir şekilde akıllı kod yazma kapasitesine sahipseniz, ekip belki de tek tip ve farklı bir şablon ve stil izlemek için daha katı kodlama standartlarını benimsemelidir. Bu, kum topunuzun çizgilerini çizmeye yardımcı olacak, böylece bir top peşinde koşarak sokağa çıkmayacaksınız.

6
maple_shaft

Eklediğiniz satırların% 20'si (% değeriniz değişebilir) veya daha fazlasının dokümantasyon olması gerekiyorsa - geri adım atmanın ve yeniden düşünmenin .

Gerçekten akıllı olmak için çaba göstermeniz gerektiğini düşünüyorum, bu daha yetkin olmanın doğal bir yan etkisidir. Kendinizi açıklığa kavuşturmak için gereken yorumların yüzdesi gibi genel bir kılavuz vermek, kendinizi geri durmaya ve öğrendiğiniz yeni şeyi kullanmak akıllıca bir seçim mi yoksa sadece yeni oyuncağınızı göstermenin bir yolu olup olmadığını değerlendirmek için iyi bir yoldur.

6
DKnight

Akıllıca bir şey denemeye dayanamıyorum.

Bu yüzden bunu bir oyuncak projesinde, kendi zamanında, evde yapıyorum.

Yenilik yıprandığında - sorun çözüldü.

4
Mike Dunlavey

Kodunuzun çok "zeki" olup olmadığını öğrenmek için bir yol geri adım atın ve kendinize aşağıdaki sormak olduğuna inanıyorum:

Bu proje/kod üzerinde hiç çalışmayan birine bu kodun bir çıktısını verirsem, onu okuyabilir ve bana fonksiyonun ne yaptığını açıklayabilirler mi (kısa bir bağlam verdikten sonra)? Değilse, ne kadar açıklama yapmam gerekir? Bunu CS101 alan birine nasıl açıklayabilirim?

Birini bir yöntem veya sınıftaki her satırda veya çoğu satırda yürümek zorunda kalırsanız, muhtemelen çok zekidir. Dil yapılarını (örneğin LINQ) bilmeyen birine açıklamak zorunda kalırsanız, muhtemelen sorun yoktur. Bir satıra bakıp açıklayabilmeniz için biraz düşünmeniz gerekiyorsa, kodunuzun yeniden düzenlenmesi gerekir.

4
Becuzz

Bu yeni numarayı İfadelerle göstermeniz veya üç farklı prosedürü genelleştirmeniz gerektiğinde bu duyguyu biliyor musunuz?

Hayır

Bu, her zaman yeni geliştiricilerin korumak ve refactor için belgelenmemiş speghetti kodunun büyük bir karmaşasına atılmasının iyi bir şey olduğunu söylememin nedenlerinden biridir. Onlara yazmadıkları aşırı 'akıllı' kodları korumanın gerçeklerini öğretecek ve umarım kodlarını 5 yıl sonra hata ayıklamak zorunda kalacak zavallı schmuck için biraz empati kuracaklar.

2
GrandmasterB

Bence konu iyi seçilmiş. Bir kerede on bin şey yapan bir Perl satırı yazmak "havalı" ama sonra tekrar ziyaret etmeniz gerektiğinde berbat.

Farklı bir notta, zeki olsun ya da olmasın, kod belgelenmelidir. Endüstri tarafından kabul edilen programlama dilleri ile insanlar olarak bizim düşüncemize alışkın olduğumuz üst düzey kavramlar arasında doğal bir empedans uyuşmazlığı vardır. Kendini belgeleyen kod, doğal dil olana kadar gerçekleştirilemez, yani. Prolog kodunun bile belgelenmesi gerekir, ancak yüksek düzeyde olsa da, hala oldukça resmidir.

İnce taneli zorunlu kod, belgelenmesi gereken kaba taneli planların uygulanmasına hizmet eder. 3 satırlı hızlı bir yol haritası yorumu yaparken yöntemin 50 satırını da okumak istemiyorum.

Daha sonra düzenleme: Daha etkili bir örnek, bilgisayarları aşan bir örnektir. Bir kitap çok iyi yazılmış olabilir, ancak genellikle farklı soyutlama düzeylerinde işlemek isteriz. Genellikle, kitabın bir özeti yapılır ve yorumların kodlamak için sunabileceği şey budur. Tabii ki iyi soyutlanmış kod, kendi kendini belgelemeye doğru uzun bir yol kat edebilir, ancak size tüm soyutlama düzeylerini veremez.

Ve ana kitaptaki bir iddianın arkasındaki akıl yürütme sürecini raydan çıkarmadan açıklamamız gerektiğinde, yorumlar bir kitaptaki sidenotlar gibi davranabilir.

Bu bağlamda, yorum ihtiyacını aşan doğal dile atıfta bulunan önceki ifademin yanlış olduğunu görüyorum. Bir kitapta olduğu gibi doğal dil bile belgelere, metinde yer alan soyutlamayı seyrek açıklamak veya ana metni raydan çıkarmadan dolambaçlı yoldan vermek için kendini ödünç verebilir. İyi yazılmış kodun kendi kendini belgelemeye çoktan yol kat etmiş olabileceğine dikkat edin.

Son olarak, en önemlisi, yorumlar kodlayıcının yüksek bir soyutlama düzeyinde kalmasına yardımcı olabilir. Çoğu zaman, bir adım listesine dahil ettiğim iki ardışık yorumun aynı soyutlama seviyesinde konuşmadığını, bu kodla ne yaptığımı derhal eleştirel bir bakışla garanti ettiğini fark ediyorum.

Bazı sorunlar kodlamayı aşar ve kodlamayı diğer etkinlikler gibi etkiler. Yorumlar, arkasındaki mantığı ve kodumuzun yönlerini açıklığa kavuşturmada yardımcı olabilir ve onlara bir değişiklik için kişiye fayda sağlamak için daha yumuşak bir dil konuşan hoş bir arkadaş buluyorum.

2
Mihai Danila

Muhtemelen basit kod yazmaya başlamak için iyi bir yol akıllılık isteyen bir projede akıllılık tutkusunu serbest bırakmaktır. Cevabın geri kalanı .NET'e özgüdür, ancak eminim ki başka bir dilde benzer seviyedeki projeleri bulabiliriz.

Üzerinde çalışmak için açık kaynak bağımlılık enjeksiyon çerçeveleri vardır, sadece Expression hileler bilgisi isteyin, F # ve denemek isteyebileceğiniz harika görevler aralığı var için.

Matematiğe giriyorsanız (ve bu dil agnostik ) ise, Project Euler sizin için.

Son olarak, ama en az değil, .NET dünyasında Mono Projesi çok fazla olan geliştiricinin dikkat etmesi gereken alanlar , bazıları oldukça karmaşık. açık kaynaklı statik .NET kod analiz aracı 'a katkıda bulunmaya ne dersiniz? Bazı IL analizlerinin yanı sıra üst düzey şeyler de var. Jb Evain Cecil yansıma kütüphanesi, Expression desteği veya bir .NET decompiler olsun, her zaman ilginç bir şey üzerinde çalışır.

Hiçbir şey uymuyorsa, sadece kendi alaycı çerçevenizi başlatın :-)

2
Dan

1) Kötü bir şey olduğunu bilmek için daha önce yanmış olun. Akıllıca yazılmış bir şeyden çok önce hata ayıklamaya çalışmak çok eğlenceli. Bence bunu örtbas ettin.
2) Kodunuzu yorumlayın, her kod bölümünden önce ne yaptığınızı açıklayın.
3) Kendinizi açıklamakta zorlanırsanız veya bir diyagram eklemeye ihtiyaç duyuyorsanız, yeni yaptığınız şey çok zekidir ve muhtemelen daha temiz yapılabilir.

Hata ayıklamak veya genişletmek zorunda kalana kadar sorunlara akıllı çözümler harika olabilir. Bazen tek çözüm budur. Eğer ne yaptığını ve nasıl yaptığını doğru bir şekilde açıklayabilirseniz, akıllı çözümler kabul edilebilir.

Genellikle kod bölümü ile ne yaptığımı açıklamak için yorum kullanın. En az kafa karıştırıcı gibi görünüyorsa, nasıl yaptığımı da açıklarım. İdeal olarak, kod doğrudan ileri ve açıklayıcı olmalıdır. Ama az önce yaptığım şeyi nasıl yaptığımı açıklamakta zorlanırsam, geri çekilmem ve tekrar denemem gereken açık bir işaret.

2
Philip

Nasıl? Kodunuzu deneyimli geliştiricilere göstermeye devam edin. ve sophomoric ve gösterişli olduğu için patladığında, onu em ve nasıl yaptıklarını ve nedenlerini (elbette çatışmasız bir şekilde) sor.

-1 ışığında düzenleme:

Birçok ay önce, aynı durumdaydım - Delphi'de ya da 'yapı ile' bir işaretçi her kullandığımda boğacak bir patronum vardı, tüm booleanlarımı kısa devre yapmayı bırakmazsam beni kovmakla tehdit eden bir patron daha vardı 0-1 ile ve her yerde tek harfli değişkenler kullanarak.

Çünkü neden sordum ve onlar bir şey - LOL miktarını düşündüm çünkü açıklamak için sorun aldı öğrendim.

1
Vector

Gösteriş yapmaya ihtiyacım var mı? Hayır, artık değil. Nasıl geçtim? Çoğu insan diğer kötü alışkanlıkları aşar gibi ... uygun tekniklerin bilinçli ve kasıtlı olarak uygulanmasını sağlar. En iyi uygulamaların değerini anlayacak ve sürekli kullanımları sayesinde iyi alışkanlıklar geliştireceksiniz.

Ayrıca, işlevsel yazılımlara odaklanarak, zamanında ve kolayca korunarak aradığınız tanınmayı elde edeceğinizi de unutmayın. Deneyimli geliştiriciler size gelecek ve "Yazdığınız modül iyi tasarlanmış. Projeye takmak için yalnızca bir bileşen uygulamak zorunda kaldım" diyecektir. "Yazdığınız modülün tamamını başka bir bileşende kullanmak için yeniden çalışmak zorunda kaldım mı? Bob Martin veya Ward Cunningham'ı bile duydunuz mu?"

TLDR: Yalnız değilsin. Becerinin tanınması en iyi şekilde, problemleri akıllıca çözmenin bir yan ürünü olarak elde edilir.

1
Heath Lilley

Benim için, aşırı zekice kod genellikle bugünün gereksinimlerine odaklanmak yerine hayali gelecekteki gereksinimleri çözmeye çalışır. Büyük tuzak!

% 0 aşırı karmaşık kod ulaşılabilir bir hedef değildir. Belki de çabalamak için en iyi hedef bile değildir. Aşırı karmaşık kod kötü, ancak bir programcı olarak büyümek için yeni şeyler denemek zorundasınız. Bundan kaçınabiliyorsanız bunları üretim kodunda denememelisiniz. Makinelerin aksine, insanlar hata yapar.

Kod incelemeleri yardımı. Başkalarının "akıllı" kodunu düzeltmek için yıllar harcamak yardımcı olur. Müşterinin bugün gerçekten neye ihtiyacı olduğuna odaklanmak, yardımcı olur.

Okullar ve işyerlerinde personel üzerinde temizlik ve bakım ekipleri bulunur. Kodun da temizlenmesi ve bakıma ihtiyacı var! Mümkünse, karışıklıkları temizleyin (özellikle kendi)! Bence bu yapabileceğin en iyi şey.

0
GlenPeterson