Her programcı programlama hakkında ne bilmelidir?

1. Hata derleyicide veya çalışma zamanı kitaplıklarında değil kodunuzdadır.

2. Olası bir hata görüyorsanız, programınızı doğru şekilde oluşturup dağıttığınızı kontrol edin. (Özellikle karmaşık bir IDE veya dağınık ayrıntıları sizden gizlemeye çalışan bir çerçeve kullanıyorsanız ... veya yapınız çok sayıda manuel adım içeriyorsa).

3. Eşzamanlı/çok iş parçacıklı programların yazılması zor ve düzgün test edilmesi daha zordur. Eşzamanlılık kütüphaneleri ve çerçevelerine olabildiğince yetki vermek en iyisidir.

4. Belgeleri yazmak, programcı olarak işinizin bir parçasıdır. Bunu "başkası" için bırakmayın.

DÜZENLEMEK

Evet, 1 numaram abartılı. En iyi tasarlanmış uygulama platformları bile hata payına sahiptir ve daha az iyi tasarlanmış olanlardan bazıları bunlarla doludur. Ancak yine de, önce kodunuzdan her zaman şüphelenmelisiniz ve yalnızca derleyici/kütüphane hatalarını varsa suçlamaya başlamalısınız. Kodunuzun hatalı olmadığını gösteren açık kanıtlar.

C/C++ geliştirme yaptığım günlerde, sözde optimize edici "hataların" bana/dilin belirttiği şeylerin tanımsız sonuçlara sahip olduğu şeyleri yapan başka bir programcı nedeniyle ortaya çıktığı vakaları hatırlıyorum. Bu, Java gibi sözde güvenli diller için bile geçerlidir; Örneğin. Java bellek modeline uzunca bir göz atın) (JLS bölüm 17).

• Başkalarının kodlarını nasıl okuyabilirim?.
• Sürüm Kontrol Sistemi'nde işaretlenmemişse kod mevcut değildir.

Kayan nokta hesaplamaları değil hassastır.

Öğrenmeyi bırakma.

Kodunuzun kalitesini ve sürdürülebilirliğini artırmak için yapabileceğiniz 1 numaralı şeyin DUPLICATION'I AZALTIN.

Sorun Giderme ve Hata Ayıklama Becerileri

Aldığım programlama derslerinin hiçbirinde bu konuya neredeyse hiç zaman harcamıyorlar ve tecrübelerime göre, bir programcının ne kadar üretken olduğunun en büyük belirleyicilerinden biri. Beğenin ya da beğenmeyin, uygulamanızın bakım aşamasında yeni geliştirme aşamasından çok daha fazla zaman harcarsınız.

Sorunu herhangi bir şekilde bulmak için herhangi bir strateji olmadan rastgele değiştirerek hata ayıklayan birçok programcı ile çalıştım. Bu konuşmayı onlarca kez yaptım.

Diğer Programcı: Bence düzeltip düzeltmediğini görmeye çalışmalıyız.
Ben: Tamam, bunu düzelttiğini varsayarak. Bu size sorunun kaynağının nerede olduğu hakkında ne söylüyor?
Diğer Programcı: Bilmiyorum, ama bir şey denemeliyiz .

1. Akıllı olmayın; açık ol.
2. Tekrar kullanmadan önce kullanın.
3. İsimler önemlidir.
4. Bir işlev 1 şey yapar ve iyi yapar.
5. Küçük büyük olmaktan iyidir.

Temeller. Şu anda programcılar kavramları değil teknolojileri öğreniyor. Yanlış.

Her programcı varsayımları her zaman koda koyduğunu bilmelidir, örn. "bu sayı pozitif ve sonlu olacak", "bu kod sunucuya her zaman göz açıp kapayıncaya kadar bağlanabilecektir".

Ve bu varsayımların ne zaman bozulacağını hazırlaması gerektiğini bilmelidir.

Her programcı test hakkında bilgi sahibi olmalıdır.

Öğrenmek kavramlar. Sözdizimini Google yapabilirsiniz.

Eleştirel ve mantıklı düşünme. onsuz iyi bir şey yapamazsın.

Mutlak Minimum Her Yazılım Geliştiricisi Unicode ve Karakter Kümelerini Kesinlikle, Olumlu Olarak Bilmeli (Bahane Yok!) .

Birim Testi. Bu, kodun nasıl kullanılacağına ilişkin varsayımlarınızı kodlamanın harika bir yoludur.

