Dev tutkal yöntemlerinden nasıl kaçınılır?

Şu andaki işimde, eski kodu birkaç kez temizlemekle görevliydim. Genellikle kod bir labirenttir ve arkasındaki veriler daha da karışıktır. Kendimi işleri güzel, temiz, modüler yöntemlerle birleştiriyorum. Her yöntem bir şey yapar ve iyi yapar. O zaman işler güneye gitmeye başlar ...

Her zaman, temiz bir API ile bitirdim ve hepsini bir araya getirmenin gerçek bir yolu yok. Çözüm, sonunda tüm "temiz" yöntemlerimi çağıran çirkin bir "yapıştırıcı" yöntemi (genellikle koşullu ifadelerle dolu) yazmaktı.

Yapıştırma yöntemi genellikle, temizlemeye çalıştığım kod / veri arapsaçılarının kısa versiyonudur. Genelde daha okunur, ancak yine de can sıkıcı.

Bu tür yöntemlerden nasıl kaçınabilirim? Bu karışık verilerin bir belirtisi mi yoksa yanlış yaptığım bir şeyin yansıması mı?

LedgerSMB’i yeniden düzenleyerek deneyimimizi size sunacağım. İşleri daha erken farklı bir şekilde yapmaya karar verdik ve hala tam olarak tanımladığınız şeyi yapıyoruz, ancak çok fazla tutkal yöntemi olmadan (çok az değil, çok az sayıda tutkal yöntemimiz var).

İki Kod Yazılı Yaşam

LedgerSMB yaklaşık 5 yıl boyunca iki kod tabanıyla hayatta kaldı ve eski kod temeli ortadan kaldırılmadan önce birkaç kez daha olacak. Eski kod temeli, dikkat edilmesi gereken gerçek bir korku. Kötü db tasarımı, Perl IS->some_func(\%$some_object);, spagetti metaforunun bazen neden kullanıldığını tam olarak gösteren kodla birlikte inşa eder (modüller ile arka ve diller arasında kafiyeli veya sebepsiz anlam ifade eden uygulama yolları). Yeni kod temeli, db sorgularını saklı yordamlara taşıyarak, istek işleme için daha temiz bir çerçeveye ve daha pek çok şeye sahip olmaktan kaçınır.

Yapmaya karar verdiğimiz ilk şey, modül modülünü yeniden yansıtmaya çalışmaktı. Bu, belirli bir alandaki tüm işlevleri yeni bir modüle taşımak ve ardından eski kodu yeni modüle bağlamak anlamına gelir. Yeni API temizse, bu önemli bir şey değil. Yeni API işler kıllı olmazsa ve bu yeni API’de biraz daha çalışmak için bir davetiye.

İkincisi, yeni kodun eski kodda mantığa erişmesi gerektiğinde birçok kez bulunmasıdır. Bundan mümkün olduğunca kaçınılmalıdır, çünkü çirkin tutkallama yöntemlerine yol açmaktadır, ancak bunlardan biri her zaman kaçınamaz. Bu durumda, yapıştırma yöntemleri mümkün olan en aza indirilmeli ve kaçınılmalı, ancak gerektiğinde kullanılmalıdır.

Bu işlemi yapmak için , belirli bir alandaki tüm işlevleri yeniden yazmayı taahhüt etmeniz gerekir . Örneğin, tüm müşteri bilgileri izleme kodunu bir kerede yeniden yazabiliyorsanız, bu işlemi eski koddan çağıran kodun çalışması zor değildir ve eski kodun yeni koddan gönderilmesi en aza indirilir.

İkincisi, yerinizde makul soyutlamalar varsa, hangi API seviyesini arayacağınızı ve bunu nasıl temiz tutacağınızı seçebilmeniz gerektiğidir. Ancak, API'nizi çağıran bölümleri de biraz daha temiz olacak şekilde yeniden yazmayı düşünmelisiniz.

İndirgenemez derecede karmaşık olan birçok iş aracı alanı vardır. Tüm karmaşıklıklardan kurtulamazsınız. Ancak, özellikle yapmanız gerekenleri yapan temiz API'lere ve bu API'yi yapıcı olarak kullanan modüllere odaklanarak yönetebilirsiniz. Tutkal ancak çağıran kodun geri kalanının daha hızlı olabileceğini düşündükten sonra son çare olmalıdır.

Yaptığınız şey, bir emsal öncesi kod temeli karışık bir karmaşa alınmış ve hoş bir modüler emsal öncesi kod tabanı oluşturmuş gibi geliyor.

Her zaman, temiz bir API ile bitirdim ve hepsini bir araya getirmenin gerçek bir yolu yok. Çözüm, sonunda tüm "temiz" yöntemlerimi çağıran çirkin bir "yapıştırıcı" yöntemi (genellikle koşullu ifadelerle dolu) yazmaktı.

Prosedürel kodla (OO olarak gizlenmiş olsa bile), her zaman bir yerde tanımlanmış, genellikle tanımladığınız karmaşık koşullu dallarla dolu bir tür ardışık iş akışına sahip olacaksınız. Bir şeyin yanlış olduğunu düşündüren kodun bu usule uygun olmasından şüpheleniyorum. Bu mutlaka kötü bir şey değildir ve eski kodla çalışırken tamamen kaçınılmaz olabilir

Büyük çirkin tutkal yöntemini, orijinal kod tabanını temizlediğiniz gibi temizlemelisiniz. Düzgün modüler yöntemlerle bölün. Muhtemelen bazı görevler yapan bu kod satırları grubunuz bu satırları yöntemlere böler, bazı değişkenleri paylaşırsanız paylaşılan değişkenleri ve yeni yöntemleri bir sınıfa koymayı düşünebilirsiniz.

Temel olarak, soyutlama katmanları eklemeye devam edersiniz , kendi başına alınan her katmana bakana kadar . Soyutlama ile ilgili paradoksal olan şey, onu azaltmak için karmaşıklık eklemenizdir, çünkü soyutlanmış kodu okuduğunuzda, yalnızca bir seferde yalnızca bir katmanla ilgilenirsiniz. Her katman kolayca anlaşılabilecek kadar küçükse, kaç katman üzerinde durduğu önemli değildir.

Aynı zamanda soyutlamaları yazmayı zorlaştıran da budur. Bir kalem kadar basit bir şey bile kafanızdaki tüm soyutlama katmanlarını bir kerede tutmaya çalışırsanız zihin bükme olabilir. Anahtar, bir katmanı istediğiniz gibi elde etmektir, yaptığınız gibi, o katmanın altında yatan tüm karmaşıklığı unutun ve aynı şeyi bir sonraki seviyede yapın.

Sadece API'nin uygulanmasını düşünerek, ancak API'yi kullanan kod hakkında yeterince düşünmeden - yani konuştuğunuz "yapıştırıcı kodu" gibi API'yi yeniden yapılandırıyormuşsunuz gibi geliyor.

Bu doğruysa, diğer taraftan başlamaya çalışabilirsiniz. Önce çirkin yapıştırıcı kodunuz olma tehdidinde olanları yeniden yazın ve bu işlemde API'niz olacak olan henüz uygulanmayan bir çift arayüz oluşturun. Bu API'nin gerçek uygulaması hakkında henüz fazla düşünmeyin - bunu yapabileceğinize dair bir içgüdüye sahipseniz sorun değil. Ve ancak o zaman bu API'ye uyması için kod labirentini yeniden yazın. Tabii ki bu süreçte API ve yapıştırıcı kodunda bazı değişiklikler olacak, ancak daha iyi bir şekilde uyması gerekir.