Có bất kỳ hy vọng để viết mã tốt trên cơ sở dữ liệu được thiết kế khủng khiếp?


18

Đây là tình trạng khó khăn của tôi. Một trong một số chương trình tôi mới kế thừa được xây dựng với cơ sở dữ liệu khủng khiếp về phần phụ trợ. Những người sáng tạo đáng kính của nó dường như không đánh giá cao các khái niệm quan hệ. Một bảng cho mỗi và mọi khách hàng, được đặt tên là ID khách hàng duy nhất. Tám mươi ba lĩnh vực được đặt tên mật mã. Mã này là tất cả các thủ tục với hàng chục câu lệnh SQL nội tuyến được nối.

Vì chúng tôi không được cung cấp một ứng dụng phụ trợ quan trọng chạy cùng cơ sở dữ liệu, tôi đã được giao nhiệm vụ tái tạo nó từ đầu. Tôi là một nhà phát triển duy nhất, thậm chí không phải là trách nhiệm chính của tôi vì ít nhất một nửa thời gian của tôi bị chiếm dụng bởi các công cụ hoạt động. Có một thời hạn không thể tránh khỏi được đặt ra trong 30 ngày kể từ bây giờ.

Mặc dù thiếu kinh nghiệm, tôi chắc chắn rằng tôi có thể đã thiết kế cơ sở dữ liệu này và ứng dụng hiện có tốt hơn nhiều so với chúng, nhưng tôi không thực sự nghĩ rằng việc thay đổi cơ sở dữ liệu, điều chỉnh ứng dụng hiện có và chắc chắn rằng tôi đã không T phá vỡ mọi thứ trong khi cần tạo ứng dụng bổ sung này một cách nhanh chóng.

Vì vậy, giả sử tôi bị mắc kẹt với cơ sở dữ liệu khủng khiếp. Cần phải làm việc với một cấu trúc tồi tệ như vậy, liệu bất cứ điều gì tôi viết phù hợp với nó chỉ cần thêm vào đống nợ kỹ thuật nặng nề để được tạm gác cho đến khi một cái gì đó hoàn toàn phá vỡ hoặc chức năng mới là cần thiết? Làm thế nào tôi có thể tiếp cận tình huống này và nhận được một cái gì đó tốt từ nó bên cạnh một ứng dụng chức năng hy vọng?

chỉnh sửa: Trong trường hợp bất kỳ ai quan tâm, cuối cùng chúng tôi đã loại bỏ cơ sở dữ liệu khủng khiếp này và ứng dụng chạy trên nó. Chúng tôi đã thuê ngoài việc tạo ra ứng dụng phụ trợ (tôi không tham gia thiết lập ứng dụng này) để cuối cùng hai nhà thầu khác nhau, cả hai cuối cùng đều rơi vào chúng tôi, không làm được gì cả. Cuối cùng tôi đã phải thực hiện một bản sửa lỗi khủng khiếp, một phần chức năng của một bản sửa lỗi trong ba ngày vẫn còn được sử dụng cho đến ngày hôm nay.


2
Chỉ cần nghĩ làm thế nào bạn sẽ mã hóa thư viện trong trường hợp đặc biệt "2 + 2" không trả về 4. Điều đó không dễ dàng.

8
Vì vậy, điều tôi đang nghe tất cả là bạn có 30 ngày để tìm một công việc khác. thử sự nghiệp.stackoverflow.com ;-)
Steven A. Lowe


@gnat: Thậm chí không gần.
Robert Harvey

Câu trả lời:


27

Có hy vọng, nhưng đó là một trận chiến khó khăn, đặc biệt là nếu không ai nhận ra thiết kế cơ sở dữ liệu là khủng khiếp. Bạn có thể cố gắng trừu tượng hóa sự khó chịu bằng các lớp trừu tượng, nhưng rất có thể nó sẽ không đáng để chiến đấu.

