Yaklaşık 8 yıldır uzun ömürlü bir ürünümüz var. Zamanla, kavramların ve varlıkların adları değişir. Tüm kod tabanını ve veritabanı tablolarını ve sütunlarını bu yeni adlarla eşleşecek şekilde yeniden adlandırmak için işe koyulmalı mıyız?
Bu ya da yayınlanan en iyi uygulamalarla ilgili yapılmış bir çalışma var mı?
Teşekkürler
Yanıtlar:
İç ve dış isimler arasındaki uyumsuzluk kesinlikle kokuyor. Rinzwind'in belirttiği gibi, sesteş sözcükler ve eşanlamlılar en kötü kokuyor.
Cevaplamanız gereken asıl soru şudur: Değişikliği yapmanın maliyet / fayda dengesi nedir?
Değişmeme maliyeti, yeni ekip üyeleri için daha dik bir öğrenme eğrisidir ve gelecekteki hataların artma olasılığıdır. Değişimin maliyeti bariz bir zaman, projedeki eski zamanlayıcılar için yeni bir öğrenme eğrisi ve yeni hataların olasılığıdır.
Nispeten çok sayıda yeni ekip üyesine sahip olmayı bekliyorsanız, değişikliği yapmanız daha olasıdır. Herhangi bir ciro beklemiyorsanız, mevcut takım karışmaya eğilimli değildir ve takım statükodan memnun kalır, o zaman şeyleri yeniden adlandırmak gerçekten mantıklı değildir.
Kodun uzun süre yaşaması bekleniyorsa ve üzerinde çalışan yeni geliştiriciler olacaksa, değişiklikleri yapardım.
Yeni bir geliştiricinin bir projeye girmesi ve varlıkların adlarını yanıltıcı bulması çok kafa karıştırıcı ve zaman alıcı olabilir.
Geçerli bir argüman da var ... Eğer kırılmazsa, tamir etmeyin.
İkinci sorunuzla ilgili olarak, yayınlanan herhangi bir çalışmanın veya en iyi uygulamaların farkında değilim. İlk soru ile ilgili olarak, 'iç' ve 'dış' adların bazen farklı olduğu benzer uzun ömürlü bir ürünle kişisel deneyimlerden bazı gözlemler sunabilirim.
Gerçekten düzeltmek istediğim isimler, bir ismin hem dahili hem de harici olarak farklı şeyler için kullanıldığı “sesteş sözcükler” . Bu, özellikle de iki şey tamamen farklı değilse (bağlamın belirsizleşmesine yardımcı olacaksa) gerçekten kafa karıştırıcı olabilir. Kişisel deneyimlerime göre bunun (soyutlanmış) bir örneği, dahili olarak Foo, birden fazla koleksiyon olan bir şeye benzer bir şeyin olduğu yerdir FooEntity; harici olarak, sadece ikincisi görünür ve buna "Foo" denir. Müşteri el kitabının birden fazla “Foo” dan bahsederken bunun aslında sizin için bir anlam ifade etmesi durumunda aslında birden fazla FooEntity(tek olarak Foo) anlamına geldiğini anlamak için biraz zaman aldı.
İkinci olarak, bazı harici adların dahili olarak kullanıldığı “eş anlamlıları” düzeltmek istiyorum. Değişken adlarında olduğu gibi, yöntem / işlev adlarının parçaları vb. Bu, genellikle geliştiriciler doğrudan bir müşteri gereksinimleri açıklamasından bir şey uyguladığında ve adları “çevirmeyi” unuttuğunda olur. Bu gerçekleştiğinde, 'yanlış' ad da yayılma eğilimindedir, çünkü diğer geliştiriciler, örneğin yeni kod için şablon olarak kullanmak üzere bu kodun bir kısmını kopyalar / yapıştırırlar. Bu eşanlamlılar çok kafa karıştırıcı değildir, ancak rahatsız edici olabilirler, çünkü kodu herhangi bir referans için Bararıyorsanız, bazı bölümlerin buna atıfta bulunabileceğini aklınızda bulundurmanız gerekebilir.Qux, bu yüzden iki kez arama yapmanız gerekir. (Bu, dinamik olarak yazılan dillerde statik olanlardan daha kötü olabilir, çünkü değişkenlerin / işlevlerin adının türlerini türlerinin adından ziyade aramak zorunda olduğunuzdan.) ", Dahili bir ad harici olarak kullanıldığında: bu, müşteri destek çalışanları vb. Genellikle iç adlardan daha az haberdar olduğu için sık sık gerçekleşmeme eğilimindedir, ancak gerçekleştiğinde müşteriler için kafa karıştırıcı olduğunu varsayıyorum.
En azından yukarıdaki iki durumu önleyebilir veya düzeltebilirseniz, tüm dahili adları harici olanlarla aynı hale getirmek için gidip gitmemeniz gerektiğinden emin değilim. Dış ad ilk etapta iç addan farklı hale getirildiğinde, iç adların da değiştirilmemesinin iyi bir nedeni olabilir. Kişisel deneyimime göre, bunun iyi bir nedeni ürünün eski sürümlerini destekleme gereğidir; çok sayıda kodun değiştirilmesi gerekiyorsa, ad düzeltmeden önceki sürümden en son sürüme bir hata düzeltmesini birleştirmek zor olabilir.
Bu oldukça yaygın bir problem. Üzerinde çalıştığım birkaç proje, ürün adları yerine kod adları kullanıyor (bu noktada kararlaştırılmamış olabilir) ve kodda kullanıcıya gösterilenden çok farklı terminoloji kullanmaktadır. Kodun büyük bir şekilde yeniden tasarlanmasından veya belirli bir sorun yaratma sorunu yoksa, işleri olduğu gibi bırakırım. Elma arabasını kızdırmanın faydası yok. Ayrıca, kim bundan 5 yıl sonra daha fazla değişiklik olmayacağını söyleyecek? Sonra yeniden adlandırma işleminden geçmelisiniz. Unutmayın, bu, sahip olabileceğiniz herhangi bir ayrı kod dokümantasyonunu da (yayınlanmış API'ler) etkiler, bu da basılıysa (basılı kopya) özellikle pahalı bir sorun olabilir.
Genellikle "pazarlama" varlıklarının iç varlıklarla tam olarak örtüşmediğini görüyorum. Bu gibi durumlarda, bir varlığı farklı bir soyutlama düzeyinde tanıtmak daha mantıklıdır, bu da terminoloji farklılıklarını tartışmalı bir nokta haline getirir.
Örneğin, bir hiyerarşiyi temsil eden bir modelimiz var. Hiyerarşideki her seviye, hiyerarşinin gerçek dünya ilişkilerini modellemek için nasıl kullanıldığına bağlı olarak onunla ilişkili bir terime sahiptir, ancak dahili olarak hiyerarşinin bir seviyesinden diğerine davranışta bir fark yoktur. Terminoloji aslında hiyerarşideki bu seviye için bir isimdir, bu yüzden ağaçtaki belirli bir düğüm için isim basitçe düğümün ne olduğunu tanımlar; belirli bir davranış öngörmez.
Ayrıca, ağaç çok köklüdür, bu nedenle ebeveynsiz birkaç düğüm vardır. Kavramsal olarak bir kök var olmasına rağmen (esas olarak evreni temsil eder) ve modele dahil edilmesi birçok işlemi çok daha basit hale getirse de, bunun için bir "pazarlama terimi" yoktur.
Tabii ki, sistemimizdeki farklı bileşenler farklı terminoloji kullanır. Farklı zamanlarda farklı ekipler tarafından geliştirildiler ve hepsi üzerinde kontrolümüz yok. Aslında, bir noktada, birisi bir bileşene bir seviye ekler veya kaldırır ve böylece diğer seviyeler birbirine göre değişir. Aynı üç seviye bir bileşende A, B ve C ile temsil edilirken, bir başka bileşende B, C ve D ile temsil edilir.
Soyutlamada bir adım atmak ve her şeyi bir "düğüm" veya eşit derecede genel bir şey olarak modellemek, bu tür modellerin akıl yürütmesini çok daha kolay hale getirir. Her düğüm kendi "pazarlama teriminin" ne olduğunu bilir ve belirli bir pazarlama terimini temsil eden tür, o terimin her bağlamda ne anlama geldiğini bilebilir.