Kariyerinde öğrendiğin en iyi ders nedir? [kapalı]

Bence benimki "beş dakikalık bir iş diye bir şey yok" - programcıların gelişme konusunda aşırı iyimser olma eğiliminde olduklarını ve bir soruna hızlı bir çözüm vaat etmeden ve sonra da koda girmeden önce gerçekten bir etki yaratıp düşünmememiz gerektiğini düşünüyorum.

Kodunuzu yazmanın her zaman daha iyi bir yolu vardır.

Yazdığınız kodu ne kadar mükemmel bulursanız olun, birkaç yıl içinde gözden geçirirseniz ne kadar kötü olduğunu görünce şaşıracaksınız. Sadece birkaç yıl önce, bugün bildiğiniz bazı kalıpların ya da bu arada öğrendiğiniz bazı dil özelliklerinin farkında değildiniz.

1. Kodlamaya başlamadan önce düşünün.

2. Geçici çözümlerden daha kalıcı bir şey yok :)

3. Bir sorunu çözmek çok zorsa, büyük olasılıkla sorunun kendisi baştan kötü bir şekilde ortaya çıkar.

Yazılımınız, yazdığınız sırada düşündüğünüzden çok daha uzun süre yaşayacaktır.

Kariyerime 80'lerde başladım. 70'lerde ortaya çıkan ve hala 90'larda kullanılmakta olan yazılımlara başladım (belki de daha uzun, kaderinden emin değilim). Kendi açık kaynak kodumun bazıları ikinci on yılda yarı yolda.

Başkalarıyla iyi çalışmak çok önemlidir.

"Bana 'Adama git'i göster ve size probleminizi göstereyim"

Slapdash Hero Coders - kongre, okunabilirlik veya üzerinde çalıştığı herhangi bir şey ile ilgili olarak herhangi bir kod yazmamış olanlar - yarardan çok zarar verebilir.

Tonlarca iyi kalitede kod yazabilen insanların kötü bir şey olduğunu söylememek. Sadece nadir.

Bu alçakgönüllülük dersi olurdu.

Yeni diller öğrenmek işin bir parçası

80'lerde okuldaki dört programlama dilini öğrendim ancak birisini bir işte kullandım. Kullanmam için kullandığım dili bile bilmediğim dört işim vardı.

Genel olarak, kariyerimde FORTRAN, c, c ++, c #, java, perl, Tcl, yakut, groovy, awk, python, sh, toplu iş, DCL, javascript, ve birkaç küçük DSL. Biraz matematik yapıyor olsam da, her iki yılda bir çok örtüşme olsa da, yeni bir dili ortalama olarak görüyorum.

Eğer kariyerimde sürekli bir şey varsa, değişim.

Yazılım asla tamamlanmaz.

Gereksinimlerde, iyileştirmelerde, işlem yapmaya hazırlanmak zorunda olduğunuz hata düzeltmelerinde her zaman bazı değişiklikler vardır. Böylece, esnek olun ve "software is never complete"iyileştirmeler için her zaman yer olduğu gerçeğini kabul edin .

Her gün ders çalışmaya devam et. Bugünün bilgisi yarın modası geçmiş.

İronik olarak bu cevap yarın da kullanılmamalıdır. Ama gerçekten, sıkı bir veya iki şeyi inceleyin ve mümkünse sertifikalandırın, o şeylerin Tanrısı olun (belki de programlama dilleri veya sistem / ağ / veritabanı yönetimi) ve her zaman önemsiz diğer diller gibi diğer küçük şeylere dikkat edin. sen.

Örneğin, Java ve Oracle DB yönetimi konusunda harika bir profesyonel olmak, ancak sertifika düzeyinde olmasa da biraz Python, PHP, C ++, HTML5, Javascript çalışın. Var olan her web veya dil çerçevesini inceleyin. SQL Server, MySQL, Cassandra, HBase, PostgreSQL ve MongoDB ve CouchDB gibi tüm No-SQL dünyaları gibi varolan her veritabanıyla ilgili (temel) bir deneyim edinmeye çalışın veya deneyin. Linux yönetimi ve sanallaştırma konusunda biraz deneyim sahibi olmaya çalışın.