Lời khuyên của tôi sẽ là tạo ra đủ trừu tượng trên cơ sở dữ liệu mà bản thân ứng dụng sạch sẽ và được thiết kế đúng; theo cách đó nếu bạn có thể sửa cơ sở dữ liệu, ứng dụng sẽ không bị ảnh hưởng vì nó không quan tâm đến cách cơ sở dữ liệu được thiết kế.

Đây là cách tiếp cận tôi thường sử dụng khi xử lý cơ sở dữ liệu tại chỗ và thường xuyên hơn là không được thiết kế với suy nghĩ không. Một vài ứng dụng lựa chọn của các mẫu Kho lưu trữ hoặc Cổng, với một số lớp dịch vụ để nói chuyện với cổng / kho lưu trữ, sẽ giúp cách ly thiết kế kém.


1
+1 Về cơ bản, tôi đã nói điều tương tự trong câu trả lời của mình trước khi đọc đầy đủ của bạn tuy nhiên tôi không thấy cách nào để xóa câu trả lời của mình vì câu trả lời của bạn bao gồm cùng một tài liệu.
Ominus

Như tôi đã nhận xét cho những người khác đưa ra đề xuất này, đó là một gợi ý tốt nhưng rất có khả năng là nếu thiết kế cơ sở dữ liệu là tào lao thì mã ứng dụng cũng có khả năng là tào lao. Tôi không thấy vấn đề sẽ gặp rắc rối nếu mã ứng dụng cũng được tái cấu trúc.
maple_shaft

3
@maple_shaft Đồng ý nhưng OP nói rằng anh ta được yêu cầu tạo, từ đầu, một ứng dụng mới sẽ tương tác với cơ sở dữ liệu. Trong trường hợp như vậy, thật hợp lý khi tạo ứng dụng mới đúng cách.
Wayne Molina

1
@maple_shaft, phần crap duy nhất của ứng dụng sẽ là phần tương tác với cơ sở dữ liệu crap. Đó là điểm của kiến ​​trúc N-Tier và SOC.
StuperUser

1
@maple_shaft Mục tiêu sẽ là đưa cơ sở dữ liệu vào một "hộp đen" các loại và cung cấp cho ứng dụng một giao diện lý tưởng hơn và không nhất thiết phải đại diện cho thiết kế cơ sở dữ liệu.
Michael Dean

10

Xây dựng một lớp giao diện xử lý tất cả các công cụ DB sau đó viết ứng dụng của bạn để giao diện với nó. Trong trường hợp cơ sở dữ liệu bị "sửa lỗi", bạn chỉ cần thay thế / cập nhật "giao diện" của mình. Cách tiếp cận này đã giúp tôi tiết kiệm rất nhiều thời gian khi xử lý một cơ sở dữ liệu xấu hoặc cơ sở dữ liệu đang nuôi các ứng dụng khác và không thể bị rối tung.


Làm thế nào bạn có thể xóa câu trả lời của riêng bạn hoặc đây không phải là một khả năng?
Ominus

Bạn có thể xóa câu trả lời của riêng bạn. Bạn tiếp tục nhìn thấy chúng với một nền màu và nó sẽ nói một cái gì đó như "bị xóa bởi chủ sở hữu". Khác với bạn, chỉ những người có quyền hạn của người điều hành mới nhìn thấy nó.
Marjan Venema

@Ominus: Điều đó là có thể, nhưng tại sao bạn lại muốn? Bạn đã có 3 lần nâng cấp!
Thất vọngWithFormsDesigner

1
@Marjan: Người điều hành và bất kỳ ai có> 10K đại diện.
Jerry Coffin

1
Tại sao bạn muốn xóa câu trả lời này? Tôi nghĩ đó là một giải pháp tuyệt vời.
Jim G.

6

Ouch ... Bạn đã thừa hưởng một mớ hỗn độn ác mộng, bạn có 30 ngày để làm cho nó có thể sử dụng được cho tổ chức của bạn, và một nửa ngày của bạn được thực hiện với các nhiệm vụ hoạt động?

Tôi chắc chắn bạn có thể tái cấu trúc nhưng chắc chắn không phải trong khoảng thời gian đó.

