Topluluk olarak çoğu zaman "hangi yeni pratiği eklemeliyiz" sorusunu tartışıyoruz. Bence aynı sıklıkla sormamız gereken soru "hangi eski pratiği bırakmalıyız" olmalı. Aşağıda yıllar içinde gözlemlediğim ve değerden çok yük üreten bazı pratikleri yapıcı eleştirel bir tonda öneri olarak paylaşıyorum. Öneri 1: erken optimizasyon refleksini bırakalım. "Ya bu bir milyon kullanıcıya çıkarsa" diye başlayan tasarım toplantıları, sonu olmayan abstraction katmanlarına dönüşüyor. Önce çalışan ve okunabilir kodu yazalım, gerçek performans sorununu measure ile gördüğümüzde optimize edelim. Donald Knuth bunu söyleyeli yarım asır oldu, hâlâ tekrarlıyoruz çünkü hâlâ uyulmuyor. Öneri 2: "clean code" dogmasını bırakalım. Bir fonksiyonun 5 satırdan uzun olması bir suç değil. Bazı problemler doğal olarak 30 satır akış gerektirir. Bunu zorla 6 küçük fonksiyona bölmek, çoğu zaman okunabilirliği artırmıyor, izlemeyi zorlaştırıyor. Soyutlama maliyeti vardır, her zaman ödenmeye değer değil. Öneri 3: yüzde 100 test coverage hedefini bırakalım. Test, gerçek davranışı doğrulamak için yazılır, metric tatmin etmek için değil. Yüzde 100 coverage, getter/setter'ları test etme zorunluluğu getirir, brittle test'ler üretir, refactor maliyetini katlar. Doğru ölçüt: kritik iş kurallarında ve sınır koşullarında %100, basit pass-through kodlarda %0 da olabilir. Öneri 4: "DRY"in körlemesine uygulanışını bırakalım. Don't Repeat Yourself, bilgi tekrarını önlemek içindir, satır tekrarını değil. İki kod parçası aynı görünüyor ama farklı domain'lere ait, gelecekte farklı evrim geçirecekse, onları tek yere toplamak aslında coupling üretir. "Premature DRY, premature coupling" cümlesini panomuza asalım. Öneri 5: comment yerine self-documenting code dogmasını bırakalım. "Kod kendini anlatır" doğrudur ama yetersizdir. "Niye bu yaklaşımı seçtik", "hangi alternatifi neden eledik", "bu workaround neyin sonucu" sorularının cevabı kodda yoktur, comment'ta olmalı. Kötü comment kötü, doğru comment kritik. Öneri 6: meeting heavy planning rituallerini bırakalım. Sprint planning, refinement, estimation, review, retro toplam haftalık takvimin yüzde 25'ini yiyor. Bu süreçlerin küçültülmüş, yazılı, asenkron varyantlarını denesek (önce yazılı paylaşım, gerekirse 15 dk sync), takımın derin çalışma süresi katlanır. Öneri 7: "learn-by-tutorial" alışkanlığını bırakalım. 100 tutorial izlemek, kendi başına bir buton koymak yerine güven veriyor olabilir ama beceriyi geliştirmiyor. Tutorial yarıya kadar izle, gerisini kendin yaz, takılınca geri dön. Pasif tüketim öğrenmiyor, aktif üretim öğreniyor. Öneri 8: araç fetişizmini bırakalım. Yeni bir framework çıktı diye mevcut çalışan stack'i değiştirmek, çoğu zaman değer değil dağınıklık üretir. Yeni araç, somut bir sorun çözmüyorsa, çözüyor görünmesi için sorun aratılır. Stack stabilitesi, takım üretkenliğinin tahminden büyük bir parçası. Bu öneriler tartışmaya açıktır, dogma değil. Topluluk olarak "hangi yeni şeyi denedik" kadar "hangi eski şeyden vazgeçtik" konuşmasını da yapalım. Bırakmak da bir beceridir.