Làm thế nào để tranh luận về việc hạ thấp tiêu chuẩn chất lượng cho codebase cũ? [đóng cửa]

Chúng tôi có một cơ sở mã di sản lớn với mã xấu mà bạn không thể tưởng tượng được.

Bây giờ chúng tôi đã xác định một số tiêu chuẩn chất lượng và muốn hoàn thành những tiêu chuẩn trong cơ sở mã hoàn toàn mới, nhưng cũng nếu bạn chạm vào mã kế thừa.

Và chúng tôi thi hành những thứ đó bằng Sonar (công cụ phân tích mã), đã có hàng ngàn vi phạm.

Bây giờ các cuộc thảo luận đã đưa ra để hạ thấp những vi phạm cho di sản. Bởi vì đó là di sản.

Các cuộc thảo luận là về quy tắc dễ đọc. Giống như có bao nhiêu ifs lồng nhau / cho .. nó có thể có.

Bây giờ làm thế nào tôi có thể lập luận chống lại việc hạ thấp chất lượng mã hóa của chúng tôi trên mã kế thừa?

Mã chỉ là một phương tiện để kết thúc. Những gì kết thúc có thể khác nhau, nhưng thường là lợi nhuận.

Nếu đó là lợi nhuận; sau đó để tranh luận thành công bất cứ điều gì bạn muốn chứng minh rằng nó sẽ cải thiện lợi nhuận - ví dụ: bằng cách tăng doanh thu, giảm chi phí bảo trì, giảm chi phí phát triển, giảm tiền lương, giảm chi phí đào tạo lại, v.v. Nếu bạn không thể / không thể hiện rằng nó sẽ cải thiện lợi nhuận; sau đó bạn hầu như chỉ nói rằng đó là một cách thú vị để xả tiền vào nhà vệ sinh.

Tôi, tôi và tôi, vừa là nhà sản xuất vừa là người duy trì mã kế thừa. Nếu công cụ của bạn tạo ra "hàng ngàn vi phạm" (hoặc thậm chí hàng trăm cho vấn đề đó), hãy quên công cụ đó, nó không thể áp dụng được cho tình huống ...

Tôi cho rằng các nhà phát triển ban đầu đã qua lâu và không có sẵn để thảo luận. Vì vậy, không có ai xung quanh hiểu được lý do tại sao và do đâu đó về phong cách thiết kế và mã hóa. Sửa chữa hàng trăm hoặc hàng ngàn vi phạm sẽ không phải là vấn đề viết lại một vài dòng mã ở đây và đó. Thay vào đó, nó chắc chắn đòi hỏi tái cấu trúc / tái phân rã chức năng. Bạn thử làm điều đó với bất kỳ cơ sở mã lớn hiện có nào mà không hiểu rõ về thiết kế hiện tại của nó và bạn buộc phải giới thiệu một loạt lỗi / vấn đề / v.v. Chỉ là một con giun mới thậm chí còn tệ hơn cái bạn đang có (hoặc tệ hơn công cụ của bạn >> nghĩ rằng << bây giờ bạn có).

Cách tiếp cận hợp lý duy nhất để giải quyết "hàng ngàn vi phạm" sẽ được viết lại từ đầu. Một nỗ lực lâu dài và tốn kém, và gần như không thể bán cho ban quản lý. Và trong trường hợp này có lẽ họ đúng ...

Mã kế thừa thường chỉ yêu cầu chỉnh sửa. Giống như cho y2k, hoặc khi cổ phiếu tăng từ 256 đến thập phân. Tôi đã tải vô số cr * p. Và rất nhiều thứ tương tự khác. Nó thường khá "chính xác" ở chỗ bạn có thể "đọc qua" phong cách đôi khi xấu, phân rã chức năng xấu, xấu, v.v. và xác định vị trí bộ sưu tập các địa điểm cần sửa đổi. Và sau đó, những gì xảy ra "giữa những nơi đó", tức là dòng chảy cấp cao hơn, có thể vẫn là một bí ẩn đối với bạn. Chỉ cần đảm bảo rằng bạn hiểu chức năng địa phương hóa mà bạn đang thay đổi, sau đó kiểm tra, thử nghiệm, kiểm tra xem có tác dụng phụ nào không, v.v., kiến ​​thức bản địa hóa của bạn sẽ không thể lường trước được.

Nếu bạn không thể xem theo cách của mình thông qua mã như vậy, thì bạn có thể không phải là người tốt nhất để duy trì mã kế thừa. Một số người có thể bắt đầu với một màn hình trống và viết các chương trình đẹp, nhưng không thể bắt đầu với một cơ sở mã lớn của mã người khác và duy trì nó. Những người khác có thể duy trì mã, nhưng không thể bắt đầu từ đầu. Một số có thể làm cả hai. Hãy chắc chắn rằng đúng người đang duy trì mã di sản của bạn.

