Chúng ta nên đổi tên mã và dữ liệu bao xa khi danh pháp người dùng cuối thay đổi?

Cách đây rất lâu, chúng tôi đã thêm một tính năng trong đó người dùng của chúng tôi có thể "Chấp nhận" một hình ảnh sau khi nó được thêm vào hàng đợi công việc. Hóa ra, chúng tôi đã sử dụng thuật ngữ sai và người dùng thực sự "Phê duyệt" hình ảnh.

Thay đổi Chấp nhận thành Phê duyệt trên giao diện của chúng tôi rất dễ dàng, chỉ cần thay thế một từ. Nhưng chúng tôi đã lập trình tất cả các lớp với từ "chấp nhận", từ tên lớp CSS đến các giá trị cơ sở dữ liệu.

• Lớp CSS chuyển nút màu xanh lá cây: ".accepted";
• Phương thức mô hình xác minh và liên kết thuộc tính lớp trên nút DOM: "isAccepted";
• Thuộc tính trạng thái JavaScript: Mảng có "không được xem xét", "được chấp nhận" và "đã xuất bản";
• Cột trạng thái Mysql: ENUM với "chưa được xem xét", "được chấp nhận" và "đã xuất bản";
• Tên thử nghiệm;

Đó là chuyện nhỏ (đặc biệt khi bạn có bài kiểm tra) để thay thế hầu hết các lần chấp nhận để phê duyệt. Khó hơn một chút là di chuyển dữ liệu, đặc biệt vì nó cần được đồng bộ hóa với việc triển khai.

Trường hợp cụ thể này là đơn giản, nhưng tôi đã phải đối mặt với các trường hợp tương tự, nhưng phức tạp hơn, trong sự nghiệp của tôi. Khi một tệp cũng được đổi tên và triển khai xảy ra trên hàng tá máy chủ hoặc khi lưu trữ bộ đệm proxy, memcached và mysql có liên quan.

Rời khỏi "được chấp nhận" trên mọi lớp khác ngoại trừ giao diện là một ý tưởng tồi, vì các lập trình viên mới gia nhập nhóm có thể không tìm hiểu lý do lịch sử dẫn đến quyết định này và trong khi chấp nhận -> chấp nhận là những từ gần nghĩa về mặt ý nghĩa, nếu nó đã được đổi tên thành "xếp hàng cho cuộc họp trạng thái tiếp theo của người quản lý", nó chắc chắn sẽ không có ý nghĩa gì. Và cảm giác nếu chúng ta thỏa hiệp ở đây và ở đó, trong một vài lần lặp lại, các khái niệm giao diện người dùng sẽ không có mối liên hệ nào với các hệ thống bên trong và tôi chắc chắn không muốn làm việc trên một hệ thống mà một nửa đầu ra không có kết nối với các bộ phận bên trong của nó.

Vì vậy, bạn luôn đổi tên mọi thứ khi cần? Nếu điều này xảy ra với bạn và bạn quyết định rằng sự đánh đổi là không đáng, liệu nó có quay lại cắn bạn không? Là nhận xét mã hoặc tài liệu dành cho nhà phát triển đủ để tránh vấn đề này?

Đối với tôi, tốt nhất là thay đổi mọi thứ liên quan đến mục được đề cập.

Đây là một hình thức xuống cấp mã và trong khi 1 mục không bị thay đổi có thể không phải là vấn đề lớn, thì nó đặt âm cho cơ sở mã.

Nó cũng có thể dẫn đến sự nhầm lẫn trong tương lai và làm cho các nhà phát triển mới khó hiểu hơn về cơ sở / tên miền mã.

Từ nội dung câu hỏi và thẻ tôi sẽ khẳng định bạn đang sử dụng ngôn ngữ phổ biến.

Theo kinh nghiệm của tôi, UL rất tuyệt nhưng, như bạn đã đề cập, có thể dẫn đến các nhiệm vụ bảo trì bổ sung khi ngôn ngữ phát triển. Điều này, bản thân nó, không phải là một điều xấu. Chắc chắn, nó bất tiện, nhưng nó cũng được mong đợi.

