Có một nghiên cứu trường hợp nào chứng minh một cách thuyết phục rằng mã sạch đã cải thiện sự phát triển? [đóng cửa]

Tôi đang làm công việc lập trình viên thực sự đầu tiên của mình và những gì tôi thấy chỉ là mã "Big Ball of Mud" (không có nhận xét hữu ích), nhưng tôi thích làm mã sạch, và thật khó để tôi viết mã tệ hơn đường.

Tôi đang tìm kiếm một số trường hợp nghiên cứu trong đó việc sử dụng mã sạch (tôi thấy các định nghĩa khác nhau ở đây về mã sạch) đã cải thiện sự phát triển và khả năng bảo trì.

Một tìm kiếm nhanh (nhưng không có nghĩa là toàn diện) của Google Scholar xuất hiện rất nhiều bài viết liên quan đến Clean Code của Bob Martin , nhưng cá nhân tôi chưa thấy bất kỳ bài báo nào nói về mối tương quan giữa "mã sạch" và sự phát triển được cải thiện.

Tuy nhiên, hãy suy nghĩ về câu hỏi của bạn một lát. Bạn đang hỏi về sự phát triển được cải thiện và bản thân nó là một lĩnh vực chủ đề rất rộng, không chỉ đơn giản bằng cách viết mã tốt hơn, mà còn bởi nhiều yếu tố khác như giao tiếp, quản lý kỳ vọng, phương pháp và quy trình hợp lý hóa, thử nghiệm, tích hợp liên tục và thực sự toàn bộ hộp và xúc xắc khi bạn xem xét có bao nhiêu điều làm cho một dự án phát triển phần mềm thành công, hãy để một mình cải thiện nó.

Vì vậy, câu hỏi của bạn có lẽ nên là: viết mã sạch có góp phần cải thiện sự phát triển phần mềm không? Để trả lời điều đó, "bằng chứng" duy nhất tôi có thể cung cấp sẽ hoàn toàn là giai thoại, và tôi nghĩ rằng cuốn sách Clean Code sẽ là một tài liệu tham khảo tuyệt vời, vì nó được viết không chỉ bởi chính Bob Martin, mà còn có nhiều chương được đóng góp bởi một số nhà phát triển phần mềm thông minh nhất hiện có. Nếu điều đó không có ích, thì có lẽ một chút logic cứng lạnh có thể được áp dụng.

Nếu bạn làm bừa bộn trong nhà, và bạn không bao giờ có thể dọn dẹp nó, thì việc sống trong nhà của bạn sẽ trở thành một việc vặt. Việc tìm đồ trở nên khó khăn hơn, di chuyển khó khăn hơn và không ai có thể muốn đến thăm bạn nếu bạn sống trong một môi trường bẩn thỉu. Tương tự với mã. Nếu mã của bạn là một mớ hỗn độn, bạn thấy khó khăn hơn trong việc xác định các vấn đề, hãy để một mình sửa chúng. Nó trở nên dễ dàng hơn để biện minh cho một công việc xung quanh có thể không thực hiện công việc, nhưng hey, nó chắc chắn nhịp đập phải lội qua tất cả các muck di sản cũ, phải không? Cuối cùng, giống như không bao giờ dọn dẹp nhà cửa của bạn, cho phép mã của bạn trở nên không gọn gàng sẽ khiến bạn mất thời gian và công sức và tạo ra khó khăn cho bạn về lâu dài. Tuy nhiên, việc giữ mã của bạn sạch sẽ sẽ cung cấp cho bạn một nền tảng đẹp hơn để làm việc, giúp tái cấu trúc và gỡ lỗi ít việc vặt hơn,

Không, tôi không có bằng chứng trực tiếp để cung cấp cho bạn và đây chỉ là suy nghĩ của một người đã làm công cụ này trong một thời gian rất dài và hy vọng họ đã có được một chút trí tuệ phát triển phần mềm trên đường đi. :-)

