Uzun vadeli, yanlış programlama varsayımları [kapalı]


281

Küçük (ve belki de kıdemli) yazılım mühendisleri tarafından yapılan yaygın hatalar ve kötü varsayımlar üzerine biraz araştırma yapıyorum.

Sonunda düzeltilen en uzun varsayım neydi?

Örneğin, bir tamsayı boyutunun standart olmadığını ve bunun yerine dile ve hedefe bağlı olduğunu yanlış anladım. Biraz utanç verici, ama işte burada.

Dürüst ol; Hangi sağlam inanca sahipsiniz ve kabaca ne kadar sürdürebilirsiniz? Bir algoritma, bir dil, bir programlama kavramı, test etme veya programlama, programlama dilleri veya bilgisayar bilimi hakkında başka herhangi bir şey olabilir.


Yanıtlar:


545

Uzun zamandır, herkesin tüm programlama kavramlarında (tasarım kalıpları, en yeni dil, hesaplama karmaşıklığı, lambda ifadeleri, buna ad veriyorsunuz) bu süper ustalığa sahip olduğunu varsaydım.

Blog okumak, Stack Overflow ve programlama kitapları her zaman tüm programcıların sezgisel olarak bilmesi gereken şeyler hakkında eğrinin arkasında olduğumu hissettiriyor gibiydi.

Zamanla, bilgimi tek bir kişi değil, birçok insanın kolektif bilgisiyle etkili bir şekilde karşılaştırdığımı fark ettim ve bu herkes için oldukça yüksek bir çubuk. Gerçek dünyadaki çoğu programcı, işlerini yapmak için gereken bir bilgi önbelleğine sahiptir ve zayıf veya tamamen cahil oldukları birkaç alandan daha fazlasına sahiptir.


68
Çok doğru! Bu çağın sorunu bu. Bilgi de cesaret kırıcıdır. Bu vahiy, birkaç hafta önce, araştırma ile ilgili yaptığım her şeyde (ilk kez değil) tam bir kaybeden gibi hissettiğimde ortaya çıktı. Belgelerini IEEE İşlemleri'nde yayınlayan çocuklar, Google'da çalışan, StackOverflow'da övünen, mükemmel profesörler olan veya harika programlama blogları yazan kişilerle aynı becerilere sahip olmak zorunda değildir. Tabii ki, en iyi adamlar bizden üstel olarak daha havalı, ama bilmediğiniz her şeyi bilmiyorlar. Yani, sakin ol.
jbasko

40
Bu blogcuların da her şeyi başlarının üstünde yazmadığını anlamaya yardımcı olur. İyi blogcular konularını araştırır ve mesaj yazarken yeni şeyler öğrenirler.
JohnFx

47
Okumak ve öğrenmek için zamanım olmayan şeyler hakkında her gün takıntılıyım. Beni bazen korkunç bir suçluluk duygusu bırakıyor.
brad

9
@Zilupe: Buna amen. Birkaç uluslararası konferans bildirisi ve dergi yayınladım. Bazı insanların gözünde bu kulağa hoş geliyordu. Bir makale yayınlamanın gerçekten fazla çaba gerektirmediğini anlayana kadar. Biz dahi değiliz. Tıpkı diğer herkes gibiyiz. Hatalar yaptık ve saçmalık kağıtları yayınladık. Gerçek dahilerin bazı azınlık grubu hariç ...
Hao Wooi Lim

4
+1 İyi okudum. Tek olduğumu düşünmüştüm.
Randell

308

İnsanlar ne istediklerini biliyorlardı.

İnsanlarla konuşacağımı düşündüğüm en uzun süre, bir problemi veya iş akışını tarif edeceklerdi ve koda koyacağım ve otomatikleştireceğim. Her seferinde ortaya çıkıyor, istediklerini düşündükleri şey aslında istedikleri şey değildi.

Düzenleme: Yorumların çoğuna katılıyorum. Bu teknik bir cevap değildir ve sorgulayıcının aradığı şey olmayabilir. Sadece programlama için geçerli değildir. Eminim bu benim en uzun süredir var olan varsayımım da değil, ama bunu yaptığım 10 kısa yıl içinde öğrendiğim en çarpıcı şeydi. Eminim saf safımdı ama beynimin nasıl bağlandığına / bağlandığına ve iş dünyasına girmeden önce edindiğim öğretim ve deneyimler, cevap verdiğim şeyi yapacağımı düşünmem için beni yönlendirdi; insanların sorunlarını çözmek için kod ve bilgisayarları kullanabileceğimi

Sanırım bu cevap, programcı olmayanların bahsettiğim şeyleri anlama / önemseme hakkındaki Robin'e benziyor. İşi çevik, yinelemeli, etkileşimli bir süreç olarak öğrenmekle ilgilidir. Programlama kodu-maymun olmak ile yazılım geliştiricisi olmak arasındaki farkı öğrenmekle ilgilidir. İkisi arasında bir fark olduğunu ve alanda gerçekten iyi olduğunu fark etmekle ilgili, sadece sözdizimi ve yazma hızı değil.

