Her programcı ne bilmeli?


245

Kullanılan programlama dilleri veya işletim sistemleri / sistemleri ya da geliştirdikleri çevre ne olursa olsun, her programcı ne bilmeli?

Bazı arka plan:

Yapabileceğim en iyi programcı olmakla ilgileniyorum. Bu sürecin bir parçası olarak bilmediğim şeyleri anlamaya çalışıyorum ve yaparsam bana çok faydası olur. “Her [programlama dilini yazanlar geliştiricisinin bilmesi gerekenler” satırları boyunca çok sayıda liste varken, henüz belirli bir dille sınırlı olmayan benzer bir şey bulamadım.

Ayrıca, bu bilgilerin ilgi çekici olmasını ve başkalarının yararına olmasını bekliyorum.

Yanıtlar:


636

Gururu yutmak ve kişisel olarak kabul etmeden hataları kabul etmek.


60
Bu, her insanın işinden bağımsız olarak yapması gereken bir şey (... cinsiyet, din, kültür, sosyal statü ...), öyle değil mi? ;)

3
Oh evet. Ama biz programcıların (en azından ben) çoğu kişiden daha fazla gurur duyma eğilimimiz var.

17
Keşke sana iki kez oy verebilseydim.

4
Üniversitede öğrendiğim bir şey olduğunu düşünüyorum. Lisede her zaman akıllı çocuklardan biriydim. Üniversiteye gitmeseydim, çok akıllı olduğumu ve büyük bir egomu olduğunu düşünürdüm. Üniversiteye gitmek ve gerçekten daha yetenekli insanlarla etkileşimde bulunmak, daha ne kadar aptal olduğumu görmeme yardım etti
Kibbee

4
Bu çok doğru olsa da, sorun her zaman inkar ya da büyük bir ego değil, en azından bir tür kendini savunma / hasar kontrolü yapmadan önce açıkça hata yapmayı kabul etmenin olası sonuçlarıdır. Bazen kültürel bir şeydir. :)

309

Bir kullanıcı gibi düşünmek ve bir techie geek programcısı gibi değil.


2
Endüstride çoğumuzun eksik gözüktüğü şeylerin sahip olabileceğimiz en önemli becerilerden biri olabileceğini hep ironik buluyorum: iletişim becerileri.

Buna daha fazla katılamadım. Bu 1 numara olmalı.

23
Ben aslında aynı fikirde değilim. Bunun için insanları işe alıyorsun. Asla bir kullanıcı gibi düşünemezsiniz, ancak kesinlikle kullanıcıların size ne düşündüklerini ve bu tavsiyeye göre hareket ettiklerini söylemelerini sağlayabilirsiniz. Sadece kullanıcılara nasıl düşündüklerini sorma! Bu en kötü seçenek.

1
Bunu yapmak için başkalarını işe alabilirsiniz, ancak geliştirme ekibiniz bir kullanıcının nasıl düşündüğünü kavrayabiliyorsa, işler doğru gitmeden önce çok daha az tartışmanız ve yinelemeniz olacaktır. Ayrıca, bir geliştirici bir kullanıcı gibi düşünebiliyorsa, hangi yeni özelliklerin ortaya çıkacağını bilen

3
Kullanıcı çok iyi bir teknoloji uzmanı programcısı olabilir, ancak daha az olasılıkla kodu uygulayan bir teknoloji uzmanı programcısı olabilir . Eğer uygulama çok ince ve karmaşık bir semantik / davranışa sahipse, kodu yazan kişi, uygulamayı nasıl kullanacağını anlayabilen tek kişi olabilir ...
Reuben

244

Ne zaman yardım istenmeli ve ne zaman yardım istenmeyecek.


2
Çok doğru. Son zamanlarda, birisine sorduğumda cevap aklıma geldi. :(
kevindaub

öyleyse, cevap nedir?)

28
Önce lastik smaççana sor. Sana yardım edemezse, o zaman başka birine sor ...
Dean Rather

