Chúng tôi đã có một sản phẩm sống lâu trong khoảng 8 năm nay. Theo thời gian, tên của các khái niệm và thực thể thay đổi. Chúng ta có nên đặt công việc để đổi tên tất cả các bảng và cột cơ sở dữ liệu để khớp với các tên mới này không?
Có một nghiên cứu được thực hiện về điều này hoặc một số thực tiễn tốt nhất được công bố?
Cảm ơn
Câu trả lời:
Sự không phù hợp giữa tên bên trong và bên ngoài chắc chắn có mùi. Giống như Rinzwind chỉ ra, các từ đồng âm và từ đồng nghĩa có mùi tệ nhất.
Câu hỏi thực sự bạn cần trả lời là: Sự đánh đổi chi phí / lợi ích trong việc tạo ra sự thay đổi là gì?
Chi phí không thay đổi là một đường cong học tập dốc hơn cho các thành viên mới của nhóm và tăng khả năng xảy ra lỗi trong tương lai. Chi phí thay đổi là thời gian rõ ràng liên quan, một đường cong học tập mới cho các bộ định thời cũ trong dự án và khả năng xảy ra lỗi mới.
Nếu bạn đang mong đợi có một số lượng thành viên nhóm mới tương đối lớn, thì nhiều khả năng sẽ có ý nghĩa để tạo ra sự thay đổi. Nếu bạn không mong đợi bất kỳ doanh thu nào, nhóm hiện tại không có xu hướng bị nhầm lẫn và nhóm hài lòng với hiện trạng, thì thực sự không có ý nghĩa gì để đổi tên mọi thứ.
Nếu mã được dự kiến sẽ tồn tại trong một thời gian dài và sẽ có các nhà phát triển mới làm việc với nó, tôi sẽ thực hiện các thay đổi.
Nó có thể rất khó hiểu và tốn thời gian cho một nhà phát triển mới tham gia vào một dự án và tìm tên của các thực thể là sai lệch.
Ngoài ra còn có đối số hợp lệ của ... Nếu nó không bị hỏng, đừng sửa nó.
Liên quan đến câu hỏi thứ hai của bạn, tôi không biết về bất kỳ nghiên cứu được công bố hoặc thực tiễn tốt nhất nào. Liên quan đến câu hỏi đầu tiên, tôi có thể đưa ra một số quan sát từ trải nghiệm cá nhân với một sản phẩm có tuổi thọ tương tự trong đó đôi khi tên 'nội bộ' và 'bên ngoài' khác nhau.
Những cái tên mà tôi thực sự muốn sửa là những từ đồng âm của người Hồi giáo, trong đó một tên được sử dụng cả bên trong lẫn bên ngoài cho những thứ khác nhau . Điều này có thể thực sự khó hiểu, đặc biệt nếu hai điều không hoàn toàn khác nhau (như bối cảnh đó giúp phân tán). Một ví dụ (trừu tượng) về điều đó theo kinh nghiệm cá nhân của tôi là trong nội bộ bạn có một cái gì đó giống như Foomột tập hợp nhiều FooEntity; ở bên ngoài, chỉ có cái sau được nhìn thấy và được gọi là một Foo '. Mất một lúc tôi mới nhận ra rằng khi hướng dẫn khách hàng nói về nhiều Foo, nó thực sự có nghĩa là nhiều FooEntity(trong một lần Foo), nếu điều đó vẫn có ý nghĩa với bạn.
Thứ hai, tôi muốn sửa bất kỳ từ đồng nghĩa nào của người Viking trong đó một số tên bên ngoài đã được sử dụng trong nội bộ. Giống như trong tên biến, các phần của tên phương thức / hàm và như vậy. Điều này thường xảy ra khi các nhà phát triển triển khai một cái gì đó trực tiếp từ một mô tả yêu cầu của khách hàng và quên dịch Dịch tên của tên. Khi điều đó xảy ra, tên 'sai' cũng có xu hướng lan rộng, vì các nhà phát triển khác tình cờ sao chép / dán một số mã đó để sử dụng làm mẫu cho mã mới chẳng hạn. Các từ đồng nghĩa này không quá khó hiểu, nhưng chúng có thể gây khó chịu bởi vì nếu bạn đang tìm kiếm mã cho bất kỳ tài liệu tham khảo nào, Barbạn có thể phải nhớ rằng một số phần có thể đề cập đến nó như làQux, vì vậy bạn phải tìm kiếm hai lần. (Điều này có thể tệ hơn trong các ngôn ngữ được gõ động so với các ngôn ngữ tĩnh, vì bạn phải tìm kiếm trên các phần của tên biến / hàm / ... chứ không phải trên tên của loại của chúng.) Đối với trường hợp ngược của từ đồng nghĩa Nghiêng, nơi một tên nội bộ đã được sử dụng bên ngoài: điều này có xu hướng không xảy ra thường xuyên, vì nhân viên hỗ trợ khách hàng và thường không biết về tên nội bộ, mặc dù tôi cho rằng nó gây nhầm lẫn cho khách hàng khi nó xảy ra.
Nếu bạn có thể tránh hoặc khắc phục ít nhất hai tình huống trên, tôi không chắc liệu bạn có nên đi xa hơn để làm cho tất cả các tên nội bộ giống như các tên bên ngoài hay không. Có lẽ có một lý do chính đáng tại sao tên nội bộ không thay đổi khi tên bên ngoài được tạo khác với tên bên trong ở vị trí đầu tiên. Theo kinh nghiệm cá nhân của tôi, lý do chính đáng đó là nhu cầu hỗ trợ các phiên bản cũ hơn của sản phẩm; nó có thể trở nên khó khăn để hợp nhất một bản sửa lỗi từ phiên bản dọn dẹp trước tên thành phiên bản mới nhất nếu có nhiều mã phải được thay đổi.
Đây là một vấn đề khá phổ biến. Một số dự án tôi đã làm việc sử dụng tên mã thay vì tên sản phẩm (có thể chưa được quyết định tại thời điểm đó) và sử dụng thuật ngữ mã khác nhau trong mã so với tên được hiển thị cho người dùng. Tôi có thể sẽ để mọi thứ như hiện tại, trừ khi bạn đang trải qua quá trình tái sử dụng mã lớn hoặc nếu có điều gì đó gây ra sự cố cụ thể. Không sử dụng trong việc đảo lộn giỏ táo. Ngoài ra, ai sẽ nói 5 năm nữa sẽ không có nhiều thay đổi? Và sau đó bạn sẽ phải thực hiện việc đổi tên một lần nữa. Và đừng quên, điều đó cũng ảnh hưởng đến bất kỳ tài liệu mã riêng biệt nào mà bạn có thể có (API đã xuất bản), đây có thể là một vấn đề đặc biệt tốn kém nếu được in (bản cứng).
Tôi thấy rằng thường các thực thể "tiếp thị" không tương ứng chính xác với các thực thể nội bộ. Trong những trường hợp như vậy, sẽ có ý nghĩa hơn khi giới thiệu một thực thể ở một mức độ trừu tượng khác nhau, điều này làm cho thuật ngữ khác biệt trở thành một điểm cần thiết.
Ví dụ, chúng ta có một mô hình đại diện cho một hệ thống phân cấp. Mỗi cấp độ trong hệ thống phân cấp có một thuật ngữ được liên kết với nó dựa trên cách phân cấp được sử dụng để mô hình hóa các mối quan hệ trong thế giới thực, nhưng bên trong không có sự khác biệt trong hành vi từ cấp độ này sang cấp độ tiếp theo. Thuật ngữ về cơ bản chỉ là một tên cho cấp độ đó trong hệ thống phân cấp, vì vậy đối với một nút cụ thể trong cây, tên chỉ đơn giản mô tả nút đó là gì; nó không quy định bất kỳ hành vi cụ thể.
Ngoài ra, cây đa gốc, vì vậy có một số nút không có cha mẹ. Mặc dù về mặt khái niệm, một gốc tồn tại (về cơ bản nó sẽ đại diện cho vũ trụ), và bao gồm nó trong mô hình sẽ có nhiều thao tác đơn giản hơn nhiều, không có "thuật ngữ tiếp thị" cho nó.
Tất nhiên, các thành phần khác nhau trong hệ thống của chúng tôi sử dụng thuật ngữ khác nhau. Chúng được phát triển vào những thời điểm khác nhau bởi các đội khác nhau và chúng tôi không có quyền kiểm soát tất cả chúng. Trên thực tế, tại một số thời điểm, ai đó đã thêm hoặc xóa một cấp độ trong một thành phần và do đó, các cấp độ khác được thay đổi so với nhau. Ba cấp độ giống nhau được đại diện bởi A, B và C trong một thành phần, nhưng là B, C và D trong một cấp độ khác.
Bước lên một cách trừu tượng và chỉ đơn giản là mô hình hóa mọi thứ như một "nút" hoặc một cái gì đó chung chung làm cho các loại mô hình này dễ dàng hơn rất nhiều để lý luận. Mỗi nút biết "thuật ngữ tiếp thị" của nó là gì và loại đại diện cho một thuật ngữ tiếp thị cụ thể có thể biết thuật ngữ đó có nghĩa gì trong mỗi ngữ cảnh.