Web Geliştirme Kaçınılması Gereken 10 Kodlayan Antipatterns

Bir web sitesinin ya da uygulamanın mimarisini tasarlamak ya da etkili bir kodlama iş akışı oluşturmak sık sık tekrarlayan problemlerle uğraşmamızı sağlar. Bu yazılım tasarımı sorunlarını sıfırdan çözmemize gerek yok. mimari düzeyde çözümler yeniden kullanılabilir Aynı şekilde mikro düzeyde kod parçacıkları.

Tasarım desenleri genellikle yeniden kullanılabilir çözümler Bazı senaryolar için Yaygın olarak ortaya çıkan sorunları çözmek için kullanışlı olmak, ve kodumuzu optimize etmemize çok yardımcı olabilir.

Tasarım kalıpları, geliştirme sürecimizi iyi test edilmiş formülleri kullanarak iyileştirmek için harika olsa da, bazen yanlış da olabiliriz. Bunlara antipatterns denir..

Antipatterns Nedir??

Dönem “antipattern” 1998 yılında AntiPatterns adlı bir kitapta icat edildi. başlangıçta faydalı görünen yeniden kullanılan çözümler, ama sonra çıkıyor iyiden daha çok zarar vermek.

Bu, örneğin kalıpları doğru bağlamda, düzende ya da zaman içinde kullanmıyorsak (geçmişte etkili olan çözümler her zaman şu an için çalışmayabilir) ya da diğer durumlarda tüm paradigma gibi farklı nedenlerden dolayı olabilir. en başından beri kötüydü.

Antipatterns ayrıca sık sık denir başarısızlık kalıpları. İyi haber şu ki onları tanımak ve önlemek mümkün.