3
Çünkü ilk başlattığımda, diğer geliştiricilere sürekli olarak basit şeyler sorarak ne kadar can sıkıcı olduğumu anlamamıştım, bazı n00b'ler yapana kadar kendimi çözmeliydim.

1
Kendime her zaman "Meslektaşım onlara soracak olsaydım ne derdi" diye bir soru sorarım. Genelde sormak zorunda kalmadan önce bu, sorunu biraz daha ileriye götürmeme yardımcı olur.

184

Diğer insanların kodları nasıl okunur?


102
Zeyilname: Başkalarının okuyabileceği kodlar nasıl yazılır

42
Ek # 2: 6 ay sonra kendi kodunu nasıl okuyabilirim

10
@Nathan Koop: Daha iyi olmalı. "6 ay sonra kendiniz okuyabilmeniz için kod yazma".
Doc Brown

4
6 ay geçtiğinde, zaten başkasının kodu haline geldi. O zamandan beri evrimleştiğiniz, daha iyi olduğunuz ve onu ilk etapta yazan başka biri olabilir.
MPelletier

7
Ek # 3: Kodunuzu 6 dakika sonra nasıl okunur?
mpen

152

Versiyon kontrol sistemlerine aşinalık. Her biri olmak zorunda değildir, ancak hepsine uygulanabilecek temel kavramlar bilinmelidir.


ve bu revizyon kontrolü yazılım değildir
jrhicks

4
Merkezi SCM'ler (örneğin, yıkılma, CVS) ve dağıtılmış SCM'ler (örneğin git, mercurial, çarşı) arasında her birinin birisini öğrenmenin önemli olduğu kadar önemli bir fark olduğunu da ekleyeceğim.
intuited

128

İşte 10 bitim:

  • Mütevazi olmak nasıl. Hepimiz öğrenmek için buradayız. Diğerlerinden daha zeki olabilirsiniz, ama sizden daha zeki insanlar var.
  • Bilgi nasıl çalışılır / tüketilir? Seni bilmem ama ben sonsuza kadar çalışıyorum! Kitaplar, İnternet, her neyse!
  • Bir sözlük nedir ve nasıl kullanılır, kısaltmalar nasıl hızlı bir şekilde bulunur.
  • Ticaretin temel araçlarının neler olduğu ve ne yaptıkları (IDE, CVS ve diğerleri).
  • Yaygın terminolojiyi ve ne anlama geldiklerini bilin: tasarım desenleri, kullanılabilirlik, test etme (ha!), Yığın vb.
  • OOP bilgisine sahip olmak.
  • En az bir dilde "yetenekli" olun, şaşırtıcı bir şey yok, sadece değişkenleri ve yöntemleri nasıl tanımlayacağınızı vb. Öğrenin. Buradan FAST öğrenebilirsiniz.
  • İnsanların nihayetinde yazılımı kullandıklarını ve bu insanları mutlu etmek istediklerini anlayın .

38
Bu sekizli bir yazı olmalı.
Hatta Eda

10
İlk parçaya gelince .... "Mütevazı olmayın, o kadar da iyi değilsiniz".
Magnus

@TheOtherScott, güzel yakalama lol, ama aslında 2 bit diyordum: D;)

3
Madde

1
@ jasper / intuited: kısaltmayı google'a yazmanız yeterlidir, biri veya diğerini seçer ... cevap genellikle yine de ilk 10 sonuçtan birindedir. daha fazla bilgi tıklayarak elde edilebilir!
mpen

104

Belki de çok incedir, ama bence “ hangi sorunu çözeceğini bilmek ”. Birçok programcı (ve normal insan) çok önemli olmayan şeyleri çözmek için muazzam çaba harcar; ya da çok fazla ekstra çalışma ile bir çözüm yaratıyorlar, bu tam olarak ihtiyaç duyulan şey değil.


4
Daha fazla çekirdek işlevsellik yerine sadece bir avuç kullanıcının yaşayabileceği saçak kullanım senaryoları hakkında endişelenmek, çok yaygın bir tuzak! Ben hala bunu zor yoldan öğreniyorum ...
Ian Robinson

