Trong khóa học này, chúng ta học cách làm sao xây dựng một ứng dụng có tính quốc tế. Người dùng sản phẩm phần mềm mà các lập trình viên tạo ra có thể ở các vùng miền khác nhau, có độ tuổi khác nhau. Do đó, chúng ta cần đặc biệt chú ý đến sự đa dạng văn hóa trong quá trình xây dựng phần mềm. Vì thế, trong chương này, chúng tôi tập trung đi sâu vào các giải pháp đã được thử nghiệm và chứng minh là đúng đắn đối với vấn đề nêu trên. Mục tiêu cuối cùng của lập trình viên là hướng đến tạo ra một phần mềm có tính phổ biến với chi phí ít nhất về thời gian, công sức và tiền bạc.

Sau khi kết thúc khóa học này, bạn có thể:

• Hiểu được vì sao chúng ta cần xây dựng phần mềm quốc tế
• Biết cách xây dựng kịch bản mà lấy người dùng làm trung tâm
• Các kĩ thuật phân tích kịch bản để ánh xa sang công nghệ
• Biết cách xây dựng code base hợp lý với chi phí thấp

1. Phân tích

1.1. Thế nào gọi là một sản phẩm phần mềm quốc tế?

Mọi ứng dụng hay sản phẩm trên thị trường nếu muốn phát triển đều cần những tiêu chuẩn nhất định về chất lượng, sự phong phú,v.v. Muốn sản phẩm được ưa chuộng trên toàn thế giới cần kết hợp được 2 yếu tố: Sản phẩm hữa ích và sự phù hợp với nhu cầu sử dụng của từng vùng, từng tầng lớp.

Ví dụ với chuỗi cửa hàng của McDonal là chuổi cửa hàng ăn nhanh nổi tiếng trên thế giới với 118 cửa hàng trên toàn thế giới. Menu sản phẩm thức ăn nhanh của McDonal đương nhiên phải đáp ứng yêu cầu chung của cửa hàng thức ăn, phù hợp với thị hiếu tiêu chuẩn của khách hàng. Tuy nhiên chung một công thức thực phẩm nhưng ở từng nước, từng thành phố khác nhau, McDonald lại có một menu thay đổi một chút để phù hợp với vùng, miền đó. Ở một số nước không ăn thịt bò, vị thịt bò được bỏ đi, v.v. Cũng như vậy, một sản phầm phần mềm đa quốc gia khi được thiết kế triển khai cũng dựa trên 2 nền tảng: Những đặc tính chung của phần mềm, hệ thống và những đặc tính riêng của từng vùng miền để khiến phần mềm phù hợp với mọi đối tượng người dùng.

Với đặc tính chung khi xây dựng thì phần mềm được xây dựng có thể dựa trên các tiện ích từ hệ thống xây dựng sẵn có. Để minh họa rõ hơn, chúng ta có thể xem xét dựa trên một ví dụ như sau: Tưởng tượng rằng bạn và một người bạn đặc biệt của bạn có thể nói cả 67 ngôn ngữ. Một ngày, người bạn của bạn muốn đọc 1 tập của cuốn sách Harry potter trong tất cả các ngôn ngữ mà bạn nói trong cùng một thời gian. Để làm được điều này, bạn phải dịch cuốn sách 67 lần. Một ngày khi bạn đã 103 tuổi, bạn kết thúc việc này, v.v. và người mà bạn muốn gây ấn tượng sẽ vô cùng cảm ơn bạn, lúc này cuộc sống sẽ tốt đẹp với bạn. Nhưng có một cách đơn giản hơn là: bạn có thể yêu cầu những cuốn sách với thứ viện, bạn chỉ việc tới thư viện và lấy những cuốn sách đó cho người bạn của bạn. Cũng như vậy, hệ thống và chương trình ngôn ngữ bao gồm rất nhiều thư viện, hoặc dữ liệu của các ngôn ngữ hoặc vùng miền đặc biệt chúng ta có thể xây dựng dựa trên thư viện ngôn ngữ đó. Đặc tính thứ 2 là đặc tính địa phương: với mỗi đối tượng người sử dụng, phần mềm sẽ được xây dựng cần tìm hiểu các khác biệt của mỗi địa phương, lớp người sử dụng.

