Tại điểm / phạm vi nào là một tệp mã quá lớn?

Tôi đang tìm thấy rất nhiều tệp dòng 2-3k và thực sự không cảm thấy chúng nên lớn như vậy.

Một tiêu chí tốt để gọi một cách khách quan một tập tin mã nguồn là "quá lớn" là gì?

Là một mô hình lý tưởng, tôi sử dụng các tiêu chí sau (với lý do tương tự với những gì Martin Beckett đề xuất, nghĩa là suy nghĩ theo cấu trúc logic chứ không phải về các dòng mã):

Quy tắc 1

Một lớp cho mỗi tệp (trong C ++: một lớp -> một tiêu đề và một tệp thực hiện).

Quy tắc 2

Seven được coi là số lượng vật phẩm mà não của chúng ta có thể quan sát cùng một lúc mà không bị nhầm lẫn. Trên 7 chúng tôi thấy khó khăn để giữ một cái nhìn tổng quan về những gì chúng ta thấy. Do đó: mỗi lớp không nên có nhiều hơn 7-10 phương thức. Một lớp có hơn 10 phương thức có lẽ quá phức tạp và bạn nên thử tách nó ra. Chia tách là một phương pháp rất hiệu quả bởi vì mỗi lần bạn tách một lớp, bạn sẽ giảm độ phức tạp của từng lớp ít nhất là 2 lần.

Quy tắc 3

Phần thân phương thức không vừa với một hoặc hai màn hình là quá lớn (tôi giả sử rằng cửa sổ màn hình / trình chỉnh sửa có khoảng 50 dòng). Lý tưởng nhất, bạn có thể thấy toàn bộ phương thức trong một cửa sổ. Nếu đây không phải là trường hợp, bạn chỉ cần cuộn lên xuống một chút, mà không quên phần phương thức bị ẩn. Vì vậy, nếu bạn phải cuộn nhiều hơn một màn hình lên hoặc xuống để đọc toàn bộ thân phương thức, phương thức của bạn có thể quá lớn và bạn có thể dễ dàng mất tổng quan.

Một lần nữa, các phương thức phân tách sử dụng các phương thức trợ giúp riêng có thể giảm độ phức tạp của phương thức rất nhanh (ở mỗi lần phân tách, độ phức tạp ít nhất là giảm một nửa). Nếu bạn giới thiệu quá nhiều phương thức trợ giúp riêng tư, bạn có thể xem xét việc tạo một lớp riêng để thu thập chúng (nếu bạn có nhiều phương thức riêng tư hơn phương thức công khai, có thể lớp thứ hai đang ẩn bên trong lớp chính của bạn).

Tổng hợp những ước tính rất thô sơ này:

• Nhiều nhất một lớp cho mỗi tệp nguồn.
• Nhiều nhất là 10 phương thức công khai cho mỗi lớp.
• Tối đa 10 phương thức riêng cho mỗi lớp.
• Tối đa 100 dòng trên mỗi phương thức.

Vì vậy, một tệp nguồn có hơn 2000 dòng có lẽ là quá lớn và bắt đầu quá lộn xộn.

Đây thực sự là một ước tính rất sơ bộ và tôi không tuân theo các tiêu chí này một cách có hệ thống (đặc biệt là vì không phải lúc nào cũng có đủ thời gian để thực hiện tái cấu trúc đúng cách). Ngoài ra, như Martin Beckett đã đề xuất, có những tình huống trong đó một lớp là một tập hợp lớn các phương thức và sẽ không có ý nghĩa gì khi tách chúng theo một cách nhân tạo chỉ để làm cho lớp nhỏ hơn.

Dù sao, theo kinh nghiệm của tôi, một tệp bắt đầu không thể đọc được khi một trong các tham số trên không được tôn trọng (ví dụ: thân phương thức 300 dòng kéo dài sáu màn hình hoặc tệp nguồn có 5000 dòng mã).

Không - không phải về dòng mã. Các trình điều khiển nên được nhóm hợp lý. Ví dụ, chắc chắn không nên có nhiều lớp trong một tệp lớn

Nếu bạn có một lớp hợp pháp có vài trăm phương thức (không thể nói là mô hình 3D), việc chia nó thành các tệp tùy ý sẽ không thuận tiện hơn nhiều. Chúng ta thường phải làm điều này khi bộ nhớ khan hiếm và bộ xử lý chậm hơn - và đó là một nỗi đau, liên tục tìm kiếm định nghĩa hàm.

Khi mã trong nó trở nên không thể nhầm lẫn. tức là: bạn không thể biết chỉ bằng cách xem mã nếu phương thức / lớp / hàm bạn đang tìm kiếm (và phải chỉnh sửa / gỡ lỗi) có ở đó hay không, và nếu vậy, nó ở đâu.

Mặc dù vậy, lựa chọn và tính năng IDE / Editor của bạn sẽ ảnh hưởng đến định lượng thực tế của giới hạn trên này. Mã gấp , liệt kê chức năng / phương pháp và tra cứu sẽ hoãn lại thời điểm kịch bản phát triển này xuất hiện.

Nhưng khi nó xảy ra, đã đến lúc chia tách nó.

