Làm thế nào để các thư viện mã nguồn mở khổng lồ được duy trì trong khi có mã cách xa các thực hành mã sạch của Tep?

Tôi vẫn chưa có kinh nghiệm để viết mã chất lượng cao, vì vậy tôi đọc những cuốn sách đề cập đến vấn đề như Clean Code của Robert C. Martin và tiếp tục kiểm tra mã của các thư viện nổi tiếng để cải thiện kỹ năng của mình.

Mặc dù nhiều thư viện nguồn mở đã được duy trì trong nhiều năm, điều đó có nghĩa là rất khó có khả năng chúng không đi đúng hướng, tôi đã tìm thấy mã trong nhiều trong số chúng nằm xa các nguyên tắc được đề cập để viết mã sạch - ví dụ như các phương thức có chứa hàng trăm dòng mã.

Vì vậy, câu hỏi của tôi là: Có phải các nguyên tắc của mã sạch quá hạn chế và chúng ta có thể làm mà không có chúng trong nhiều thư viện như thế này không? Nếu không, làm thế nào các thư viện khổng lồ được duy trì mà không xem xét nhiều nguyên tắc này?

Tôi sẽ đánh giá cao bất kỳ làm rõ ngắn gọn. Tôi xin lỗi nếu câu hỏi có vẻ ngớ ngẩn từ một người mới.

BIÊN TẬP

Kiểm tra ví dụ này trong thư viện Butterknife - một trong những thư viện được biết đến nhiều nhất trong cộng đồng Android.

Đã có câu trả lời tốt ở đây, nhưng hãy để tôi nói một từ về ví dụ butterknife của bạn : mặc dù tôi không biết mã này làm gì, nhưng thoạt nhìn, nó không thực sự khó hiểu đối với tôi. Các biến và tên phương thức dường như được chọn một cách có chủ ý, mã được thụt lề và định dạng đúng, nó có một số nhận xét và các phương thức dài ít nhất hiển thị một số cấu trúc khối.

Vâng, không có cách nào tuân theo quy tắc "mã sạch" của chú Bob, và một số phương pháp chắc chắn quá dài (có thể là cả lớp). Nhưng nhìn vào mã tôi vẫn thấy đủ cấu trúc để chúng có thể dễ dàng "dọn sạch" bằng cách tự trích xuất các khối đó thành các phương thức (với rủi ro thấp khi đưa ra các lỗi khi sử dụng các công cụ tái cấu trúc).

Vấn đề thực sự với mã như vậy là, thêm một khối và một khối khác và một khối khác hoạt động ở một mức độ nào đó, đôi khi qua nhiều năm. Nhưng mỗi ngày, mã trở nên khó phát triển hơn một chút và phải mất một chút thời gian để sửa đổi và kiểm tra nó. Và khi bạn thực sự phải thay đổi thứ gì đó không thể giải quyết bằng cách "thêm một khối khác", nhưng yêu cầu cơ cấu lại, thì bạn sẽ ước ai đó đã bắt đầu dọn sạch mã sớm hơn.

Các nguyên tắc nêu trong "Mã sạch" không phải lúc nào cũng được thỏa thuận chung. Hầu hết đó là lẽ thường, nhưng một số ý kiến ​​của tác giả khá gây tranh cãi và không được mọi người chia sẻ.

Cụ thể, ưu tiên cho các phương pháp ngắn không được mọi người đồng ý. Nếu mã trong một phương thức dài hơn không được lặp lại ở nơi khác, việc trích xuất một số mã đó sang một phương thức riêng biệt (để bạn có được nhiều phương thức ngắn hơn) làm tăng độ phức tạp chung, vì các phương thức này hiện có thể nhìn thấy đối với các phương thức khác không quan tâm đến chúng. Vì vậy, nó là một sự đánh đổi, không phải là một cải tiến khách quan.

Lời khuyên trong cuốn sách cũng (giống như tất cả các lời khuyên) hướng đến một loại phần mềm cụ thể: Ứng dụng doanh nghiệp. Các loại phần mềm khác như trò chơi hoặc hệ điều hành có các ràng buộc khác với phần mềm doanh nghiệp, do đó, các mẫu và nguyên tắc thiết kế khác nhau đang được sử dụng.

Ngôn ngữ cũng là một yếu tố: Clean Code giả định Java hoặc một ngôn ngữ tương tự - nếu bạn sử dụng C hoặc Lisp, rất nhiều lời khuyên không được áp dụng.