Hình ảnh dưới đây là một số sự khác nhau khi chúng ta xây dựng phần mềm cho các đối tượng người dùng là những người trên các vùng miền khác nhau:

Bảng. Quy ước chuyển đổi định dạng giữa các vùng miền

Từ bảng thống kê trên chúng ta có thể thấy khi xây dựng phần mềm ở các nước khác nhau sẽ có những điểm khác biệt: định dạng số, đơn vị tiền tệ, định dạng thời gian, ngày đầu tiên của tuần, timezone, lịch của Đức so với Nhật hoặc Nhật so với Anh cũng có sự khác biệt, v.v.

1.2. Phân tích thị trường hướng đến

Bất kỳ sản phẩm thành công nào cũng đều bắt đầu với ý tưởng cho được một số nhu cầu nào đó. Một kĩ thuật hay để định hình ý tưởng là hãy luôn luôn đặt câu hỏi như "Tôi ước mình có một cách để ...", "Phải có một cách dễ dàng hơn để ...", "Tôi cần một giải pháp thay thế ít tốn kém, mạnh hơn hoặc đáng tin cậy hơn cho ...". Nếu bạn muốn tận dụng công nghệ mới trong sản phẩm của mình, bạn có thể đưa ra những câu hỏi "Giấc mơ này là bây giờ có thể", "Nhiệm vụ này bây giờ trở nên ít phức tạp và tốn kém để hoàn thành", "Bây giờ sẽ nhanh hơn / giải trí / an toàn hơn để làm những điều tôi muốn hoặc cần làm".

Nhìn chung, ý tưởng của bạn nảy sinh từ bối cảnh cuộc sống của bạn và môi trường xung quanh. Sản phẩm của bạn có thể rất có ý nghĩa với những người có cùng sở thích, lối sống, hoặc kinh nghiệm như bạn, nhưng điều đó không có nghĩa nó phù hợp với tất cả mọi người khác. Thực tế, bạn không thể triển khai một sản phẩm vào các thị trường khác ngoài thị trường ban đầu bạn hướng tới. Nếu bạn muốn tạo một ứng dụng cho cả thế giới dùng, điều quan trọng là phải suy nghĩ trước thật kĩ ứng dụng đó có khả thi hay không.

Khi bạn đang lựa chọn thị trường phù hợp nhất cho ứng dụng của mình, trước hết bạn cần tự hỏi những câu hỏi cơ bản sau đây:

• Liệu khách hàng trong thị trường này cần phần mềm của bạn? Có ai sử dụng nó?
• Liệu khách hàng trong thị trường này có thể sử dụng phần mềm của bạn ngay khi họ muốn? Liệu quốc gia của họ có cơ sở hạ tầng phù hợp? Họ có thiết bị tương thích? Các quy định nào có cấm sử dụng không?
• Tìm hiểu liệu có cạnh tranh nào ở địa phương?
• Nếu phần mềm của bạn có đầy đủ nhu cầu và mọi người có thể và sẽ muốn sử dụng nó, câu hỏi tiếp theo là, họ có trả tiền để sử dụng nó không?
• Nếu họ dường như trả tiền cho nó, bây giờ bạn phải hỏi, "Liệu họ có đủ tiền để nó vận chuyển phần mềm của tôi vào thị trường của họ có đáng nỗ lực?"

1.3. Văn hóa ảnh hướng tới mức độ thành công của phần mềm

