Là tốt hơn để sử dụng các thực tiễn xấu đã có từ trước, hoặc các thực tiễn tốt không phù hợp với mã cũ?

Tôi đã nghĩ về điều này bởi vì tôi đã cố gắng viết một phần mở rộng cho một phần mềm bên thứ 3 hiện có và cơ sở dữ liệu của họ bị phi chuẩn hóa khủng khiếp. Tôi cần sử dụng các bảng hiện có của họ và thêm một loạt các trường mới.

Tôi có tùy chọn tạo các bảng mới theo phong cách thiết kế của chúng (bao gồm hầu hết tất cả các propeties nằm trong một bảng lớn) hoặc tạo ra một tập hợp các bảng mới hoàn toàn và sử dụng một cái gì đó bổ sung như Triggers để đồng bộ hóa dữ liệu giữa cái mới và bàn cũ.

Cuối cùng tôi đã đi đến tùy chọn đầu tiên là sử dụng phong cách thiết kế kém hiện có, nhưng tôi bị bỏ lại với câu hỏi này: tốt hơn là nên sử dụng các thực tiễn xấu đã có từ trước, hoặc thực hiện các thực tiễn tốt không chơi tốt với mã hiện có? Có một số tình huống mà tôi nên chọn cái này hơn cái kia không?

LƯU Ý: Nhiều câu trả lời cho đến nay phải làm với việc từ từ tái cấu trúc mã xấu, tuy nhiên tôi không thể làm điều đó. Mã này không phải của chúng tôi và nó thường được nhà cung cấp cập nhật. Tôi chỉ có thể xây dựng lên nó.

Bạn nên chọn thiết kế tốt hơn nếu:

1. Bạn sẽ tiếp quản một phần lớn tiền mã hóa trong tương lai

2. Thiết kế tốt hơn không đắt hơn cho khách hàng về lâu dài. Chẳng hạn, tôi đã chứng kiến ​​"tái cấu trúc" nhiều tháng cho các dự án đã bị ngừng vào cuối năm nay.

Bạn nên chọn "cùng phong cách xấu" nếu:

1. Bạn chỉ đang giúp đỡ. Thật không thực tế khi nghĩ rằng bạn có thể đưa một nhóm hiện có và họ sẽ đạt tiêu chuẩn thiết kế cao hơn nếu bạn chỉ là một phần bổ sung bán thời gian cho dự án. Thiết kế tốt hơn là chủ quan và hầu như luôn luôn có một đường cong học tập. Nếu phần còn lại của nhóm không học được thiết kế đó thì dự án sẽ kết thúc với một kiểu hỗn độn và mã được thiết kế tốt hơn của bạn có thể kết thúc trong đống thứ mà không ai thay đổi vì họ không thể hiểu nó Trong ví dụ của bạn ở trên, điều gì xảy ra nếu có bản cập nhật cho phần mềm bên thứ ba?

2. Hy sinh thiết kế "tốt hơn" sẽ giúp bạn có được lợi thế kinh doanh hữu hình. Giống như thêm tính năng X một cách tệ hại sẽ giúp bạn có được một hợp đồng lớn, nhưng việc thiếu thời hạn sẽ khiến bạn không có gì. Đây là nơi xảy ra xung đột lịch sử giữa mgmt và đội ngũ kỹ thuật. Giống như cải tạo một ngôi nhà, ai đó phải quyết định khi nào sẽ trả tiền. Bạn có thể trả hết nợ ban đầu bằng cách sống không có điện hoặc hệ thống ống nước trong một năm. Hoặc bạn có thể trả gấp 3 lần với lợi ích có được những tiện ích đó.

Về lâu dài, tốt hơn là sử dụng các thực hành tốt. Nó sẽ tiết kiệm thời gian và công sức vì những thay đổi sẽ mất ít thời gian hơn để thực hiện.

Nếu có thể, hãy thực hiện các bước nhỏ để cấu trúc lại để thực hành tốt (ví dụ: trong SQL sẽ phá vỡ các bảng khử nhiễu thành bảng được chuẩn hóa và sử dụng các khung nhìn với tên bảng cũ).