Düzenleme: Bu cevap şimdi bana cevap veren bu cevapta üzgün insanları yatıştırmak için topluluk-wiki.


9
Veya daha önce ne istediklerini gördükten sonra istediklerini değiştirin. İnsanlar fikirlerini değiştirmeyi sever. Biliyorum, çünkü ben bir insanım.
J. Polfer

13
Onlara istediklerini değil, istediklerini veriyordunuz.
Brent Baisley

47
Sıkıcı tartışmasız cevaplar neden bu kadar aşırı oy alıyor ?!
nes1983

39
Vay. Birisinin sarılmaya ihtiyacı olduğu anlaşılıyor.
bzlm

24
Tanrım @ insanlar şikayetçi, stackoverflow temsilcisi bir rekabet değil. Cevabı beğendiyseniz oy verin, kıskanmayın çünkü kıskanıyorsunuz, önce göndermediniz.
Dmitri Farkov

292

Profil sorununun profil oluşturmadan nerede olduğunu biliyorum


10
Erken optimizasyonun bu kadar yaygın bir yer olmasının nedeni budur.
Hao Wooi Lim

10
+1 Vay be, birisi önemsiz veya konu dışı bir cevap ekledi.
Mark Rogers

3
Erken optimizasyonda yardımcı olması gereken bazı tabletlerim var ...
AndyM 28.08

232

Bir işlev / yöntemden yalnızca bir çıkış noktası olması gerektiğini.


91
Mükemmel gerçekleştirme; gerektiği sıklıkta çıkın. Kişi, daha fazla devam etmenin bir anlamı olmadığı anda bir işlevden kurtulmalıdır. Bunu yapmak, örneğin yöntemin düzgün çalışması için gerekli önkoşullar olduklarında, örneğin derin yuvalanmış koşullardan kaçınarak karmaşıklığı azaltabilir ve okunabilirliği artırabilir. Bellek yönetimi ve / nihayet gibi kaynak yapılarına sahip modern dillerde, bir yöntemin sonuna kadar devam etmek dogmatik olarak bir anlam ifade etmez.
Triynko

24
Bu arada kim geldi? Programlama kentsel bir efsane gibi.
brad

49
Başkalarının kodlarında hata ayıklamak zorunda olan insanlar bunu ortaya çıkaranlardır.
gatorfax

23
Bence bu yaygın olarak tutulan ama yanlış fikir bir yanlış anlaşılmaya dayanıyor. Eğer bir işlev çıktığınızda, her zaman gerekir dönmek aynı noktaya. Bu BASIC gibi dillerde zorlamayan önemli bir kuraldı: Kural, örneğin GOTO yerine GOSUB kullanmanız gerektiği anlamına geliyordu. C # veya Java gibi yöntemleri çağıran dillerde, otomatiktir. Ancak otomatik olduğu için, mantıklı "tek bir dönüş noktasından" anlamsız "tek bir çıkış noktasına" dönüştüğünü düşünüyorum.
Ryan Lundy

35
Kaynakların manuel olarak yayınlanması gereken C gibi dillerden. Birden fazla çıkış noktası, kaynakların sızması için iyi bir fırsattı. Artık çıkış noktalarınızı artık bilmediğinizden veya bir ifadenin ortasında olduğunuzdan, IMO'nun istisnalar dışında dillerde bir anlamı yoktur. - Bu dillerde geriye kalan tek şey "okunabilirlik için yapı" dır.
peterchen

228

Programcı olmayanlar neden bahsettiğimi anlıyor.


243
anlamak / bakım ..
nickf

8
Ben hala bu zaman zaman var ... En azından eşim şimdiye kadar düzgün anlamaya başlayacak düşündüm: P
workmad3

3
Ah canım, korkarım bunu henüz öğrenmemiş olabilirim!
thatismatt

3
evet, bazen izleyicilerimi unutuyorum ve bana yüzünü diken boş görünümlerle bir grup insanla sonuçlanıyorum, insanlar yine de bir ilgi gösterdiğinde güzel
Petey B

3
Bu mesleğimdeki en büyük hayal kırıklığım.
Andres Jaan Tack

219

Bu bugfree yazılımı mümkün oldu.


35
+1, ancak NASA neredeyse başardı
Patrick McDonald

55
Evet ama "neredeyse" birkaç milyon dolara mal oldu :)
Jem

15
@Triynko sizin "olası" ve @ JaredPar'ın "olası" aynı değildir. Teori ve pratik teoride aynı olabilir, ancak pratikte çok farklıdır.
wilhelmtell

13
@Joseph, sorunun bir parçası insanların Hello World programlarının hatasız olduğunu düşünmesidir. Onlar değil. Çoğu, printf'deki hataları kontrol etmez veya başarısız olan diğer IO girişimlerini denetler.
JaredPar

9
@RussellH, hayır. Bir dönüş değeri belirtmediniz ve sonuçta ortaya çıkan işlem rasgele çöp belleği döndürecek.
JaredPar