• Niềm tin tôn giáo. ở mỗi đất nước, vùng miền khác nhau, niềm tin tôn giáo làm nên thói quen cũng như nhu cầu về sản phẩm của họ. Nếu như bạn xây dựng một phần mềm tự làm beer để cung ứng cho người dùng, mà một số nước họ lại cấm sản xuất trái phép, hoặc với tôn giáo của họ không sử dụng beer như vậy phần mềm sẽ hoạt động sẽ không hiệu quả.
• Mức thu nhập (JDP). ở các nước còn đang phát triển thu nhập JDP sẽ thấp, nếu phần mềm quá nhiều chi phí: bảo trì, đánh giá, v.v. thì sẽ không được phổ biến
• Ngày đặc biệt. Khi xây dựng phần mềm cũng cần quan tâm tới: Ngày lễ, ngày nghỉ, giảm giá của từng vùng miền sẽ khác nhau. Phần mềm về thương mại, bán hàng chẳng hạn, ở một số nước có ngày Black Friday nhưng một số nước thì không. Lượng mua hàng vào ngày Black Friday sẽ tăng mạnh và ứng dụng triển khai cũng cần có những thay đổi phù hợp.
• Hệ thống ngân hàng. Một số nước chủ yếu thanh toán bằng thẻ điện tử hoặc visa. Ở các nước đang phát triển lại phổ biến hơn là tiền mặt hoặc thanh toán qua thẻ. Như vậy, khi xây dựng phần mềm chúng ta lại cần những tư vấn, những chuyên gia về mặt tài chính
• Luật. Ngoài ra, một khía cạnh nữa đó là về luật. Khi xây dựng phần mềm, ở các nước khác nhau luật của mỗi nước cũng khác nhau. Vậy nếu bạn không hiểu luật của các nước thì bạn không thể xây dựng được một phần mềm hợp lí, thậm chí bạn có thể bị buộc tội vì phần mềm làm sai hoặc xây dựng trái so với luật quy định. Từ đó dẫn đến yêu cầu cần một chuyên gia tư vấn về luật.

2. Thiết kế kịch bản

Để xây dựng được thiết kế có chất lượng cao, khóa học đưa ra ba bước được mô tả trong hình 1. Đầu tiên, điều quan trọng trên hết là các nhà thiết kế cần tìm hiểu các thông tin liên quan đến người dùng cuối như phong tục tập quán, vị trí địa lý, thói quen sinh hoạt, v.v. Bằng cách khảo sát, nghiên cứu và phân tích kĩ về người sử dụng, các nhà thiết kế có cái nhìn sâu sắc hơn về chính bản thân người dùng. Dựa trên những thông tin này, người thiết kế cầnxây dựng các kịch bản phù hợp với người sử dụng. Cuối cùng, dựa trên các kịch bản này, người thiết kế cần lựa chọn công nghệ thích hợp nhất sao cho chi phí hiện thực kịch bản là nhỏ nhất có thể.

Hình 1: Các bước xây dựng kịch bản chất lượng.

2.1. Tìm hiểu người dùng

Hình 2. Đặt câu hỏi để tìm hiểu người dùng.

Để hiểu sâu sắc về người dùng cuối sản phẩm, các nhà thiết kế phải tìm cách biến mình trở thành nhà tâm lý nghiệp dư bằng cách liên tiếp đặt các câu hỏi về bản chất người dùng. Các câu hỏi được đặt ra được trình bày trong bảng dưới đây.

Bảng. Danh sách các câu hỏi để hiểu người dùng

Ví dụ cụ thể, ứng dụng hiển thị bản đồ trực tuyến Google Map đã từng hiển thị nhầm thông tin biển Đông - vùng biển tranh chấp giữa sáu quốc gia gồm: Việt Nam, Trung Quốc, Indonesia, Malaysia, Philipines, Bruney. Tại thời điểm đó, thông tin tên biển được hiển thị thể hiện vùng biển thuộc về chủ quyền Trung Quốc (Hình 3). Sự nhầm lẫm trong thể hiện thông tin nhạy cảm này đã gây làn sóng phản đối từ nhiều quốc gia trong vùng xung đột. Như vậy, từ bài học của Google Map, các nhà thiết kế cần phải rút ra bài học kinh nghiệm rằng nội dung sản phẩm cần phải tránh các vấn đề liên quan đến xung đột, tranh chấp.