Eski takım liderimin ana sayfası olarak cevabınıza bir link vermeliyim. çok haklısın.

4
"Bir sürü programcı (ve normal insan)"

95

Rahatlamak için nasıl. Verimliliğin sırrı bu.

Sonunda, irade ve kafein yeterli değildir. Yaptığımız bu sürekli kasılma çok zarar verici.

Bu büyük bir mesele.


1
Kasılma ile ne demek istiyorsun?

4
@Egg: Bazen çalışırken, tamamen rahat ve üretken olabiliyorum. Kötü günlerimde adrenalin ve kafeinle koşuyorum ve vücudumda muazzam bir gerilim hissediyorum. Çok dikkat edersem, aslında kasları kasılırım. Bu gerilimi her zaman başkalarında görüyorum. Ne yazık ki, tükenmişlik ve kalp hastalığı gibi her türlü soruna yol açabilir ve muhtemelen sınırlı bir süre için sürat atmak mümkün olduğu için muhtemelen net bir verimlilik kaybına da yol açar. Bahsettiğim daralma bu.
Brian MacKay

@Egg, kullanılmayan kasların kasılması anlamına geliyor.

2
kahveden ve daralmadan söz ederken, kahvenin beynin kanını besleyen atardamarı küçülttüğünü biliyor muydunuz? Bu beynin uyanmasına neden olur. Ne de olsa kahve böyle iyi bir şey değil. dr su içmek
Reno

83

Temel veri tipi ve algoritma teorisi. Big O notasyonu, diziler, sıralar vb. Gibi şeyler.


Yaptığınız tek şey, web içerik yönetim sistemleri için şablonlar hazırlamak ise size hiç yardımcı olmuyor.

3
Eh, günümüzde standart algoritmaları kitaplıkları / çerçeveler uygulanır ama bazı sert algoritma benzeri düşünce çok sık yararlıdır, ama kabul

7
Sadece zaten uygulandıkları için ne zaman ne kullanacağınızı, karmaşıklığın garanti altına alındığını vb. Anlamanız gerekmediği anlamına gelmez. Bu, algoritmaların arkasındaki önemli şeydir.

3
Greg Rogers ile anlaştı. Algoritmaları uygulamanız gerekebilir, ancak karmaşıklıklarını ve değişimlerini daha iyi anlayabilirsiniz. Örneğin. Bazı algoritmalar daha fazla hafıza alır ancak daha hızlıdır.

6
Onları anlamadığınızda hangisini kullanacağınızı bilemezsiniz. Algoritmalar çok önemlidir.

60

Doğru görev için doğru aletin nasıl seçileceği ve en sevdiği programlama araçlarıyla ilgili saçma alevli savaşlarda yer almaması.


+1 ki bu durum 42'de kalmıyor :)
CharlesB

54

