Yazılımınızı Sürdürülemeyen Hale Getiren 5 Yaygın C# Hatası — Derek Comartin Tarafından Açıklandı

1. Durum Üzerinde Sahiplik Eksikliği

Derek, paylaşılan verilerin net bir sahiplik olmadan birden fazla sınır veya hizmet tarafından güncellenmesine izin verme hatasını belirterek başlıyor. Örnek olarak, fatura sisteminin uygulamanın başka bir kısmına ulaşarak durumu değiştirmesi olayı üzerinden gidiyor. Bu, özellikle o nesne sistem içinde farklı bir konumda ikamet ediyorsa, veri tutarlılığı sorunlarına yol açar.

Bu tür sınırsız bir yaklaşım, geliştiricilerin şu soruları sormasına neden olan hatalara yol açar: "Bu veriler neden yanlış?" veya "Kim bunu değiştirdi?" Derek, sahipliği tanımlamanız gerektiğini vurguluyor. Her sistem parçası durumu yönetmekten sorumlu iyi tanımlanmış bir API veya yöntem sunmalıdır.

Uygulamanın herhangi bir bölümünün paylaşılan verileri değiştirmesine izin vermek yerine, Derek açık komutlar ve sorgular oluşturmayı önerir. Örneğin, bir sevkiyatı güncellemek istediğinizde, özel bir arayüz üzerinden bir komut verirsiniz. Bu, yapı sağlar ve izlenemeyen değişikliklerden kaynaklanan kaynak sızıntılarını önler.

2. Gizli Kod vs. Açık İş Akışları

Derek'e göre, birçok sistem CRUD işlemlerine (Oluştur, Oku, Güncelle, Sil) fazlasıyla dayanıyor, ancak bu, örtük iş akışlarına yol açıyor. Kod teknik olarak işlevsel fakat ne yaptığı konusunda netlik sağlayamıyor. Sınıfınız yalnızca genel işlemleri destekliyorsa, gerçek iş akışı gizlidir.

Şu örneği alın: bir sürücü bir paketi alır ve bir Taşıma Konşimentosu üretilir. Sistem sadece UpdateShipment çalıştırıyorsa, değişikliğin (örneğin BOL numarası gibi) bir alımdan mı yoksa bir düzeltmeden mi kaynaklandığını anlamak zordur. Derek, belirsiz güncellemelerin yerini PickupStopLoaded gibi açık işlemlerle değiştirmemiz gerektiğini belirtiyor.

Bu, daha okunabilir bir koda yol açar. Ayrıca, bir istisna ex meydana geldiğinde, istisnanın hangi işlemde meydana geldiğini net bir şekilde belirten stack trace sağladığı için istisna yönetimini de destekler. Açık yöntemler, daha iyi kodlama standartlarını da destekler, çünkü her fonksiyonun tek bir sorumluluğu vardır.

3. Gereksiz Yönlendirme Eklemek

Derek, yönlendirmeye, yani çağrıcınız ve hedef yönteminiz arasına gereksiz katmanlar eklemeye geçer. Bunu veritabanı bağlantılarıyla açıklar. Bir kontrolcü bir hizmeti çağırabilir, bu bir yardımcıyı çağırır, bu da başka bir hizmeti çağırır ve nihayetinde sorguyu Entity Framework aracılığıyla yürütür.

Bu piramit soyutlamaları, sorunları izlemeyi ve performansı artırmayı zorlaştırıyor. Soyutlamalar oluşturmak faydalı olabilir, örneğin IDisposable arayüzlerini daha iyi kaynak yönetimi için sarmalayarak, ancak Derek fazla ileri gitmenin tehlikeleri konusunda uyarıyor. Soyutlamanız API'yi basitleştiriyor mu yoksa yalnızca bir yere uyumluluk sağlayan üçüncü parti bir bağımlılığı mı gizliyor diye kendinize sorun.

Yalnızca katmanlama yapmak için katmanlama yapmak yerine, Derek doğrudan bağlama yönetmek gerektiğini önerir. Aşırı yönlendirme yalnızca kodunuzu dağınık hale getirmekle kalmaz, aynı zamanda olası bellek sızıntılarını artırır ve çöp toplama faydalarını zayıflatır.

4. "Ya Eğer" Oyununu Oynamak

