Fikrimi değiştiren şeyler: Eskiden karşı çıktığım ama artık inandığım şeyler
- Deneyim seviyesi farklı kişilerden oluşan takımlarda typed diller daha iyidir
- Stand-up toplantıları yeni başlayanları gözlemlemek için faydalıdır
- Sprint retrospektiflerinin faydalı olan ve kötü olan yanları ayrıdır (agile/scrum master'ın herkesin zamanını boşa harcaması gibi)
- Yazılım mimarisi her şeyden daha önemlidir. İyi bir soyutlamanın kötü uygulanması kod tabanına zarar vermez. Kötü soyutlamalar veya eksik katmanlar yüzünden her şey kötüleşir
- Java o kadar da kötü bir dil değil
- Zekice yazılmış kod genelde iyi kod değildir. Açıklık her şeyin önündedir
- Herhangi bir paradigmada kötü kod yazmak mümkündür
- "Best practice" duruma göre değişir ve her şeye uygulanamaz. Körü körüne takip edersen aptal olursun
- Gerek yokken ölçeklenebilir bir sistem tasarlarsan kötü bir mühendis olursun
- Statik analiz faydalıdır
- DRY nihai hedef değil, belirli bir problemi önleme aracıdır
- Genel olarak RDBMS > NoSQL
- Fonksiyonel programlama her derde deva değil, sadece başka bir araçtır
Bu sırada benimsediğim görüşler:
- YAGNI > SOLID > DRY : bu sırayla
→ You Aren't Gonna Need It : XP'nin ilkelerinden biri
→ SOLID : nesne yönelimli tasarımın 5 temel ilkesi
Single responsibility
Open-close
Liskov substitution
Interface segregation
Dependency inversion
→ DRY : Don't Repeat Yourself - Kalem ve kağıt, yeterince kullanılmayan en iyi programlama araçlarıdır
- Saflıktan ödün verip pratiklik kazanmak genelde iyi bir tercihtir
- Daha fazla teknoloji eklemek iyi bir seçim değildir
- Müşteriyle doğrudan konuşursan daha az zamanda, sorun hakkında daha doğru ve daha fazla şey öğrenebilirsin
- "Scalable" kelimesi yazılım mühendislerinin zihni üzerinde mistik ve şaşırtıcı bir güce sahiptir. Bu kelimeyi hafifçe telaffuz etmek bile onları yozlaşmış bir çılgınlığa sürükler. Bu kelime kullanılarak acımasız davranışlar meşrulaştırılır
- Kendilerine "mühendis" denmesine rağmen, çoğu karar arkasında analiz, veri ya da sayı olmadan yapılan bir cargo cult'tan ibarettir
→ cargo cult: teknik olarak ileri birilerinin (toplum/atalar) gemi ya da uçakla özel bir kargo getireceğine inanarak bekleme geleneği - Proje yöneticilerinin %90'ı, belki %93'ü, etki ya da verimlilik açısından hiçbir katkı sağlamadığı için yarın ortadan kalksa bile olur
- 100 mülakat yaptıktan sonra şunu gördüm: mülakat yöntemi tamamen bozuk. Bunu nasıl düzelteceğimi ben de bilmiyorum
Değişmeyen eski görüşlerim:
- Kod stili, linting kuralları ve diğer ufak şeyleri abartan insanlar deli kaçıklardır
- Kod kapsamının kod kalitesiyle hiçbir ilgisi yoktur
- Monolith'ler çoğu durumda gayet iyidir
- TDD püritenleri en kötüsüdür. Kırılgan küçük zihinleri, başka iş akışlarının da var olduğunu kaldıramaz
-
- yıla geldiğimde başka nelerin değiştiğine ya da tersine döndüğüne bakacağım
9 yorum
Her bir cümleye tek tek katılıyorum. Her şeyin kusursuz olabileceği idealizmden pragmatizme doğru geçiliyor gibi görünüyor.
TDD'nin önemini fark ettiğiniz andan itibaren, o andan sonra programcı ...
Mülakatların bozuk olduğuna dair görüşler durmadan geliyor. Benden de önce bir kodlama testi çözmem istense pek kendime güvenemem (...)
Böyle bir yazıya da rastladım. Bunun 『HARD CODE』 adlı kitapta geçen bir içerik olduğu söyleniyor.
https://johngrib.github.io/wiki/better-interview/
Bunları 6 yılın sonunda mı fark ettiniz? hahaha Harika gerçekten.
6 yılın sonunda aydınlanıp Buda olmuşsunuz demek!
Hacker News'te diğer geliştiriciler ve 20 yılı aşkın deneyime sahip mühendisler de gelip ek yorumlar yazıyor.
https://news.ycombinator.com/item?id=25887373
İlk yorumdan itibaren sert başlamış haha. Her birini tek tek ele alırsak istisnai durumlar da olabilir ama ne olursa olsun körü körüne inanmak tehlikeli gibi.
Yalnızca type check ile çözülebilen epey fazla bug olduğu için, bu muhtemelen sürekli gündeme gelen bir konu olacaktır. Type'ları güvenli şekilde ele alma yöntemleri de durmadan geliştiriliyor.
(Ama TypeScript biraz zor gerçekten ;_; )