İşte benim .02

  • Öğrenme asla durmaz. Ne kadar iyi olduğunu düşünürseniz düşünün, daima sizden daha iyi birileri vardır ve daima kendinizle ilgili geliştirebileceğiniz bir şeyler vardır. Öğrenmeyi bırakırsanız, kaçınılmaz olarak bir programcı olarak bozulursunuz. Kitapları oku. Blogları oku. Diğer programcılar ile konuşun.
  • Birkaç dil öğrenmeye çalışın. En az biri nesne yönelimli. Ayrıca, öğrendiğiniz dille ilgili çeşitli teknolojiler hakkında bir şeyler bilmelisiniz (örneğin, Java'yı öğrenirseniz, Bahar hakkında bir şey biliyor olmanız iyi olurdu.).
  • Yeniden düzenleme. Er ya da geç bu bilgiye ihtiyacın olacak.
  • Eski kodlarla nasıl başa çıkacağınızı öğrenin.
  • Birim testleri yaz. TDD hakkında bilgi edinin.
  • Takımda çalışmayı öğrenin.
  • Zarif ve okunabilir kodlar yazın. Eski demişler: “Kodunuzu, sürdürecek kişi nerede yaşadığınızı bilen bir psikotik seri katilmiş gibi yazın.”
  • Aynı zamanda tembel ve disiplinli olmayı öğrenin. İyi programcılar bu niteliklerin her ikisini de ortaya koyar. Göründüğü gibi garip, birbirleriyle çelişkili değil, tamamlayıcı.

Bu 0,2 dolar mı, yoksa 02 sent mi? LOL! :-D

"Kodunuzu, sürdürecek kişi nerede yaşadığınızı bilen bir psikotik seri katilmiş gibi yazın." +1
Ben

50

Bir üründe kaliteyi test edemezsiniz.


2
Dolayısıyla "Kalite Güvencesi" profesyonelleri yanlış isme sahipler.

1
Teknik olarak QA ve Test aynı şey değildir, ancak sizin açınıza göre çoğu organizasyonun aslında farkı uyguladığından emin değilim.
Uzun Jeff

5
Son zamanlarda karşılaşılan - ve sıkışmış: "Test sonucu kalite değil bilgidir".
peterchen

richdiet: SQA uzmanı James Bach, SQA / QA'daki "A" nın "Yardım" anlamına gelmesi gerektiğine inanıyor. Onun görüşüne ve ifadesine kesinlikle katılıyorum.

44

Her programcının tasarım modellerini anlaması gerekir .


13
Ayrıca, her şeyin belirli bir tasarım düzeninde ayakkabı boynuzu olamayacağına dair bir anlayışa ihtiyaçları olduğunu da eklerdim.
tloach

10
Ayrıca, her programcının tasarım modellerini anlamaması gerektiğini de eklerdim. Uzaktaki yerlerde, düşünceleri doğrudan programcıdan ve çalışma programlarına akan güçlü olan diğer özelliklere sahip diller var. Bu dillerde, kasıtlı kalıplar yanlış yönlendirmedir.
Ali

2
tasarım kalıpları "programcılar" değil tasarımcılar içindir - bir programcının "tasarımcı" olduğu zaman bilmesi gerekir

10
İki tür insan vardır. Kodlamadan hoşlananlar ve kodlama hakkında konuşmayı tercih eden insanlar. Tasarım desenleri ikinci grup için bir zorunluluktur ..
Bjorn Reppen 28:08

1
Bu tür kalıplar, dil sınırlamalarını aşmanın bir yoludur. Bir programcı onları anlamalıdır çünkü dillerinin zayıf yönlerini anlamalı ve üstesinden gelebilmelidir.

44

Buna biraz geç kaldım, ama Edsger Dijkstra'nın ortaya koyduğu bilgilerle gideceğim:

Matematiksel bir eğimin yanı sıra, istisnai derecede iyi bir ustalık ana dili, yetkin bir programcının en hayati varlığıdır.

İyi bir paragraf yazamıyorsanız, iyi bir kod da yazamazsınız.


8
Yine de bazı programcılar tarafından doğal dil yazımında kullanılan korkunç yazım, dilbilgisi ve noktalama işaretlerine hayran kaldım. Her gün yazım hatalarına karşı toleransı sıfır olan ve geçersiz sözdizimi olan sistemler ile çalışmanın yararlı bir etkisi olacağını

1
@cheduardo, bunun nedeni bir programı bir kez derlediğinizde veya çalıştırdığınızda, çoğu dilde yazım, dilbilgisi veya noktalama hataları hakkında size bilgi verilecek ve ardından kolayca düzeltilebilecek. Mantıksal hatalar için öyle değil.
İnşallah

@ İnşallah: Siz böyle bir şey yapmazsanız if (BlowUpTheSystem = 1). Uygun ünite testi verildiğinde, yalnızca zamandan tasarruf edersiniz. Ama o zaman zaman çok önemli.
intuited

2
Kabul ... hmm ... eksi "anadil" kısmı, bazılarımız [ne yazık ki?] Anadili olmayan dillerimizde daha iyi / anlaşılır bir şekilde iletişim kurar.

39

Herhangi bir teknoloji, işletim sistemi ya da dil hakkında duygusal olarak giyilmeyin, bunlara bağlı olmayın ya da dindar olmayın - hiçbiri mükemmel değil - uzun vadede, kendinizden alabileceğiniz kendi alakartınızı oluşturabilirsiniz. Her biri gibi.

Arabalar gibi düşünün - daha önce belirli bir araba kullanmamış olabilirsiniz, ancak hepsinde anahtarlar, direksiyon simidleri, gaz pedalları ve frenler var - bir taneye girip, nerede olduğunu çözdükten sonra hızlıca sürmeniz gerekir. İşletim sistemlerine ve dillere benzer şekilde davranın ve verilen herhangi bir vakanın özelliklerine bağlı olmasanız bile, bunların altında yatan temel kavramları öğrenmeye odaklanın.

Ve zamanla, perspektifinizi korumanıza yardımcı olacak çeşitli teknolojilerin soylarını, mirasını ve ortak yönlerini anlamaya ve takdir etmeye çalışın. Örneğin, evrimsel ağacın aktif bir şekilde dallanıp çıkmazlarla dolu olmasına rağmen, zaman içinde teknolojinin art arda “en iyi uygulamalar” ve “ölçek ekonomileri” etrafında yakınsama eğilimi gösterdiğini ( örneğin bir Mac'in tamamen farklı olmadığı farkına varın) Bu gün kaputun altında PC ...).

Son olarak, ne kadar eğlendiğinizin bir önemi yok, teknoloji aslında zihninizin öngörebildikleri ile gerçekte ne ürettiğiniz arasında kusurlu bir merceği temsil ediyor. Elinden geleni yap, öğrenmeyi öğren ve uyarlanabilir kal ...



35

Öğrenmeyi bıraktığınız gün, artık programcı olmadığınız gün olmalıdır.


Bir dileğim olsaydı, Santa benim babamdı.

Çünkü Noel Baba ...

1
Öğrenmeyi bıraktığın gün, öldüğün gün olmalı. :) +1 zaten
ShdNx

Yani sonsuza dek yaşamak için sürekli öğrenmeye devam etmelisin? Şimdi onaylayabileceğim bir fikir var!
Kanadalı

34

Birim testi ve hata ayıklama.


Birincisi, ikinciye olan ihtiyacı ortadan kaldırır. ;-)