Những gì tôi thường làm (và đã thấy xong) là:

• Tái cấu trúc trả trước 1-shot: Tái cấu trúc tất cả các lớp của ứng dụng để áp dụng ngôn ngữ cập nhật; hoặc là
• ghi nhật ký nợ kỹ thuật: Bạn có thể thay đổi mã đối mặt với người dùng ngay lập tức và sau đó ghi nhật ký các tác vụ nợ kỹ thuật để đưa phần còn lại của các lớp ứng dụng phù hợp với ngôn ngữ được cập nhật. Điều này thường dẫn đến một số nhiệm vụ nhàm chán (nhưng có thể quản lý). (Hoàn hảo cho 5 giờ chiều!)

Tôi nghĩ điều quan trọng ở đây là những gì bạn mô tả là nợ kỹ thuật và nên được công nhận như vậy.

Tôi đã có những người quản lý đã lập luận rằng chúng ta không nên lãng phí thời gian vào những nhiệm vụ tầm thường như vậy mà không thêm bất kỳ chức năng hiển thị nào. Đây là khi tương tự nợ thực sự có ích. Nó hiểu rõ điều này:

Nhóm đã chọn làm DDD với Ngôn ngữ Ubiquitous. Đi lạc khỏi phương pháp này bằng cách để mã ở trạng thái không nhất quán làm tăng thêm sự nhầm lẫn và loại bỏ nhiều lợi ích mà DDD và UL cung cấp. Về mặt quản lý, nó làm tăng thêm chi phí cho dự án. Mã trở nên khó quản lý hơn (đắt tiền) và khó hiểu hơn đối với các nhà phát triển mới (đắt tiền).

Bạn có thể muốn xem xét các tùy chọn Bản địa hóa (l10n). Mặc dù có vẻ không quyết liệt bằng việc chuyển từ tiếng Anh sang tiếng Tây Ban Nha, bạn đang xử lý một thuật ngữ khác cho cùng một khái niệm. Nếu điều này dường như xảy ra phổ biến, thì việc sử dụng l10n có thể cho phép bạn nhanh chóng thay đổi những gì được hiển thị trong giao diện người dùng trong khi không phải thay đổi thuật ngữ được sử dụng trong mã.

Với điều đó, chỉ cần sử dụng các thuật ngữ trong mã của bạn được hiểu rộng rãi nhất. Chọn tên từ tên miền vì nhà phát triển biết nó và có thể mong đợi nó.

Khi bạn mô tả một cách thích hợp điều này, việc theo dõi các thay đổi về danh pháp của người dùng cuối trong mọi phần của nguồn là một khoản đầu tư. Tuy nhiên, nó hoàn toàn xứng đáng, đặc biệt đối với một sản phẩm sống lâu được phát triển bởi một cơ sở hạ tầng hoàn chỉnh (với đường dây nóng, người thử nghiệm, v.v.)

Theo dõi danh pháp người dùng cuối trong nguồn là một khoản đầu tư là do có rất nhiều loại thành phần xuất hiện và không có cây đũa thần hoạt động đồng thời trên tất cả các thành phần này. Có lẽ phát triển một cây đũa thần như vậy, thành phần sau thành phần, là một khoản đầu tư thú vị mà bạn có thể pha loãng trong suốt thời gian của dự án.

Tôi đã làm việc trên một cơ sở mã 30 năm tuổi, trong đó sự trôi dạt giữa danh pháp người dùng cuối và danh pháp nội bộ phát triển đặc biệt lớn. Dưới đây là một vài nhược điểm của tình huống này, tất cả đều bổ sung vào chi phí công việc của mọi người:

1. Trong trường hợp không có chính sách đầy đủ, phát triển mới có xu hướng sử dụng danh pháp người dùng cuối hiện tại. Do đó, cùng một khái niệm có thể có hai hoặc nhiều tên trong các thành phần khác nhau. Do các thành phần tương tác với nhau, điều này dẫn đến một số tên đồng nghĩa hiện có một cách tương tự trong một số phần cục bộ của mã.

