Son kullanıcılar terminolojileri değiştiğinde kodu ve verileri ne kadar yeniden adlandırmalıyız?

Uzun zaman önce, kullanıcılarımızın bir iş akışı kuyruğuna eklendikten sonra bir resmi "Kabul Et" seçeneğine sahip olduk. Anlaşılıyor, yanlış terimi kullandık ve kullanıcılar görüntüyü gerçekten "Onayladı".

Arayüzümüzde bulunan Onayı Kabul Et seçeneğinin değiştirilmesi kolaydır, sadece bir kelimeyi değiştirin. Ancak CSS sınıfından veritabanı değerlerine kadar tüm katmanları "accept" kelimesi ile programladık.

• Düğmeyi yeşile çeviren CSS sınıfı: ".accepted";
• DOM düğümündeki sınıf niteliğini doğrulayan ve bağlayan model yöntemi: "isAccepted";
• JavaScript durum özelliği: "Gözden geçirilmemiş", "kabul edildi" ve "yayınlanmış" dizileri;
• Mysql durum sütunu: ENUM "gözden geçirilmemiş", "kabul edildi" ve "yayınlandı";
• Test isimleri;

Onaylamayı kabul etmenin çoğunun yerini alması önemsizdir (özellikle testler varken). Verilerin taşınması biraz daha zor, çünkü özellikle dağıtımla senkronize edilmesi gerekiyor.

Bu özel durum basittir, ancak kariyerim boyunca benzer, ancak daha karmaşık vakalarla karşılaştım. Bir dosya da yeniden adlandırıldığında ve düzinelerce sunucuda dağıtım olduğunda veya proxy önbelleğe alma, memcached ve mysql dahil olduğunda.

Arabirim dışındaki diğer tüm katmanlara "kabul edilmek" bırakılması kötü bir fikirdir, çünkü ekibe katılan yeni programcılar bu karara neden olan tarihsel nedenleri öğrenemeyebilirler ve kabul ederken -> onaylarken, anlam bakımından yakın kelimelerdir. "yönetici gelecek durum toplantısı için kuyruğa alındı" olarak yeniden adlandırıldı, kesinlikle bir anlam ifade etmiyordu. Ve burada ve orada uzlaşırsak, birkaç yinelemede, kullanıcı arayüzü konseptlerinin sistemin iç kısımlarına hiçbir etkisi olmayacağını hissediyor ve kesinlikle çıktının yarısının içindekiler ile bağlantısı olmayan bir sistem üzerinde çalışmak istemiyorum.

Peki, gerektiğinde her zaman her şeyi yeniden adlandırıyor musunuz? Bu senin başına geldiyse ve takasın değmeyeceğine karar verdin, seni ısırmaya geri mi geldi? Bu sorunu önlemek için kod yorumu veya geliştirici belgeleri yeterli mi?

Benim için, söz konusu maddeyle ilgili her şeyi değiştirmek kesinlikle en iyisidir.

Bu bir kod yıkımı biçimidir ve değişmeyen 1 öğe büyük bir sorun olmasa da, kod tabanının tonunu belirler.

Ayrıca gelecekte kafa karışıklığına yol açabilir ve yeni devlerin kod tabanını / etki alanını anlamalarını zorlaştırabilir.

Soru içeriği ve etiketlerinden, her yerde bir dil kullandığınızı varsayacağım.

Tecrübelerime göre UL harika ama sizin de belirttiğiniz gibi, dil geliştikçe ek bakım görevlerine yol açabilir. Bu, kendi başına, kötü bir şey değil. Elbette, uygun değil, ama aynı zamanda bekleniyor.

Genelde yaptığım (ve yaptığımı gördüklerim):

• 1-shot upfront refactoring: Güncellenmiş dili kabul etmek için uygulamanın tüm katmanlarını yeniden yansıtın; veya
• teknik borçları günlüğe kaydetme: Kullanıcıya yönelik kodu hemen değiştirebilir ve daha sonra uygulama katmanlarının geri kalanını güncellenmiş dile uygun hale getirmek için teknik borç görevlerini günlüğe kaydedebilirsiniz. Bu genellikle bir avuç sıkıcı (ancak yönetilebilir) görevle sonuçlanır. (5 pm için mükemmel!)

Bence buradaki en önemli şey, tarif ettiğiniz şeyin teknik borç olduğu ve bu şekilde tanınması gerektiğidir.

Görünür bir işlevsellik eklemeyen bu önemsiz görevlerle zaman kaybetmememiz gerektiğini savunan yöneticilerim oldu. Bu, borç analojisinin gerçekten işe yaradığı zamandır. Bu aşağı kaynar:

Ekip, Ubiquitous Language ile DDD yapmayı seçti. Kodu tutarsız bir durumda bırakarak bu yaklaşımdan yola çıkarak karışıklık eklenir ve DDD ve UL'in sağladığı birçok fayda giderilir. Yönetici açısından projeye maliyet katıyor. Kodun yönetilmesi daha zor (pahalı) ve yeni geliştiriciler için daha kafa karıştırıcı (pahalı) hale geliyor.

