Khi nào mã Code kế thừa là khi nào? [đóng cửa]

Tất cả chúng ta đã làm điều đó, chúng ta đã gắn nhãn một số mã (thường là thứ chúng ta đã thừa kế) là "di sản"? Nhưng nó vẫn được sử dụng trong các hệ thống sản xuất - vậy nó có thực sự là di sản không? Và những gì làm cho nó di sản? Chúng ta có nên né tránh việc dán nhãn không chính đáng này vào mã hoạt động hoàn hảo; nơi ghi nhãn là một sự đồng thuận thuần túy cho phép chúng ta vượt qua những thứ mới và giữ cho quản lý cấp trên tốt đẹp và hạnh phúc?

Tóm tắt câu trả lời

Nhìn qua các câu trả lời tôi thấy bốn chủ đề chung. Đây là khi tôi thấy sự cố:

1. Bất kỳ mã nào đã được gửi: 6
2. Hệ thống chết: 2,5
3. Không có bài kiểm tra đơn vị: 2
4. Các nhà phát triển không ở quanh: 1,5

Bản thân tôi khá là một phần trong bản tóm tắt của Wikipedia :

Hệ thống cũ là một phương pháp cũ, công nghệ, hệ thống máy tính hoặc chương trình ứng dụng tiếp tục được sử dụng, điển hình là vì nó vẫn hoạt động cho nhu cầu của người dùng, ngay cả khi công nghệ mới hơn hoặc phương pháp thực hiện nhiệm vụ hiệu quả hơn hiện đã có.

Rất nhiều điều mà người khác đang mô tả trong câu trả lời của họ là lý do tại sao mã trở thành "di sản". Nhưng câu hỏi quan trọng chính là đây:

Nhưng nó vẫn được sử dụng trong các hệ thống sản xuất - vậy nó có thực sự là di sản không? Và những gì làm cho nó di sản?

Thực tế là nó vẫn được sử dụng trong sản xuất chính xác là những gì làm cho nó trở thành di sản . Nếu mã không hoạt động đúng hoặc không còn được sử dụng trong sản xuất, thì mã đó lần lượt là "bị hỏng" hoặc "đã nghỉ hưu". Di sản có nghĩa là nó vẫn đang được sử dụng và hoạt động tốt, nhưng kết hợp các thiết kế hoặc kỹ thuật không còn được sử dụng phổ biến.

Bất kỳ mã hoặc hệ thống nào mà bạn (a) muốn nâng cấp / cập nhật, nhưng không thể, hoặc (b) vẫn đang trong quá trình nâng cấp, là một hệ thống cũ. Điều này không có nghĩa là tái cấu trúc hoặc dọn dẹp mã chung, nó có nghĩa là những thay đổi quan trọng đối với thiết kế, có thể sử dụng một khung mới hoặc thậm chí là một nền tảng mới.

Có bất kỳ lý do nào khiến các hệ thống hoặc mã có thể trở thành di sản:

• Thiếu bảo trì thường xuyên hoặc thối phần mềm . Rõ ràng nếu ứng dụng không được duy trì thường xuyên, nó sẽ không theo kịp với những thay đổi lớn trong thế giới phần mềm. Điều này có thể là do bỏ bê đơn giản hoặc nó có thể là một lựa chọn có chủ ý dựa trên các ưu tiên kinh doanh hoặc các ràng buộc ngân sách.

• Thiếu kiểm tra. Một câu trả lời khác tham chiếu yêu cầu cường điệu của một tác giả nổi tiếng về bất kỳ mã nào không nằm trong các thử nghiệm là mã kế thừa. Đây thực sự không phải là một định nghĩa chính xác nhưng nó là một nguyên nhân gốc rễ có thể; không có các bài kiểm tra tốt (tự động hoặc thủ công), các nhà phát triển trở nên rụt rè và ngại thực hiện các thay đổi lớn vì họ lo lắng về việc phá vỡ một cái gì đó, do đó dẫn đến "sự thối phần mềm" ở trên.

• Rev-lock, một yếu tố thường bị bỏ qua, đặc biệt xảo quyệt trong các dự án sử dụng các thư viện hoặc khung công tác nguồn mở lớn (mặc dù tôi cũng đã thấy điều đó xảy ra với các công cụ thương mại). Thường sẽ có các tùy chỉnh chính được thực hiện cho khung / thư viện, khiến việc nâng cấp trở nên khó khăn hoặc tốn kém. Do đó, hệ thống trở thành di sản vì nó chạy trên nền tảng cũ hơn (và có thể không còn được hỗ trợ).

