Có trường hợp nghiên cứu thực tế nào về việc viết lại tỷ lệ thành công / thất bại của phần mềm không?


36

Tôi đã thấy nhiều bài viết về việc viết lại các ứng dụng là xấu, trải nghiệm của mọi người về nó ở đây trên Lập trình viên và một bài viết tôi đã sẵn sàng bởi Joel Spolsky về chủ đề này, nhưng không có bằng chứng cứng hoặc nghiên cứu trường hợp nào. Khác với hai ví dụ Joel đã đưa ra và một số bài đăng khác ở đây, bạn sẽ làm gì với một cơ sở mã xấu và làm thế nào để bạn quyết định làm gì với nó dựa trên các nghiên cứu thực tế?

Đối với trường hợp cụ thể, có hai khách hàng mà tôi biết rằng cả hai đều có mã cũ. Họ tiếp tục đi khập khiễng vì điều đó vì một trong số họ phát hiện ra, việc viết lại là một thảm họa, nó rất tốn kém và không thực sự hiệu quả để cải thiện mã nhiều. Khách hàng đó có một số logic kinh doanh rất phức tạp khi các nhà văn nhanh chóng phát hiện ra.

Trong cả hai trường hợp, đây là những ứng dụng quan trọng mang lại nhiều doanh thu cho công ty. Người đã cố gắng viết lại cảm thấy rằng họ sẽ va vào một bức tường gạch nếu phần mềm cũ không được nâng cấp vào một lúc nào đó trong tương lai. Đối với tôi, loại rủi ro đó đảm bảo nghiên cứu và phân tích để đảm bảo một con đường thành công.

Đã có trường hợp nghiên cứu thực tế đã điều tra này? Tôi sẽ không muốn thử viết lại mà không biết một số thực tiễn tốt nhất, cạm bẫy và thành công dựa trên các nghiên cứu thực tế.

Hậu quả: được thôi, sau khi tìm kiếm nhiều hơn, tôi đã tìm thấy ba bài viết thú vị về nghiên cứu trường hợp:

  1. Viết lại hoặc sử dụng lại . Họ đã làm một nghiên cứu về ứng dụng Cobol được chuyển đổi sang Java.
  2. Khác là về Tái sử dụng phần mềm: Kinh nghiệm và nhận thức của nhà phát triển .
  3. Tái sử dụng hoặc viết lại Một nghiên cứu khác về chi phí bảo trì so với viết lại.

Gần đây tôi đã tìm thấy một bài viết khác về chủ đề: The Great Rewrite . Ở đó tác giả dường như đánh vào một số vấn đề lớn. Cùng với điều này là ý tưởng tạo mẫu bằng cách sử dụng ngăn xếp công nghệ mới được đề xuất và đo xem các nhà phát triển đã nhặt nó nhanh như thế nào. Đây là tất cả như một khúc dạo đầu để viết lại, mà tôi nghĩ là một ý tưởng tuyệt vời!


10
Tôi không biết về nghiên cứu trường hợp, nhưng tôi nghĩ rằng câu trả lời tiêu chuẩn cho cách tiếp cận có lẽ là "thêm các bài kiểm tra đơn vị và cấu trúc lại."
Jerry Coffin

2
Nó tấn công tôi như là cách tiếp cận rủi ro thấp nhất có thể. Tất nhiên, tôi không biết đủ chi tiết để chắc chắn rằng đó là cách tiếp cận đúng, nhưng dựa trên những gì tôi biết cho đến nay, tôi không biết nhiều về điều đó đặc biệt có khả năng tốt hơn rất nhiều.
Jerry Coffin

2
Nếu họ thực hiện các bài kiểm tra đơn vị (đúng - thực sự nắm bắt được tất cả các yêu cầu), thật khó để đưa ra cách tái cấu trúc để dẫn đến một thảm họa thực sự. Về điều tồi tệ nhất có thể xảy ra là bạn không đạt được nhiều tiến bộ nhanh như bạn muốn. Đồng thời, nếu cơ sở mã của họ có hình dạng xấu như câu hỏi ngụ ý, rất có thể sẽ cần nỗ lực nghiêm túc để cho phép tiến bộ, bất kể tuyến đường đã đi.
Jerry Coffin

2
Vì vậy, nhiều dự án là riêng tư, thật khó để một nghiên cứu có một bộ mẫu thực sự tốt. Bạn có thể bị giới hạn trong các bằng chứng giai thoại.
mike30

1
Vấn đề không phải là viết lại toàn bộ cơ sở mã. Vấn đề là muốn viết lại toàn bộ thứ chết tiệt đó cùng một lúc và sau đó nhấn một nút và làm giảm tất cả những cơn đau đầu của bạn đã biến mất. Trong hầu hết các trường hợp, bạn không thể dành thời gian cho đối thủ của mình để thêm các tính năng mới, các lỗi còn tồn tại và khách hàng sẽ bị hủy bỏ. Tuy nhiên, phần lớn thảm họa hoàn toàn là một codebase, nên có thể xác định các điểm đau và mô đun hóa các phần đúng của spaghetti khi bạn đi.
Erik Reppen

Câu trả lời:


6

Tôi không thể tin vào những bình luận tuyệt vời này, nhưng chúng không bao giờ được đưa ra câu trả lời của tác giả ban đầu, vì vậy tôi đánh dấu nó là wiki cộng đồng.

Tôi không biết về nghiên cứu trường hợp, nhưng tôi nghĩ rằng câu trả lời tiêu chuẩn cho cách tiếp cận có lẽ là "thêm các bài kiểm tra đơn vị và cấu trúc lại."

Nó tấn công tôi như là cách tiếp cận rủi ro thấp nhất có thể. Tất nhiên, tôi không biết đủ chi tiết để chắc chắn rằng đó là cách tiếp cận phù hợp, nhưng dựa trên những gì tôi biết cho đến nay, tôi không biết nhiều về điều đó đặc biệt có khả năng tốt hơn rất nhiều.

Nếu họ thực hiện các bài kiểm tra đơn vị (đúng - thực sự nắm bắt được tất cả các yêu cầu), thật khó để đưa ra cách tái cấu trúc để dẫn đến một thảm họa thực sự. Về điều tồi tệ nhất có thể xảy ra là bạn không đạt được nhiều tiến bộ nhanh như bạn muốn. Đồng thời, nếu cơ sở mã của họ có hình dạng xấu như câu hỏi ngụ ý, rất có thể sẽ cần nỗ lực nghiêm túc để cho phép tiến bộ, bất kể tuyến đường đã đi.

Tôi cho rằng các dự án viết lại không khác biệt đáng kể về tỷ lệ thất bại so với các dự án nói chung và sẽ tham khảo báo cáo CHAOS mới nhất để biết thông tin tốt nhất.


8
mã cần được viết lại thường được viết theo cách không thể kiểm chứng được (khớp nối chặt chẽ, các lớp làm quá nhiều, v.v.) khiến bạn rơi vào tình trạng kỳ quặc cần phải cấu trúc lại trước khi bạn có thể kiểm tra đơn vị.
Kevin

Vâng, đó là lý do tại sao nhận xét về cuốn sách: "Làm việc hiệu quả với Bộ luật kế thừa" là rất phù hợp. Tôi đã phải làm một cái gì đó như thế này năm ngoái và thực hiện một cách tiếp cận có phương pháp hơn như những gì được giải thích trong cuốn sách đó sẽ giúp tôi tiết kiệm rất nhiều thời gian và để lại một tài liệu / thử nghiệm có ích. Tôi cảm thấy chỉ cần làm cho nó hoạt động là tuyệt vời, nhưng không đủ. Các đối tượng có quá nhiều phụ thuộc, tôi cảm thấy thử nghiệm của mình có thể có phạm vi bảo hiểm tốt hơn.

6

Tôi đã lướt qua Làm việc hiệu quả với Bộ luật kế thừa của Michael Feathers một thời gian trước và thấy nó cung cấp một số hiểu biết tốt về thực tiễn trong việc duy trì mã kế thừa trong thế giới thực, bao gồm cả kiểm tra viết (ngay cả khi bạn không biết mã này để làm gì) và của tái cấu trúc khóa học / viết lại. Nó hơi cũ nhưng được đánh giá cao trên Amazon.


3

Phát biểu từ kinh nghiệm và sống trong một công ty có kiến ​​trúc doanh nghiệp kém ngay từ đầu tôi có thể thành thật nói rằng vấn đề lớn nhất là phát triển sự hiểu biết toàn diện.

Ý tưởng này là một hệ thống có thể được chia thành từng mảnh và được hiểu riêng lẻ là thiếu sót. Tại một số thời điểm, một cá nhân, hoặc một vài cá nhân phải có khả năng hình thành toàn bộ vấn đề. Nếu vấn đề đó là một loạt các vấn đề kinh doanh và các công nghệ thúc đẩy chúng; có thể mất một người trong công ty vài năm để hiểu tất cả các hệ thống đến mức thay thế chúng mà không gặp thảm họa hoặc yêu cầu bị bỏ lỡ là có thể. Đây chắc chắn là trường hợp của công ty tôi khi tôi đảm nhận chức Giám đốc Công nghệ. Nếu thực tế tôi không phải là một lập trình viên thì tôi đã không thể hiểu từ từ tất cả các chi tiết của kiến ​​trúc kém, được kết hợp chặt chẽ, kiến ​​trúc ràng buộc chặt chẽ và tích hợp công nghệ. Nếu nhỏ ẩn, chi tiết không có giấy tờ như"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" bị bỏ qua kết quả có thể là thảm họa, và cách duy nhất để biết điều này là từ từ khám phá tất cả.

Nếu ai đó được yêu cầu thay thế động cơ trên máy bay khi đang bay, hoặc đối mặt với cái chết nhất định - với số lượng công cụ và tài nguyên phù hợp mà cá nhân sẽ cần biết cách ghi đè các cảm biến, hệ thống thủy lực, cách định tuyến lại dòng nhiên liệu , thao tác các hệ thống không bao giờ được thiết kế để thay đổi hoặc thao tác bên ngoài hoặc từ buồng lái. Đây thường là triển vọng của việc viết lại một ứng dụng kinh doanh là như thế nào. Ứng dụng này thường được đưa vào kinh doanh giữa nhiều công nghệ khác nhau.