Đây là một cái nhìn khác: bạn đang hỏi về cách giới hạn kích thước tệp. Ý kiến ​​của tôi là có nhiều yếu tố làm cho các tệp mã lớn rất có vấn đề. Đôi khi tệp mã rất lớn nhưng nội dung của nó được phân cụm tốt và mã cực kỳ sạch sẽ, do đó kích thước không gây ra bất kỳ vấn đề đáng kể nào. Tôi đã thấy rất nhiều tệp rất dễ đọc mặc dù LỘC cao.

Thay vì nhấn vào số liệu LỘC, tôi thà nghĩ về việc sử dụng dữ liệu lịch sử để hiểu tần suất mã bị hỏng trong các tệp lớn đó. Thông thường lý do cho điều đó là các nhà phát triển không có thời gian kiên nhẫn để kiểm tra các địa điểm khác có liên quan trong cùng một tệp và thực hiện thay đổi với tâm lý "sửa nhanh" mà không đủ hiểu biết.

Mối nguy hiểm lớn hơn là sự hiện diện của mã sao chép-dán. Sao chép-dán mã hóa tự nhiên cũng tăng tốc độ tăng trưởng LỘC. Tôi nghĩ rằng việc loại bỏ sao chép-dán thậm chí còn quan trọng hơn việc giữ LỘC dưới một số phép thuật. Ngoài việc sao chép thuần túy, còn có một mối nguy hiểm thứ hai trong các tệp lớn: chức năng chồng lấp. Tệp càng lớn, càng có nhiều khả năng bạn sẽ thực hiện lại một số đoạn đã có trong một số phần khác của cùng một tệp.

Vì vậy, miễn là tỷ lệ sửa lỗi (tỷ lệ sửa lỗi cam kết với tất cả các cam kết) là thấp đối với các tệp lớn hơn, tình huống có thể chấp nhận được. Vui lòng thử git logvà đọc lướt qua bao nhiêu lần xác nhận có liên quan đến lỗi. Hoặc sử dụng một công cụ có thể tự động phân tích và trực quan hóa nó, ví dụ Softagram .

Hãy xem xét điều này Metaphor. Khi nói đến độ dài mã, tôi nghĩ chúng ta nên xem xét những điều sau:

The Cat in The Hat (50 pp.)

và

Lord of The Rings (1,178 pp.)

Không có gì sai với Lord of the Rings. Đó là một cuốn sách tuyệt vời. The Cat in the Hatcũng là một cuốn sách tuyệt vời Cả hai có thể được hiểu bởi một đứa trẻ 5 tuổi, nhưng chỉ có một phù hợp hơn do nội dung.

Theo quan điểm của tôi, viết mã nên có ý nghĩa với một đứa trẻ 5 tuổi bất cứ khi nào chúng ta có thể. Cyclomatic Complexitylà một khái niệm quan trọng mà các nhà phát triển có thể cân nhắc khi họ tạo mã. Sử dụng và tạo các thư viện để tăng cường khả năng sử dụng lại mã và mã càng nhiều càng tốt. Bằng cách này, mã của chúng tôi có thể nói nhiều khối lượng hơn những gì chúng ta thấy bằng văn bản.

Hầu hết chúng ta không viết mã lắp ráp . Nhưng gốc của mã của chúng tôi là lắp ráp. Tìm kiếm thông qua lắp ráp 10000 dòng khó hơn 10000 dòng python, nếu nó được thực hiện chính xác.

Nhưng một số công việc yêu cầu viết 500 đến 1000 dòng. Mục tiêu của chúng tôi với mã phải là viết 300 dòng mã sạch.

Là nhà phát triển, chúng tôi muốn viết "Lord of The Rings". Cho đến khi chúng tôi gặp một lỗi và ước chúng tôi viết "Cat in the Hat". Đừng biến mã hóa thành thước đo của bản ngã. Chỉ cần làm cho mọi thứ hoạt động một cách đơn giản.

Các nhà phát triển không muốn viết mã tài liệu, (Tôi thích mã tài liệu cá nhân, tôi không ích kỷ như vậy). Vì vậy, đừng viết mã mà chỉ bạn mới có thể hiểu / đọc. Viết Cat in the Hatmã.

Chúng tôi đều biết bạn là JRR Tolken (trong đầu của bạn). Hãy nhớ rằng bạn sẽ không có gì để chứng minh với mã miễn phí lỗi.

Một lý do khác cho phép ẩn dụ.

Đừng quá mức để người đọc lan truyền sự giàu có. Nếu bạn làm việc với một nhóm người và tất cả họ phải thay đổi cùng một tệp lớn, có lẽ bạn sẽ tự đặt mình vào gitđịa ngục hợp nhất.

Mọi người đều thích nổi loạn.

-> Nói không ai bao giờ!

TL; DR Tập trung vào khả năng đọc. Truyền bá mã của bạn và trợ giúp trên nhiều dòng và tệp nhiều nhất có thể. Đừng ném 8 hoặc 9 lớp vào một tệp, Nó làm cho mã khó đọc và khó bảo trì hơn. Nếu bạn có mã điều kiện hoặc vòng lặp lớn, hãy xem xét thay đổi chúng thành Lambdas nếu ngôn ngữ hỗ trợ nó. Các chức năng tiện ích nên được coi là một con đường tuyệt vời để tăng khả năng đọc mã. Tránh làm tổ nặng.