• Mã nguồn không còn khả dụng, có nghĩa là hệ thống chỉ có thể được thêm vào, không bao giờ thay đổi. Vì các hệ thống này phải được viết lại để nâng cấp - trái ngược với sửa đổi tăng dần / lặp đi lặp lại - nhiều công ty sẽ không bận tâm.

Bất cứ điều gì làm chậm hoặc dừng cập nhật cho cơ sở mã có thể dẫn đến cơ sở mã đó trở thành di sản.

Bây giờ câu hỏi riêng biệt, không có căn cứ nhưng ngụ ý là, có gì sai với mã kế thừa? Nó thường được sử dụng như một thuật ngữ mang tính miệt thị, do đó câu hỏi:

Chúng ta có nên né tránh việc dán nhãn không chính đáng này của mã hoạt động hoàn hảo?

Và câu trả lời là không, chúng ta không nên; việc ghi nhãn được bảo hành và bản thân thuật ngữ này bao hàm rõ ràng mã chức năng. Vấn đề không phải là có chức năng của nó, nhưng cách nó hoạt động.

Trong một số trường hợp không có gì sai với mã kế thừa. Đó không phải là một từ xấu. Mã / hệ thống kế thừa không phải là Evil. Họ vừa mới thu thập một ít bụi - đôi khi một chút, đôi khi rất nhiều.

Di sản trở nên lỗi thời khi hệ thống không còn có thể phục vụ (tất cả) nhu cầu của khách hàng. Nhãn đó là một cái mà chúng ta cần phải cẩn thận. Mặt khác, nó chỉ đơn giản là một phương trình chi phí / lợi ích; nếu chi phí nâng cấp sẽ thấp hơn chi phí lợi ích của nó (bao gồm cả chi phí bảo trì trong tương lai thấp hơn) thì hãy nâng cấp, nếu không, hãy để yên. Không cần phải thốt ra từ "di sản" trong cùng một giai điệu mà bạn thường dành cho "kiểm toán thuế". Đó là một tình huống hoàn toàn OK để được vào.

Thông thường nó có nghĩa là nó được viết bằng ngôn ngữ hoặc dựa trên một hệ thống mà bạn thường không phát triển mới.

Ví dụ: hầu hết các địa điểm không viết chương trình mới bằng Cobol. Tuy nhiên, một phần lớn hoạt động kinh doanh của họ có thể chạy trên các ứng dụng được viết bằng Cobol. Do đó, các ứng dụng đó, được gắn nhãn "Di sản".

Di sản có nghĩa là bất kỳ mã nào bạn muốn thay thế hơn là làm việc với. Với thái độ của hầu hết các lập trình viên đối với hầu hết các mã hiện có, thường bao gồm gần như mọi thứ trừ những gì bạn đang tích cực viết vào lúc này (và trên một dự án lớn nơi bạn phải viết mã cho một thiết kế bị đóng băng, ngay cả những gì bạn đang viết tại thời điểm có thể được bao gồm là tốt).

1. Việc nhấn mạnh "đúng hơn" nhằm truyền đạt mã kế thừa đó cũng có nghĩa là bạn bị mắc kẹt khi làm việc với nó mặc dù bạn không muốn. Tôi không chắc chắn sự nhấn mạnh là đủ mặc dù. Lý do cho điều đó có thể khác nhau. Một số thực sự chỉ là quá lớn và phức tạp để thay thế. Những người khác là giao diện cho các hệ thống khác. Vẫn còn những người khác bị thúc đẩy bởi chính trị và tính cách (ví dụ, mã là khủng khiếp, nhưng gian hàng bé thật tuyệt vời).
2. Một điểm khác tôi có thể không nhấn mạnh đầy đủ là trong khi chất lượng mã có thể là một yếu tố, thì hiếm khi (nếu có) là yếu tố duy nhất - và thường không phải là một yếu tố đặc biệt quan trọng.
3. Tôi nghĩ rằng những người đẩy các bài kiểm tra đơn vị là yếu tố quyết định duy nhất giống như anh chàng nhìn dưới ánh đèn đường để lấy chiếc khuyên tai mà vợ anh ta đánh rơi một khối. Ánh sáng có thể tốt hơn, nhưng bạn vẫn nhìn nhầm chỗ. Hãy suy nghĩ trước khi bạn uống Kool-Aid .
4. (Một hệ quả đến 3.) Dường như với tôi rằng một số người đang nói nhiều hơn về cách họ ước mọi thứ hơn là cách họ thực sự. Nếu John Conways ' Game of Life cho một của Apple IIc Ngoài ra không phải là di sản, đó là vì nó đủ nhỏ và đơn giản rằng đó là dễ dàng để tái thực hiện từ mặt đất lên. Thử nghiệm đơn vị hoàn hảo nhất từng được viết sẽ không thay đổi một iota duy nhất .