Đôi khi bạn có thể muốn thiết kế lại và viết lại cơ sở mã di sản của mình từ đầu là khi các yêu cầu của doanh nghiệp (hoặc khác) thay đổi đến mức "chỉnh sửa" chỗ ngồi không thể đáp ứng các yêu cầu đã thay đổi nữa . Và tại thời điểm đó, bạn cũng có thể bắt đầu bằng cách viết một tài liệu yêu cầu chức năng mới ngay từ đầu, đảm bảo tất cả các bên liên quan đều ở trên tàu. Về cơ bản, đây là một trò chơi bóng hoàn toàn mới.

Điều sai lầm một và duy nhất >> điều cần làm là thử xử lý bảo trì mã kế thừa giống như cách bạn đi về sự phát triển mới. Và đó là một điều sai lầm dường như chính xác là con đường bạn muốn đi :) Hãy tin tôi đi, đó không phải là điều bạn muốn làm.

Câu hỏi không phải là mã đó tốt hay xấu. Câu hỏi là bạn nhận được bao nhiêu lợi ích từ đầu tư bao nhiêu.

Vì vậy, bạn có một công cụ tìm thấy hàng ngàn thứ mà nó không thích. Bạn có thể chọn bỏ qua kết quả của công cụ hoặc đầu tư công việc để thay đổi hàng ngàn thứ. Đó là rất nhiều thứ. Mọi người sẽ không tập trung, không phải trong khi thực hiện các thay đổi, không phải trong khi xem xét chúng và điều này sẽ không được kiểm tra đúng cách vì phải mất nhiều thời gian để tìm ra cách kiểm tra (hoặc chỉ để thử) mọi thay đổi, do đó sẽ có lỗi. Vì vậy, cho đến khi bạn tìm thấy và sửa những lỗi đó, bạn đã đầu tư rất nhiều thời gian và tiền bạc với kết quả tiêu cực chung.

Mặt khác, các công cụ có thể tìm thấy những thứ mà chúng không chỉ "không thích", mà đó là lỗi hoặc lỗi tiềm ẩn. Nếu mã kế thừa vẫn được sử dụng rộng rãi, thì công cụ phù hợp thực sự có thể tìm thấy lỗi. Vì vậy, lần lượt cảnh báo trình biên dịch từng cái một, kiểm tra xem chúng có hữu ích không (không phải tất cả đều hữu ích) và sửa các cảnh báo đó có đáng giá hay không.

Nếu nó không bị hỏng, đừng sửa nó.

Điều này thực tế nên được xăm trên mọi nhà phát triển và quản lý phần mềm để họ không bao giờ quên nó.

Vâng, nó phá vỡ tất cả các quy ước mã hóa hiện đại. Vâng, nó được viết bằng FORTRAN-77 với trình bao bọc bằng C để có thể được gọi từ Python. Vâng, đó là những GOTO không có cấu trúc. Vâng, có một chương trình con dài ba ngàn dòng. Vâng, tên biến chỉ có ý nghĩa đối với một Croatia. Vân vân.

Nhưng nếu nó đã được thử nghiệm trong sự tức giận từ một thập kỷ trở lên và đã qua, hãy để nó yên! Nếu sửa đổi cần thiết là nhỏ, sau đó giữ nó càng nhỏ và càng cục bộ càng tốt. Bất cứ điều gì khác có nguy cơ cao hơn phá vỡ một cái gì đó không cần sửa chữa.

Tất nhiên, đôi khi bạn thấy rằng nó thực sự là một kluge không thể nhầm lẫn và cách duy nhất để bổ sung cho sửa đổi "nhỏ" là viết lại từ đầu. Trong trường hợp đó, bạn phải quay lại với bất cứ ai đang yêu cầu thay đổi và nói cho anh ta biết nó sẽ có giá bao nhiêu (cả bằng đô la hoặc giờ làm việc để viết lại, và trong mồ hôi máu và nước mắt cho những lỗi mới không thể tránh khỏi).

Một thời gian dài trước đây đã xảy ra sự cố về một trong những ổ đĩa của Digital. Cuối cùng họ đã thu hồi và thay thế tất cả trong số họ biết chi phí. Rõ ràng có một đốm keo giữ bộ lọc bên trong HDA. Bản kê khai kỹ thuật nói về loại keo "Không quy định cụ thể, KHÔNG CÓ CHẤP NHẬN ĐƯỢC CHẤP NHẬN". Một bộ đếm đậu "được lưu" dưới một xu trên mỗi ổ đĩa bằng cách tìm nguồn cung cấp keo khác. Nó phát ra một hơi bên trong HDA đã giết chết ổ đĩa sau một vài năm phục vụ. Nó đã không bị phá vỡ cho đến khi anh sửa nó. Không nghi ngờ gì nữa "đó chỉ là một thay đổi nhỏ ..."

Chắc chắn không có điểm nào để giảm mức chất lượng cho mã kế thừa. Cũng không cần phải sửa cảnh báo ngay lập tức. Chỉ cần đảm bảo rằng tất cả các thay đổi "mới" của bạn trong mọi thành phần của dự án đều tuân theo tiêu chuẩn chất lượng cao. Tức là không có cam kết nên tăng số lượng cảnh báo bao giờ.

Đó là một cách tiếp cận đơn giản và thống nhất.