Điều bạn cần hiểu là không có công ty nào bắt đầu viết mã tầm thường. Vấn đề là 50% mã, cho hoặc nhận, được viết bởi các lập trình viên trung bình dưới đây của công ty bạn. Bạn đang giảng cho dàn hợp xướng khi bạn giải thích những lợi ích của mã sạch. Bí quyết là làm thế nào để làm điều đó. Thực hiện một số nghiên cứu về những thứ như công cụ đánh giá ngang hàng, phân tích tĩnh, kiểm tra tự động, tích hợp liên tục, TDD, scrum, lập trình cực đoan, v.v. và đưa ra các giải pháp tiềm năng thay vì chỉ giải thích tại sao vấn đề lại tồi tệ.

Tôi biết điều này sẽ đi ngược lại với ngũ cốc ở đây nhưng đã đến lúc đưa ra thị trường, nhận được các yêu cầu đúng đắn, có nguồn vốn phù hợp, tiếp thị tốt, mức giá phù hợp và may mắn rõ ràng có ảnh hưởng lớn hơn đến sự thành công của sản phẩm phần mềm so với chất lượng mã.

Điều này KHÔNG phải để nói rằng chất lượng mã nên được bỏ qua, nhưng, bạn nên thừa nhận nó chỉ là một trong nhiều yếu tố.

Có nhiều ví dụ về mã đơn giản khủng khiếp trong các sản phẩm cực kỳ thành công (ví dụ: Hệ điều hành Apple ban đầu để lại quản lý luồng cho các ứng dụng).

Tôi không thể nghĩ ra bất kỳ ví dụ nào về mã đẹp vượt qua một sản phẩm được quan niệm tồi tệ hoặc quá đắt.

Vì vậy, nếu thời gian của nó để tiếp thị so với mã đẹp, thời gian để thị trường nên ưu tiên!

Bạn phải tách mã sạch khỏi các mục tiêu thực tế: giảm chi phí sửa lỗi sau khi triển khai và giảm việc làm lại không cần thiết. Khi bạn nói về "viết mã sạch để làm cho nó có ít lỗi hơn", bạn đang nói về tôn giáo. Khi bạn nói về việc "giảm tỷ lệ lỗi 10%, tiết kiệm 2 tháng công sức cho dự án", bạn đang nói về quản lý. Mã sạch là một công cụ để cải thiện chất lượng ban đầu của cơ sở mã và do đó làm giảm tổng chi phí, nhưng nó là một trong nhiều.

Bài viết sau đây giải thích tại sao việc làm đúng ngay từ lần đầu tiên lại quan trọng từ góc độ chi phí: http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

Tôi không biết về bất kỳ nghiên cứu cụ thể nào, nhưng hãy kiểm tra công việc của Steve McConnell .

Nếu ai có nó, anh sẽ làm. Ví dụ, một lần quét hai phút đã tìm thấy điều này (16 tuổi nhưng vẫn còn liên quan đến ngày hôm nay).

Để thêm vào câu trả lời của mattnz, nếu bạn chưa nói, tôi sẽ nói cụ thể kiểm tra Code Complete: Cẩm nang thực hành về xây dựng phần mềm của Steve McConnell. Bên cạnh thực tế là nó có khả năng sẽ cải thiện mã hóa của bạn, ông trích dẫn nhiều nghiên cứu trong suốt cuốn sách về cách thức thực hành mã hóa khác nhau ảnh hưởng đến chất lượng của các chương trình.

Ví dụ (từ cuốn sách):

Một nghiên cứu khác về 450 thói quen khác nhau (chỉ là sự trùng hợp bất thường) đã phát hiện ra rằng các thói quen có tỷ lệ khớp nối cao nhất có tỷ lệ mắc lỗi cao gấp 7 lần so với các tỷ lệ khớp nối thấp nhất và có chi phí cao gấp 20 lần để sửa chữa (Selby và Basili 1991).

Ngoài ra, nó từng là câu trả lời số một cho câu hỏi Cuốn sách có ảnh hưởng nhất mà mỗi lập trình viên nên đọc là gì? (mặc dù tôi thấy câu trả lời cho câu hỏi này gần đây đã được tổ chức lại theo cách khập khiễng)