Nói tóm lại, cuốn sách là ý kiến ​​của một người về một loại phần mềm cụ thể. Nó sẽ không áp dụng ở mọi nơi.

Đối với các dự án nguồn mở, chất lượng mã dao động từ sâu thẳm đến rực rỡ. Rốt cuộc, bất cứ ai cũng có thể xuất bản mã của họ dưới dạng nguồn mở. Nhưng nếu bạn nhìn vào một dự án nguồn mở trưởng thành và thành công với nhiều người đóng góp, bạn có thể khá chắc chắn rằng họ đã có ý thức giải quyết một phong cách phù hợp với họ. Nếu phong cách này mâu thuẫn với một số ý kiến ​​hoặc hướng dẫn, thì (nói một cách thẳng thắn), đó là hướng dẫn sai hoặc không liên quan, vì mã làm việc vấp phải ý kiến.

Tóm lược

Như JacquesB viết, không phải ai cũng đồng ý với "Mã sạch" của Robert C. Martin.

Các dự án nguồn mở mà bạn thấy là "vi phạm" các nguyên tắc mà bạn mong đợi có thể chỉ đơn giản là có các nguyên tắc khác.

Góc nhìn của tôi

Tôi tình cờ giám sát một số cơ sở mã tuân thủ rất nhiều nguyên tắc của Robert C. Martin. Tuy nhiên, tôi không thực sự cho rằng họ đúng , tôi chỉ có thể nói họ làm việc tốt cho chúng tôi - và thực tế là "chúng tôi" là sự kết hợp của ít nhất

• phạm vi và kiến ​​trúc của các sản phẩm của chúng tôi,
• thị trường mục tiêu / kỳ vọng của khách hàng,
• Bao lâu các sản phẩm được duy trì,
• phương pháp phát triển chúng tôi sử dụng,
• cơ cấu tổ chức của công ty chúng tôi và
• thói quen, ý kiến ​​và kinh nghiệm trong quá khứ của các nhà phát triển của chúng tôi.

Về cơ bản, điều này tập trung vào: mỗi nhóm (có thể là một công ty, một bộ phận hoặc một dự án nguồn mở) là duy nhất. Họ sẽ có những ưu tiên khác nhau và quan điểm khác nhau, và tất nhiên họ sẽ thực hiện những sự đánh đổi khác nhau. Những sự đánh đổi này, và kiểu mã mà họ tạo ra, phần lớn là vấn đề của hương vị và không thể được chứng minh là "sai" hay "đúng". Các đội chỉ có thể nói "chúng tôi làm điều này vì nó hiệu quả với chúng tôi" hoặc "chúng tôi nên thay đổi điều này vì nó không hiệu quả với chúng tôi".

Điều đó nói rằng, tôi tin rằng để có thể duy trì thành công các cơ sở mã lớn trong nhiều năm, mỗi nhóm nên thống nhất một bộ quy ước mã mà họ cho là phù hợp với các khía cạnh nêu trên. Điều đó có thể có nghĩa là áp dụng các thực hành của Robert C. Martin, bởi một tác giả khác, hoặc phát minh ra của họ; nó có thể có nghĩa là viết chúng xuống chính thức hoặc ghi lại chúng "bằng ví dụ". Nhưng chúng nên tồn tại.

Thí dụ

Hãy xem xét thực tiễn "tách mã từ một phương thức dài thành một số phương thức riêng".

Robert C. Martin nói rằng phong cách này cho phép hạn chế nội dung của từng phương pháp để một mức độ trừu tượng - như một ví dụ đơn giản, một phương pháp nào có lẽ chỉ bao gồm các cuộc gọi đến các phương pháp cá nhân như verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)và cuối cùng sendJsonToClient(...), và các phương pháp này sẽ có các chi tiết thực hiện.

• Một số người thích điều này bởi vì độc giả có thể có được cái nhìn tổng quan nhanh về các bước cấp cao và có thể chọn chi tiết nào họ muốn đọc.
• Một số người không thích nó bởi vì khi bạn muốn biết tất cả các chi tiết, bạn phải nhảy xung quanh trong lớp để theo dõi quá trình thực thi (đây là những gì JacquesB có thể đề cập đến khi ông viết về việc thêm độ phức tạp).

Bài học là: tất cả chúng đều đúng, bởi vì chúng có quyền có ý kiến.