Để trả lời câu hỏi của bạn, tôi không nghĩ rằng bạn thực sự có thể viết mã tốt trên một thiết kế như vậy. Các khoản nợ kỹ thuật là quá nhiều rồi. Nếu tôi là bạn, tôi sẽ hack các tính năng mà tôi có thể, và nhấn để tái cấu trúc hoàn chỉnh vào một ngày sau đó khi bạn có nhiều thời gian hơn và mọi người trong nhóm của bạn sẽ giải quyết nó tốt hơn.

Chỉ cần cẩn thận đẩy cho tái cấu trúc. Đôi khi, một cấp cao hơn sẽ đưa ra quyết định mua mã nguồn sản phẩm và quyền sở hữu và họ không muốn nghĩ rằng họ hoàn toàn lãng phí tiền của mình vào rác. Đây là trường hợp đối với tôi tại một công việc tôi có. Thật không may, các nhà quản lý đưa ra quyết định mua phần mềm như thế này và họ không bao giờ tham gia kỹ thuật để đánh giá những gì họ đang mua và xem liệu nó có thể duy trì được không và có một khoản nợ kỹ thuật lớn. Trong trường hợp này, quyết định tồi tệ là một quyết định chính trị và thúc đẩy tái cấu trúc có thể khiến công việc của bạn gặp nguy hiểm.


Mặc dù mọi người không quen thuộc với lập trình, tôi đã nói rõ chất lượng của cơ sở mã này sẽ ảnh hưởng đến khả năng bảo trì như thế nào. Họ ở trên tàu với một nỗ lực tái cấu trúc lớn để có được mọi thứ ở trạng thái phù hợp hơn nên tôi không có nguy cơ gây nguy hiểm cho công việc của mình, nhưng tôi không nghĩ rằng nó sẽ xảy ra trong tháng này.
John Straka

3
Đôi khi thực hiện hack thành công như trải nghiệm đầu tiên của bạn với dự án có thể mang lại cho bạn uy tín để tái cấu trúc trong các dự án sau này cho cùng một ứng dụng. Đáng buồn nhưng là sự thật. Đầu tiên họ phải tin rằng bạn biết bạn đang làm gì trước khi họ xem xét bất kỳ thay đổi căn bản nào. Các poster là ở một điểm khó khăn để chắc chắn.
HLGEM

1
@ John, thật tốt khi họ NHẬN ĐƯỢC nhu cầu tái cấu trúc. Đó là một dấu hiệu của quản lý dài hạn tốt và là bước đầu tiên để thực sự tái cấu trúc.
maple_shaft

3
+1 cho một câu trả lời tuyệt vời, thực tế. Bạn có một tháng, nhưng thực sự chỉ có nửa tháng vì bạn làm việc nửa giờ với các hoạt động. Đó là 11-15 ngày tùy thuộc vào việc bạn có nghỉ cuối tuần hay không. Tôi ghét nói điều đó, nhưng tôi đồng ý rằng cách tốt nhất của bạn là kết hợp một cái gì đó hoạt động càng sớm càng tốt và ghi chú về cách cải thiện hoặc viết lại nó sau này, đặc biệt là khi quản lý của bạn đã sẵn sàng với việc tái cấu trúc.
Bob Murphy

6

Cơ sở dữ liệu có thể được cấu trúc lại giống như các mã khác. Khắc phục phần bị ảnh hưởng bởi mã bạn cần viết và viết bài kiểm tra để đảm bảo không có gì khác bị hỏng. Làm từng chút một tại một thời điểm giống như bất kỳ cấu trúc lại nào khác. Có một cuốn sách hay về tái cấu trúc cơ sở dữ liệu có thể giúp bạn bắt đầu dọn dẹp mớ hỗn độn. http://www.amazon.com/Refactoring-Database-Evolutionary-apersback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

Cũng có những người khác, nhưng cá nhân tôi đã đọc và làm việc với các kỹ thuật trong phần này.

Và đừng quên bạn có thể cấu trúc lại cách bạn cần truy vấn cơ sở dữ liệu bằng cách tạo các khung nhìn để thực hiện công việc chuyển đổi khó chịu cho bạn thành một câu hỏi dễ truy vấn hơn.