Tôi đoán điểm chính của tôi là, hệ thống phải được hiểu gần như toàn bộ sự phức tạp của nó và đôi khi nó phải được hiểu về tính đầy đủ của nó để hệ thống mới được "thiết kế" đúng cách chứ không chỉ là "chế tạo".

Cookies được làm, phần mềm (nên được) thiết kế.


2
+1 cho nhu cầu hiểu rất nhiều về hệ thống kinh doanh từ trước. Tuy nhiên, như bạn đã biết, thách thức ở đây là thời gian và nguồn lực (từ doanh nghiệp) cũng như các yếu tố thay đổi. Đối với các hệ thống vừa và lớn, việc hiểu được sự phức tạp hoàn toàn trước mắt đôi khi không phải lúc nào cũng có thể.
NoChance

2

Có nhiều ví dụ về các công ty đã chết vì viết lại, như Netscape . Cũng có những công ty sống sót sau khi viết lại mà không gặp rắc rối lớn như twitter .

Không có bất kỳ nghiên cứu điển hình nào được định lượng, bởi vì không thể thực hiện được một thử nghiệm kiểm soát trong đó bạn nhìn vào thành công kinh doanh của việc không viết lại so với thành công kinh doanh của việc viết lại. Mỗi ứng dụng là khác nhau.

Có một số trường hợp rõ ràng trong đó viết lại có ý nghĩa và nhiều trường hợp không viết lại. Tôi đã nấu một công thức nhỏ để tìm hiểu xem viết lại có hợp lý trong trường hợp của bạn không.

Tôi nghĩ rằng việc viết lại có ý nghĩa hơn hiện nay bởi vì chúng ta đang viết mã nhanh chóng trên vai của việc cải thiện các khuôn khổ xâm lấn như Rails, Grails, AngularJS. Nếu bạn muốn chuyển từ js đơn giản sang Angular, viết lại là tất cả những gì bạn có thể làm. Nó vẫn có thể có ý nghĩa. Nếu bạn đang thay thế một triển khai tự làm bằng một triển khai khác (như tất cả các ví dụ trong bài viết của Joel Spolsky ) thì có lẽ bạn đang điên.


1

Bạn sẽ không tìm thấy nhiều nghiên cứu trường hợp không thiên vị, bất cứ điều gì khác ngoài báo cáo hành động - hầu hết mọi người sẽ không trả tiền để thực hiện cùng một công việc ít nhất hai lần (một lần viết lại, một lần là nâng cấp, tốt nhất trường hợp sẽ được viết lại / nâng cấp bởi các đội khác nhau).

Nghiên cứu điển hình mà bạn thấy dường như được sản xuất bởi Fujitsu, và không ngạc nhiên khi kết quả là sử dụng các công cụ của Fujitsu tốt hơn.

Từ quan điểm tổ chức, viết lại chỉ rõ ràng là một thất bại khi ứng dụng viết lại không hoạt động hoặc dự án bị hủy trước khi kết thúc - nếu không thì không thể biết liệu sự chậm trễ trong việc phát hành phiên bản viết lại là nguyên nhân của bất kỳ mất mát nào bạn phải chịu hoặc chỉ là trùng hợp ngẫu nhiên. Nếu hủy bỏ trước khi hoàn thành, nó thường được coi là tổng lãng phí thời gian và tài nguyên. Một bản nâng cấp có khả năng có cùng một vấn đề, nhưng việc gia tăng dường như không thể ở cùng một quy mô (bạn nhận được một số tiền cho số tiền của mình).

Trường hợp tốt nhất từ ​​góc độ lập trình là thực hiện cả hai - nâng cấp gia tăng trong khi viết lại, cả hỗ trợ và truyền cảm hứng cho nhau. Trừ khi bạn có các đội khác nhau, điều này sẽ tự nhiên mất nhiều thời gian hơn.

Lưu ý rằng điều này cung cấp một hướng dẫn sơ bộ khi bạn nên xem xét viết lại toàn bộ - dự án đủ nhỏ để bạn có thể thực hiện dễ dàng hoặc tối ưu hóa đủ lớn để có thể đủ khả năng thực hiện cả hai, tính công sức hoặc chi phí học tập đáng giá Cũng lưu ý rằng nếu việc viết lại không bao giờ bắt kịp bài tập, điều đó có thể có nghĩa là một số thứ, nhưng tất cả những thứ khác đều bằng nhau, có lẽ có nghĩa là viết lại là không cần thiết.


1
Viết lại có thể là một thất bại khi nó chạy ồ ạt trên ngân sách và bị hủy trước khi hoàn thành. Tiền rơi xuống mương. Khả năng của sự kiện này là lý do tại sao viết lại được coi là rủi ro hơn so với tái cấu trúc.
MarkJ

@MarkJ: Tôi nghĩ rằng nó được đề cập trong phần "không hoạt động", nhưng tôi sẽ chỉnh sửa để làm cho nó rõ ràng hơn.
jmoreno
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.