Derek'in belirlediği bir sonraki hata, asla olmayabilecek varsayımsal kullanım durumlarına hazırlanmaktır — buna "Ya Eğer Oyunu" diyor. Birçok C# geliştiricisi, gelecekteki ihtiyaçlara cevap vermek için esnek sınıflar ve fonksiyonlar yazar. Örneğin: "İki dili desteklememiz gerekse ne olacak?" veya "Teknolojileri değiştirmemiz gerekse ne olacak?"

Derek, bu zihniyetin şişmiş çerçevelere ve aşırı genel koda yol açtığını konusunda uyarıyor. Karşılaştığı bir durum olarak, anlaması zor string birleştirme mantığı ve referans türü sarmalayıcılarla ilgileniyor çünkü bunlar yalnızca bir gerçek kullanım durumuna hizmet ediyor.

Bilinmeyenler için hazırlanmaktansa, Derek gerçek gereksinimlere odaklanmayı önerir. Her metod ve değişken, mevcut, gerekçelendirilmiş bir amaca hizmet etmelidir. Kullanılmayan özellikler sadece bakım maliyetini artırır. Derek'in dediği gibi, sadece geliştirme süresi değil — sahiplik maliyetidir. Örneğin, public bool Equals uygulamanız her hayal edilebilir uç durumu kapsıyorsa, fakat gerçekte hiçbiri gerçekleşmiyorsa — değerli zamanınızı boşa harcamışsınız demektir.

5. İş Akışlarını Doğru Yönetmeme

Son olarak, Derek iş akışlarını prosedürel bloklar yerine modüler adımlar olarak ele almanın hatasını tartışıyor. Gerçek dünya örneği kullanıyor: çevrimiçi sipariş verme. Kullanıcı ödeme işlemini tamamladıktan sonra, sistem kredi kartını çeker ve ardından bir onay e-postası gönderir.

Eğer bir adım başarısız olursa — örneğin ödeme işlemi — kodunuz nasıl tepki verir? Siparişi geri alır mısınız? Bir hata mı gösterirsiniz? Bir başarısızlık e-postası gönderir misiniz? Derek, bunu tek bir bloğa yığmanın yönetilemez bir karmaşıklık yarattığını açıklar.

İş akışlarını mesajlaşma yoluyla iletişim kuran küçük, izole edilmiş üniteler olarak tasarlamayı önerir. async Task işlemleri ve yield return kullanarak bu adımların yönetimini kolaylaştırır. Dahası, using ifadesi ve using bloğu yaparak dosya erişimi veya veritabanı bağlantıları gibi harici kaynakları çevreleyerek hafıza sızıntılarını önlemek yardımcı olabilir.

Örneğin, bir akışı çevreleyen bir using bloğu onun doğru atılmasını sağlar — IDisposable arayüzleri ile çalışırken hayati bir noktadır. İş akışları karmaşık hale geldiğinde, bu en iyi uygulamalar, istisnaların etkili bir şekilde yakalanmasını ve yönetilmesini sağlayarak performansı ve sürdürülebilirliği korur.

Sonuç: Temiz, Sürdürülebilir Kod Yazın

Derek, videosunda (12:45) bu hatalarla yalnızca karşılaşmadığını, aynı zamanda büyük iş sistemleri kurarken kişisel olarak da yaptığını belirterek sonuçlandırıyor. Bunlar deneyim yoluyla öğrenilen derslerdir ve izleyicilere kendi hatalarını yorumlarda paylaşmalarını önerir.

Derek'in tavsiyesi yalnızca C# için değil, diğer birçok dil için de geçerlidir. İster string karşılaştırma, ister Equals() yöntemleri ile çalışıyor ya da yeni özellikler tasarlıyor olun, anahtar netlik, niyet ve kodun sürdürülebilirliğini korumaktadır.

C# becerilerinizi geliştirip bu yaygın tuzaklardan kaçınmak istiyorsanız, Derek'in kanalı sistem mimarisi, tasarım desenleri ve gerçek dünya programlama dili tavsiyeleri üzerinde birçok ücretsiz kaynak sunmaktadır. Bu hatalardan sadece birinden kaçınmak bile projenizin kalitesini önemli ölçüde artırabilir.

Bu yüzden bir dahaki sefere kod yazmaya başladığınızda, Derek'in sözlerini hatırlayın ve kendinize sorun: "Bunu gereğinden fazla mı karmaşık hale getiriyorum?"

Bu tür içerikler için Derek Comartin'in CodeOpinion YouTube kanalına göz atın.