Hình 3. Thông tin nhạy cảm về vùng biển hiển thị trên Google Map (năm 2015).

2.2. Mô tả kịch bản

Thực tế, thật khó để thiết kế một trải nghiệm hoàn hảo cho tất cả mọi loại người dùng. Một phương pháp hợp lý là phân loại các lớp người dùng thông qua xác định rõ họ đang muốn làm gì. Để hoàn thành tác vụ, một người sẽ phải thực hiện qua từng bước. Các bước này tạo thành một kịch bản. Một kịch bản cần được hoàn thành một cách có ý nghĩa và hợp lý. Tức là, kịch bản cần thể hiện như một câu chuyện có khởi đầu, có phần nội dung chính và phần kết thúc. Bản thân các nhà thiết kế cần phải đặt chính bản thân họ vào đôi giày của người dùng, và tự đặt các câu hỏi về bản chất gồm "Tôi là ai?", "Tôi đang làm gì?", "Khi nào tôi thực hiện điều này?", "Tôi thực hiện điều này ở đâu?", "Tại sao tôi làm điều này?", và cuối cùng là câu hỏi "Tôi làm điều này như thế nào?".

Tôi đang làm gì?

Nhà thiết kế cần mô tả các hành động cần thiết mà người dùng cần thực hiện để hoàn thành công việc của họ. Tuy nhiên, thường thì kịch bản mà họ đưa ra thường không đủ tốt ở góc nhìn người sử dụng. Hầu hết chúng ta phải đối mặt với những hướng dẫn sử dụng rườm rà, khó chịu khi sử dụng sản phẩm. Để giải quyết vấn đề này, các nhà thiết kế có thể sử dụng phương pháp mô tả bảng như sau. Ở cột bên trái, các bước để thực hiện tác vụ được mô tả lần lượt ở mức tổng quan. Cột bên phải trình bày chi tiết hơn từng bước tổng quan đó. Để cho dễ hiểu, ví dụ sau trình bày kịch bản làm bánh sandwich.

Bảng. Ví dụ mô tả chi tiết các bước trong kịch bản

Tôi là ai? Khi phác hoạ kịch bản, bạn có thể cập nhật bản mô tả đối tượng của mình. Thực hiện mô tả kịch bản theo cách mà người sử dụng mong muốn đòi hỏi sự hiểu biết sâu sắc về khán giả. Các nhà thiết kế phải tập trung vào những gì thực sự quan trọng đối với người sử dụng và bỏ qua bất cứ điều gì cảm thấy không cần thiết. Để xác định được điều gì thực sự quan trọng, các nhà thiết kế thường đánh giá qua các thuộc tính người sử dụng như nền tảng giáo dục, giới tính, nghề nghiệp, tuổi, ngôn ngữ, đất nước, v.v.

• Mỗi thế hệ người dung có những đặc trưng và thái độ riêng. Môi thế hệ bị ảnh hưởng sâu sắc bởi thời tiết chính trị, kinh tế, và xã hội, cũng như tiến bộ công nghệ với các mức độ khác nhau.
• Niềm đam mê cá nhân là tiêu chí để phân loại người dùng nhằm tập trung xây dựng chung trải nghiệm cho một nhóm người có chung niềm đam mê (ví dụ: thích rượu vang, xe máy, một số đội thể thao hoặc người nổi tiếng, hài hước, hoặc mèo).
• Các nhà thiết kế có thể xây dựng kịch bản dựa trên thói quen và công việc hàng ngày của người dùng. Có những người nhận cà phê mỗi sáng, đọc tin tức mỗi ngày và mua sắm hàng tạp hóa hàng tuần. Và đừng quên những thói quen xấu liên quan đến quản lý - như tính hay quên của người sử dụng.

