Derek Comartin tarafından Açıklanan 5 C# Yaygın Hatayı Yazılımınızı Sürdürülemez Hale Getiren Hatalar

1. Durum Üzerinde Sahiplenme Eksikliği

Derek, sorumluluğu olmayan bir şekilde paylaşılan verileri güncelleyen birden fazla sınır veya servisin hata olduğuna dikkat çeker. Bir örnek olarak, faturalama sisteminin başka bir uygulama parçasına girip durumu değiştirmesini gösterir. Bu, özellikle o nesne sistemde farklı bir yerde bulunuyorsa veri tutarlılığı sorunlarına yol açar.

Bu tür bir özgürlük yaklaşımı, geliştiricilerin "Neden bu veri yanlış?" veya "Kim değiştirdi?" gibi sorular sormasına neden olan hatalar yaratır Derek, sahipliği tanımlamanız gerektiğini vurguluyor. Sistem her bir parçası, durumu yönetmekten sorumlu olan belirlenmiş 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ça komutlar ve sorgular oluşturmayı öneriyor. Örneğin, bir sevkiyatı güncellemek istediğinizde, belirli bir arayüz aracılığıyla bir komut verirsiniz. Bu, yapı sağlar ve izlenemeyen değişikliklerden kaynaklanan kaynak sızıntılarını önler.

2. Örtük Kod ve Açık İş Akışları

Derek'e göre, birçok sistem CRUD işlemlerine (Oluştur, Okuma, Güncelleme, Silme) güçlü bir şekilde bağlı kalır, ancak bu, örtük iş akışlarına yol açar. Kod teknik olarak işlevseldir, ancak ne yaptığı hakkında netlik eksiktir. Sınıfınız yalnızca genel işlemleri destekliyorsa, gerçek iş iş akışı gizlidir.

Aşağıdaki örneği ele alalım: bir şoför bir paketi alır ve bir Yük Fatura Ladingi (BOL) oluşturulur. Sistem yalnızca UpdateShipment çalıştırıyorsa, dizge değişikliğinin (BOL numarası gibi) bir alım mı yoksa bir düzeltme nedeniyle mi olduğu belirsizdir. Derek, belirsiz güncellemeler yerine PickupStopLoaded gibi açık işlemleri koymamızı öneriyor.

Bu, daha okunabilir kod sağlar. Ayrıca exception işleme konusunda yardım eder, çünkü bir exception ex oluştuğunda, yığın izi hangi işlemin başarısız olduğunu açıkça gösterir. Açık yöntemler aynı zamanda daha iyi kod standartlarını destekler, çünkü her işlevin tek bir sorumluluğu vardır.

3. Anlamsız Yönlendirmeler Ekleme

Derek, arayan ile hedef yöntem arasında gereksiz katmanlar eklemek yani yönlendirme ile devam eder. Bunu veritabanı bağlantıları ile açıklar. Bir denetleyici bir hizmeti çağırabilir, bu da bir yardımcıyı, sonra başka bir hizmeti çağırabilir, ve sonuçta sorguyu Entity Framework aracılığıyla yürütür.

Bu soyutlamalar piramidi, sorunları izlemeyi ve performansı iyileştirmeyi zorlaştırır. Soyutlamalar yaratmak, IDisposable arayüzlerini daha iyi kaynak yönetimi için sarmalamak gibi kullanışlı olabilirken, Derek bunu fazla yapmaktan kaçınılması gerektiğini uyarır. Soyutlamanızın API'yi basitleştirip basitleştirmediğini veya sadece tek bir yerde bulunan üçüncü parti bir bağımlılığı gizleyip gizlemediğini sorun.

Katmanlama uğruna katmanlamanın yerine, Derek bağlamayı doğrudan yönetmenizi öneriyor. Aşırı yönlendirme, kodunuzu karıştırmakla kalmaz, aynı zamanda hafıza sızıntısı potansiyelini artırır ve çöp toplamayı zayıflatır.

4. "Ya Öyle Olursa" Oyunu Oynamak