2. Khi bàn gọi đường dây nóng / trợ giúp được gọi, họ viết ra một câu chuyện người dùng bằng cách sử dụng danh pháp người dùng cuối. Nhà phát triển chịu trách nhiệm khắc phục sự cố phải dịch danh pháp người dùng cuối để phù hợp với danh pháp nguồn. Tất nhiên nó không được lưu trữ, và tất nhiên nó là một mớ hỗn độn. (Xem 1.)

3. Khi lập trình viên gỡ lỗi mã, cô ấy muốn đặt các điểm dừng trong các chức năng có liên quan. Thật khó để tìm thấy các chức năng phù hợp nếu danh pháp người dùng cuối và danh pháp nguồn không đồng ý. Thậm chí có thể khó hoặc không thể tự tin rằng một danh sách các chức năng có liên quan thậm chí còn hoàn chỉnh. (Xem 1.)

4. Trong trường hợp không có chính sách đầy đủ, việc duy trì nguồn bằng cách sử dụng danh pháp lỗi thời theo thời gian sẽ đặt danh pháp lỗi thời này trước người dùng một lần nữa. Điều này tạo ra ấn tượng kém và gây ra chi phí.

Tôi đã theo dõi hai ngày dài tại nơi mà một số dữ liệu được đọc khỏi cơ sở dữ liệu và được tiêm vào một số thành phần của cơ sở mã này. Bởi vì dù tôi và bất kỳ ai ở công ty tôi làm việc đều có thể tìm ra một cái tên dẫn đến nơi này, cuối cùng tôi đã gạt bỏ và quyết định tìm một giải pháp khác cho vấn đề đó.

Mặc dù tốn hơn [1] hai ngày bảo trì mà không mang lại bất cứ điều gì (không có kiến ​​thức, không sửa chữa, không có gì) có thể tệ như nó có thể nhận được, sự khác biệt giữa danh pháp người dùng và danh pháp nguồn thêm chi phí cho nhiều nhiệm vụ thường xuyên trong việc duy trì một phần mềm.

Điều quan trọng cần lưu ý là chi phí hoạt động tăng lên khi công ty sản xuất phần mềm, trong một tổ chức lớn, một báo cáo vấn đề sẽ không đến trên bàn của bạn trước khi nó được một số đồng nghiệp xem xét và việc khắc phục có thể phải kiểm tra.

[1] Bởi vì có nhiều hơn một nhà phát triển được tham gia.

Tôi không luôn đổi tên mã và dữ liệu vì một số gói được chia sẻ giữa các khách hàng. Về cơ bản họ đang sử dụng cùng một thứ nhưng gọi nó là khác nhau. Ví dụ, trong một CMS, một khách hàng gọi khách hàng của họ là "Khách hàng" và một khách hàng khác sử dụng "Khách hàng". Vì vậy, chúng tôi đã thay thế Khách hàng bằng Khách hàng trên một bề mặt cho một khách hàng, nhưng CMS sẽ luôn là Hệ thống Quản lý Khách hàng.

Một ví dụ khác là Quản lý người dùng với các thuật ngữ như quyền và danh sách kiểm soát truy cập, quản trị viên và người quản lý, v.v. Nó có thể gây nhầm lẫn cho những người mới đến nhưng đối với các thành phần cốt lõi như thế, thường có các nhà phát triển cốt lõi đảm bảo rằng các thành phần đó hoạt động cho tất cả các máy khách và cũng dễ dàng thực hiện bởi các nhà phát triển khác (ví dụ: bằng cách tạo nhãn có thể định cấu hình).

Có thể giúp bạn nghĩ rằng nếu bạn thực hiện thay đổi này, hy vọng bạn sẽ không cần phải thực hiện lại nếu cùng một phần được sử dụng bởi khách hàng khác, về cơ bản biến nó thành một sản phẩm.