Büyük O gösterimi ve sonuçları.

Bazı faydalı referanslar

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

Alan bilgisi. Spesifikasyon asla% 100 değildir; birlikte geliştirdiğiniz gerçek alan adını bilmek DAİMA ürünün kalitesini artıracaktır.

Düşündüğünden daha zor.

Her ne kadar normal kullanıldığında çalışan bir şeyleri bir araya getirmek kolay olsa da, hatalı giriş, tüm Edge ve köşe vakaları, olası arıza modları vb. İle başa çıkmak zaman alıcıdır ve muhtemelen işin en zor kısmı olacaktır.

O zaman uygulamayı da iyi göstermelisin.

Tabii ki işaretçiler. :)

Veriler koddan daha önemlidir.

Verileriniz akıllıysa, kod aptal olabilir.

Aptal kodun anlaşılması kolaydır. Akıllı veriler de öyle.

Neredeyse sahip olduğum her algoritmik keder, verilerin yanlış yerde olması veya gerçek anlamının kötüye kullanılması nedeniyle olmuştur. Verileriniz bir anlam taşıyorsa bu anlamı tür sistemine girin.

Kod Tamamlandı 2 - örtmek için örtün

İş için en uygun dil ve çevre. Ve bu her zaman favoriniz değil.

Böl ve fethet. Programlamadan hata ayıklamaya kadar her türlü pratik sorunu çözmenin en iyi yolu genellikle budur.

Gerçek beceri, karmaşık bir tasarımın hiç çalışmamasına değil, basit bir tasarımı iyi uygulama yeteneğine de yansır.

Bu beceri, sırların ustalığında değil, temellere daha fazla hakimiyetten gelir. Yüksek kalibreli bir programcı, başkalarının yapamayacağını kodlama yetenekleriyle tanımlanmaz (daha yüksek seviyeli fonksiyonlar kullanarak, gelişmiş fonksiyonel programlama, sahip olduğunuz) ama daha çok sıradan kodlamayı hassaslaştırma becerilerinde. Sınıflar arasında uygun işlev ayrışmasının seçilmesi; sağlamlık içinde bina; savunma programlama tekniklerini kullanarak; ve daha fazla kendi kendine belgelemeye yol açan desen ve isimler kullanarak, bunlar yüksek kalibreli programlamanın ekmeği ve tereyağıdır.

Sizin veya bir başkasının ayda bir veya bir hafta içinde geri gelebileceği ve bu kodun nasıl kullanılacağını, değiştirilebileceğini, geliştirilebileceğini veya genişletilebileceğini iyi bir kod yazmak çok önemlidir. Size zaman ve zihinsel çaba kazandırır. Daha önce karşılaşacağınız barikatları kaldırarak üretkenlik çarklarını yağlar (belki de düşünce treninizi kesintiye uğratır veya belki de diğer çalışmalardan saatler veya günlerce çaba harcar vb.) Zor sorunlara konsantre olmanızı kolaylaştırır. ve bazen zor problemleri ortadan kaldırır.

Tek kelimeyle: zarafet. Her sınıf, her yöntem, her koşul, her blok, her değişken adı: zarafet için gayret edin.

Kullanıcıyı asla daha temiz bir kullanıcı deneyimi veya daha iyi belgelerle düzeltilebilecek şeyleri suçlamayın. Çoğu zaman, programcılar otomatik olarak kullanıcının sorun genel bir deneyim veya iletişim eksikliği olduğunda doğru bir şey yapamayan bir aptal olduğunu varsayar. Programların kullanılması amaçlanmıştır ve kullanıcıya hor davranmak, ilk etapta programlama noktasını kaçırmaktır.

Her programcı hata ayıklayıcıyı nasıl kullanacağını ve nasıl kullanacağını bilmelidir iyi.

Google nasıl kullanılır?

Veri yapıları

Kısa devre değerlendirmesi, boolean operatörleri hakkında size öğrettikleri ilk şeylerden biri olduğunu düşündü.

Kullanıcı hataları değildir; bunlar kullanılabilirlik hatalarıdır:

• Tehlikeli işlevsellik sadece uyarılmamalı, geri alınamaz olmalıdır. İşte rm 'a bakın, hangi yine de çöp kutusuyla çalışmaz.
• Kullanıcı bozulursa en az zararlı olan yapın (ESC, Ctrl-C). İdeal olarak, sistem komutu çalıştırmadan önce aynı durumda olmalıdır. rm, tekrar.
• Zararlı seçenekler zararsız olanlardan uzak olmalıdır. GNOME Çöp Kutusu'ndaki bir dosyayı sağ tıkladığınızda "Geri Yükle" nin hemen yanındaki "Kalıcı Olarak Sil" görüntülenebilir :(

Özellikle GNU Araçlar veya GNOME'u seçmemekle birlikte, bunlar en kolay örneklerdir.

Bir özelliğin uygulanması için ne kadar zaman alacağını doğru bir şekilde tahmin etme. Daha da önemlisi, bu tahmini gönderdiğinizde saçmalık olmadığınızı nasıl ifade edersiniz.

Kodlama stili önemlidir:

• tutarlı girinti önemlidir,
• beyaz alanın (ör. operatörler) tutarlı kullanımı,
• {} s konularının tutarlı bir şekilde yerleştirilmesi,
• iyi seçilmiş tanımlayıcılar önemlidir,
• vb.

... ve iyi tasarım önemlidir.

İdeal olarak, programcı ilk kod incelemesinden önce (veya sırasında) bunları öğrenir. En kötü durumda, programcı patron ona aceleyle korkunç bir kodda önemsiz değişiklikler yapmasını söylediğinde öğrenir.

Burada ticari yazılımlardan bahsetmişken ... Açıkçası bir DOD güvenlik sistemi veya bir riskten korunma fonu miktarı için geçerli olmayabilir.

• Akıllıca değil, neyin işe yaradığına odaklan, KISS.
• 80/20 kuralını aklınızda bulundurun ve zamanınızı azınlığı memnun etmek/satmak için harcamayın.
• Veri yapıları/algoritmalar hakkında bir ders alın.
• Test, test, test.
• Üretimde olan ve şu anda çalışan kodda uğraşmayın. Aşırı nakit akışınız yoksa ve yeni bir fikriniz yoksa. O zaman sorun değil.
• Zamanınızın büyük çoğunluğu ilginç programlama problemlerini çözmeyecek şekilde, sıralama yoluyla harcanacak. Görüşme yapmadığınız sürece, bu durumda insanlar sadece ilginç programlama sorunlarını nasıl çözdüğünüzü görmek ister.

Orada -

1) = OO (nesne yönelimi)) ötesinde diğer programlama paradigmaları

Bilgisayar gerçekten nasıl çalışır, dil temelleri, algoritmalar/veri yapıları, algoritma analizi ve karmaşıklık teorisinin bir ölçüsüdür.

Bundan bahsedilmediğine inanamıyorum

Değerli her programcı tuz üretmek gerekir dünyaya hazır yazılım .

Bununla, tüm dizeleri dışsallaştırma gibi temel uluslararasılaştırma ilkelerini takip etmek kastediyorum.

Ürün çevrildiğinde kaç kez kodlanmış İngilizce dizeleri veya kesilmiş dizelerle vb. İletişim kutuları gördüğüme inanamıyorum.

Birim testi gümüş bir kurşun değildir. Yine de hataları tanıtabilir, yanlış testler yazabilirsiniz ve yaptığınız tek test şekli olmamalıdır.

Bilgisayarlar anlambilimi anlamıyor. Varsayalım:

var ferrari = new Ferrari();
ferrari.DriveTo(Places.Seattle);

Bilgisayar için farklı tür adları da kullanmış olabilirsiniz:

var mxEEcceqs = new safHBBdueWE();
mxEEcceqs.HYBbQAW(n3dNm.pDojeW);

Bir şeyleri adlandırmak çok önemlidir, ancak sadece "Ferrari" türünüzü veya "DriveTo" yöntemini adlandırdığınız için bilgisayarın ne demek istediğini bildiğini varsaymak gibi bir hata yapmayın.

Yürütme sırası.

Programcılarla, kod görmemiş veya dokunmamış insanlarla veya taklit programcılarla * konuşurken, şaşırmadıkları şey, yürütme sırasıdır. Kontrol yapılarını alamayan biriyle tanışırsanız, önce bu fikri başlarına alın. Bundan sonra daha hızlı öğrendiklerini göreceksiniz.

* evet, programcı olarak iş bulabilen insanlar, ama onlara en basit teknik soruyu sorduğunuzda, beyin osuruğuna giderler. Sanırım hepimiz bunlardan biriyle tanıştık.