199

Özel üye değişkenleri, sınıfa değil örneğe özeldi.


192
Bu varsayımı ... şimdiye kadar sürdürdüm.
TheMissingLINQ

9
@ebrown Ben genellikle sadece equals () yöntemi yazarken yararlı buluyorum
Dave Webb

12
Ruby'de.
Mike Kucera

17
Bu benim için o kadar normal ki, bu cevap ilk okuduğumda anlamsızdı. Şimdi Ruby'yi öğrenmek istiyorum, böylece beni başka şekilde karıştırabilir. :)
jmucchiello

16
@Kiewic Sınıfınızın içinde myVar adında özel bir üye değişkeniniz varsa, diğeri bu sınıfın bir örneğiyse, other.myVar öğesine doğrudan kodunuzda başvurabilirsiniz. Sınıf içinde other.getMyVar () kullanmak zorunda "özel" olduğunu varsaymıştı.
Dave Webb

166

Statik yazmanın klavyenizde çok oturduğunu düşündüm.


53
Samimi ya da değil, bu uzun bir iş günü sonunda beni güldürdü. : P
Olivier Tremblay

5
İyi bir kahkaha için ++. (teknik olmayan) kocamın ortaya çıkaracağı bir şey gibi geliyor.
jess

11
1! Ördek yazmanın da yazmayı düşündüm. Veya ördekler. Ya da her ikisi de.
SqlACID

162

Gelişmeye başlamadan önce bir problemi tam olarak anlayabilmeniz.


32
Bu, dostum şöyle olmalıdır: "Bir problemi tam olarak anlayabileceğin." Ama bu çok doğru. Ve görünüşe göre anlaşılması hatta kabul edilmesi zor bir kavram.
KarlP

4
Sorunu "tam olarak" anlayamazsınız, ancak kesinlikle gelişmeye başlamadan önce sorunu (bir dereceye kadar) anlamalısınız. bit.ly/kLXgL
OscarRyz

Bazen sorunu anlamak için gelişmeye başlamanız gerekir. Ve / veya sorun ne kadar gelişirse değişir.
Evan Plaice

158

Akıllı İnsanlar Her Zaman Benden Akıllıdır.

Hata yaptığımda gerçekten kendimi yenebilirim ve sık sık kendini beğenmeme söylendi. Eskiden birçok geliştiriciye huşu içinde bakıyordum ve çoğu zaman X'te benden daha fazlasını bildikleri için benden daha fazlasını bildiklerini varsayıyordum .

Tecrübe kazanmaya ve daha fazla insanla tanışmaya devam ettiğimden, çoğu zaman belirli bir konuda benden daha fazlasını bildikleri halde, benden / sizden daha akıllı olmaları gerekmediğini fark etmeye başladım .

Hikayenin ahlakı: Masaya neler getirebileceğinizi asla hafife almayın.


İyi bir! Şu anda .NET gelişimi hakkında çok şey bilen bir meslektaşımla çalışıyorum. Müşterilerin neye ihtiyacı olduğunu anlamada daha iyi olduğumu fark etmem için biraz zaman aldı.
Treb

58
Diğer taraftan, diğer insanlardan daha çok şey biliyorum. Görünüşe göre sadece farklı şeyler biliyorlar. Diğer ahlak: Bir başkasının masaya ne getirebileceğini asla küçümsemeyin.
thursdaysgeek

1
İşte o eski "Başkalarına yap" olayı ... Yeni bir cümle kuruyorum: Teknik zorbalık ~ Üstün hissetme durumu çünkü bazı şeyler biliyorsunuz ve herkesin bunu bilmesine izin verme hatası yapıyor. @seealso: smartass.
corlettk

1
Mükemmel gözlem - versiyonum daha olumsuz "Herkes zaman zaman aptalca". Biraz "bozo bitini çevirme" ile ilgili.
peterchen

2
Sadece aptal insanlar senden daha akıllı olduğunda endişelenmelisin.
Brad Gilbert

131

En uzun zamandır Kötü Programlamanın saçakta olan bir şey olduğunu düşündüm .. İşleri Doğru Yapmanın norm olduğunu. Bugünlerde çok saf değilim.


30
Kötü Programlamanın Kötü Programlarımdan biri tarafından yapılana kadar sadece diğer programcılar tarafından yapıldığını düşünürdüm. Şimdi İşleri Doğru Yapıyorum! (Bana bu sefer inanıyorsun, değil mi?)
Jared Updike

2
Tamamen. Ben "Bu asla haricinde olur üzere "asla olmaz That" geçmemize bu işin" "Her yerde kötü kodu vardır."
Ryan Lundy

1
Hacking normdur. Mühendislik gerçekten rekabetçi olanın tasavvurudur. Eğer herhangi bir yazılım mühendisiyle tanışırsam size haber vereceğim.
corlettk