Cuối cùng, bạn cần nhớ rằng phần mềm được thiết kế cho một đối tượng cụ thể có thể sẽ hấp dẫn người dùng hơn. Giống như các bộ phim điện ảnh, một số phần mềm thành công hơn trên thị trường quốc tế hơn là ở trên thị trường mà nó đã được dự định ban đầu. Nếu kịch bản của nhà thiết kế khác nhau cho từng loại người dùng, thật khó dự đoán ai thực sự muốn sử dụng nó.

Khi nào tôi thực hiện điều này? Vào thập niên 70 - 80, khi các máy tính nặng vài tấn và bị giới hạn trong một phòng lớn tại một trường đại học hoặc một công ty (hầu hết mọi người không được phép truy cập), vấn đề tối ưu hóa trải nghiệm người dùng ít được quan tâm. Ngày nay, không chỉ kích thước máy tính mà tốc độ xử lý được cải thiện chóng mặt qua từng năm. Vì thế, người sử dụng có thể sử dụng máy tính, hoặc nói chung là thiết bị điện tử ở khắp moi nơi. Từ đó dẫn đến bài toán, liệu khách hàng mong đợi một trải nghiệm nhất quán giữa các địa điểm và thiết bị.

Để đạt được "trải nghiệm nhất quán ở bất cứ nơi đâu, bất cứ lúc nào, trên bất kỳ thiết bị" là thách thức. Một số thách thức là hiển nhiên, chẳng hạn như duy trì trải nghiệm nhất quán trên vô số thiết bị với các kích cỡ và độ phân giải màn hình khác nhau. Những thứ khác ít hiển thị đối với người dùng, nhưng thiết kế và mã của bạn vẫn cần phải thích ứng với chúng gồm:

• Luật địa phương về vị trí lưu trữ dữ liệu cá nhân "trong đám mây"
• Sự khác biệt vùng về tiêu chuẩn phần cứng hoặc các giao thức truyền thông
• Các hạn chế của chính phủ về thu thập thông tin về trẻ em hoặc học sinh
• Sự khác biệt trong luật thuế hoặc các thủ tục thu thuế bán hàng hoặc thuế VAT

Bạn có thể phải hạn chế một số dịch vụ theo ranh giới khu vực. Giấy phép đối với nội dung đa phương tiện, chẳng hạn như nhạc trực tuyến hoặc video, có xu hướng khác nhau đối với từng quốc gia. Một số chính phủ thậm chí có thể cấm hoặc kiểm duyệt nội dung cụ thể. Sự khác biệt về luật pháp và giấy phép là một trong những lý do khiến các dịch vụ như Netflix không cho phép các thuê bao ở Mỹ đăng nhập từ các địa chỉ IP không phải của Mỹ để phát nội dung.

"Tại sao tôi làm điều này?" Bằng cách hiểu được lý do tại sao, nhà thiết kế có thể đưa ra được giả định đơn giản hóa cho sự xây dựng kịch bản. Ví dụ, các nhà sản xuất trò chơi cao cấp có thể giả định rằng khách hàng của họ có máy tính cá nhân với card đồ họa mạnh mẽ, bộ nhớ gigabyte, màn hình lớn và Internet băng thông rộng. Họ không cần phải tinh chỉnh hiệu suất cho các máy tính cá nhân cấp thấp; những game thủ muốn trải nghiệm sâu sắc sẽ không bao giờ sử dụng những máy đó.

"Tôi làm điều này như thế nào?". Như chúng ta đã bàn luận trước đây, người sử dụng không thích phải nỗ lực cố gắng để làm cho một cái gì đó hoạt động mà không làm việc theo cách mà họ mong đợi. Thiết kế tốt làm thiểu sự bực bội và nhường chỗ cho những nỗ lực tinh thần mang lại hiệu quả hoặc giải trí. Một trong những kĩ thuật hay được áp dụng là dự đoán những gì một người muốn hoặc cần phải làm tiếp theo, dựa trên bối cảnh của kịch bản, và thậm chí làm nhiệm vụ cho họ bất cứ khi nào có thể.