Bạn sẽ lưu ý rằng tôi đã nói về lâu dài - tam giác "chất lượng, thời gian, tiền bạc" cũng áp dụng ở đây (tức là - chọn hai). Nếu bạn không có thời gian bạn có thể phải thực hiện các thực tiễn cũ, nhưng điều này có nghĩa là bạn đang thêm vào vấn đề và thiết kế của bạn cũng sẽ cần phải được sửa chữa.

Nếu bạn tiếp tục làm việc và thêm mã của thiết kế xấu, bạn sẽ không bao giờ kết thúc với một cơ sở mã sử dụng thiết kế tốt. Càng nhiều càng tốt để cố gắng sử dụng thiết kế tốt và tái cấu trúc để thiết kế tốt.

Vâng, tôi nghĩ rằng nó phụ thuộc rất nhiều vào từng trường hợp. Nếu hiệu suất và thiết kế cho phép nó, tốt hơn là sử dụng các thực hành tốt. Nhưng nếu, ví dụ, nếu bảng đó là một bảng truy cập cao, thì việc tạo ra một kích hoạt cho sự đồng bộ hóa có thể có tác động tiêu cực đến hiệu suất.

Bây giờ, khách hàng của bạn sẽ không thấy rằng bạn đã sử dụng một thiết kế tốt hơn, anh ta sẽ chỉ thấy rằng giải pháp của bạn làm cho hệ thống của anh ta chậm hơn. Loại quyết định này nên được đưa ra trong từng trường hợp, và bạn nên sử dụng kinh nghiệm và tiêu chí của mình để quyết định.

Tôi nghĩ rằng bạn có thể lựa chọn đúng.

Càng nhiều càng tốt, bạn nên cách ly mã ứng dụng của mình khỏi thiết kế dữ liệu kém.

Bạn đang cập nhật bảng của họ? Nếu không, sau đó tạo các khung nhìn SQL để trình bày các bảng đó theo cách thuận tiện cho ứng dụng của bạn. Các khung nhìn SQL tương đối dễ viết và dễ kiểm tra hơn nhiều so với mã ứng dụng.

Nếu bạn phải cập nhật các bảng kế thừa, hãy xem xét việc viết các thủ tục được lưu trữ để quản lý các bản cập nhật. Chúng phức tạp hơn một chút để viết, nhưng chúng có thể được kiểm tra ngay lập tức.

Để giữ mã cũ đồng bộ hóa khi bạn bình thường hóa cơ sở dữ liệu với các kích hoạt, đây là một giải pháp tốt nếu đó là tạm thời. Mục tiêu nên là thay đổi mã cũ, nhưng khi giao dịch với bên thứ ba, điều đó có thể không hiệu quả. Bạn sẽ phải theo kịp các thay đổi lược đồ của họ.

Chồng chất ngày càng nhiều tính năng vào mã xấu sẽ tạo ra các vấn đề liên tục. Công việc xung quanh trở thành chuẩn mực. Người dùng sẽ trở nên thất vọng vì những thay đổi sẽ mất quá nhiều thời gian và có thể giới thiệu các lỗi hoặc hạn chế khác. Ai muốn trở thành lập trình viên nói rằng chúng ta không thể làm điều đó thay vì chúng ta không nên làm điều đó?

Một số mã có thể được để lại một mình; chúng ta không phải lúc nào cũng có sự xa xỉ đó.

Bạn đang xử lý nợ kỹ thuật ở đây. Nói tóm lại, nợ kỹ thuật ngụ ý lãi suất, mà bạn phải trả theo thời gian, và đến một lúc nào đó, bạn phải hoàn trả nó.

Thời gian của Develloper tốn tiền, vì vậy nợ kỹ thuật có thể được nhìn thấy giống như nợ thật và tốn tiền thật.

Về cơ bản, bạn có hai giải pháp chính và nhiều giải pháp ở giữa. Bạn có thể quyết định rằng bạn không muốn hoàn trả khoản nợ đó ngay bây giờ và tiếp tục trả lãi. Rõ ràng, điều này sẽ có giá cao hơn trong thời gian dài, nhưng cho phép bạn có kết quả ngay bây giờ. Bạn cũng có thể chọn hoàn trả khoản nợ đó, vì vậy bạn sẽ không tiếp tục nữa miễn là bạn không hoàn trả khoản nợ đó, nhưng cuối cùng, bạn được miễn lãi.