3
@corlettk: Yani maymun kodlama norm, değil mi? Hacking bir sanattır, üst düzey bir sanat sizi başarmaktan çok uzakta olduğumu düşünür.
hasen

2
@Hasen: Hayır, bilgisayar korsanlığı ustaca bir ağaca balta alıp, gerçek bir planı olmayan deli bir panik içinde küçük parçaları keserek ve ağaç nihayet başınıza düşene kadar kanlı büyük bir karışıklık yaratan bir benzetmedir. "Hack", "ticari başarı kazanma umuduyla banal ve vasat iş üreten" bir hacktir. Neden bilgisayar alanı "hack" değişti "yetenekli" demek, asla bilemeyeceğim.
Lawrence Dol

113

Mümkün olduğunca soyutlamaya yönelmem gerektiğini düşündüm. Çok fazla iç içe geçmiş küçük işlevsellik nedeniyle, bununla kafa kafaya çarptım.

Şimdi işleri olabildiğince basit ve ayrıştırmaya çalışıyorum. Soyut bir şeyi yapmak için yeniden düzenleme yapmak, bir şeyi nasıl soyutlamam gerektiğini tahmin etmekten çok daha kolaydır.

Böylece hepsini yöneten bir çerçeveyi geliştirmekten işi yapan işlevsellik parçacıklarına geçtim. Asla geriye bakmadım, ancak bir sonraki büyük şeyi geliştiren kişi olacağımı safça düşündüğüm zaman hariç.


26
Ayrılmış = gerçek Soyutlama. Kendi iyiliği için soyut ... erken optimizasyon.
Jared Updike

1
Bu, performans ayarı yaparken bulduğum şeyle birlikte gider. Birden fazla soyutlama katmanına sahip hoş bir program olabilir. Sonra iş yükü ağırlaşır ve her zaman neye mal olduğunu tahmin edin ... tüm soyutlamalar. Bilgisayarlar soyutlamaları değil talimatları uygular.
Mike Dunlavey

5
Soyutlama ve genelleme, soyut bir kullanım durumunu tek bir uygulama ile genelleştirmek için ne yazık ki kullanılan güçlü araçlardır. Komik olan şey, uygulamanın değiştirilmesi gerektiğinde, soyutlamaların ve genellemelerin de değişmesi gerektiğidir ...
KarlP

Jared ile tamamen aynı fikirdeyim ... "basit ve ayrıştırılmış" hale gelmeyi başarırsanız, gerçek bir soyutlama elde ettiniz. Arayüzlere ve fabrikalara vb. Soyutlamadıysanız işler nasıl çözülebilir? Tüm "if type = this öyleyse bunu yapın, ya da tür buysa başka bir şey kodu yapın" seçeneğini kaldırmazsanız ne kadar basit olabilir?
Richard Anthony Hein

Burada aynı. Sanırım bir sürü spagetti kodu yapmadan önce soyutlamayı öğrendim . Kod spagetti olsa bile işlerin nasıl yapılacağını öğretmeli ve sonra bize OO ve soyutlama hakkında bilgi vermelilerdi.
hasen

103

Kadınlar bilgisayar programcıları seksi ...


70
Bir saniye bekle???
Çağdaş Tekin

4
o o o o .. tamam, günün geri kalanında gülüşümü devam ettirecek bir şey arıyordum. Sanırım buldum !!! :)
OscarRyz

17
"Ooh, bebeğim! Evet, 'eğer' deyin - bana bazı istisnalar atın .. Evet, nasıl istediğimi biliyorsunuz": P
cwap

5
Ne? Programcılar zengin mi? Bu ne zaman oldu?
Filip Navara

3
Bazı kadınlar (doğru tür), anlayışlı akıllı erkeklere çekilir. Hangi, prototipik boyun sakalı ve sosis-bağırsak eksi, programcıların oldukça yaygın özellikleridir. Öz-imaj / hijyen ve sıra dışı sporların heyecanı / heyecanı için biraz endişe serpiştirin ve yolunuza devam edin.
Evan Plaice

100

Yazılımın kalitesinin daha fazla satışa yol açması Bazen öyle ama her zaman değil.


37
Yazılım mı satıyorsunuz? Bu böyle 1999.
bzlm

Abonelik tabanlı web sitelerinin
çoğu

11
Microsoft eminim bir öldürme yapar.
Bill Martin

Bunu sevmeliyim, çok doğru.
dr. kötü

18
Keşke yazılımımızın kalitesini / performansını artırmanın bir özellik olarak sayılmasını isterdim
Tom Leys

82

Tüm diller (çoğunlukla) eşit yaratılmıştır.

Uzun bir süredir, seçim dilinin, geliştirme sürecinin zorluğu ve proje başarısı potansiyeli konusunda gerçekten bir fark yaratmadığını düşündüm. Bu kesinlikle doğru değil.

İş için doğru dili seçmek, verilen diğer herhangi bir proje kararı kadar önemli / kritiktir.


13
Önemli kütüphaneleri seçmenin önemli olduğunu hissediyorum. Böyle olur, genellikle diller ve kütüphaneler arasında bire bir yazışmalar olur ...
Kevin Montrose