4
Hayır, ünite testi başarısız olduğunda hata ayıklama gerekir. İkisi birlikte gider.
Zan Lynx

Bunu yeterince vurgulayamıyorum.
fastcode java

33

Daha önce de bahsedildi, ancak bence kendi cevabını haketti.


Daha fazla kullanmaya başladım, burada ve orada parçalar topladım, ama hala amatör bile değilim.

Tamamen katılıyorum. Anlamadığınızda garip ve zor görünüyor, ancak anladığınızda, başka bir şeyi yapmak için gerekli olan bir tonluk subring / indexof işlev çağrısından çok daha kolaydır. Sadece kalıplarınızın iyi yorumlanmasını sağlarım.
Kibbee

9
Bazı insanlar, bir sorunla karşılaştığında, "Biliyorum, düzenli ifadeler kullanacağım" deyin. Şimdi onların iki problemi var. - "Jamie Zawinski": j.z.livejournal.com , comp.lang.emacs içinde
Bjorn Reppen 28:08

Temelde etraflarında yerleşik bir düzenleyici kullanmak, iğrenç nitty cesaretini öğrenmek için iyi bir yoldur. Deneyimlerim, fiili standart PCRE'lerle çoğunlukla karşılaştırılabilir bir eşdeğerini kullanan vim ile - ama aynı kuralların emacs dünyasında da geçerli olduğu izlenimini edindim.
intuited

1
Bazı insanlar, düzenli bir ifadeyle karşı karşıya kaldıklarında, “Biliyorum, Jamie Zawinski'yi alıntılayacağım” diye düşünürler. .
Donal Fellows

29

Hiç kimse yazılımı kullanmak istemiyor. Sorunların çözülmesini istiyorlar.


