Làm thế nào để chia sẻ một cơ sở mã trong số hơn 10 dự án và giảm thiểu nỗi đau?


8

Tôi có một số ứng dụng chia sẻ cùng một dữ liệu trong cùng một cơ sở dữ liệu. Để thử và giảm thiểu sự dư thừa mã, Lớp truy cập dữ liệu là một dự án được chia sẻ. Điều này ngăn mỗi dự án cần mã hóa lại quyền truy cập dữ liệu của riêng nó, nhưng điều này cũng tạo ra một điểm đau lớn. Khi một nhóm cần cập nhật lớp dữ liệu, tất cả các nhóm khác cần kéo vào và kiểm tra các thay đổi để đảm bảo rằng họ không phá vỡ bất cứ điều gì và đây là một quá trình chậm và đau đớn.

Tôi đã nghĩ về ý tưởng xóa lớp dữ liệu được chia sẻ và chỉ cần mỗi nhóm quản lý lớp dữ liệu của riêng họ nhưng vấn đề là tất cả các đội vẫn truy cập vào cùng một cơ sở dữ liệu, vì vậy nếu có bảng thay đổi, điểm đau vẫn còn đó bởi vì mỗi đội cần cập nhật mã liên quan của họ.

Vì vậy, câu hỏi của tôi là, làm thế nào tôi có thể thiết kế dữ liệu và lớp truy cập của chúng tôi để nhiều dự án được điều khiển khỏi cùng một nguồn dữ liệu và giảm thiểu sự đau đớn khi thực hiện thay đổi đối với cơ sở dữ liệu hoặc lớp truy cập?


Bạn đã thử phiên bản chưa? Khi Đội số 1 cập nhật mã, họ sẽ tăng số phiên bản từ X lên X + 1. Đội # 2 vẫn có thể sử dụng phiên bản X mà không phải lo lắng. Họ có thể nâng cấp lên X + 1 tùy ý.
2023861

Câu trả lời:


5

Lớp dữ liệu được chia sẻ trông khá tốt. Giải pháp để giảm thiểu cơn đau là:

  1. tạo các mô-đun thử nghiệm ném ngoại lệ (như: mọi thứ ngừng hoạt động không chỉ là một tin nhắn) khi một số thử nghiệm thất bại.
  2. Đặt TẤT CẢ các mô-đun kiểm tra trong thư mục chia sẻ. Ý tôi là tất cả các mô-đun thử nghiệm của hơn 10 dự án phải nằm trong cùng một thư mục (Hoặc một đường dẫn dễ hiểu).
  3. Nếu một lập trình viên muốn chỉnh sửa lớp quan trọng, anh ta phải thực hiện tất cả các thử nghiệm trong thư mục đó, nếu một cái gì đó không hoạt động, anh ta không thể cam kết mã.

Theo cách này, nếu tôi tạo một đoạn mã, tôi có động lực để viết một lớp kiểm tra tốt, giống như một lớp kiểm tra thực sự bởi vì nếu lớp kiểm tra của tôi phát nổ với một số sửa đổi có nghĩa là những sửa đổi đó sẽ phá vỡ mã của tôi. Vì vậy, mọi lập trình viên buộc phải viết bài kiểm tra tốt (nếu tôi không mã của mình thỉnh thoảng có thể bị hỏng). Thực hiện tất cả các thử nghiệm của dự án mà không có lỗi có nghĩa là: "ok bạn có thể cam kết", khi có sự cố xảy ra, điều đó có nghĩa là "không, những sửa đổi đó sẽ phá vỡ hệ thống ở một số dòng x"

Đây là một điểm tốt bởi vì các công cụ kiểm tra quá thường bị bỏ lại trong một dự án ... tất nhiên việc duy trì mã kiểm tra đòi hỏi một số nỗ lực bổ sung.


4

Tôi đã trải nghiệm vấn đề này đầu tiên. Thật khó khăn và tôi chỉ tích hợp năm ứng dụng. Tôi có thể cung cấp một vài lời khuyên:

  1. Phân tách cơ sở dữ liệu bằng cách sử dụng các dịch vụ RESTful cho càng nhiều thứ càng tốt. Điều này cho phép bạn dễ dàng tạo nhiều phiên bản giao diện nếu cần và nó giúp việc di chuyển cơ sở dữ liệu dễ dàng hơn nhiều.
  2. Nếu quyền truy cập cơ sở dữ liệu cho một số ứng dụng ở chế độ chỉ đọc, hãy tạo chế độ xem cơ sở dữ liệu của dữ liệu cần thiết. Nếu bạn phải thực hiện một quy trình hàng loạt để tính toán các giá trị, hãy thực hiện nó trong chế độ xem cụ thể hóa.
  3. Hãy suy nghĩ cẩn thận về thiết kế. Bất kỳ thay đổi cơ sở dữ liệu rất có thể sẽ phá vỡ các ứng dụng khác. Có phải tất cả các ứng dụng thực sự cần truy cập cơ sở dữ liệu đầy đủ? Nếu không, hãy phá vỡ chúng để sử dụng một dịch vụ. Tách bất kỳ cơ sở dữ liệu truy cập từ bất kỳ logic.

2
Đúng. Tách các ứng dụng khỏi dữ liệu họ truy cập. Không có vấn đề gì trong CS không thể giải quyết bằng cách thêm một lớp chuyển hướng (trừu tượng hóa).
RubberDuck

2

Câu trả lời ngắn gọn là bạn cần đặt RẤT NHIỀU thời gian vào mã được chia sẻ của mình để làm cho nó mạnh mẽ / vững chắc / đáng tin cậy nhất có thể.

Khi bạn khám phá, bạn không thể thường xuyên thay đổi mã thư viện của mình.

Có thể cần phải chia lớp dữ liệu của bạn thành hai phần - phần cấp thấp thực hiện những điều rất đơn giản nhưng không bao giờ thay đổi (nghĩa là mã được chia sẻ) và phần cấp cao có thể phải là duy nhất cho mỗi ứng dụng.

Đối với phần chia sẻ cấp thấp, bạn cần suy nghĩ như một nhà phát triển thư viện & không phải là nhà phát triển ứng dụng. Điều này có nghĩa là rất nhiều bài kiểm tra đơn vị, giao diện ứng dụng được xác định rất rõ ràng và kỹ lưỡng, tài liệu chính xác, đầy đủ và hữu ích và rất nhiều mã phòng thủ - tất cả các đầu vào đều không hợp lệ cho đến khi được chứng minh khác đi.

Mã được chia sẻ phải được viết để phục vụ nhu cầu của các ứng dụng bạn có ngày hôm nay sẽ sử dụng mã, nhưng bạn sẽ muốn dành thêm thời gian để xem xét mã này sẽ hoạt động như thế nào cho hàng tá ứng dụng tiếp theo chưa có đề xuất chưa. Nói cách khác, mã chia sẻ giải quyết vấn đề chung là phơi bày dữ liệu theo cách có ý nghĩa với người tiêu dùng. Nếu được thực hiện tốt, người tiêu dùng mới có thể sử dụng thư viện này mà không thay đổi.


Vì vậy, giả sử chúng ta có một lớp truy cập được chia sẻ rất mạnh mẽ, một số chiến lược để giảm bớt nỗi đau từ những thay đổi khi chúng xảy ra là gì? Hay đó chỉ là một viên đạn chúng ta phải cắn?
tt9

1
@ user2313300 Thực hiện theo nguyên tắc Mở / Đóng. Điều này sẽ làm giảm các vấn đề khi mở rộng thư viện. Cần loại bỏ khả năng hoặc sửa đổi giao diện.
BillThor
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.