Làm thế nào để thuyết phục mọi người rằng một lớp duy nhất với 11975 dòng mã là xấu? (phải không?)

Question

Tôi có cảm giác dejavu khi đọc [What to do about a 11000 lines C++ source file?] bài đăng, nhưng tôi không nghĩ rằng mình có thể tự mình bắt đầu hành động vì tôi không có quyền hành động. Vì vậy, tôi nghĩ rằng bước đầu tiên là thuyết phục mọi người trong tổ chức rằng một khối mã lớn là xấu.

Tôi có tình huống tương tự khi có một lớp duy nhất với 11975 dòng mã và mỗi lần có các tính năng mới, có khả năng cao là lớp này sẽ ngày càng lớn hơn.

Answer 1

Bạn có cảm tình của tôi. Bất kỳ lớp học nào lớn như vậy chắc chắn sẽ phá vỡ Single Responsibility Principle, khiến việc duy trì khó khăn.

lời khuyên tốt nhất của tôi là để lãnh đạo bằng ví dụ:

• Giữ mã mới của bạn nhỏ.
• Refactor không thương tiếc khi thay đổi mã để giảm kích thước của lớp và chức năng.

Mã của bạn sẽ tỏa sáng như đèn hiệu so với mã cũ và nhóm của bạn sẽ hiểu mã nào dễ bảo trì hơn.

Answer 2

Có một lớp học lớn không phải là xấu. Nếu lập trình viên có thể quản lý và hiểu nó, thì đó là một lớp hoàn hảo. Nếu lập trình viên bị mất hoàn toàn khi anh ta/cô ấy cố thay đổi hoặc thêm thứ gì đó vào lớp, thì điều đó là xấu.

Với lập trình, tất cả đều là tùy chọn. Nếu họ muốn có một lớp duy nhất của 11975 dòng mã, và họ có thể quản lý nó, thì đó là sự lựa chọn của họ.

Nhưng có, nói chung là xấu.

Answer 3

Nếu lớp này bao gồm nhiều phương pháp nhỏ hơn VÀ các phương pháp này thực sự thuộc về lớp, tức là chúng được gắn kết với nhau và lớp, thì điều này không nhất thiết là xấu.

Thực tế là một lớp lớn không làm cho nó tự động xấu.

Điều quan trọng hơn là tránh cái gọi là "lớp thần" có chứa nhiều phương pháp không có mối quan hệ khái niệm với nhau hoặc chính lớp đó.

Giữ kích thước của các phương pháp riêng lẻ cũng đáng chú ý vì hầu hết các nhà phát triển sẽ cần "tải" toàn bộ phương pháp vào bộ não của họ cùng một lúc chứ không phải toàn bộ lớp. Vì vậy, càng súc tích thì phương pháp càng dễ dàng để các nhà phát triển duy trì.

Bạn nên thu thập số liệu về số lượng sự cố hỗ trợ có thể được truy nguyên ngược lại mã trong lớp này. Ngoài ra, các nhà phát triển dành ra bao lâu để thực hiện các thay đổi đối với lớp này so với các lớp học nhỏ hơn? Khi bạn có các chỉ số này, bạn đang ở vị trí tốt hơn để giải thích cho quản lý lý do tại sao một lớp học lớn như vậy không tốt.

Trong trường hợp của một lớp lớn với một số lượng nhỏ các phương pháp lớn, tôi sẽ sử dụng các kỹ thuật tái cấu trúc được mô tả trong Martin Fowlers book, cùng với các bài kiểm tra đơn vị để đảm bảo không có lỗi mới được giới thiệu.

Khi bạn đã tái cấu trúc một phương pháp khổng lồ xuống một số phương pháp dễ hiểu hơn và có các thử nghiệm đơn vị thành công, chỉ cần chứng minh điều này cho đồng nghiệp của bạn.Tại thời điểm này, nếu đồng nghiệp của bạn không đồng ý hoặc không thể thấy sự cải thiện chung về tính dễ hiểu và khả năng bảo trì của mã được tái cấu trúc, bạn đang xử lý vấn đề chính trị/cá tính. Trong trường hợp đó, tùy thuộc vào bạn nếu bạn muốn tiếp tục làm việc trong môi trường như vậy.

Answer 4

11975 (hoặc là 12000 đã :)) dòng thực hiện lớp học. Nó có tồi không? Cerainly trông như vậy. Nhưng ...

Điều đó tùy thuộc. Thông thường các lớp thực hiện mẫu Dàn xếp hoặc mẫu Mặt tiền có xu hướng rất lớn. Họ có giao thức định tuyến/truyền thông rất phức tạp. "Thiên Chúa" như các lớp học cũng có xu hướng rất lớn và nguyên khối. Tóm lại, một lớp học thực sự có thể lớn nhưng có thể không phải là một vấn đề.