Trên thực tế, nhiều thư viện nguồn mở chịu các thực tiễn mã hóa kém khách quan và được duy trì khó khăn bởi một nhóm nhỏ những người đóng góp dài hạn có thể xử lý khả năng đọc kém vì họ rất quen thuộc với các phần của mã mà họ thường xuyên duy trì . Tái cấu trúc mã để cải thiện khả năng đọc sau thực tế thường là nỗ lực của Herculean vì mọi người cần phải ở trên cùng một trang, điều đó không vui và không trả tiền vì không có tính năng mới nào được triển khai.

Như những người khác đã nói, bất kỳ cuốn sách nào về mã sạch đều nêu rõ tất cả đều có chứa lời khuyên không được đồng ý trên toàn cầu. Đặc biệt, hầu như bất kỳ quy tắc nào cũng có thể được tuân theo với sự nhiệt tình quá mức, thay thế một vấn đề dễ đọc bằng một quy tắc khác.

Cá nhân, tôi tránh tạo các hàm được đặt tên nếu tôi không có tên tốt cho chúng. Và một cái tên hay phải ngắn gọn và mô tả trung thực những gì chức năng làm với thế giới bên ngoài. Điều này cũng gắn liền với việc cố gắng có càng ít đối số chức năng càng tốt và không có dữ liệu có thể ghi trên toàn cầu. Cố gắng cắt giảm một hàm rất phức tạp thành các hàm nhỏ hơn thường dẫn đến danh sách đối số rất dài khi hàm thực sự phức tạp. Tạo và duy trì mã có thể đọc được là một bài tập ở trạng thái cân bằng giữa các quy tắc ý thức chung mâu thuẫn lẫn nhau. Đọc sách là tốt, nhưng chỉ có kinh nghiệm sẽ dạy bạn làm thế nào để tìm ra sự phức tạp sai lầm , đó là nơi đạt được khả năng đọc thực sự.

Hầu hết các dự án nguồn mở được quản lý tồi. Rõ ràng có những ngoại lệ cho điều đó, nhưng bạn sẽ tìm thấy rất nhiều rác trong thế giới nguồn mở.

Đây không phải là một bài phê bình của tất cả các chủ sở hữu / người quản lý dự án mà tôi đang nói về dự án, nó chỉ đơn giản là vấn đề thời gian sử dụng. Những người này có những điều tốt hơn để làm với thời gian của họ, như công việc trả lương thực tế của họ.

Ban đầu, mã là công việc của một người và có lẽ là nhỏ. Và mã nhỏ không cần phải sạch. Hay đúng hơn, nỗ lực cần thiết để làm cho mã sạch sẽ lớn hơn lợi ích.

Thời gian trôi qua, mã là một đống các bản vá của nhiều người khác nhau. Người viết bản vá cảm thấy không có quyền sở hữu mã, họ chỉ muốn một tính năng này được thêm vào hoặc lỗi này được sửa theo cách dễ nhất có thể.

Chủ sở hữu không có thời gian để dọn dẹp mọi thứ và không ai quan tâm.

Và mã đang trở nên lớn. Và xấu xí.

Vì càng ngày càng khó tìm ra cách của bạn xung quanh mã, mọi người bắt đầu thêm các tính năng ở sai vị trí. Và thay vì sửa lỗi, họ thêm cách khắc phục các vị trí khác trong mã.

Tại thời điểm này, không phải mọi người không quan tâm, họ không còn dám dọn dẹp vì họ sợ phá vỡ mọi thứ.

Tôi đã có người mô tả các căn cứ mã là "hình phạt tàn khốc và bất thường".

Trải nghiệm cá nhân của tôi không tệ lắm, nhưng tôi đã thấy một vài điều rất kỳ quặc.

Dường như với tôi, bạn đang hỏi làm thế nào công cụ này thậm chí hoạt động nếu không ai đang làm những gì họ phải làm. Và nếu nó hoạt động, vậy tại sao chúng ta phải làm những việc này ?

Câu trả lời, IMHO, là nó hoạt động "đủ tốt" , còn được gọi là triết lý " tệ hơn là tốt hơn " . Về cơ bản, mặc dù lịch sử đầy đá giữa nguồn mở và Bill Gates, cả hai đều thực tế đã áp dụng cùng một ý tưởng, rằng hầu hết mọi người quan tâm đến các tính năng, không phải lỗi .