Điểm cuối cùng dẫn đến hai điểm khác tôi nghĩ thường đúng.

Đầu tiên, mã thường được giữ lại như là di sản, ngay cả khi nó thực sự không nên. Các nhà quản lý cấp cao hơn thường cho rằng việc triển khai lại một hệ thống sẽ có chi phí cao hơn hoặc nhiều hơn so với việc triển khai ban đầu, điều này hiếm khi đúng.

Thứ hai, bài kiểm tra đơn vị là một con dao hai lưỡi. Họ làm cho tất cả quá dễ dàng để nghĩ rằng những thay đổi cục bộ trong việc thực hiện là điều thực sự quan trọng. Để thực hiện những cải tiến đáng kể trong một hệ thống lớn hơn, bạn thường xuyên (thường là?) Phải thay đổi đủ thiết kế tổng thể mà nhiều (nếu không phải hầu hết) các bài kiểm tra đơn vị trở nên không liên quan. Thật không may, sự hiện diện của các bài kiểm tra đơn vị và thái độ mà họ tạo ra có thể khiến mọi việc trở nên quá dễ dàng để bỏ qua những thay đổi thực sự cần thiết.

Có lẽ một ví dụ về điều đó sẽ giúp: giả sử một chương trình có thư viện UI với thử nghiệm đơn vị tuyệt vời và một số chương trình sử dụng thư viện đó. Ai đó trong quản lý cấp trên trở nên tin rằng "kích hoạt web" là quan trọng (và, chỉ để tranh luận, hãy giả sử rằng trong trường hợp này, anh ta thực sự đúng về điều đó). Sau khi xem xét cẩn thận, các nhà quản lý cấp trung thấy rằng thử nghiệm đơn vị hiện tại của họ đủ để họ có thể thay đổi từ giao diện người dùng được hiển thị qua khả năng cửa sổ của hệ điều hành cục bộ sang được hiển thị từ xa thông qua HTML / CSS / AJAX, trong khi vẫn giữ lại tất cả xác thực đầu vào ban đầu.

Thật tuyệt phải không? Nó cho thấy thử nghiệm đơn vị hữu ích như thế nào. Chúng tôi đã trao đổi toàn bộ việc thực hiện toàn bộ giao diện người dùng, nhưng đảm bảo rằng giao diện, chức năng và chức năng vẫn gần như nhất quán và tất cả đầu vào của người dùng được xác thực để đảm bảo tính toàn vẹn dữ liệu. Kiểm tra đơn vị đã tiết kiệm trong ngày!

Hay không! Thư viện UI được kiểm tra cẩn thận, rất linh hoạt, được kiểm tra cẩn thận đã giúp mọi người tham gia thực tế rằng đối với chương trình này trên thị trường với người dùng, giao diện người dùng dựa trên web hoàn toàn không phù hợp. Điều thực sự cần thiết là một dịch vụ web có giao diện RESTful và hoàn toàn không có giao diện người dùng nào .

Bây giờ, chắc chắn rằng việc kiểm tra đơn vị không, tự nó loại bỏ khả năng hiểu thị trường của mọi người hoặc nhận ra điều đó thực sự cần thiết. Đồng thời, dòng cũ về búa và đinh hầu như nhảy vào tâm trí. Nó có thể còn tồi tệ hơn khi bạn không chỉ có búa, mà còn có nhiều kinh nghiệm với cây búa này, và biết nó thực sự là một cây búa chất lượng cao hoạt động cực kỳ tốt trong nhiều tình huống khác nhau. Thực tế là nó rất tốt trong rất nhiều thứ trong nhiều tình huống khiến chúng ta càng khó nhận ra khi nó hoàn toàn là công cụ sai cho công việc trong tay.