Her programcı Bilgisayar Bilimi'nde (bilim, tasarım desenleri, algoritmalar, nesneler, vb.) “Bilimi” bilmelidir, eğer bu konuda ustalaşırsanız, herhangi bir dili kullanarak programlayabilirsiniz, bu sadece sözdizimine alışmak meselesidir.

Lexing ve ayrıştırma nedir, sadece belirsiz bir bakış iyidir. Daha da iyisi, en az bir ayrıştırıcı jeneratör çerçevesine aşinalık.

Gördüğüm en korkunç WTF'lerin çoğu, insanların özel ayrıştırma rutinleri. Başlangıçta kodlamak korkunç, korumak daha kötü.

Değerlendirme.

Bir programcı, yazdıkları ifadelerin nasıl değerlendirildiğini bilmelidir. a(line.of(code) is aSequenceOf(evaluations)) ve değerlendirmenin her adımından sonra bu satırın neye benzediğini anlamıyorsanız, dil özelliklerinden yararlanabilmeniz için programcı olarak son derece kısıtlı olacaksınız.

Sadece temel şeylerden bahsetmiyorum

if (bool == false):
    return true
else:
    return false

tabii ki return !bool ile değiştirilebilir.

Ayrıca, dilinizi böyle bir şey bulabileceğiniz noktaya anlama yeteneğinden de bahsediyorum:

string[] thingsToOutput;
for(int i = 0; i <= thingsToOutput.Length; print(thingsToOutput[i++]));    

Böyle bir ifadeyi ilk gördüğümde aklımı biraz havaya uçurdu; Bana öyle gelmemişti ki for döngüsünü bu şekilde kaldırabilirdim. Bu ifadeyi yazan kişi, mevcut olanakları daha iyi anladı - benden daha fazla açık kapı gördüler, bu da onlara kod tasarlama yeteneklerinde daha fazla özgürlük ve güç verdi.

Şimdi, iyi kodunun bir sorun olup olmadığı - bu kapılardan herhangi biri açılmalı açılsın - bu tartışmaya açık. Bu kalır büyük güç ile büyük sorumluluk gelir.

Bu sorunun cevabını bilmek sizi programcı yapmaz

Yazılım Lisanslama Temelleri

• Kapalı kaynak dostu Apache ve viral olmayan MS-PL/MS-RL ile karşılaştırıldığında "viral" copyleft lisansı (GPL) arasındaki fark.

• LGPL ne zaman kullanılmalı, ne zaman kullanılmamalıdır.

• Lisans uyumluluğu. Örneğin, modern bir Apache lisanslı kitaplığı bir GPLv3 koduna bağlayabilirsiniz, ancak GPL 1 veya 2'ye bağlayamazsınız.

• Kaynak kodun tamamına sahipseniz, kodu istediğiniz kadar çok (veya az) lisans altında yayınlayabilirsiniz.

S.O.'ya not topluluğu:
Lütfen uygun gördüğünüz gibi bu cevabı düzenlemekten çekinmeyin ... temel olarak aşağıdaki yorumlar bölümü için uygun olmayan bilgiler içindir.

Kriptografi. Kendi şifreleme algoritmanızı yazmanız gerekmez, ancak şifreleme, mesaj kimlik doğrulaması ve PKI'nın nasıl çalıştığı hakkında temel bir anlayışa sahip olmanız gerekir. Bu alanda kör deneme ve yanılma ile çok uzun süre mücadele ettim. Son zamanlarda "Kriptografi Mühendisliği" (Ferguson, Schneier, Kohno tarafından) kitabını aldım ve gerçek bir göz açıcı oldu.

Kodlamaya başlamadan önce OS/Platformunuzu tanıyın.

Windows/Linux/Android/iOS vb. Kodlarsanız, işletim sistemini öğrenerek başlayın. Web gibi başka bir şeyi hedeflerseniz aynı şey oraya gider.

insanlar için kod yaz!

artık sihirli sayı yok!

tüm kodu tek bir satıra yazma!

1. insanların istediği bir şey inşa et
2. her gün kullanmak istediğiniz bir şey inşa edin
3. kodunuzu yorumlamazsanız, kodun temiz okuduğundan emin olun
4. koduna yorum yap

Hata olabilecek bir şey diye bir şey yoktur.