7
Ama eğer iki programlama dili Turing tamamlanmışsa, fark nedir? Herhangi bir programı her iki dilde de yazabilirsiniz! ;)
Kertenkele Bill

8
Kabul etmiyorum, hangi dilin kullanılacağına karar vermek, projeyi kimin uygulayacağından çok daha az önemli. Diğer birçok önemli kararın sadece bir örneği olarak.
Boris Terzic

13
BrainFu ** python kadar tur tamamlandı.
hasen

9
Turing tam dillerinin bir şekilde eşit olarak uygulanabilir olması yaygın bir yanlış anlamadır. Bir Turing tam dili, bir Turing makinesinin yapabileceği her şeyi hesaplayabilir (ve genellikle başka bir şekilde de ima edilir). Performansla ilgili kesinlikle bir sonuç yoktur. Bir dilde doğrusal zaman alan bir işlem başka bir dilde üstel zaman alabilir ve her ikisi de Turing tamamlanmış olabilir. Teorik olarak hesaplanabilir ve pratikte mümkün olan arasında büyük bir fark vardır.
TrayMan

81

Büyük bir yorum / kod oranı iyi bir şeydir.

Kodun kendi kendini belgelemesi gerektiğini fark etmem biraz zaman aldı. Tabii, burada bir yorum ve kod daha net hale getirilemiyorsa veya bir şey yapılmasının önemli bir nedeni varsa faydalıdır. Ancak, genel olarak, bu yorum zamanını değişkenleri yeniden adlandırmak için harcamak daha iyidir. Daha temiz, daha net ve yorumlar kodla "senkronize değil".


1
Kabul ediyorum içinde Javadoc açıklamalar (veya eşdeğeri) hariç ... gerçek kod.
corlettk

11
+1, 10 satır işlevi için
yazdığım alıştırmaları bile başlatmama

Buna eklemek için, bir assert () ifadesi bir önkoşulu / sonkoşulu belgelemekten daha iyidir. .NET 4 kod sözleşmeleri de otomatik olarak belgelere dönüştürülebilir!
Robert Fraser

66

Bu programlama imkansız.

Şaka yapmıyorum, her zaman programlamanın öğrenilmesi imkansız bir şey olduğunu düşündüm ve her zaman ondan uzak durdum. Ve koda yaklaştığımda asla anlayamadım.

Sonra bir gün oturdum ve bazı temel başlangıç ​​derslerini okudum ve oradan yoluma devam ettim. Ve bugün bir programcı olarak çalışıyorum ve her dakikasını seviyorum.

Eklemek gerekirse, programlamanın kolay olduğunu düşünmüyorum, bu bir zorluk ve daha fazla öğrenmeyi seviyorum ve bazı programlama problemlerini çözmekten daha eğlenceli bir şey yok.


7
Amin! Ama, hey, bu görüşü çatılardan ilan etmeyin. Herkesin programlamanın eğlenceli olduğunu bilmesini istemiyoruz , şimdi değil mi? ;); P
Peter Perháč

9
MasterPeter: Buraya soru sormaya geldiklerinde temsilcimizi arttırmamız bize daha fazla yem verecekti.
TheTXI

4
Programlamanın doğru yapılmasının zor olduğunu söyleyebilirim . Bununla birlikte, bu sizin açınızdan mümkün gibi görünüyor.
Steve S

4
@Olafur: Sorunun neden wiki olmasını istiyorsun ama cevabın olmasın ki?
gnovice

2
Bu benim deneyimimi aynen yansıtıyor. Keşke daha erken
başlasaydım

65

"On Error Resume Next" bir tür hata işlemeydi


6
Seni hissediyorum ... ama vbscript (esp. Asp), SADECE "hata işleme" seçeneği mevcut, bir hata gerçekten olup olmadığını makul kontrol ve adil bir miktar dua ile birlikte kullanılabilir.
flatline

2
Evet ... bir çeţit ... kaçmaktan mutlu olduđumuz bir tür
Matthew Whited

6
İyi?! ama bu. Hata işleme bloğunuzu On Error Resume Next ile başlatırsınız, bir şey deneyin ve sonra If (err.number <> 0) sonra
jpinto3912

Bu bir try catch eşdeğer tek vbscript değil mi?
James

-1: Bu bir tür hata işlemedir. O kadar zarif değil.
JohnFx

64

Bu programlama yazılımı yüksek matematikte güçlü bir temel gerektirir.

Kodlamaya başlamadan yıllar önce, her zaman iyi bir programcı olmak için gelişmiş cebir, geometri, matematik, trig, vb. Konusunda iyi olmanız gerektiği söylendi.

On yıl sonra ve sadece bir kez sekizinci sınıf öğrencisinin yapamayacağı bir şey yapmak zorunda kaldım.