2.3. Lựa chọn công nghệ

Trong các phần trước, bạn đã biết kĩ thuật đặt câu hỏi "who, what, where, when, why, how" trong quá trình xây dựng kịch bản. Trong bước này, bạn - bản thân là một nhà thiết kế - cần tìm công nghệ thích hợp nhất để xây dựng kịch bản. Điều này trở nên phức tạp hơn nếu kịch bản có thể phân nhánh ra theo các hướng khác nhau tùy thuộc vào sự lựa chọn của người dùng, hoặc giới hạn về công nghệ (ví dụ, điều gì sẽ xảy ra khi có kết nối mạng và điều gì sẽ xảy ra nếu không có kết nối mạng).

- Bước 1. Đặt câu hỏi về lựa chọn công nghệ Sau đây là một danh sách các câu hỏi giúp nhà thiết kế lựa chọn công nghệ phù hợp nhất:

• Loại phần mềm bạn sẽ viết, ví dụ: ứng dụng web, phần mềm nhúng, phần mềm hệ thống, v.v.
• Bạn hướng đến tạo ra sản phẩm trên nền tảng hệ điều hành nào, ví dụ: Android, iOS, Mac, Windows
• Kiểu thiết bị nào chạy ứng dụng của bạn, ví dụ: máy tính cá nhân, điện thoại, máy tính bảng, bảng điều khiển trò chơi, IoT. Lưu ý rằng một số thiết bị có thể không có ở một số quốc gia.
• Bạn sẽ sử dụng ngôn ngữ lập trình nào, ví dụ: C ++, C #, Java, JavaScript, PHP, Python, Ruby
• Môi trường phát triển tích hợp (IDE) nào bạn sẽ chọn, ví dụ: Aptana Studio, Eclipse, Microsoft Visual Studio, Oracle NetBeans
• Bạn sẽ áp dụng nền tảng điện toán đám mây nào, ví dụ: Amazon Web Services, Azure, Google, HP, IBM, Salesforce.com

- Bước 2. Xác định các công nghệ cơ bản cần dùng Tiếp theo, ghi lại một số công nghệ cơ bản mà kịch bản của bạn sẽ cần. Một lần nữa, bạn có thể xem lại danh sách này nhiều lần. Sau đây là một số ví dụ:

• Kết nối mạng hoặc di động
• Đăng nhập an toàn
• Tương tác thông qua liên lạc, giọng nói hoặc mực
• Khả năng ghi hoặc phát âm thanh hoặc video
• Lưu trữ dựa trên máy chủ hoặc đám mây
• Cơ sở dữ liệu
• Hỗ trợ cho các giao dịch tài chính
• GPS hoặc theo dõi vị trí
• Phân phối qua cửa hàng trực tuyến

Phần lớn các công nghệ cơ bản trong danh sách của bạn sẽ tồn tại, ví dụ như các cơ sở dữ liệu và quản lý nhận dạng. Nếu có, bạn cần liệt kê các nguồn khả thi, ví dụ: cơ sở dữ liệu SQL Server hoặc cơ sở dữ liệu Oracle. Trường hợp ngược lại, nếu bạn cần một công nghệ chưa tồn tại, bạn có thể phải phát triển nó. Cách để tìm ra điều này là để tự hỏi: "Có cách nào để làm XYZ?" Đồng thời bạn cũng tìm kiếm các giải pháp đã được làm sẵn từ các công ty khác. Ví dụ: "Có cách nào để giao tiếp với máy làm mì Ý thông qua XML?".

- Bước 3. Đánh giá về sự phụ thuộc công nghệ

Hình 4. Kĩ thuật đồ thị phụ thuộc trong lựa chọn công nghệ.