Thông thường, bạn có thời hạn giao hàng và việc thiếu thời hạn sẽ gây mất lòng tin của khách hàng và cuối cùng bạn sẽ mất nó. Đây có thể là một lý do hợp lệ để đào sâu nợ kỹ thuật: bạn cho rằng những gì bạn đạt được với khách hàng xứng đáng với khoản nợ vượt trội của nợ kỹ thuật.

Bạn biết rằng cuối cùng, bạn phải áp dụng phương pháp mới, khác, bạn sẽ ngày càng nhiều nợ và cuối cùng bạn phá sản (bây giờ, khi mọi người quyết định bắt đầu lại từ đầu hoặc khi dự án thất bại nặng nề).

Bạn phải lập kế hoạch về cách bạn sẽ thay đổi cơ sở mã hiện tại và chuyển sang thực tiễn mới theo thời gian và phân biệt thay đổi từng chút một trên cơ sở hàng ngày. Tại một số điểm, khi tái cấu trúc sẽ dẫn đến những tổn thất khác, hãy xem xét tổn thất nào là tồi tệ hơn và đi theo hướng tốt nhất.

Chi phí không tái cấu trúc sẽ tăng theo thời gian (đây là lợi ích của nợ kỹ thuật). Vì vậy, điều này cuối cùng sẽ trở thành sự lựa chọn tốn kém nhất.

Hãy chắc chắn rằng ông chủ của bạn hiểu khái niệm về nợ kỹ thuật. Ngay cả khi đề phòng, bạn sẽ tạo ra nợ kỹ thuật. Tại một số điểm, tiền sẽ được sử dụng để hoàn trả nó. Khi bạn tạo ra nợ kỹ thuật trên mục đích, bạn phải có một lý do hợp lệ cho nó và xem khoản nợ đó là một khoản đầu tư (giống như nợ thực sự). Trong mọi trường hợp khác, chỉ cần KHÔNG NÊN nợ kỹ thuật.

Bạn có thể quan tâm đến các phương pháp để phát triển DB và triển khai các phát triển: http://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

Nhân tiện, đó là một nhiệm vụ khó khăn, thật may mắn. Nó đáng giá !

Đây là một vấn đề điển hình của: "Tôi có cần gặt hái những lợi ích của công việc của mình bây giờ hay sau này không?" và tôi không nghĩ có thể có một giải pháp chung cho câu trả lời đó. Chỉ có bạn biết tất cả các yếu tố (kỹ thuật và con người) liên quan đến một quyết định như vậy.

Tuy nhiên, vấn đề của bạn đặt ra một câu hỏi thú vị:

Là tái cấu trúc mã tự động tạo ra đủ tiến bộ để tính đồng nhất của mã phải được coi trọng hơn?

Cuối cùng, thiết kế xấu nên thay đổi hoặc chết. Hoặc nếu không, nó không phải là một thiết kế xấu. Câu hỏi thực sự ở đây là về chi phí tái cấu trúc. Có vẻ như rõ ràng từ câu hỏi của bạn rằng bạn (hoặc chủ nhân của bạn) không sẵn sàng trả giá ngay bây giờ, và trong tình trạng công nghệ hiện tại, dường như không bao giờ muốn.

Tuy nhiên, tự động tái cấu trúc mã đang thực hiện một số tiến bộ. Nếu trình biên dịch có thể tối ưu hóa nhị phân ngày hôm nay, ai sẽ nói rằng họ sẽ không tối ưu hóa mã vào ngày mai? Tại một số điểm, một số công cụ sẽ xuất hiện, cho phép các nhà phát triển và nhà thiết kế cấu trúc lại mã của họ rất dễ dàng, để thích ứng với các yêu cầu mới hơn. Xét cho cùng, xử lý mã kế thừa là một trong những thách thức lớn nhất hiện nay.

Nếu một công cụ như vậy từng tồn tại (tôi sẽ không ngạc nhiên rằng nó đã tồn tại), sẽ rất tốt nếu tính đến nó, khi đưa ra quyết định như vậy.

Thực hành tốt luôn kèn những người nghèo. Nếu cơ sở mã của bạn bị vấy mã sai cách, bạn không nên tự vận chuyển hàng hóa của mình theo cùng một cách, bạn nên viết mã đúng cách và sau đó cố gắng giáo dục mọi người khác theo cách chính xác.