Yerelleştirme (l10n) seçeneklerine bakmak isteyebilirsiniz. İngilizceden İspanyolcaya geçmek kadar sert görünmese de, aynı konsept için farklı bir terimle başa çıkıyorsunuz. Bu yaygın olarak görülürse, l10n kullanmak, kullanıcı arayüzünde görüntülenenleri hızla değiştirmenize izin verirken, kodda kullanılan terimi değiştirmek zorunda kalmazsınız.

Bununla birlikte, kodunuzdaki terimleri en çok anlaşılan terimler kullanın. Geliştiricilerin bildiği ve bekleyebileceği gibi etki alanından adları seçin.

Bunu uygun şekilde gösterdiğiniz gibi, kaynağın her bölümündeki son kullanıcı isimlendirme değişikliklerini takip etmek oldukça bir yatırımdır. Bununla birlikte, özellikle komple bir altyapı tarafından geliştirilen uzun ömürlü bir ürün için (telefon hattı, test cihazları, vb.) Kesinlikle buna değer.

Kaynaktaki son kullanıcı isimlendirmesini takip etmek bir yatırımdır çünkü göründüğü yerde çok fazla bileşen tipi vardır ve tüm bu bileşenler üzerinde aynı anda çalışan sihirli bir değnek yoktur. Belki de bu bileşenden sonra böyle bir sihirli değnek geliştirmek, projenin ömrü boyunca seyreltebileceğiniz ilginç bir yatırımdır.

Son kullanıcı isimlendirme ve iç isimlendirme arasındaki sürüklenmenin özellikle büyüdüğü 30 yıllık bir kod tabanında çalıştım. İşte herkesin çalışmasının yüküne ek olarak, bu durumun dezavantajları:

1. Yeterli bir politikanın yokluğunda, yeni gelişme mevcut son kullanıcı terminolojisini kullanma eğilimindedir. Dolayısıyla, aynı kavram farklı bileşenlerde iki veya daha fazla ada sahip olabilir. Bileşenler birlikte etkileşimde bulunduğundan, bu, kodun bazı yerel bölümlerinde aynı anda varolan birkaç eş anlamlı isimle sonuçlanır.

2. Yardım hattı / yardım masası arandığında, son kullanıcı isimlendirme kullanarak bir kullanıcı hikayesi yazılır. Sorunu çözmekten sorumlu olan geliştirici, kaynak terminolojiyle eşleşmesi için son kullanıcı terminolojisini çevirmelidir. Elbette arşivlenmedi ve elbette bir karmaşa. (Bkz. 1.)

3. Programcı kodda hata ayıkladığında kesme noktalarını ilgili işlevlerde ayarlamak ister. Son kullanıcı isimlendirmesi ve kaynak isimlendirmesi aynı fikirde değilse uygun işlevleri bulmak zordur. İlgili işlevlerin bir listesinin bile tamamlandığından emin olmak bile zor veya imkansız olabilir. (Bkz. 1.)

4. Yeterli bir politikanın bulunmaması durumunda, zaman zaman eski bir isimlendirme kullanarak kaynağın korunması zaman zaman bu eski isimlendirmeyi tekrar kullanıcıların önüne koyacaktır. Bu kötü izlenim üretir ve ek yüke neden olur.

Zaten iki gün boyunca bazı verilerin veritabanından okunduğu ve bu kod tabanının bir bileşenine enjekte edildiği yeri izledim. Çünkü ben çalıştığım veya çalıştığım hiç kimse bu yere yönlendiren bir isim bulabildi mi, sonunda görevden aldım ve bu soruna başka bir çözüm bulmaya karar verdim.

Hiçbir şey vermeden iki günlük bakım maliyeti [1] 'den fazlaya mal olurken (bilgi yok, düzeltme yok, hiçbir şey) muhtemelen elinden geldiğince kötü, kullanıcı adlandırma ve kaynak adlandırma arasındaki tutarsızlıklar, bakımın sürdürülmesinde birçok rutin göreve genel destek sağlıyor bir yazılım.

Genel gider maliyetinin, yazılımı üreten şirketle birlikte arttığını, büyük bir organizasyonda, birkaç meslektaşınız tarafından düşünülmeden önce bir sorun raporunun masanıza gelmeyeceğini ve düzeltmenin teste tabi olabileceğini belirtmek önemlidir.

[1] Birden fazla geliştiricinin dahil olması nedeniyle.

Bazı paketler müşteriler arasında paylaşıldığından kod ve verileri her zaman yeniden adlandırmam. Temel olarak aynı şeyi kullanıyorlar, ancak farklı diyorlar. Örnek olarak, bir CMS'de bir müşteri müşterisine "Müşteri" diyor ve bir diğeri "Müşteri" kullanıyor. Böylece, Müşteriyi bir müşterinin yüzeyinde Müşteri ile değiştirdik, ancak CMS her zaman bir Müşteri Yönetim Sistemi olacaktır.

Bir başka örnek, izinler - erişim kontrol listesi, yönetici - yönetici, vs. ayrıca diğer geliştiriciler tarafından gerçekleştirilmesi de kolaydır (örneğin, yapılandırılabilir etiketler oluşturarak).

Bu değişikliği yaparsanız, aynı parça başka bir müşteri tarafından kullanılıyorsa, temel olarak bir ürüne dönüştürüldüğünde tekrar yapmanız gerekmeyeceğini düşünmenize yardımcı olabilir.