Vì vậy, thay vì tập trung vào LOC làm tham số, hãy tập trung vào chức năng/thiết kế của lớp. Lớp học có vi phạm Nguyên tắc về trách nhiệm duy nhất không? LOC một mình không thể là yếu tố quyết định duy nhất để kết luận nếu một lớp thực sự là rất lớn. Xem xét các số liệu khác, ví dụ: Phức tạp cyclomatic.

Tuy nhiên, nếu bạn kết luận rằng điều này thực sự xấu trong ngữ cảnh của dự án, bạn phải có lý do chính đáng để thuyết phục các bên liên quan có liên quan. Ví dụ:

a. Lớp học này có nhiều lỗi không?

b. Các bản sửa lỗi của lớp này có luôn giới thiệu các lỗi hồi quy không? (Khớp nối cao, sự kết dính thấp?)

c. Mất bao lâu để sửa lỗi trong lớp học này? Điều này so sánh với các mô-đun khác như thế nào?

d. Tạo một vài sơ đồ UML cho mô-đun này để minh họa các vấn đề quan trọng (ví dụ: ghép nối).

e. Đọc nhiều về số liệu/tham khảo nhóm Chất lượng/Chỉ số/QA của bạn và tạo đủ điểm dữ liệu. Ví dụ về số liệu OOAD là here nhưng tôi chắc chắn có rất nhiều.

CHỈNH SỬA 2 (một số thay đổi nhỏ)

f. Nhận hỗ trợ ban đầu từ một số bên liên quan chính trong lĩnh vực kiểm soát của bạn. Tiếp theo, có được, một người có thể trình bày những sự kiện này tốt !. Tôi đã thấy nhiều điều thất bại ở giai đoạn này !.

Chúc may mắn!

Answer 5

Yêu cầu họ tóm tắt những gì lớp học \ đại diện trong một phút.

Answer 6

Dưới đây là phản ứng ban đầu của tôi:

1. Có không có nơi để cấu trúc lại để giảm SLOC? Bạn đã thử tái cấu trúc trước, trước bất cứ điều gì khác?
2. Có phải nó đang xử lý nhiều trách nhiệm hay như một áp phích khác được nêu là một Mặt tiền?
3. Có nhiều macro được xử lý trước được tích hợp vào mã do đó làm cho "nhỏ hơn" so với thực tế dường như không?
4. Có bất kỳ câu lệnh truy vấn kiểu SQL nào đang được xây dựng không? Tôi đã nhìn thấy chúng chiếm khá nhiều không gian và nhanh chóng thêm vào SLOC mà không nhất thiết phải là chỉ số về chất lượng mã kém.
5. Mã này được lắp ráp như thế nào và dưới áp lực nào? Lịch sử của mã là gì?Tôi đã chỉ nhìn thấy mã như thế này (và sản xuất một số bản thân mình) khi lịch trình đã được nigh biên giới điên rồ. Có lẽ đó là một "... tạo ra trong 6 ngày, thứ 7 để nghỉ ngơi" loại vội vàng khổng lồ nhưng không bao giờ cố định.
6. Các nhà phát triển khác có thực sự là nhà phát triển không?

Không có đề xuất nào ở đây ngoại trừ refactor những gì bạn có thể. Tìm bất cứ chức năng nào vi phạm D-R-Y và sau đó chà sạch nó.

Answer 7

Thuyết phục bất kỳ ai thay đổi việc triển khai hiện tại (đặc biệt nếu "hoạt động") không dễ dàng.

Tôi sẽ bắt đầu với việc yêu cầu đối thủ thực hiện nhiệm vụ tầm thường (từ kinh nghiệm của tôi với các lớp cực đoan như vậy, tôi tin rằng có vài phương pháp đủ lớn) như thêm một thứ gì đó vào một trong những phương pháp rất lớn. Nó nên dạy cho họ một bài học: tìm đúng chỗ sẽ thực sự đau đớn. Sau đó, bạn có thể hỏi: "tưởng tượng bạn hỗ trợ lớp này, nó sẽ là một nhiệm vụ dễ dàng?".

Bạn có thể thử cách tiếp cận khác, nhưng có thể sẽ không thành công: yêu cầu họ viết kiểm tra đơn vị cho mã này. Hoặc đơn giản yêu cầu họ suy nghĩ về bất kỳ ...

Answer 8

Về cơ bản những người đó không có kiến ​​thức về oops? Làm OOAD trước khi bắt đầu dự án là ý tưởng tốt hơn để tránh điều này, từ kinh nghiệm của tôi tôi có thể nói rằng mọi lập trình viên không có kiến ​​thức về oops, vì vậy rõ ràng họ không thể viết một mã tốt hơn.

Đây là nơi mà sự khác biệt đi kèm với một lập trình viên và analyst-