5
Çok doğru. Çoğu durumda matematik uzmanı olmanıza gerek yoktur. Herhangi bir ileri matematik bilmek için ihtiyacım olan tek zaman, 3D programlamayı hobi olarak yapmaktı. Aslında, lise sırasında 3D programlama, trig ve pre-cal sınıflarında daha iyi dikkat etmem için bana ilham verdi. Bunun dışında, çok temel matematik genellikle ihtiyacınız olan tek şeydir.
Steve Wortham

29
Bence yanlış bilgilendirildin. Elbette, iyi bir programcı olmak için çok daha yüksek seviyeli matematik kullanmanıza gerek yoktur, ancak belirli bilgisayar bilimi kavramlarını gerçekten anlamak ve uygulamak için sekizinci sınıf matematikten daha fazlasına ihtiyacınız olacaktır.
hbw

12
Matematiğin vurgusu, günlük bilgisayar programlamada kullanacağınız bir şey olarak değil, eleştirel düşünme becerilerini ve problem çözmeyi öğretmektir.
Zack,

14
Gelişmiş matematiği anlamak için ihtiyaç duyduğunuz soyutlama türü, yazılım oluşturmak için ihtiyaç duyduğunuz soyutlamaya çok benzemektedir.
OscarRyz

6
Matematikte daha güçlü bir temele sahipseniz işlevsel programlama kavramlarının anlaşılması çok daha kolaydır, çünkü sözdiziminden çok da korkmuyorsunuzdur. Tanıdık geliyor. C # için yeni fonksiyonel programlama kavramlarını göstermek için basit matematiksel fonksiyonlar kullanarak hata yaptım. Bazı insanlar bunun çok karmaşık olduğunu hemen beyan ediyorlardı.
Richard Anthony Hein

63

Bu montaj dilini == yeniden yazma optimize.

Montajı gerçekten ilk anladığımda (BASIC'ten geliyor), kodun daha hızlı çalışmasını sağlamanın tek yolunun montajda yeniden yazmak olduğu görülüyordu. Derleyicilerin optimizasyonda çok iyi olabileceğini fark etmek için birkaç yıl sürdü ve özellikle şube tahmini vb. Ayrıca, algoritmayı optimize etmek için zaman harcamanın, yüksek seviyeden düşük seviyeli bir dile dönüştürme zamanından daha iyi bir kazanç sağlaması muhtemeldir. Ayrıca bu erken optimizasyon tüm kötülüklerin köküdür ...


8
Peek ve Poke arkadaşlarınız :)
Matthew Whited

4
Sapık! Hakime söyle!
Shalom Craimer

1
Bu, karmaşıklık teorisinin devreye girdiği yerdir. Montaj genellikle mikro optimizasyondur. Algoritmalarınızı zaman karmaşıklığını azaltmak hız kazanılan yerdir.
PeteT

@ scraimer: Seni burada görmek çok hoşuma gitmezdi, bunu hiç beklemezdim ;-)
Robert S. Barnes

@ Matthew - "Peek ve Poke senin arkadaşların :)": ** ÇOK kıskanç İlk önce ben yazmadım.
FastAl

63
  • Şirket yöneticilerinin kodun kalitesine önem vermesi.
  • Bu daha az çizgi daha iyidir.

2
önemsiyorlar, ancak sanatçı-becerilerini işçi-becerileri ile birleştirmelisiniz. Her algoritma parçası da bir sanat eseri olamaz. Bazıları dolgunlaştırıcı olacak, bu yüzden "daha az kullanılmış" yeniden kullanın. Eski 80/20 kuralını hatırlayın. Programın% 80'i zamanın% 20'si kullanılır. Yani kodun% 20'sine% 80 odaklanın ve GERÇEK PARÇA YAPIN! : OP
BerggreenDK

71
daha az çizgi daha iyidir! Java'yı dil olarak sevmememin bir parçası, bir şey yapmanın çok fazla kod satırı almasıdır. daha az kod satırı, kodunuzu değiştirmenin daha kolay olduğu anlamına gelir.
Claudiu

7
Daha az satır almak için neyi kaldırdığınıza bağlıdır. Kod daha az satırla hala okunabiliyorsa, o zaman iyidir. Ancak, kodu daha da kötüleştiren kod satırlarının sayısını azaltmanın birçok yolu vardır.
Herms

2
İnsanlar zincirleme yöntemle "daha az satır daha iyi" zihniyeti aldıklarında, 7 derin çağırır, böylece bunlardan biri boş bir işaretçi attığında, bunun ne olduğu hakkında hiçbir fikriniz yoktur. Veya bir satırda 150 karakter uzunluğunda ve 4 işlem gerçekleştiren çok sayıda eylemi yoğunlaştırırlar. Bu hem okumayı hem de hata ayıklamayı zorlaştırır, ancak daha hızlı değildir ve yürütme sırasında daha az bellek kullanmaz.
Trampas Kirk

17
Satırınız biterse))))) ve Lisp yazmıyorsanız, çok az satırınız var.

58