7
Kesinlikle. Geliştiricilerin bir şeyi neden yapamayacağı konusundaki sorularına cevap olarak bir son kullanıcıya veri tabanını açıklamaya çalıştıklarını duyduğumda, bağırdım. Nasıl yaptığımızı bilmelerine gerek yok. Sadece çalışmasını istiyorlar. Ve olması gereken de bu.
Kevin Fairchild

İnsanların bir zevk bulabilecekleri yazılımlar yazabileceğine inanmak hoşuma gidiyor.

Daha fazla katılamadım. Ancak bu, API'ler için de geçerlidir. Kimse yeni API'ler öğrenmek istemiyor çünkü çok komik. API'nin işlevselliğini istiyoruz, temsil ettiği kodu değil.
Blub,

Kevin, "uygulama programcımız" (test görevlisi için lüks kelime) okuyup anlasaydı keşke. Ben de masamın arkasında oturup, döngülerden ve son kullanıcılara yönelik ifadelerden bahsetmeye başladığında dünyanın onu yutmasını umuyorum.

27

Coffee ve IntelliSense , şimdiye kadarki en iyi arkadaşlarınız.


Keşke bunu birden fazla oy verebilseydim!
Dinah,

Daha fazla kahve içmeyi umuyorum !!!! ñ_ñ

Sanırım bu konuda daha çok SO ile aynı fikirdeyim.
Unkwntech

Bir projeyi X saat içinde kesinlikle bitirmem gerekmediği sürece pratik olarak asla kahve içmem. Ne zaman: Günde kullanılan saat + X> 8.
Blub

Kahve size enerji vermiyor. Sadece iç rezervinizden biraz sıkın. Bu kötü / sağlıksız.
Andrei Rinea

18

Büyük ve karmaşık bir nesneyi nasıl gözlemler ve tekrar bir araya getirdiklerinde aynı görevi yerine getiren küçük basit nesnelerde nasıl ayrıştırılır.


18

Bir kullanıcıya asla güvenmeyin ( özellikle uygulama herkese açıksa!), Uygulamanızı bir şekilde bozmak için ellerinden geleni yaparlar.

Gelecekte ispatlanabilir ve genişletilebilir hale getirin - birkaç yıl içinde ne zaman genişletmek istediğinizi asla bilemezsiniz ve kötü oluşturulan kodu yeniden kodlamak için ne kadar çaba harcayacağınızı fark edemezsiniz.


1
Bu çok genelleştirilmiş. Bazı pragmatizm de iyidir.
mafu

18

Programcının her şeyi bilmediği ve daima yeni dilleri / teknolojileri, vb. Öğrenmeye çalışması gerektiği.


16

İyi UI tasarım ve iletişim (aka grafik) tasarımının temelleri .

Kötü tasarım veya düşük kullanılabilirlik yüzünden çok fazla uygulama ve proje görüyorum. Sadece temelleri öğrenmek, fark yaratan bir dünya yaratabilir. Ayrıca görsel problem çözme teknikleri (yani, bir kavramı görsel olarak nasıl iletirsiniz), gözlerinizi yeni görmenin yollarına açması gereken ve ardından kodunuz üzerinde bir etkisi olması gereken uyarıcı bir zorluktur.

Önerilen bir kitap Robin Williams'ın Tasarımcısı Olmayan Tasarım Kitabıdır .

İşte Joel Spolsky'nin söylediği şey :

Vaov! Herkes biraz grafik tasarım yapmak zorundadır ve her yazılım ekibi profesyonel tasarımcıların lüksüne sahip değildir. Bu mükemmel, ince kitap size sayfa düzeninin, yazı tiplerinin vb. Arkasındaki prensipleri anlayacaktır. İyi haber, su soğumadan banyoda okuyabilir ve ertesi gün, iletişim kutularınızı ve powerpoints ve web sayfaları daha iyi görünmeye başlayacak.


1
İkincisi, 'günlük şeylerin tasarımı' için ek bir başını sallayarak. amazon.com/Design-Edaysday-Things-Donald-Norman/dp/0385267746
Stimul8d

14