Mã di sản thường mồ côi theo một cách nào đó. Nhà phát triển chính, người duy nhất hiểu nó, đã bị xe buýt đâm, và các ghi chú của anh ta được viết bằng phương ngữ tiếng Ukraina bản địa, hiện là ngôn ngữ chết. Hoặc, xen kẽ, bất cứ điều gì được viết trong Visual Basic 6.0 .

Tôi làm việc trên mã kế thừa tất cả các thời gian. Tôi muốn nói các đặc điểm là:

• Nó không thể được mở rộng mà không cần nỗ lực lớn
• Nó không thể dễ dàng được chuyển sang phần cứng mới
• Nó là quá quan trọng kinh doanh để dễ dàng thay thế

Nếu nó không có những đặc điểm đó, thì có lẽ nó không phải là di sản. Nếu bạn không thích các kịch bản Perl của người tiền nhiệm , tôi đồng cảm, nhưng tôi không nghĩ đó là di sản. Gần đây tôi đã hiện đại hóa một số kịch bản Perl 15 năm tuổi được kết hợp với cơ sở dữ liệu Sybase đã lỗi thời . Đó là chiếc bánh so với việc tạo ra sự thay đổi dù là nhỏ nhất đối với hệ thống kế toán COBOL tuyệt vời của chúng tôi .

Trong cuốn sách của mình, Làm việc hiệu quả với Mã kế thừa , Michael Feathers định nghĩa mã kế thừa là mã không được bao gồm trong các bài kiểm tra đơn vị. Đó là một định nghĩa, mà tôi đồng ý với. Tôi cũng thấy mã kế thừa là cũ, nhưng vẫn có thể sử dụng được.

Về mặt kỹ thuật, di sản là bất kỳ mã nào đã sẵn sàng. Vì vậy, ngay khi nó được sản xuất, đó là di sản. Bởi vì đã có giá trị ở đó, bạn không thể vứt nó đi ... Bạn phải đối phó với nó.

Đó là "trước thời gian của bạn" nhưng "vẫn là vấn đề đau đầu của bạn" .

Mã kế thừa là mã chỉ còn lại trong cơ sở mã vì rất nhiều thứ sẽ ngừng hoạt động nếu không. Nói cách khác: đó là lý do duy nhất cho sự tương thích ngược.

Bạn muốn thay đổi nó hoặc thậm chí vứt nó đi, nhưng bạn không thể bởi vì bạn sẽ phá vỡ tất cả các mã dựa vào nó (có thể là mã mà bạn không thể điều chỉnh phù hợp). Do đó, bạn phải giữ nó (và đôi khi thậm chí duy trì nó), nhưng bạn muốn tất cả các mã mới không được viết chống lại nó.

Một ví dụ là các phương thức không dùng được API của thư viện. Chúng vẫn ở đó, vì vậy nếu bất cứ ai cập nhật thư viện vẫn có thể xây dựng dự án của mình, nhưng chúng được đánh dấu là không dùng nữa và trình biên dịch của bạn sẽ đưa ra cảnh báo cho bạn.

Một ví dụ khác là tất cả những thủ thuật kỳ lạ mà Microsoft thực hiện để làm cho các chương trình chạy được viết cho các phiên bản HĐH của họ, họ đã hoàn toàn không tán thành. Đỉnh cao của sự tồn tại này:

Lần đầu tiên tôi nghe về điều này từ một trong những nhà phát triển của trò chơi đình đám SimCity, người đã nói với tôi rằng có một lỗi nghiêm trọng trong ứng dụng của anh ấy: nó đã sử dụng bộ nhớ ngay sau khi giải phóng nó, một điều không nên xảy ra là hoạt động tốt trên DOS nhưng sẽ không hoạt động trong Windows khi bộ nhớ được giải phóng có khả năng bị chiếm đoạt bởi một ứng dụng đang chạy khác ngay lập tức. Những người thử nghiệm trong nhóm Windows đã trải qua nhiều ứng dụng phổ biến khác nhau, thử nghiệm chúng để đảm bảo chúng hoạt động tốt, nhưng SimCity vẫn bị sập. Họ đã báo cáo điều này với các nhà phát triển Windows, người đã phân tách SimCity, bước qua nó trong trình gỡ lỗi, tìm thấy lỗi và thêm mã đặc biệt để kiểm tra xem SimCity có đang chạy hay không, và nếu có, đã chạy bộ cấp phát bộ nhớ trong chế độ đặc biệt mà bạn vẫn có thể sử dụng bộ nhớ sau khi giải phóng nó.
- Tham gia phần mềm