Derek'in belirlediği bir diğer hata, belki de hiç gerçekleşmeyecek varsayımsal kullanım durumlarına hazırlık yapmak — onun "Ya Öyle Olursa Oyunu" olarak adlandırdığı bir durum. Birçok C# geliştiricisi, gelecekteki ihtiyaçlara hazırlık için esnek sınıflar ve işlevler yazar. Örneğin: "Ya iki dili desteklemek zorunda kalırsak?" veya "Ya teknolojileri değiştirmemiz gerekirse?"

Derek, bu zihniyetin şişmiş çerçeveler ve aşırı genel kodlarla sonuçlandığını uyarır. Sadece bir gerçek kullanım durumu için hizmet eden kimsenin anlamadığı dize birleştirme mantığı ve referans tipi sarmalayıcılarla karşılaşmaktan bahseder.

Bilinmeyene hazırlık yapmak yerine, Derek gerçek gereksinimlere odaklanmanızı önerir. Her yöntem ve değişken, geçerli, haklı bir amaca hizmet etmelidir. Kullanılmayan özellikler sadece bakım maliyeti ekler. Derek'in söylediği gibi, sadece geliştirme süresi değil — sahip olma maliyeti. Örneğin, her gördüğünüz durum için uygun public bool Equals uygulamanız varsa, ancak aslında gerçekleşen hiçbir durumda değil, değerli zamanınızı boşa harcamış olursunuz.

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 almamak ile yapılan hataya değinir. Çevrim içi bir sipariş verme gibi gerçek dünya bir örneği kullanır. Kullanıcı kasayı tamamladıktan sonra, sistem kredi kartını şarj eder, ardından bir onay e-postası gönderir.

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? Başarısızlık e-postası mı gönderirsiniz? Derek, bunu tek bir blok içine dahil etmenin yönetilemez bir karmaşıklık yarattığını açıklar.

Mesajlaşma yoluyla iletişim kuran küçük, izole edilmiş birimler olarak iş akışlarını tasarlamayı önerir. Async Task işlemleri ve yield return kullanımı bu adımların yönetilmesini kolaylaştırır. Ayrıca, dosya erişimi veya veritabanı bağlantıları gibi harici kaynaklar etrafında using ifadesi ve using bloğu kullanmak, bellek sızıntılarını önlemeye yardımcı olabilir.

Örneğin, bir akışın etrafında bir using bloğu kullanmak, İDisposable arabirimleriyle çalışırken hayati önem taşıyan doğru bir şekilde yok edilmesini sağlar. İş akışları karmaşıklaştığında, bu en iyi uygulamalar, performansı ve sürdürülebilirliği koruyarak istisnaların etkili bir şekilde yakalanmasını ve yönetilmesini sağlar.

Sonlandırma: Temiz, Sürdürülebilir Kod Yazın

Derek, videosunun 12:45'te yaptığı gibi, bu hataların sadece gördüğü şeyler olmadığını, aynı zamanda büyük işletme sistemleri kurarken kişisel olarak yaptığı hatalar olduğunu düşünüyor. Bunlar deneyimle edinilen derslerdir ve izleyicileri kendi hatalarını yorumlarda paylaşmaya teşvik eder.

Derek'in tavsiyeleri, sadece C# için değil, birçok diğer dil için de geçerlidir. İster string karşılaştırması, Equals() yöntemleri ile çalışıyor olun, ister yeni özellikler tasarlıyor olun, anahtar, açıklık, niyet ve kodunuzu sürdürülebilir kılmaktır.

C# becerilerinizi geliştirmek ve bu yaygın hatalardan kaçınmakla ilgileniyorsanız, Derek'in kanalı sistem mimarisi, tasarım kalıpları ve gerçek dünya programlama dili tavsiyeleri üzerine birçok ücretsiz kaynak sunar. Bu hatalardan sadece birinden kaçınmak bile projenizin kalitesini önemli ölçüde artırabilir.

Kod yazmaya başlarken, Derek'in sözlerini hatırlayın ve sorun: "Bu, gerektiğinden daha mı karmaşık hale getiriyorum?"

Bu tür içerikler için Derek Martin'in CodeOpinion YouTube Kanalına göz atabilirsiniz.