Elveda, Clean Code (2020)

Kodu düzenlemeye veda

• Bir iş arkadaşının bir hafta boyunca yazdığı kod, akşam geç saatte check-in edildi.
• Grafik düzenleyici tuvalinde bir şeklin boyutunu ayarlama özelliği uygulandı.
• Kod çalışıyordu ama tekrarlıydı.

Ertesi sabah...

• Yönetici özel olarak konuşmak istedi ve kod değişikliğinin geri alınmasını talep etti.
• İlk başta sarsıcıydı, ama sonunda yöneticinin kararının doğru olduğunu fark etti.

Aşama

• "Temiz kod"a takıntılı olmak ve tekrarları kaldırmaya odaklanmak, birçok geliştiricinin geçtiği bir aşamadır.
• Koda güvenmediğinizde, özsaygınızı ve profesyonel gururunuzu ölçülebilir şeylere bağlamak cazip gelir.
• Soyutlamayı öğrendikten sonra, tekrarlanan kod gördüğünüz her yerde soyutlama kullanmak istersiniz.

GN⁺ görüşü

• Önemli olan, kodun "temizliğini" hedeflemenin asıl amaç olmaması; bunun karmaşık sistemlerle uğraşma sürecinde bir tür savunma mekanizması olmasıdır.
• "Temiz kod", geliştiricilerin bilinmeyen alanlarda yol bulmasına yardımcı olur, ancak ona saplanıp kalmamak ve gerektiğinde bırakabilmek gerekir.
• Bu yazı, geliştiricilere kod yazma ve bakım sürecinde işbirliği ile pragmatizmin önemini hatırlatan ilgi çekici bir bakış açısı sunuyor.

[GN⁺]

Hacker News görüşleri

• "Clean Code" markasının yeniden konumlandırılmaya ihtiyacı var

  • Clean Code'un amacı kodu daha basit ve bakımı daha kolay hale getirmektir
  • Yazılımın değeri, zaman içinde değişebilme yeteneğinde yatar
  • Refactoring bakımı daha zor hale getirdiyse bu Clean Code değildir
  • Orijinal geliştiriciyle refactoring hakkında konuşulmamış olması, Clean Code'dan ayrı bir sorundur

• Kod tekrarları bazen iyi olabilir, ancak bu Clean Code'un kötü olduğunun kanıtı değildir

  • Tekrarlanan 10 satırlık matematik hesaplamasını bir fonksiyonla değiştirdiyseniz daha temiz olabilir
  • PR gözden geçirilmeli ve kriterlere uymuyorsa reddedilmelidir
  • Clean Code'un önemini görmezden gelen tutum, sonunda kimsenin üzerinde çalışmak istemeyeceği bir kod tabanına yol açar
  • Çıkarılması gereken ders, daha iyi iletişim ve ölçülülüktür

• Bir iş arkadaşı kopyala-yapıştırla çok sayıda kod yazıyor

  • Refactoring, inceleme için gönderilmelidir
  • Yöneticinin doğrudan devreye girip geri alınmasını söylemesi kötü bir işarettir
  • Buradan çıkarılacak ders, kopyala-yapıştırın fonksiyon yazmaktan daha iyi olduğu değildir

• Clean Code sürümü büyük olasılıkla kirli kodun yerini aldı

  • Ekip olarak nasıl çalışılacağına dair dersler gerekli

• Kod değişikliklerinde ekip arkadaşı incelemesi gerekir

  • İyi bir sürecin eksik olduğu kabul edilmelidir
  • Kod refactoring'i yalnızca gerektiğinde yapılmalıdır

• Finans alanında çoğu zaman benzer ama farklı ürünlerle uğraşılır

  • Aşırı soyutlamadan kaçınırken Clean Code'u korumak önemlidir

• Haskell gibi diller, soyutlamayı dil seviyesinde en üst düzeye çıkarır

  • Proje bazlı soyutlamayı en aza indirirken öğrenme maliyeti yüksektir

• Tekrarlanan matematik hesaplamalarını ayrı bir fonksiyona taşımak Clean Code kapsamına girer

  • Arayüz oluşturma gibi görünen resize fonksiyonlarını refactor etmek yanlıştır

• Kötü soyutlamaya dair açıklama

  • Gelecekteki kullanımı yeterince düşünmeden tasarlamak sorundur

• Rob Pike, "Biraz kopya, biraz bağımlılıktan iyidir" demiştir

  • DRY ilkesi bazen soyutlama ekler, ancak soyutlama yeterince ortogonal değilse sorunu daha da kötüleştirir