"Merhaba dünya" tam bir uygulama değildir, çünkü çıktı aslında "Merhaba dünya" olduğu kanıtlanmış/programlı bir iddia yoktur. Birim test edilinceye kadar kod tam değil.

Bunlardan bazıları zaten gönderildi, ama işte benim listem:

• İhtiyaçlarınızı karşılayın, ihtiyacınız olmayan şeyleri eklemeyin, özellikle de "düşünürseniz". Daha sonra ihtiyacınız varsa ekleyin.
• Google aramayı kullanma. Bakana kadar iş arkadaşınızı rahatsız etmeyin.
• Zeki olma.
• TÜM gereklilikleri karşılayana, test edilip belgelenene ve SVN'de kontrol edilene kadar yapılmaz.
• Uygun kodlama standartları, örneğin: adlandırma kuralları

Kodunuzu, testlerinizi ve yazılım paketinizi nasıl dağıtacağınızı öğrenin.

Endüstride gördüğüm geliştiricilerin en kötü alışkanlıklarından biri, yazılımınızı diğer insanların ellerine nasıl koyacağınıza dair yaygın bir cehalettir, işte bazı kötü işaretler:

Yeni geliştirme ortamı-itus:

• Öğrenmek istedim Ruby bu yüzden eşyalarımızı içine yazdık, müşteri ve ana yapı bir Ruby ortam şimdi almak zorunda kalacak)

Sürüm-itus:

• Ekibimiz X + 1 derleyici sürümüne geçti, çünkü en yenisi, kimseye söylemedik mi?
• Kütüphane sürümü Y'ye ihtiyacımız var, oh, eşyalarınız bununla çalışmıyor mu?
• Gerçekten eski bir sürümde test ettik, en son sürümle çalışmıyor mu?
• İşe giriş izni almak için çekirdeğin özel bir sürümünü hackledik

İkili okunur-itus:

• Yapım ortamımız gerçekten karmaşık, size sadece ikili dosyalar vereceğiz

Çok çekirdekli-itus:

• SMP'yi devre dışı bırakın, ürünlerimiz yalnızca tek işlemcili ortamda çalışır

Sabit kodlanmış-özellikli itus:

• X özelliğini etkinleştirmek için bu #define izin verin, çalışma zamanında olmasını istediğiniz şey nedir?

Basitlik, Netlik, Genellik. http://www.math.harvard.edu/computing/programming/rules.html

• soketler/borular ile bağlanan basit süreçlerin ağları olarak sistemler inşa etmek
• basit bir metin biçiminde veri alışverişi: "anahtar: değer" çiftleri veya TSV kayıt kümeleri

"En etkili hata ayıklama aracı, dikkatli bir şekilde düşünülmüş ve mantıklı bir şekilde yerleştirilmiş basılı ifadelerdir." BWK

Seçtiğiniz platformda güvenliğin nasıl çalıştığını daha iyi bilirsiniz.

İş için doğru aracı kullanın.

Programcı önemli bir unsurdur ve dil ve araçlar soruna göre seçilmelidir. Yeni diller ve projelerden korkmayın.

çtuğunuz gibi test edin, test ettiğiniz şeyi uçurun .

Programlamada ağlamak yok!

1. temel kavramlarının tam olarak anlaşılması örn. veri tipleri, arayüzler
2. kullandıkları aracın orta ve yüksek düzeyde anlaşılması örn. belirli .net/Java bilgisi
3. 'öğelerinizin arayüz sağladığı diğer teknolojiler' hakkında makul bir fikir; veritabanları nasıl çalışır
4. kabaca teknoloji tabanlarının bulunduğu yer; bulut bilişim nedir ve mevcut yetenekleri üzerinde ne gibi bir etkisi olacak

Bir FizzBuzz programı nasıl yazılır.

Bir uygulamayı dağıtmanız veya bir web sitesini şirketinizin sınırları dışında üretime sokmanız gerektiğinde, düşündüğünüz her şeyin önemi yoktur.

Kod sadece yapması gerekeni yaparsa güzeldir.

• İkili imzalı ve imzasız temel anlayış.
• Herhangi bir konumsal sayısal sistemin nasıl çalıştığını anlayın.
• Temel veri yapılarının bellekte nasıl saklandığını anlayın.

Kodu sabitlemek, başlangıçta aynı kodu yazmaktan daha fazla zeka gerektirir.