Tất nhiên điều này cũng dẫn chúng ta đến " bình thường hóa sự lệch lạc " dẫn đến các tình huống như Heartbleed , trong đó, chính xác như để trả lời câu hỏi của bạn, một đống spaghetti khổng lồ, phát triển quá mức của mã nguồn mở có tên OpenSSL đã "bị ô uế " trong khoảng mười năm , cuộn lên với một lỗ hổng bảo mật lớn ảnh hưởng đến hàng ngàn triệu người .

Các giải pháp đã phát minh ra một hệ thống hoàn toàn mới gọi là LibreSSL , được sẽ sử dụng mã sạch-ish , và dĩ nhiên là hầu như không ai sử dụng nó .

Vì vậy, làm thế nào các dự án nguồn mở mã hóa lớn được duy trì? Câu trả lời là trong câu hỏi. Rất nhiều trong số chúng không được duy trì ở trạng thái sạch sẽ. Chúng được vá ngẫu nhiên bởi hàng ngàn người khác nhau để bao gồm các trường hợp sử dụng trên các máy và tình huống lạ khác nhau mà các nhà phát triển sẽ không bao giờ có quyền truy cập để kiểm tra. Mã này hoạt động "đủ tốt" cho đến khi không , khi mọi người hoảng loạn và quyết định ném tiền vào vấn đề .

Vậy tại sao bạn phải bận tâm làm điều gì đó ' đúng cách ' nếu không có ai khác?

Câu trả lời là bạn không nên. Bạn có làm hoặc không , và thế giới tiếp tục thay đổi , bởi vì bản chất con người không thay đổi theo quy mô của một đời người . Cá nhân, tôi chỉ cố gắng viết mã sạch vì tôi thích cảm giác làm việc đó.

Điều gì tạo nên mã tốt phụ thuộc vào bối cảnh và những cuốn sách kinh điển hướng dẫn bạn về điều đó, nếu không quá cũ để thảo luận về nguồn mở, ít nhất là một phần của truyền thống tiến hành cuộc chiến không ngừng chống lại các cơ sở mã hóa xấu trong nhà. Vì vậy, thật dễ dàng để bỏ qua thực tế là các thư viện có mục tiêu hoàn toàn khác nhau và chúng được viết theo đó. Xem xét các vấn đề sau, không theo thứ tự cụ thể:

• Khi tôi nhập thư viện hoặc từ thư viện, có lẽ tôi không đủ chuyên gia về cấu trúc bên trong để biết chính xác phần nhỏ của bộ công cụ tôi cần cho bất cứ điều gì tôi đang làm, trừ khi tôi sao chép những gì Stack Exchange trả lời bảo tôi làm. Vì vậy, tôi bắt đầu gõ from A import(nếu nó bằng Python, nói) và xem những gì sẽ xuất hiện. Nhưng điều đó có nghĩa là những gì tôi thấy cần liệt kê để phản ánh các nhiệm vụ logic mà tôi cần mượn và đó là những gì phải có trong cơ sở mã. Vô số phương pháp trợ giúp làm cho nó ngắn hơn sẽ chỉ làm tôi bối rối.
• Các thư viện ở đó dành cho các lập trình viên thiếu kinh nghiệm nhất đang cố gắng sử dụng một số thuật toán mà hầu hết mọi người chỉ nghe thấy mơ hồ. Họ cần tài liệu bên ngoài, và điều đó cần phản ánh chính xác mã, điều này không thể làm được nếu chúng ta tiếp tục tái cấu trúc mọi thứ để làm cho những người tuân thủ phương pháp ngắn và làm một điều hạnh phúc.
• Mọi phương thức thư viện mà mọi người mượn có thể phá vỡ thế giới với những hậu quả tai hại nếu nó bị gỡ xuống hoặc thậm chí đổi tên. Chắc chắn, tôi ước sklearn sẽ sửa lỗi đánh máy trong Calinski-Harabasz , nhưng điều đó có thể gây ra một sự cố bên trái khác . Trong thực tế, theo kinh nghiệm của tôi, vấn đề lớn nhất đối với sự phát triển của thư viện là khi họ cố gắng hết sức để áp dụng một số "cải tiến" mã mới tốt cho cách họ cấu trúc mọi thứ.
• Trong nhà, các bình luận phần lớn là một điều ác cần thiết nhất, vì tất cả các lý do tôi không cần phải lấy lại (mặc dù những điểm đó đã phóng đại phần nào). Một nhận xét tốt cho biết tại sao mã hoạt động, không phải như thế nào. Nhưng các thư viện biết độc giả của họ là những lập trình viên có năng lực, những người không thể, nói, viết tuyến tính-đại số theo cách của họ ra khỏi túi giấy. Nói cách khác, mọi thứ cần bình luận lại: tại sao nó hoạt động! .
• Giả sử bạn cập nhật một cái gì đó trên Github và chờ xem liệu mã của bạn có được chấp nhận hay không. Nó phải rõ ràng tại sao thay đổi mã của bạn hoạt động. Tôi biết từ kinh nghiệm rằng tái cấu trúc để làm cho khu cắm trại sạch hơn như là một phần của cam kết chức năng thường có nghĩa là rất nhiều việc tiết kiệm dòng, sắp xếp lại và đổi tên, khiến công việc của người đánh giá không có lương của bạn trở nên khó khăn hơn và gây ra các vấn đề khác đã nói ở trên.