16 yıllık tecrübemden öğrendiğim en büyük ders bu. Neredeyse 10 yıl boyunca, o dönemde Pascal, binyıl başında Visual Basic 6 ve 9 yıldan beri bir PHP geliştiricisi kullanan bir mono dil programcısıydım. Ama ondan sonra, geliştiricilerin her şeyden en azından bir kısmını bilmesi gerektiğini öğrendim.

"Matematiğin yanlışsa, sen tostsun."

Birkaç yıl önce ilk kez öğrendim. Sadece iki hafta önce tekrar öğrendim.

Öğrendiğim en iyi ders olduğunu söyleyebilirim.

“Her zaman yaklaşımın değil , mümkün olan en iyi yaklaşıma gitmelisin .”

En iyi tasarım prensibinin KISS olduğunu öğrendim (Basit tutun, Aptal!) .

Kodunuzu basit ve temiz tutmanın birincil endişe olması gerektiğini ve her ekip üyesinin neye sahip olduğunuzu anlaması gerektiğini öğrendim. The KISS principleÇoğu sistemin karmaşık hale getirilmek yerine basit tutulursa en iyi şekilde çalıştığını belirtir, bu nedenle sadelik tasarımda kilit bir amaç olmalı ve gereksiz karmaşıklıktan kaçınılmalıdır.

Kırılmazsa, tamir etmeyin!

Zaten çalışan şeyleri genişletmeye ve iyileştirmeye çalışmak size büyük bir baş ağrısı verebilir

Burada deneme yok

Diyelim ki 4 gün alacağı tahmin edilen bir göreve veya göreve sahipsin. Sonra patronunuz veya proje yöneticiniz, önemli bir nedenden dolayı iki gün içinde halletmeyi deneyip deneyemeyeceğinizi sorar. İyi ve esnek bir çalışan olmak istemeniz, şunu söylemekten çekinirsiniz: tabi, deneyebilirsiniz. Bundan en muhtemel sonuçlar ya son tarihi kaçırmış olmanızdır ya da bunu yapmak için yarı kıçlı kesmeyi yapacaksınız. Ve senden bunu yapmanı istemek patronunun suçu değil, bu onun işi. Hayır dememek senin suçun, ki bu senin işin.

Zamanla pazarlık edemezsin. Kapsam ile pazarlık yapabilirsiniz. Profesyonel ol ve kendini kısa satma.

"Bu asla olmayacak" aslında "Üretimde ilk güne kadar asla olmayacak" anlamına geliyor.

Birinci sınıf, son teknoloji, temiz kod yazmak iyi hissettiriyor.

Kod tabanını mahvedecek hızlı bir çözüm önerisi yapmam istense bile, bunu iyi bir şekilde yapmayı tercih ederim.

• Kod yazmak kolaydır. Kod okumak zor. Kod sana ait olsa bile. Bu yüzden, mümkün olduğunda, okunabilir bir yaklaşım benimseyin.

• Sen diğerlerinden daha akıllı değilsin. Asla senin yaklaşmanın en iyisi olduğunu düşünme, çünkü senin.

• Neyin söylendiğine değil, neyin söylendiğine dikkat edin. En beklenmedik kaynaklar için harika fikirler ortaya çıkabilir.

• Tembel olmayın. Güzel kod yazmak için zaman ayırın. Yine de daha yüksek bir maliyetle düzeltmeniz gerekecek.

Fantezi OOP özelliklerini sadece kullanabildiğiniz için kullanmayın ! - YAGNI (Buna ihtiyacın olmayacak)

Use fancy OOP featuresÇünkü çözmeye çalıştığınız problemin kendine özgü, bariz bir faydası var . Gülüyorsun ama ben her zaman bunu görüyorum. Çoğu programcı, sevmedikleri bir nesneyle asla tanışmadı. Bence bunun tam tersi olmalı: bu teknikler KISS mahkemesinde masum olduğu kanıtlanana kadar suçlu .