Her programcının çabuk öğrenmeyi bilmesi gerekir. Çoğu zaman bir işe girdiniz ve hiç kullanmadığınız bir teknolojide gelişmeniz istenecek. Üretim kalitesinde bir kod yazmanız istenmeden önce (eğer şanslıysanız) ayağa kalkmanız için size bir hafta kadar süre verebilirler.


İlk programlama işime başladım ve bir hafta içinde sonunda canlı yayınlanacak kod yazıyordum. Neyse ki ben hızlı bir öğreniciyim ve geçmiş programlama deneyimim vardı. 6 ay içerisinde performansı üç katına çıkarmak için istemci-sunucu bağlantısını yeniden yapılandırdım. Bu daha önce hiç kullanmadığım bir dildi.

14

Sürüm kontrolü Ve kız arkadaşıma alıntı yapıyorum: "Sadece bulaşıkları yıkmanı istemiyorum, hoşlanmanı istiyorum !"


10

Gereksinimler değişir, kodunuz uyum sağlamak zorunda kalır ve uyum sağlamak zorunda olan siz olabilir veya olmayabilir.

Olmuştur birkaç soru burada bu etkilenen konularla ilgili.


10

Başımın üstünden:

  1. Çok az programlama problemi toplama, çıkarma, çarpma ve bölme işlemlerinin ötesinde matematik gerektirir. Bir problemi çözmek için hesabı kullanmayı düşünüyorsanız, bunu yapmadan önce alternatifleri ayrıntılı olarak araştırın.

  2. Bir şeyin nasıl çalışması gerektiğini tahmin ederken kendini ne zaman bulursan, yanlış yapıyorsun. Telepatik olmak senin işin değil.

  3. Spesifikasyonu size veren kişi, siz onu bitirene kadar istediği her şeyi nadiren bilir.

  4. Büyük bir programcı olmanın yarısından fazlası insanlarla başa çıkmaktan geliyor. Ekibinizle etkileşime girmek, yöneticinizi yönetmek ve son kullanıcıya hükmetmek işin yarısı.

  5. İyi kod, derleyicileriniz tarafından okunması gerektiği kadar insanlar tarafından okunması için yazılmıştır.

  6. En iyi uygulama ve pratik gerçeklik, programcının düşündüğünden daha fazla, ancak yöneticinin düşündüğünden daha az çatışma içinde olacaktır. Çatışma içerisindeyken, çatışmayı betimlemek ve anlamak ve sonra pratiği yapmak sizin sorumluluğunuzdadır. İnce ve zekice olan çözüm, uzun vadede daha düşük maliyetli olması durumunda, sadece çirkin olandan daha iyidir.

  7. Harika araçlar harika programcılar yapamaz, ancak kötü araçlar bizi aynı derecede berbat yapar.

  8. Asla bir teknolojiye bakma, ama her zaman en iyi alternatifi ara.

  9. Ne kadar çok dil biliyorsanız, kullandığınız dilde o kadar iyi olursunuz.

  10. Programlama odaklı düşüncelerin yavaş yavaş günlük hayatınıza girmesinden rahatsız olmayın. Bilgisayarda olmasak bile, hepimiz bant genişliği sınırlamalarından muzdaripiz, görev değiştirmeden performans cezaları alıyoruz ve yedek depolama alanından şeyler yüklemeliyiz. Bilgisayarların insan düşüncesini taklit etmesi gerekiyor ve analogları her yerdeler.


10 numara beni güldürdü. Pek çok kez işte bir sorun üzerinde çalışacağım ancak saat 10: 00'da sadece yatakta, sonunda cevabı buldum!

9

Diğer insanların kodlarını okumak beyninizi bozmayacak, aksine neden böyle yapamayacağınıza karar vereceksiniz (eğer daha iyi ya da olmasa).

Bu size programlama gedanken deneyi verir ve bazen bir şeyi daha iyi uygulayan birini bulursunuz! Daha iyi şekilde gibi.

Bu cevap doğal olarak kendi kodunuzu okumak için genişler, böylece sürüm kontrolünü ve DIFF'yi ve böylece 42'ye kadar genişler.

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.