Việc xem xét các đoạn mã ngẫu nhiên có hữu ích để nhanh chóng xác định chất lượng của một dự án không?

Để có được ý tưởng về chất lượng của một dự án mà tôi chưa từng thấy trước đây (thường là các dự án nguồn mở mà tôi đang cân nhắc có nên sử dụng hay không), tôi thường bắt đầu bằng cách mở các tệp ngẫu nhiên và đánh dấu các chi tiết tốt về mã.

Tôi tìm những thứ như:

• Phong cách (nó tuân theo các quy ước được chấp nhận cho ngôn ngữ và nó có nhất quán không)
• Chất lượng và tính nhất quán của ý kiến
• Gotchas ngôn ngữ cụ thể phổ biến (ví dụ: luôn luôn không sử dụng ===trong javascript)
• Nó trông có cấu trúc logic

Tôi thấy điều này mang lại cho tôi một ý tưởng tốt về kỹ năng của các nhà phát triển đã viết mã, ngay cả khi tôi hoàn toàn không biết gì về việc mã này có nghĩa là gì.

Mọi người có nghĩ rằng điều này là hữu ích? Người ta cần phải tính đến điều gì để nhanh chóng đánh giá chất lượng của cơ sở mã dự án, giả sử không có kiến ​​thức về cách thức hoạt động của nó?

Làm thế nào dễ dàng cho tôi để sửa một lỗi trong mã này?

Bất cứ khi nào tôi gặp một cơ sở mã mới, tôi tự hỏi mình câu hỏi đó.

Nhanh chóng làm quen với mã cho phép tôi xác định điểm chung với (các) nhà phát triển đã tạo ra nó. Tôi có xu hướng tìm kiếm những thứ sau đây (không theo thứ tự cụ thể):

• sử dụng thống nhất các quy ước đặt tên
• ác cảm với việc làm cho mã phức tạp - tuân thủ nguyên tắc KISS
• kiểm tra đơn vị làm việc ra khỏi hộp
• một tệp readme ngắn mô tả dự án với những gợi ý hữu ích để hiểu
• bình luận tốt
• sử dụng các mẫu thiết kế khi thích hợp
• phong cách nhất quán trong ý kiến ​​và bố trí mã
• sử dụng các thư viện hỗ trợ nổi tiếng và được tôn trọng (ví dụ: Boost, Guava, v.v.)
• sự hiện diện của thành ngữ ngôn ngữ

Càng có nhiều thứ ở trên thì tôi càng có niềm tin vào các kỹ năng và kinh nghiệm của các nhà phát triển để khi WTF không thể tránh khỏi?! Khoảnh khắc xảy ra Tôi có xu hướng nhìn vào bản thân mình vì thiếu hiểu biết về miền vấn đề hơn là cho rằng nhà phát triển ban đầu đã mắc lỗi.

Nếu bạn chỉ thực hiện một lựa chọn, có khả năng bạn đã làm sai. :) Ngoài ra, đây thực chất là một mẫu ngẫu nhiên , một cách tiếp cận khá đáng kính để thu thập thông tin trong các trường hợp như bạn mô tả. Để biết thêm chi tiết khoa học về cách thực hiện điều này, hãy nghiên cứu về phương pháp Monte Carlo .

Về những điều cần tìm, hãy xem xét việc tìm kiếm, nghiên cứu và điều chỉnh theo nhu cầu cụ thể của bạn một số danh sách kiểm tra đánh giá mã đã thử và đúng .

Một số khía cạnh khác đáng xem xét khi đánh giá một dự án được liệt kê dưới đây ( kiểm tra danh sách tóm tắt từ kinh nghiệm trước đây của tôi ):

• Các bản phát hành (cùng với changelog), phiên bản và kỷ luật xuất bản Việc
  điều tra các vấn đề nói chung dễ dàng hơn nhiều khi người ta có thể phát hiện ra lỗi trong bản phát hành 1.2.3, có thể tải xuống vào lúcsome URL hơn hai năm trước ai đó đã gửi cho tôi một thư có nhị phân đính kèm .

• Tài liệu dành cho nhà phát triển, tham chiếu API và ví dụ mã
  Giúp tránh các nỗ lực lãng phí khi phát minh lại bánh xe và học tập cơ bản bằng cách dùng thử và lỗi.
  Lưu ý những điều này cũng có thể được lấy mẫu ngẫu nhiên cho một nghiên cứu nhanh chóng.

• Theo dõi lỗi
  Nếu không có theo dõi nào cả, đó là một lá cờ đỏ khổng lồ; nếu có, hãy cân nhắc nhanh chóng kiểm tra nó bằng cách sử dụng phương pháp lấy mẫu ngẫu nhiên giống như bạn làm với mã nguồn

• Phản hồi tích cực
  Tìm hiểu về người dùng dự án và cố gắng thực hiện một nghiên cứu lấy mẫu ngẫu nhiên về phản hồi của họ.

Tôi nghĩ phương pháp này khá tiết lộ các kỹ năng tạo kiểu và khả năng làm cho mã có thể đọc được, nhưng nó không cho biết gì về các kỹ năng giải quyết vấn đề, phân tích, logic của các nhà phát triển làm việc về mã.

Vì vậy, khi bạn phân tích mã theo cách này, bạn chỉ có được thông tin về mức độ "tốt" của mã và liệu nó có thể đọc được hay không. Nhưng bạn vẫn không biết mã được tối ưu hóa, nếu nó hoạt động tốt, nếu nó có cấu trúc tốt, v.v.

Các đặc điểm bạn chú ý là rất quan trọng. Chúng hiển thị nếu mã có thể đọc và duy trì. Nhưng có nhiều lập trình viên đưa ra các giải pháp tuyệt vời nhưng không thực sự chú ý đến các bình luận và kiểu dáng (mà tôi nghĩ là dễ học hơn nhiều so với lập trình).

Vâng, tôi nghĩ rằng đó là một ý tưởng tốt. Các dự án được viết kém có nhiều khả năng bị bỏ rơi.

Nhưng đừng dựa vào quyết định của bạn. Lịch sử mã nguồn imho và số lượng ủy viên là một yếu tố quan trọng hơn nhiều.

Tôi nghĩ rằng nhìn vào các phần nhỏ của mã là một cách tuyệt vời - nếu nó được mã hóa tốt, các biến / lớp / phương thức được đặt tên tốt và nó được nhận xét tốt, sau đó hiểu một phần nhỏ làm gì và mục đích của nó là gì dễ dàng. Nếu bạn gặp khó khăn lớn để hiểu một khối nhỏ (như bất cứ thứ gì niềng răng), thì có lẽ nó không được mã hóa tốt cho tất cả.

trừ khi các mẫu rất nhiều và lớn, rất có khả năng bạn sẽ không có được một mặt cắt tốt của cơ sở mã. Bạn có thể kết thúc với một vài miếng tốt hoặc một vài quả táo xấu khá dễ dàng.