Bu nedenle, akıllılığınızın sınırına kod yazarsanız, tanım gereği, kırıldığında düzeltmek için yeterince akıllı değilsiniz.

Önce veri yapılarınızı yazın - bu, veritabanı şemalarından dönen/serileştirme mekanizmalarına kadar her şey anlamına gelir.

Çoğu proje, verileri A noktasından B noktasına C biçiminde depolamak ve taşımakla ilgilidir.

Her şey söylendiğinde ve yapıldığında kodunuzun yaklaşık% 90'ı biçimlendirme yapmak için mantıksal olacaktır, ancak gerçek katil sadece verilerinize erişmek ve yazmak için bir biçime sahiptir. Veri erişimi için bir API'ye sahip olduğunuzda, istediğiniz şekilde biçimlendirmeyle oynayabilirsiniz, ancak bir depolama API'sı ile üretime başladığınızda, onu vidaladığınızı fark etmek gerçekten acıtabilir.

Steve Yegge'in 5 temel telefon ekranı sorusunda, görüşmecilerin aşağıdakiler hakkında temel bilgilere sahip olduğundan emin olmaya çalışıyor:

1. Kodlama. Aday, C, C++ veya Java'da doğru sözdizimi ile basit bir kod yazmalıdır.
2. OO tasarımı. Aday temel OO kavramlarını tanımlamalı ve basit bir problemi modellemek için sınıflar bulmalıdır.
3. Komut dosyası oluşturma ve normal ifadeler. Aday, 50.000 HTML sayfasında telefon numaralarının nasıl bulunacağını açıklamalıdır.
4. Veri yapıları. Aday en yaygın veri yapıları hakkında temel bilgileri göstermek zorundadır.
5. Bitler ve baytlar. Aday, bitler, baytlar ve ikili sayılar hakkında basit soruları cevaplamalıdır.

http://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions

Bunu yazdığı sırada Amazon'daydı, ancak şimdi Google'da çalışıyor (ve muhtemelen röportajlar yapıyor). Bu sadece ekranı geçmenizi sağlar. Aradığı şeyi şöyle tarif etti:

burada aradığım şey, bu alanlardan birinde tam bir boşluk. Biraz mücadele edip çözdüklerinde sorun yok. Bazı küçük ipuçlarına veya isteme ihtiyacınız varsa sorun değil. Paslı mı yoksa yavaş mı olduklarını umursamıyorum. Aradığınız şey, söz konusu alan hakkında tamamen clueless veya korkunç bir şekilde karışan adaylardır.

Dokümantasyon çok önemlidir. Daha çok sıfırdan bir şey inşa ediyorsanız. Herhangi bir kod yazmadan önce fikirlerinizi belgelemenize yardımcı olur.

Bunu zor yoldan öğrendim.

Henüz yorum yapamam, ama "Test ve hata ayıklama becerileri" konusunda, bu küçük gem Ned Batchelder tarafından okunması gereken bir. (O zaman kazanın, hata ayıklama ve iddialar hakkında söylediklerinin çoğu dikkate değerdir.)

Her programcı, bildiği tek şeyin hiçbir şey bilmediğini bilmelidir. Öğrenilecek çok şey var.

Her programcı FindNextSelected ve FindPreviousSelected eylemlerini (visual studio) klavye tuşlarına (tercihen F4 ve F2) bağlamalıdır. Bundan iki şey alıyorsunuz:

1. Değişken/işlev/alt dize kullanımının farklı noktaları arasında gezinmenin daha hızlı yolu ("Tüm referansları bul" ile olduğundan daha hızlı)
2. Belgeleri tek bir belgede ayırma imkanı. Bazı alt dizeleri ararken ileri ve geri atlayarak farklı konumlar arasındaki farkları görebilirsiniz. Aynı belgenin bazı bölümlerini karşılaştırmanız gerektiğinde Winmerge kullanmaya gerek yoktur.

Koşullu gruplama dahil temel düzenli ifade sözdizimini bilir. Kütüphaneye özel regex komut eklentilerini kullanmaktan uzak durun veya en azından bu bölümleri yorumlayın/etkileyin.

Nasıl yapılır.

... 15 karaktere ihtiyacım var ne demek?

Sürdürülebilirliği göz önünde bulunduran program.

Normal ifadeler

Basit düzenli ifadelerin, insanların manipüle edilmesi günler alacağını düşündüğü verileri kaç kez dönüştürdüğünü söyleyemem. Her programcı araç kutusunda bulunmalıdır.