Bu yazıda, web geliştirmemizde iyi kodlanmış kodlarımız olduğunu düşünmemize neden olabilecek 10 ortak kodlama karşıtı antipatüre bir göz atacağız. (Bu gönderide listelenen antipatterns'ın mutlaka yukarıda belirtilen kitapta bulabileceğinizlerle aynı olmadığını unutmayın.)

1. Erken Optimizasyon

İyi zamanlama, kod optimizasyonunda çok önemli bir faktördür. Antipattern'i kolayca çoğaltabiliriz “erken optimizasyon”, küçük verimliliklere dikkat edersek ve gelişim sürecinde çok erken bir zamanda onlar için optimize edersek, ne yapmak istediğimizi tam olarak bilmeden önce.

Donald Knuth'un ünlü alıntılarına göre “erken optimizasyon tüm kötülüklerin kökenidir“, Bu abartı olabilir, ancak yine de erken optimizasyonun daha sonra ne kadar ciddi sorunlara yol açabileceğini gösteriyor.

Etkili bir mimari kurmadan önce performansı optimize edersek, düşük kod okunabilirliği, Yapmak hata ayıklama ve daha zor bakım, ve gereksiz parçalar ekleyin kodumuza.

Erken optimizasyonun önüne geçmek için YAGNI (Buna İhtiyacınız Değil) programlama prensibini takip etmek iyi bir fikirdir. “her zaman gerçekten ihtiyaç duyduğunuzda bir şeyler uygulayın, hiçbir zaman sadece ihtiyacınız olduğunu öngörmediğinizde.”

2. Tekerleği Yeniden Keşfetmek

“tekerleği yeniden icat etmek” Antipattern bazen aynı zamanda denir “vakumda tasarım”. İstediğimiz zaman olur her şeyi kendimiz yap ve sıfırdan her şeyi yaz, zaten var olan yöntemleri, API'leri veya kütüphaneleri aramadan.

Tekerleği yeniden icat etmek, zaman harcayan bir şey değil, aynı zamanda Özel çözümler, özellikle temel işlevler için, nadiren standart olanlar kadar iyidir Zaten birçok geliştirici ve kullanıcı tarafından test edilmiştir..

3. Bağımlılık Cehennemi

Karşısında “tekerleği yeniden icat etmek” antipattern denilen başka bir ortak antipattern “bağımlılık cehennemi”.

Her şeyi sıfırdan yazmak yerine kullanırsak, diğer kütüphanelerin belirli sürümlerine dayanan çok sayıda üçüncü taraf kütüphanesi, Güncellemek istediğimizde zorlukla yönetilebilir bir duruma kolayca ulaşabiliriz, çünkü bu bağlılıklar bir çok durumda birbiriyle uyumsuz.

Bağımlılık cehennemi yapabilen paket yöneticileri kullanılarak çözülebilir birbirine bağlı bağımlılıkları akıllıca güncelleme. Sorun yüzünden çok fazla şaşırırsak, yeniden yapılanma da iyi bir fikir olabilir..

4. Spagetti Kodu

“Spagetti kodu” Muhtemelen en ünlü kodlama karşıtıdır. Açıklar uygun bir mimarinin olmaması nedeniyle hata ayıklanması veya değiştirilmesi zor olan bir uygulama.

Kötü yazılım tasarımının sonucu, yapılı bir spagetti kasesine benzer bir yapı kodudur, yani. karışık ve kıvrımlı. Spagetti kodunun okunabilirliği çok düşüktür ve tam olarak nasıl çalıştığını anlamak neredeyse imkansız bir görevdir.

Spagetti kodu genellikle farklı kötü kodlama uygulamalarının kombinasyonu, uygun koşul blokları içermeyen kodlar, çok fazla sayıda goto ifadesi, istisnalar ve başka bir yere ait parçalar içeren iş parçacığı gibi nesneler arasında en az düzeyde ilişki vardır, yeniden kullanılamayan veya uygun şekilde belgelenmemiş işlevler veya yöntemler vardır veya hiç.

5. Permütasyonla Programlama

“Müdahale ile programlama” veya “kazayla programlama” Küçük modifikasyonlarla başarılı bir şekilde deneyerek, bunları tek tek test ederek ve değerlendirerek ve sonunda ilk başta çalışanı uygulayarak problem için bir çözüm bulmaya çalıştığımızda olur.

Permütasyonla programlama kolayca yapabilir kodumuza yeni hatalar ekleyin, Daha da kötüsü, onlar bir kerede mutlaka tanımadığımız hatalardır. Çoğu durumda, çözümün olası tüm senaryolar için işe yarayıp yaramadığını tahmin etmek de imkansızdır..

6. Programlamayı Kopyala ve Yapıştır

“Kopyala ve yapıştır programlama” Kendinizi Tekrar Etme (DRY) kodlama ilkesini takip etmediğimizde ortaya çıkar ve genel çözümler oluşturmak yerine, zaten mevcut kod parçacıklarını farklı yerlere ekleriz ve daha sonra bunları verilen içeriğe uyacak şekilde düzenleriz.

Bu pratik tekrarlayan bir kodla sonuçlanır, eklenen kod bölümleri genellikle yalnızca küçük tutarsızlıklar bakımından farklılık gösterdiğinden.

Kopyala ve yapıştır programlama sadece acemi geliştiriciler tarafından değil, aynı zamanda deneyimli programcılar tarafından da kabul edilir belirli görevler için önceden yazılmış, iyi test edilmiş kod parçacıklarını kullanın., kolayca yol açabilir istenmeyen tekrarlar.

7. Kargo-Kült Programlama

Adı “kargo-kült programlama” denilen belirli bir etnografik fenomenden geliyor “kargo tarikatı”. İkinci Dünya Savaşı'ndan sonra Güney Pasifik'te kargo kültü ortaya çıktı, ileri medeniyetlerle olan zorla temas yerlilerin, Coca-Cola, TV'ler ve kargo gemilerinin adalara getirdiği buzdolapları gibi üretilen ürünlerin doğaüstü tarafından yaratıldığını düşünmelerini sağladı. yöntem; ve Batılıların geleneklerine benzer büyülü törenler gerçekleştirirlerse, mallarla dolu kargolar tekrar gelir..

Kargo kültü programlamanın antipatternini işlediğimizde, temelde aynısını yaparız. Başkaları için iyi çalışan çerçeveler, kütüphaneler, çözümler, tasarım desenleri vb. Kullanıyoruz., neden böyle yaptığımızı anlamadan, ya da söz konusu teknolojilerin tam olarak nasıl çalıştığını.

Çoğu durumda sadece geliştiriciler o sırada kalça olanı gerçek bir amaç olmadan yapma. Bu uygulama sadece kötü değil çünkü uygulamamızı gereksiz yere şişiriyor, aynı zamanda kodumuza kolayca yeni hatalar getirebiliyor.

8. Lav Akışı

Hakkında konuşuyoruz “lav akışı” antipattern ihtiyacımız olduğunda yedekli veya düşük kaliteli parçalara sahip kodlarla uğraşmak o ayrılmaz görünüyor programa, henüz ne yaptığını veya tüm uygulamayı nasıl etkilediğini tam olarak anlamıyoruz. Bu onu çıkarmak için riskli yapar.

Bu genellikle olur eski kod, veya ne zaman kod başkası tarafından yazılmış (genellikle uygun belgeler olmadan) veya proje geliştirme aşamasından üretim aşamasına çok hızlı geçtiğinde.

Antipattern'in adı volkanlardan gelen lav ile uyumsuzluktan geliyor, yani ilk başta çok fazla önlem almadan hızlı ve akıcı bir şekilde hareket ediyor, ancak daha sonra katılaşıyor ve çıkarılması zorlaşıyor.

Teoride lav akışlarından kurtulabiliriz kapsamlı test ve yeniden düzenleme, ama pratikte, uygulama sık sık zor hatta imkansız. Lav akışları genellikle yüksek performans maliyetlerine sahip olduğundan, iyi tasarlanmış bir mimari ve en baştan itibaren sağlıklı bir iş akışı oluşturarak bunları önlemek daha iyidir..

9. Sabit Kodlama

“Sert kodlama” web geliştirme kitaplarının çoğunun bizi önsöz konusunda uyardığı bilinen bir antipattern. Sabit kodlama, talihsiz bir uygulamadır yapılandırma veya giriş verilerini depolarız, dosya yolu veya uzak ana bilgisayar adı gibi, kaynak kodunda bir yapılandırma dosyasından, bir veritabanından, bir kullanıcı girişinden veya başka bir harici kaynaktan elde etmek yerine.

Kodun asıl sorunu şudur: sadece belirli bir ortamda düzgün çalışır, ve at şartlar ne zaman değişirse, değiştirmemiz gerek kaynak kodu, genellikle birden fazla yerde.

10. Yumuşak Kodlama

Eğer zor kodlamanın çökmesinden kaçınmak için çok çaba sarfedersek, adı verilen başka bir kaymaz kapıya kolayca girebiliriz. “yumuşak kodlama”, tam tersi olan.

Yumuşak kodlamada, kaynak kodunda olması gereken şeyleri dış kaynaklara koyarız, örneğin, iş mantığını veritabanında saklıyoruz. Bunu yapmamızın en yaygın nedeni, iş kurallarının gelecekte değişeceği korkusudur, bu nedenle kodu yeniden yazmamız gerekecek..

Aşırı durumlarda, yumuşak kodlanmış bir program o kadar soyut hale geldik ki, onu kavramak neredeyse imkansız hale geldi (özellikle yeni ekip üyeleri için) ve son derece bakımı ve hata ayıklaması zor.