Đây là tất cả tốt và tốt nhưng tôi có nghi ngờ mạnh mẽ rằng nếu thiết kế cơ sở dữ liệu là một mớ hỗn độn thì mã ứng dụng có lẽ cũng vô giá trị.
maple_shaft

@maple_shaft, đó có thể là mặc dù đó là kinh nghiệm của tôi mà ngay cả các nhà phát triển ứng dụng giỏi cũng thiết kế cơ sở dữ liệu khủng khiếp. Dù bằng cách nào, chỉ việc tái cấu trúc dần dần sẽ khắc phục được mớ hỗn độn, anh ta không thể thay thế nó hoàn toàn mặc dù tôi chắc chắn rằng anh ta sẽ thích.
HLGEM

+1 @HLGEM, Đây là những điểm tốt. Lời khuyên của bạn là âm thanh nếu mã ứng dụng được thiết kế tốt. Tái cấu trúc trong các phần có lẽ là cách tốt nhất để đi nhưng trong toàn bộ sự nghiệp của tôi, tôi chưa bao giờ thấy công việc đó thành công. Nó có thể là do quản lý dự án kém, tuy nhiên, không phải vì đó là một ý tưởng không có căn cứ.
maple_shaft

5

Để có được tiếng vang lớn nhất cho bạn, hãy tạo các chế độ xem có thể cập nhật để khôi phục một số "quan hệ" và để cung cấp các tên cột có ý nghĩa hơn.


Đây sẽ là một khởi đầu tốt. Nếu cơ sở dữ liệu không được chuẩn hóa, thì tôi sẽ thêm các trình kích hoạt hoặc các thủ tục được lưu trữ để cách ly ứng dụng khỏi sự không chuẩn hóa.
kevin cline

4

Một khả năng có thể là thiết lập cơ sở dữ liệu thứ hai có cấu trúc (ít nhất là gần hơn) theo cách bạn muốn và thiết lập sao chép giữa hai cơ sở dữ liệu. Sau đó, bạn có thể viết mã của mình dựa vào cơ sở dữ liệu mới và vẫn giữ nguyên cơ sở dữ liệu (và ứng dụng) hiện có, để được xử lý khi bạn có nhiều thời gian hơn.

Thật ra, nó vẫn mở ra rất nhiều câu hỏi liệu bạn có thể làm điều đó trong ~ 15 ngày làm việc hay không. Cụ thể, có thể phụ thuộc vào việc bạn cần sao chép hai chiều (nghĩa là ứng dụng mới của bạn sẽ thực sự cập nhật dữ liệu) hay chỉ một cách (ứng dụng mới của bạn chỉ cho phép mọi người xem dữ liệu). Trường hợp thứ hai là (tất nhiên) dễ dàng hơn để giải quyết.

Nếu bạn cần nhân rộng hai chiều, rất có thể là nó không đủ thời gian để thực hiện công việc. Cụ thể, sao chép hai chiều liên quan đến việc chuyển đổi cấu trúc về cơ bản không bao giờ là chuyện nhỏ và các công cụ có sẵn thường hỗ trợ nó khá kém (ví dụ: phải viết tay tất cả SQL cho tất cả các biến đổi dữ liệu theo cả hai hướng).

Nếu bạn chỉ cần một chiều, điều đó đúng ở điểm có thể có thể xảy ra. Nó cũng sẽ phụ thuộc khá nhiều vào việc bạn có được phép chi bất kỳ khoản tiền nào hay không - có khá nhiều ứng dụng lưu trữ dữ liệu được dành cho chính xác loại công việc này có thể giúp thực hiện nhanh hơn và dễ dàng hơn một chút để quản lý - nhưng hầu hết trong số họ không rẻ.


+1, Đây có thể là một ý tưởng tốt miễn là tất cả mã truy cập dữ liệu ứng dụng được tách biệt đúng cách với các lớp khác và mã truy cập dữ liệu có thể được cấu trúc lại để hoạt động với lược đồ mới
maple_shaft
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.