Nhà thiết kế cũng cần phải suy nghĩ về các sự phụ thuộc, tức là, "kịch bản này chỉ có thể thực hiện nếu XYZ là đúng.". Hình 4 mô tả đồ thị phụ thuộc giúp đánh giá sự phụ thuộc công nghệ hiệu quả hơn. Nếu công nghệ B phụ thuộc vào công nghệ A, ta biểu diễn bằng một mũi tên nối từ B đến A. Ví dụ, "Kịch bản đưa mọi người chỉ đường từ vị trí hiện tại của họ tới vị trí khác chỉ có thể nếu người dùng cấp phép cho ứng dụng của bạn Sử dụng dữ liệu vị trí GPS của họ.".

- Bước 4. Tạo bảng ánh xạ công nghệ với yêu cầu người dùng

Cột "Những gì người dùng làm" chứa các bước chi tiết để thực hiện kịch bản. Cột "Những gì người dùng xem" có thể là mô tả, bản vẽ hoặc bản mô tả (bạn có thể phải làm nhiều phiên bản nếu bạn đang nhắm mục tiêu nhiều hơn một nền tảng hoặc loại thiết bị). Cột cuối cùng mô tả các cân nhắc về công nghệ như yêu cầu sử dụng các nền tảng cấp cao, các tính năng cụ thể (ví dụ, định dạng ngày và giờ cho các ngôn ngữ Tây Âu), các bộ API (ví dụ, Win32 National Language Support API), hoặc các phương pháp cá nhân (ví dụ, DateTime.ToString ()).

Trong thời đại phát triển ứng dụng nhanh này, một số nhà thiết kế không muốn dành thời gian để tạo chi tiết bảng ánh xạ này. Tuy nhiên, nếu bạn không có bản ánh xạ đủ chi tiết trước khi bắt đầu phát triển, thì bạn có thể đánh giá thấp những yêu cầu đó. Đầu tư quá nhiều thời gian cho việc viết một bản thông tin có thể trì hoãn phát triển. Vì thế, bạn cần phải cân bằng giữa việc mô tả chi tiết bảng ánh xạ với nguồn lực về thời gian.

Bảng. Bảng ánh xạ công nghệ với yêu cầu người sử dụng

3. Phát triển

3.1. Code base

Trong mỗi ứng dụng, chúng ta chỉ nên tạo duy nhất một code base thay vì tạo nhiều bản sao phần mềm khác nhau, trong mỗi bản sao là một code base khác nhau. Người ta có thể cố gắng biện minh cho việc xây dựng nhiều code base khác nhau vì nhu cầu riêng biệt của các nhóm ngôn ngữ khác nhau.

Ví dụ, các nhà phát triển trong Age of Yore đã tạo nhiều bản sao của toàn bộ cây mã nguồn và thay đổi các bản sao để hỗ trợ các phiên bản bản địa hoá của phần mềm. Nhóm dự án bắt đầu với các sản phẩm cho thị trường Hoa Kỳ và Châu Âu. Tiếp theo, họ hỗ trợ thêm cho các ngôn ngữ Đông Á. Khi thị trường mở rộng và phát triển, nhóm phát triển này hỗ trợ cho các ngôn ngữ Trung Đông. Nhóm cuối cùng hỗ trợ là tiếng Thái và Ấn Độ.

Tiếng Anh và châu Âu sử dụng các văn tự Latin, Hy Lạp, và Cyrillic. Các ngôn ngữ này tuân theo quy tắc tương tự cho nhập văn bản và hiển thị, ví dụ: các ký tự được sử dụng phổ biến trên một bố cục bàn phím, v.v. Các ngôn ngữ ở Đông Á như Trung Quốc, Nhật Bản và Hàn Quốc cần hỗ trợ nhập hàng nghìn ký tự bằng bàn phím. Các ngôn ngữ này cũng yêu cầu khả năng đặt văn bản theo chiều dọc trong các cột được đọc từ phải sang trái. Các ngôn ngữ Trung Đông sử dụng hệ thống chữ viết tiếng Ả Rập hoặc Hebrew cần hỗ trợ việc bố trí và hiển thị văn bản hai chiều, cũng như các hình tượng thay đổi hình dạng tùy thuộc vào vị trí của chúng trong một từ (được gọi là định dạng theo ngữ cảnh). Các ngôn ngữ Nam Á, bao gồm các ngôn ngữ Ấn Độ, có thể cần hỗ trợ việc định hình theo ngữ cảnh của các ký tự glyphs cũng như các ký tự xếp chồng lên nhau hoặc kết hợp để tạo ra các cụm.