Di sản đòi hỏi sự kế thừa. Mã kế thừa đơn giản là mã mà bạn kế thừa từ quá khứ. Đó là mã kế thừa ngay cả khi bạn đã tự viết nó trước đây!

Tất cả các cân nhắc khác về cơ bản xuất phát từ thực tế là bạn đã không viết nó cụ thể cho dự án hiện tại của bạn. Nó không hẳn là một điều xấu mỗi se.

Ý kiến ​​của tôi là những gì được coi là mã kế thừa phụ thuộc vào nhiều thứ và thẻ 'di sản' có thể là đặc thù của tổ chức.

Nếu phần cứng / HĐH mà nó chạy đã cũ và đã bị nhà cung cấp ngừng cung cấp - đình công 1.

Nếu việc sửa nó là nhiều việc hơn là viết lại, vì bất kỳ lý do gì vì

• nhà phát triển ban đầu đã biến mất
• chương trình được viết rất tệ
• nó có thể được thực hiện tốt hơn trên nền tảng mới hơn và vẫn xứng đáng với công ty

làm như vậy

• nguồn ban đầu không còn nữa và / hoặc phần còn thiếu

Tấn công 2.

Việc sáp nhập nhiều tổ chức thành một - Đột kích 3 - một bên có lẽ sẽ được gắn thẻ là di sản.

Có một lựa chọn tốt hơn, rẻ hơn được bán dưới dạng ứng dụng và / hoặc dịch vụ của bên thứ ba - đình công 4.

Là tổ chức giống như một bệnh viện hoặc khu học chánh, nơi tính nhất quán được đánh giá cao hơn công nghệ mới khi hoạt động hàng ngày? Sẽ mất nhiều thời gian hơn để một ứng dụng được coi là di sản so với cùng một ứng dụng trong một tổ chức thương mại / cạnh tranh.

Nếu công ty là một công ty phát triển nhỏ tiếp tục tăng cường / hỗ trợ ứng dụng để làm những gì khách hàng cần, thì đó có được coi là mã kế thừa hay chỉ là mã 'cũ'. Tôi biết một công ty tên là Mc2Ok - họ đã phát triển phần mềm trên những gì dường như là Windows 3.1 và vẫn tiếp tục mang nó đi về phía trước. Nó vẫn còn rất nhiều giao diện Windows 3.1, nhưng họ cũng đã thêm một giao diện web cho nó. Đó là một công ty phát triển hai người (theo phỏng đoán của tôi) và tôi nói rằng khi họ ngừng làm việc với nó, thì nó sẽ được coi là di sản và thời gian để di chuyển một hoặc hai năm sau khi sử dụng nó. Nhưng đó có thể là 10 năm hoặc hơn.

Đôi khi, khi quản lý thay đổi, nó có thể thay đổi trong các sóng có nhiều hiệu ứng nhỏ giọt ... Tùy thuộc vào đầu mối của quản lý mới, nó có thể khiến nhiều ứng dụng trở nên tốt hơn.

Mỗi tổ chức, tôi tin rằng, phải xác định "mã di sản" nghĩa là gì đối với họ. Tôi thường xem qua các trang rao vặt của tờ Thời báo Chủ nhật hàng tuần để xem những gì các tổ chức đang tìm kiếm. Đó từng là phong vũ biểu của tôi cho những gì không còn phù hợp (nghĩa là di sản). Chà, Thời báo Chủ nhật không còn phù hợp nữa :-) Và chúng ta có thể khái quát rằng COBOL là di sản, ASP Classic là di sản, v.v ... Nhưng tôi tin rằng mỗi tổ chức phải quyết định khi nào một ứng dụng được coi là di sản cho nó.

Mã là di sản khi một người sợ thay đổi nó, bởi vì anh ta có thể phá vỡ nó. Thậm chí còn đau đớn hơn khi toàn bộ hệ thống có thể bị đánh bại bởi những thay đổi đối với mã đó.

Đây là lý do tại sao tôi cũng đồng ý với định nghĩa của Michael Feathers. Mã có các bài kiểm tra đơn vị tốt có thể được thay đổi một cách không sợ hãi.

Tôi cũng nghĩ rằng mã kế thừa không liên quan gì đến tuổi của nó. Người ta có thể viết mã kế thừa từ đầu.