Bir tarihin yıl öğesini 2 basamak olarak depolamanın, tüm nesil geliştiricileri etkileyen bir varsayım olduğunu söyleyebilirim. Y2K'ya üflenen para oldukça korkunçtu.


1
Ben oylayacağım tek cevap bu, bir CW olmasına rağmen önemli değil ...
Dan Rosenstark

4
IIRC bazı sistemler 60'larda ve belki de 70'lerde daha az bellek kullandığı için sadece bir rakam kullandı. Hatta "196_" ve "197_" nin hazırlandığı kağıt formları bile gördüm.
bazı

3
Hala 200_ ile formlar görüyorum ve muhtemelen 201_ ile basılmış olanlar var.
Macha

5
Üzücü kısmı ... 2038'de Unix'in ikinci turu olacak
Evan Plaice

4
@Billy Sadece makine mimarisinin değişmesi veri formatının değişeceği anlamına gelmez. İnt biçiminde 2 basamak çözünürlük depolamak bayt (8 bit) tarih formatı oluşturacak ve yine de 2 bin tonluk 32 bit donanım mimarisi makinesini etkileyecektir. Bu, düşük seviyeli donanım adamlarının veri formatlarını belirtmesine neden izin vermediğinize bir örnektir. Onlar uzak bir gelecekte planlanmış bir SNAFU olacak bilgi ile kuruş tutam bit.
Evan Plaice

57

Yerleştirme / kabarcık türünden başka bir şey oldukça karanlık bir sihirdi.


Haha, bunu beğendim, eve yakın olduğu için. N-kare zaman daha hızlı sıralamak ?? İmkansız!
Ross

Özyineleme ve bölme ve fethetme için güçlü bir his verdiğinizde, çoğu sıralama algoritmasının ne kadar basit ve açık göründüğü şaşırtıcıdır. O zamana kadar, çoğu kara büyü gibi hissediyor.
Brian

74
Ben algoritmaları sıralamada bir ARAŞTIRMACIyım! Ve onlar hala karanlık sihir gibi hissediyorlar.
SPWorley

14
Bir zamanlar programımda uzun ve karmaşık bir kod satırı vardı ve onu parçalamak veya açıklamak gibi hissetmedim (bazı karmaşık aydınlatma formülü idi), bu yüzden hepsini tek bir satıra koydum ve #define ' DARK_MAGICK olması ve tek yorum, karanlık büyünün gizemlerini çözmeye çalışmamaya karşı bir uyarıydı
Alex

2
Bogosort hepsinden en gizemli olanı.
Alex Beardsley

50

Bu XML gerçekten birlikte çalışabilir ve insan tarafından okunabilir bir veri biçimi olacaktır.


7
XML her derde deva değil ama düzenli olarak ilişkisel verileri tek csv dosyalarına sıkıştırmaya çalışan uygulamaları gördüğüm günlere geri dönmek istemiyorum.
Tony Edgecombe

4
kuşkusuz işletilebilir bir sözdizimi. Sadece bu sözdizimi genellikle herhangi bir çözümün en az önemli yönüdür.
Simon Gibbs

2
+1, istek listesine de küçük ve hızlı ekleyebilirsiniz.
MarkJ

1
Doğru ama belgeler olmadan vidalı csv ve sabit uzunluk üzerinde bir gelişme.
PeteT

7
XML'i veri formatlarına getirdiği standardizasyon ve karakter kodlamaları doğru bir şekilde işlemek için seviyorum. Ancak bazen XML kullanılarak yapılanlardan nefret ediyorum .
Joachim Sauer

48

Bu C ++, diğer tüm dillerden bir şekilde daha iyiydi.

Bu kolejden birkaç yıl önce bir arkadaşımdan aldım. Utanç verici bir şekilde uzun süre yanımda tuttum (şu anda kızarıyorum). Sadece ne için çatlaklar görebiliyordu önce 2 yıl kadar onunla çalıştıktan sonra oldu.

Hiç kimse - ve hiçbir şey - mükemmel değildir, her zaman iyileştirme için yer vardır.


5
"daha iyi" tonlarca nefretten az yorum getirecektir. Ama en hızlı çalışan, esnek, engelsiz olanlardan biri olduğunu söyleyebilirim. Aynı zamanda, gençliğinizi düzgün bir şekilde öğrenmesi için alır, sadece aynı uygulamayı daha fazla veya daha az yapabileceğinizi bulmak için. java veya C # ile (biraz daha fazla ton veya iki elektrik üreten kömür gerektirse de).
jpinto3912

@JP: Kelime seçimimden memnunum :)
Binary Worrier

Verimlilik, iş uygulamaları dünyasında daha önemlidir. Tabii ki, c ++ gerekli bazı nişler ve tek seçenek vardır.
Shaw

7
Ben her zaman C ++ düz ANSI C daha kötü olduğunu varsaydım, çünkü sadece C ++ programcıları içine gördüğüm sorun tür C programcıları gördüğüm türden çok daha karmaşık olduğu için.
Nosredna

