Harici verileri programladığınız dile çevirme

Aşağıdakilerle ne yapacağımdan emin değilim:

Kendi aracımızdaki verileri harici bir araçtan alıyoruz. Bu veri Hollandaca yazılmıştır. Java kodumuzu İngilizce olarak yazıyoruz. Bu Hollandalıyı İngilizceye mi çevirmeliyiz yoksa Hollandalı olarak mı tutacağız? Örneğin, 2 departmanımız var: Bouw (İngilizce olarak inşaat) ve Onderhoud (İngilizce olarak bakım).

Daha sonra oluşturmak için mantıklı olurdu:

public enum Department { BOUW, ONDERHOUD }

veya:

public enum Department { CONSTRUCTION, MAINTENANCE }

ya da:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling Hollandaca Bölümdür)

Bu senaryoda, enum değerlerini Hollandaca olarak bırakırdım :

public enum Department { BOUW, ONDERHOUD }

Çünkü bu sabitleri kullanan mantık , aynı zamanda Hollandaca olan verilere göre olacaktır . Örneğin, giriş "bouw" ise, karşılaştırma kodu şöyle görünebilir:

if (Department.BOUW == input.toUpper())

Değerler eşleştiğinde hata ayıklamayı daha kolay buluyorum (değerlerin ne anlama geldiğini bilmesem bile). Çeviri sadece zihinsel bir çember ekler, ben bir geliştirici olarak, doğruluğunu kanıtlamak için atlamak zorunda kalmamalıyım.

Yine de, başkalarının verinin içeriğini anlamalarına yardımcı olması durumunda, kodu yorumlayabilirsiniz:

public enum Department { 
    BOUW, /* build */
    ONDERHOUD /* maintenance */
}

İngilizce, bir sebeple lingua franca / en düşük ortak paydadır. Sebep kavramsal olarak "Herkes yapar" kadar zayıf olsa bile, bu hala oldukça önemli bir sebep.

Yaygın uygulamaya karşı çıkmak, yazılımdaki veri yapılarını anlamak için Hollandaca'yı anlamanız gerektiği anlamına gelir. Hollandaca'da yanlış olan bir şey yok, ancak kod temeli ile etkileşime girmesi gereken herhangi bir mühendisin İngilizce konuşması ihtimalinden daha düşük.

Bu nedenle, sürece bir Hollandalı salt alışveriş konum ve uluslararası genişlemeyi düşünmüyorsanız hiç , bu kod temeli tek dilli tutmak ve en popüler kodlama dilini kullanmak iyi bir fikirdir hemen her zaman var.

Not: Bu tavsiye yalnızca program kodu için geçerlidir . Kullanıcı verileri kesinlikle çevrilmemeli, "olduğu gibi" işlenmelidir. "Goldstein" müşteriniz olsa bile, ismini "golden stone" olarak kaydetmemelisiniz.

Sorun şu ki, "kullanıcı tarafından sağlanan, dokunma" ile "kod parçası, her zaman İngilizce'yi kullanma" arasında sürekli bir terim olması. Müşteri isimleri, spektrumun sonlarına yakın, Java değişkenleri ise sonlarına yakın. enumDeğerler için sabitler , özellikle iyi bilinen benzersiz dış varlıkları (bölümleriniz gibi) belirtirlerse biraz daha uzağa gider. Kuruluşunuzdaki herkes bölümler için Hollandaca terimleri kullanıyorsa, kimseyle karşılaşmayan kod üssü ile yüzleşmeyi planlamıyorsunuz ve mevcut bölümler kümesi nadiren değişiyorsa, o zaman bölümün kabul edilen adlarını kullanmak daha fazlasını yapabilir. Yerel değişkenlerden ziyade enum sabitlerini anlama. Yine de hala yapmazdım.

Mümkün olan her yerde çeviri yapmaktan kaçının, çünkü her çeviri ek bir çabadır ve hataları ortaya çıkarabilir.

"Domain Driven Design" ın modern yazılım mühendisliğine kilit katkısı, projenin tüm paydaşları tarafından kullanılan tek bir dil olan Ubiquitous Dil kavramıdır . DDD'ye göre, çeviri bir ekip içinde yapılmamalı (sadece bir şartname belgesinin vekili tarafından sunulsa bile etki alanı uzmanlarını da içermelidir), ancak yalnızca ekipler arasında (daha fazla okuma: Eric Evans tarafından "Domain Driven Design", özellikle de bölümler arasında yapılmalıdır) Ubiquitous Dil ve stratejik tasarım hakkında).

Diğer bir deyişle, işletme uzmanlarınız (veya şartname belgeniz) Hollandaca konuşabiliyorsa, işletme kaygılarını kaynak kodunda ifade ederken (Hollandaca) terminolojilerini kullanın. Gereksiz yere İngilizceye çevirmeyin, çünkü bunu yapmak iş uzmanları ile programcılar arasında iletişim için yapay bir engel oluşturur; bu da zaman alır ve (belirsiz veya kötü çeviri yoluyla) hatalara neden olabilir.

Buna karşılık, işletme uzmanlarınız işlerini hem İngilizce hem de Hollandaca konuşabiliyorlarsa, projenin her zamanki dilini seçebilmeniz için şanslı bir durumdasınız ve İngilizce'yi tercih etmek için geçerli nedenler varsa (örneğin "uluslararası olarak anlaşılabilir ve "standartlar tarafından kullanılması daha muhtemeldir"), ancak bunu yapmak, kodlayıcıların iş adamlarının neden bahsettiğini tercüme etmesi gerektiği anlamına gelmez. Bunun yerine iş adamları dil değiştirmeli.