Tabii, xkcd'yi unutamayız: 

Her programcı bir işlemcinin nasıl çalıştığını bilmelidir.

Bir şey Master olun, ama Farkında olun - Her şey !!!!

Burada çok iyi bazı öneriler var, ama hiç kimse Ulrich Drepper'ın mükemmel makale serisinden bahsetmediğine şaşırdım: Her programcının bellek hakkında ne bilmesi gerekir .

Tüm sorunlar bilgisayar biliminde başka bir dolaylılık düzeyi ile çözülebilir.

Kodunuzu tasarlayın ve yöneticiniz RAD stil yaklaşımı kullanmak istiyorsa mümkün olduğunca fazla ayrıntı deneyin ve daha fazla işlevsellik eklendiğinde mevcut kodun daha önce yeniden yazılabilir olup olmadığını düşünün. sadece daha fazla kod kazık ve bir ev yerine bir highrise ile sonuçlanır.

her programcının yazılım mühendisliğinde sağlam bir topraklaması ve ayrıca sistem analizi/tasarımı ve bilgi sistemleri kavramları olmalıdır. bu şekilde sistem analizine/tasarımına ve/veya bilgi mimarisine önemli ölçüde katkıda bulunmaları istenirse, bilgi + opionion pozisyonunda olacaklardır; normalde bunun yerine genellikle kişisel tercihlerden kaynaklanan kişisel görüş gibi görünmektedir. en iyi sorun çözümü. yazılım mühendisliğini ölçmek biraz daha zordur, ancak önkoşul bilgisi orada ve biraz kod birlikte nasıl çözüleceğinden daha fazlasını öğrettikleri uygun üniversite derece derslerinde mevcuttur. Her neyse, bu olumsuz olmak anlamına gelmez çünkü ana ruh ancak iyileştirmedir, ancak daha sonra BT bilgisi olmayan bazı kişilerle çalıştım ya da kod ve yeniden kodlama yapan tek fikirli "script kiddies" var (ve sadece kendi dilleri) ve sadece her problemi daha önce uygulanmış çözümlerin (bu kodlayıcı tarafından) bir tekrarı olarak görüyorum, bu yüzden programcılar yazılım mühendisliği (SSADM) açısından daha büyük resme daha fazla odaklanır ve sorunlara fırsat olarak bakarlarsa çok tercih ederim müşteri için daha iyi yapmak.

Önce kafanızdaki veya kağıdınızdaki kodu veya mantığı çalıştırın. Derleme vurmak ve test etmek için komut çalıştırmak için acele etmeyin.

Gerçekten birkaç harfle duruyor:

• RTFM (ve bugün kewl kidz için: JFGI )
• KURU
• ÖPÜCÜK
• h2g2

Tamam, aşırı basitleştiriyorum, ancak temel olarak oldukça otodidaktiyseniz, asla öğrenmeyi bırakmazsanız ve biraz mükemmeliyetçiyseniz, iyi bir programcı olma temeline sahip olmalısınız.

Bunun ötesinde her şey belirli rollere ve teknolojilere daha özgüdür.

Bir şey ters gidebilirse, o zaman olur. En kötü davayı varsayalım

Oluşturduğunuz yazılımı kullanacak kişiyi unutmayın.

Yanlış gidebilecek her şeyin yanlış gideceğini kabul edin. Kod yazmak için çok az zaman harcayın - ancak ortak kalıpları tanımak ve yeniden kullanmak. İdeal tasarıma ulaşmak için sürekli olarak refactor kodu.

Tüm veriler bir yerde yaşamak zorundadır. Yeterince sert bakarsanız bulabilirsiniz.

Kapakların gücünü bilmeleri ve kullanmaya başlamaları gerekiyor.

Onaltılık gösterim. Ayrıca bit alanları - ANDing, ORing (kapsayıcı ve özel), tamamlayıcı (1'ler ve 2'ler), bit kaydırma.

İlk oylama Adlandırma Sözleşmeleri için olacak.

Birisi sizden bir şey inşa etmenizi istediğinde unutmayın: onlar da sizden onu korumanızı ister. Muhtemelen, sonsuza dek.

Programlar ne yaparsa yapsın, bir makineye nasıl iş yapılacağını anlatmaktan çok, diğer insanlara nasıl iş yapılacağını göstermenin en açık yoludur.