1
Aslında, diğerlerinden daha iyi olan dil Common Lisp'dir. Yine de C ++ kötü değil.
David Thornley

47

Program oluşturmanın sınıfta öğretilen gibi olacağına inanıyordum ... bir grup insanla oturuyorsun, bir sorunun üstesinden geliyorsun, bir çözüm buluyorsun, vb. Bunun yerine, gerçek dünya "İşte benim sorunum, çözülmesine ihtiyacım var, git "ve on dakika sonra bir tane daha alıyorsunuz ve çözümünüzü verimli bir şekilde planlamak için size gerçek bir zaman kalmıyor.


24
Bence buna hayat denir.
Robin Günü

9
hmmm .. o şirketi kurtarmanın zamanı geldi. ..
jpinto3912

8
@ jpinto3912: Hayır. Çünkü bir sonraki şirket hayatın bir parçası olacak (önceki yoruma bakınız).
Treb

42

Bir CS sınıfında tanıtıldıklarında, ana tasarım desenlerinin harika olduğunu düşündüm . Bundan önce yaklaşık 8 yıl hobi olarak programladım ve gerçekten iyi soyutlamaların nasıl yaratılacağı konusunda sağlam bir anlayışım yoktu.

Tasarım desenleri sihir gibi hissediyordu; gerçekten düzgün şeyler yapabilirsin. Daha sonra işlevsel programlamayı keşfettim (Mozart / Oz, OCaml, daha sonra Scala, Haskell ve Clojure aracılığıyla) ve daha sonra desenlerin çoğunun sadece yaygın veya karmaşık olduğunu anladım, çünkü dil yeterince etkileyici değildi.

Tabii ki neredeyse her zaman bir çeşit kalıp vardır, ancak bunlar ifade dillerinde daha üst seviyededir. Şimdi Java'da bazı profesyonel kodlamalar yapıyorum ve desen eşleştirme ve daha üst düzey işlevler yerine ziyaretçi veya komut deseni gibi bir kural kullanmam gerektiğinde gerçekten acı hissediyorum.


diyerek şöyle devam etti: "örüntülerin çoğu sadece kaynak levhası veya ek karmaşıklıktı, çünkü dil yeterince etkileyici değildi." Etkileyici basitçe dile kablo bağlantılı bir koddur.
Bilinmiyor

4
Doğru değil, yüksek dereceli fonksiyonlarda olduğu gibi, bir programcının yeteneklerini sınırlamak yerine birinci sınıf malzemelere sahip olmak nasıl bir kazan plakasıdır. Lisps bunun güzel bir örneğidir.
egaga

38

Programladığım ilk birkaç yıl boyunca 1 Kbyte teknik olarak 1000 bayt değil, 1000 bayt olduğunu yakalamadım. Veri dosyalarımın boyutlarının beklediğimden biraz uzakta görünmesi gerçeğiyle her zaman biraz şaşırdım. olmak.


114
Sabit disk üreticileri hala yakalanmadı ...
Michael Myers

10
@mmyers Sanırım sabit disk pazarlamacıları demek istiyorsun değil mi? Yoksa sürücüler aslında böyle mi inşa edilmiş?
Instantsoup

16
Hey, kibi nefretini durdur. MeBi ve KiBi en azından abbiguobus'tur.
bzlm

21
Kilo 1000, Mega 1000000, Giga 1000000000 anlamına gelir. Sürücü üreticileri değil, yanlış anlayan RAM ve OS üreticileri.
Mark Ransom

39
Kimse yapmayacak mı? Ciddi anlamda? Tamam, yapacağım ... xkcd.com/394
Erik Forbes

36

Bu durum şöyle kontrol eder:

if (condition1 && condition2 && condition3)

belirtilmemiş bir sırayla gerçekleştirilir ...


15
Hangi dilde? C / C ++, Java ve Python gibi diller koşulların soldan sağa değerlendirilmesini ve değerlendirmenin false döndüren ilk koşulda durmasını garanti eder. Bu, dil özelliklerinin bir parçası. Diğer dillerin çoğunun aynı garantiyi verdiğini varsayıyorum.
Clint Miller

44
@ Clint: Evet, bu nedenle "bunun yanlış olduğu ortaya çıktı".
bzlm

Evet, bu harika. wrint şeylerini if ​​gibi yapar (myList! = null && myList.Count> = 0) {do stuff ();} çok daha kolay
Zack

4
aslında, bu dile bağlıdır ve tüm koşulları değerlendirir (kısayol değil). Ve birçok insanın AndAlso yerine VB'de And (&) kullandığını gördüm (&&)
Lucas

2
. . . AndAlso re Lucas'ın yorumunu kullanmadığınız sürece aslında VB.net'te de çökecek
Binary Worrier

35

Yalnız gerçekleştirirsem programlamamın daha hızlı ve daha iyi olacağını.


Ama belki kodunuz hariç Pair- Programming :-) kadar çirkin olamaz
Yumurta

33
Her şey diğer kişiye bağlıdır. =)
JohnFx
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.