Her yerde bir dile sahip olmak, gereksinimler karmaşıksa ve tam olarak uygulanması gerekiyorsa özellikle önemlidir, eğer sadece CRUD kullanıyorsanız, içsel olarak kullandığınız dil daha az önemlidir.

Kişisel anekdot: Bazı iş hizmetlerini SOAP bitiş noktası olarak gösterdiğimiz bir projedeydim. İş tamamen Almancaydı ve ingilizcede olduğu gibi yeniden kullanılması pek mümkün değildi, çünkü belirli bir yargı alanına özgü yasal meselelerle ilgiliydi. Bununla birlikte, bazı fildişi kule mimarları, SOAP arayüzünün gelecekte yeniden kullanımı teşvik etmek için İngilizce olmasını zorunlu kılmıştır. Bu çeviri geçici olarak gerçekleşti ve geliştiriciler arasında çok az koordinasyon vardı, yine de yalnızca ortak bir sözlük vardı; aynı işletme teriminde web servis sözleşmesinde birkaç isim vardı ve bazı ticari terimler web servis sözleşmesinde aynı isimdeydi. Oh, ve elbette bölünmenin iki tarafında da kullanılan bazı isimler - fakat farklı anlamlara sahip!

Yine de çevirmeyi seçerseniz, lütfen çeviriyi bir sözlükte standardize edin, yaptığınız tanımınıza o sözlüğe uygunluğunu ekleyin ve incelemelerinizde kontrol edin. Bizim kadar dikkatsiz olmayın.

Doğru çözüm, bölümleri hiç zorlamamaktır:

ArrayList<String> departments = (... load them from a configuration file ...)

Ya da kesinlikle bir bölüme ihtiyacınız varsa:

class Department { String name; Department(String name) { this.name = name; } ... }
HashMap<String, Department> = (... generate from configuration file ...)

Kodunuzdaki belirli bölümlere karşı test etme ihtiyacı bulursanız, o bölüm hakkında neyin özel olduğunu daha genel olarak sormanız ve o bölümü o özelliğe sahip olarak yapılandırmayı kabul etmeniz gerekir. Örneğin, eğer bir departman haftalık bordroya sahipse ve kodun önemi bu ise, konfigürasyon ile herhangi bir departmana eklenebilecek bir WEEKLY_PAYROLL özelliği olmalıdır.

Merak eden her insan için: ilk seçeneği tercih ettik, çünkü çeviri için şartlar oluşturmamanız gerektiğini düşünüyoruz. Bununla birlikte, bazen bir uluslararası geliştirici proje üzerinde çalışıyorsa, bunu açıklamak için bazı belgeler ekledik:

/** The possible departments of a project, given in the Dutch language. */
public enum Department { BOUW, ONDERHOUD }

Kullanıcıyı veya başka bir şeyi göstermek için bir dize temsili olması konusunda endişeleniyorsanız, enum içinde bir açıklama dizisi tanımlayın ve bir yöntemi gösterin.
Örn: Department.BUILD.getDescription();"BOUW" çıktısını alacak

public enum Department { 
    BUILD,
    MAINTENANCE;

    private String[] descriptions = new String[] {
        "BOUW",
        "ONDERHOUD"
    };

    public String getDescription() {
        return descriptions[ordinal()];
    }
}

Aksini seçtiğini biliyorum, ama sadece google vorteks buradaki insanları kazara atarsa ​​diye.

EDIT: Pokechu22 tarafından belirtildiği gibi enum yapıcılarını ve bunun gibi özel özellikleri kullanabilirsiniz:

public enum Department {
    BUILD("BOUW"),
    MAINTENANCE("ONDERHOUD");

    private final String description;

    private Department(String description) {
        this.description = description;
    }

    public String getDescription() {
        return description;
    }
}

hangi da bu etkiyi elde edecek.

Kodunuzun bazı değişmezlerinin beklemesi bekleniyor. Bu değişmezlerden biri, bir tanımlayıcı yeniden adlandırıldığında bir programın farklı davranmamasıdır. Bu durumda özellikle, bir numaraya sahip olduğunuzda ve bu numaradan herhangi bir üyeyi yeniden adlandırdığınızda ve o üyenin tüm kullanımlarını güncellediğinizde, kodunuzun farklı şekilde çalışmaya başlamasını beklemeyeceksiniz.

Ayrıştırma, verileri okuma ve ondan veri yapılarını alma işlemidir. Dış verileri aldığınızda, okuyun ve numaralandırmanızın örneklerini oluştururken, verileri ayrıştırıyorsunuz. Bu ayrıştırma işlemi, programınızın, onu nasıl edindiğiniz ile veri temsili ile veri tiplerinizdeki üyelerin şekli ve isimleri arasındaki ilişkiyi sürdürmekten sorumlu olan tek kısmıdır.

Bu nedenle, enum üyelerine hangi isimleri verdiğiniz önemli olmamalıdır. Okuduğunuz verilerde kullanılan karakter dizileriyle çakışması, tesadüfidir.

Etki alanını modellemek için kodunuzu tasarlarken, üyelerin adları verilerin seri hale getirme biçimiyle ilişkilendirilmemelidir. Ne Hollandaca terimler olmalı ne de Hollandaca terimlerin çevirileri olmalı, ancak etki alanı modeline en uygun olana karar vermelisiniz.

Veri biçimi ve etki alanı modeliniz arasında çeviriden daha ayrıştırıcı. Bu, veri formatının kodunuz üzerindeki etkisinin sonuncusu.