Tại sao chúng ta cần xây dựng mã nguồn cho các ngôn ngữ Đông Á hoặc Trung Đông trong các phiên bản châu Âu của phần mềm? Lý do rất đơn giản. Ngôn ngữ mà mọi người muốn sử dụng trong trải nghiệm phần mềm của họ, không nhất thiết phải khớp với ngôn ngữ UI của phần mềm. Người ta có thể sử dụng một phiên bản tiếng Anh của phần mềm để tạo các tài liệu bằng tiếng Đức, hoặc phần mềm Pháp để tạo tài liệu bằng tiếng Ả Rập.

Nếu bạn nghĩ rằng có thể tạo ra các code base riêng biệt cho các nhóm ngôn ngữ khác nhau, chúng tôi có thể cho bạn biết rằng những người khác đã làm điều này, và thực sự nó không có ý nghĩa. Nếu mỗi phiên bản ngôn ngữ có code base riêng của mình, thì chi phí kiểm thử tăng lên rất nhiều. Do sự khác biệt mã nguồn, mỗi phiên bản ngôn ngữ đòi hỏi phải vượt qua các bộ test 100%. Công ty cần đầu tư nhiều nguồn lực hơn để kiểm thử từng code base một cách nghiêm ngặt, và kiểm thử viên phải có cả kiến ​​thức kỹ thuật về sản phẩm và các kỹ năng ngôn ngữ trong các ngôn ngữ mục tiêu. Nhìn chung, chúng ta nên hạn chế tạo nhiều code base. Lời khuyên duy nhất là bạn nên tạo một code base duy nhất để có hiệu quả về chi phí để phát triển và quản lý. Bạn sẽ tránh được các vấn đề kiểm soát phiên bản, bạn chỉ cần kiểm thử một code base duy nhất.

3.2. Viết mã nguồn tổng quát Chúng ta đã thảo luận về lợi ích của việc tạo ra một code base duy nhất. Sau đây là các lời khuyên cho việc viết mã:

• Cô lập bất kỳ chức năng nào sẽ yêu cầu thay đổi, thêm hoặc xóa mã dựa trên ngôn ngữ trong một phần riêng biệt của cây nguồn của bạn. Nếu một số tính năng của bạn chỉ áp dụng cho các ngôn ngữ hoặc thị trường cụ thể, bạn có thể biên dịch chúng thành các mô-đun riêng biệt, ví dụ: các thư viện được liên kết động. Một lựa chọn khác là cho phép người dùng tải các "gói ngôn ngữ". Sau đó, người dùng có thể chọn để cài đặt hỗ trợ cho các ngôn ngữ họ sẽ sử dụng.
• Sử dụng thư viện cho các hoạt động dựa trên ngôn ngữ hoặc địa phương bất cứ khi nào có thể. Làm như vậy cho phép bạn viết mã mà không cần phải thay đổi giữa các phiên bản ngôn ngữ khác nhau của phần mềm của bạn. Một vài API được liệt kê trong bảng dưới đây.

Bảng. Ví dụ API cho hỗ trợ nhiều định dạng khác nhau tùy theo vị trí người dùng

Tham khảo

• https://courses.edx.org/courses/course-v1:Microsoft+DIS50x+3T2016/info
• https://techmaster.vn/posts/33987/vai-tro-quan-trong-cua-thiet-ke-trai-nghiem-nguoi-dung-user-experience-design