Tôi chắc rằng những người có nhiều kinh nghiệm hơn tôi có thể đề cập đến những điểm khác.

Đã có rất nhiều câu trả lời hay - tôi muốn đưa ra quan điểm của một người duy trì nguồn mở.

Góc nhìn của tôi

Tôi là người duy trì rất nhiều dự án như vậy với ít mã hơn. Đôi khi tôi thậm chí còn bị ngăn không cho cải thiện mã như vậy vì những lo ngại về tính tương thích vì các thư viện được tải xuống hàng triệu lần mỗi tuần.

Nó làm cho việc duy trì khó khăn hơn - vì là thành viên cốt lõi của Node.js, có những phần mã tôi sợ chạm vào nhưng có rất nhiều việc phải làm bất kể và mọi người sử dụng nền tảng thành công và tận hưởng nó. Điều quan trọng nhất là nó hoạt động.

Trên mã có thể đọc được

Khi bạn nói:

Tôi đã tìm thấy mã trong nhiều trong số chúng khác xa với các nguyên tắc được đề cập để viết mã sạch - ví dụ: các phương thức chứa hàng trăm dòng mã.

Các dòng mã không phải là thước đo tuyệt vời về mức độ dễ đọc của nó. Trong nghiên cứu tôi liên kết với kernel linux đã được phân tích và một cuộc khảo sát các lập trình viên đã tìm thấy mã "thông thường" (mã mà mọi người mong đợi về cơ bản) và mã nhất quán sẽ tốt hơn mã "sạch". Điều này cũng phù hợp với kinh nghiệm cá nhân của tôi.

Một số dự án nguồn mở không quá hoan nghênh

Linus "nổi tiếng" nói rằng linux không nên có trình gỡ lỗi tích hợp vì những người sử dụng trình gỡ lỗi không đủ tốt để làm việc trên linux và anh ta không muốn thu hút thêm họ.

Cá nhân tôi hoàn toàn không đồng ý với lập trường của anh ấy ở đó - nhưng đó cũng là điều mọi người làm.

Phần mềm nguồn mở không nhất thiết có nghĩa là có nhiều tác giả tham gia. Khi một phần mềm (hoặc đơn vị phần mềm) được viết bởi một tác giả, các chức năng dài xuất hiện thường xuyên.

Điều này xuất phát từ bản chất của quá trình phát triển. Một phương pháp đơn giản được mở rộng theo thời gian, các tính năng mới đang được thêm vào và sửa lỗi.

Các phương pháp dài làm giảm nghiêm trọng sự hiểu biết về chức năng cho các tác giả mới. Tuy nhiên, với một tác giả, điều này hiếm khi là một vấn đề và vấn đề có xu hướng bị bỏ qua. Một bản chất khác của nguồn mở là thực tế là rất nhiều phần mềm không được phát triển tích cực, do đó, không có công việc tái cấu trúc, ví dụ, sẽ chia các phương thức phức tạp thành nhiều phương thức đơn giản.

Bạn đã không đưa ra bất kỳ ví dụ nào nhưng theo hiểu biết của tôi thì điều này cũng thường được kết nối với ngôn ngữ phát triển. Một số ngôn ngữ thực thi các quy tắc nghiêm ngặt ngay từ đầu và kiểm tra đơn vị nặng (hoặc thậm chí TDD). Cả hai thử nghiệm linting và đơn vị thường ngăn chặn vấn đề đó (thật khó để thử nghiệm các phương pháp phức tạp / dài).

Nói chung, khó làm sạch mã hơn nếu phần mềm được phát triển bởi một tác giả duy nhất và những người đóng góp khác chỉ khắc phục các sự cố nhỏ.