Nó cho phép mã kế thừa cũ hoạt động như bình thường (vì không có sửa đổi không cần thiết nào được thực hiện đối với nó). Nó đảm bảo mã mới có chất lượng cao. Không có chi phí bổ sung có liên quan.

Kiểm soát rủi ro.

• Mã trong cơ sở mã di sản lớn đã được kiểm tra ít nhất bằng cách sử dụng phần mềm trong đời thực.
• Nó rất không giống với mã trong cơ sở mã di sản lớn được bao phủ bởi các thử nghiệm đơn vị tự động.
• Do đó, bất kỳ thay đổi nào đối với cảm lạnh trong cơ sở mã di sản lớn đều có nguy cơ cao.

Giá cả….

• Làm mã vượt qua trình kiểm tra mã trong khi bạn đang viết mã là giá rẻ
• Làm như vậy ở trạng thái sau sẽ tốn kém hơn nhiều

Lợi ích

• Bạn hy vọng rằng việc tuân thủ các tiêu chuẩn mã hóa sẽ dẫn đến một thiết kế mã tốt hơn.

• Nhưng rất khó có khả năng ai đó dành nhiều tuần để thay đổi mã chỉ để xóa cảnh báo khỏi công cụ kiểm tra tiêu chuẩn mã hóa, sẽ dẫn đến sự cải tiến trong thiết kế mã.

• Mã đơn giản rõ ràng hơn và có xu hướng dễ hiểu hơn, trừ khi mã phức tạp được chia thành các phương thức ngắn bởi một người không hiểu nó.

Sự giới thiệu….

• Nếu một phần của mã được hiển thị có nhiều lỗi trong đó hoặc cần nhiều thay đổi để thêm các chức năng bổ sung thì hãy dành thời gian để hiểu 100% về những gì nó làm.
• Cũng dành thời gian để thêm bài kiểm tra đơn vị tốt vào phần mã đó, vì bạn có nhu cầu đã được chứng minh cho chúng.
• Sau đó, bạn có thể xem xét tái cấu trúc mã (bây giờ bạn đã hiểu) để nó cũng vượt qua kiểm tra mã mới.

Trải nghiệm cá nhân.

• Trong 20 năm làm lập trình viên khác, tôi chưa bao giờ thấy trường hợp nào thay đổi cũ một cách mù quáng để loại bỏ tất cả đầu ra khỏi trình kiểm tra tiêu chuẩn mã hóa mới có bất kỳ lợi ích nào ngoài việc tăng thu nhập của các nhà thầu được hướng dẫn làm như vậy.
• Tương tự như vậy khi mã cũ phải được thực hiện để vượt qua các đánh giá mã (TickIt / ISO 9001 đã làm sai) yêu cầu mã cũ trông giống như tiêu chuẩn mã hóa mới.
• Tôi đã thấy nhiều trường hợp sử dụng các công cụ kiểm tra tiêu chuẩn mã hóa trên mã mới có lợi ích lớn bằng cách giảm chi phí liên tục.
• Tôi chưa bao giờ thấy một công ty thất bại với chi phí duy trì mã cũ được sử dụng trong một sản phẩm có nhiều khách hàng.
• Tôi đã thấy công ty thất bại do không nhận được thu nhập từ khách hàng do quá chậm để tiếp thị thị trường.

Là cuộc thảo luận về việc hạ thấp ngưỡng của công cụ? ... hoặc tôi đã hiểu nhầm nó. Nó được viết một cách khó hiểu. Nếu không, xin vui lòng loại bỏ câu trả lời của tôi.

IMHO sẽ là một ý tưởng tốt để giảm độ nhạy của công cụ. Tại sao? Bởi vì nó sẽ làm nổi bật những đoạn mã nhiều lông nhất. Sự thay thế đang tạo ra các báo cáo với hàng ngàn vi phạm, trở nên vô dụng bởi quy mô tuyệt vời của nó.

... Ngoài ra, chỉ cần nói về nó với những người liên quan và nghe lý do của họ.

Tôi sẽ cố tách mã kế thừa khỏi mã sạch mới. Ví dụ, Eclipse bạn có thể làm điều này bằng cách đưa chúng vào các dự án khác nhau sử dụng lẫn nhau. 'dự án sạch ' và 'di sản' dự án .

Bằng cách này bạn có thể phân tích cả hai dự án trong sonar với các tiêu chuẩn chất lượng khác nhau. Các tiêu chuẩn chỉ nên khác nhau về tầm quan trọng của các quy tắc. Các quy tắc nên được giống nhau. Bằng cách này, bạn có thể thấy trong 'dự án' di sản cần phải được 'cố định' để đáp ứng các tiêu chuẩn của dự án 'sạch' .

Bất cứ khi nào bạn quản lý để nâng một số mã kế thừa lên các tiêu chuẩn cao hơn, bạn có thể chuyển nó sang dự án 'sạch'.

Trong mọi công việc hàng ngày, bạn không thể hoàn thành việc nâng mọi lớp học mà bạn chạm tới các tiêu chuẩn dự án 'sạch' vì độ trễ của thời gian. Nhưng bạn nên cố gắng đến đó trong vài bước bằng cách cố gắng cải thiện mã kế thừa một chút mỗi khi bạn chạm vào nó.