Tôi có nên bị làm phiền nếu tỷ lệ LỘC / ngày của tôi quá cao không? [đóng cửa]


9

Tôi hiện đang làm việc trong một dự án độc lập, vì vậy tôi thực sự không có sự sang trọng trong suốt quá trình kiểm tra con người hoặc đánh giá mã bên ngoài - tuy nhiên, tôi không thấy bất kỳ lỗi khó khăn nào trong mã hiện tại của mình (tôi sửa chúng khi tôi thấy chúng và hầu hết thời gian họ chỉ sai tên trường và những thứ bạn sửa trong một hoặc hai phút) và tôi kiểm tra nó sau khi thực hiện bất kỳ tính năng nào trước khi đẩy nó. Gần đây, số LỘC của tôi là khoảng 400 mỗi ngày (đối với bản ghi, đó là C #) và tôi không chỉ triển khai các hệ thống mới mà còn viết lại những điều tôi đã viết và sửa một số lỗi.

Tôi có nên bị làm phiền? Đây có phải là dấu hiệu tôi cần dừng lại và xem lại tất cả các mã tôi đã viết cho đến ngày hôm nay và cấu trúc lại nó không?


Bạn đo LỘC như thế nào? Có loại trừ mã phòng thu trực quan tạo mã hay không?
jk.

Với lệnh bash này trong thư mục mã của tôi: (tìm ./ -name '* .cs' -print0 | xargs -0 cat) | wc -l
Max Yankov

đúng vì vậy có khả năng bao gồm bất kỳ mã được tạo nào, ví dụ: designer.cs - Tôi sẽ không lo lắng về số lượng dòng bạn đang viết
jk.

Nói chung là có, nhưng với môi trường đặc biệt này (công cụ trò chơi Unity) thì không phải vậy.
Max Yankov

1
Tôi cố gắng loại bỏ càng nhiều dòng mã càng tốt trước khi thêm vào. Làm việc trên một hệ thống tối thiểu là dễ chịu hơn nhiều so với giải pháp thay thế.
Jon Purdy

Câu trả lời:


18

LỘC có lẽ là một trong những số liệu bị lạm dụng nhiều nhất và kết quả có lẽ là một trong những thước đo vô dụng hơn về chất lượng mã, và một phép đo thậm chí còn vô dụng hơn đối với nỗ lực lập trình.

Vâng, đó là một tuyên bố táo bạo để tôi đưa ra, và không, tôi không thể chỉ cho bạn các nghiên cứu chứng minh quan điểm của tôi. Tuy nhiên, tôi có thể nói với kinh nghiệm khó kiếm được rằng khi bạn bắt đầu lo lắng về việc bạn đã viết bao nhiêu mã, có lẽ bạn đang lo lắng về các vấn đề sai.

Trước tiên, bạn cần tự hỏi mình đang cố gắng đo lường hoặc chứng minh điều gì, và liệu bằng chứng này chỉ đơn thuần là không quan tâm hay để hỗ trợ cải thiện chất lượng rộng hơn và nơi bạn cần sử dụng thông tin này để mua từ nhóm của mình / quản lý để làm một cái gì đó về nó.

Một trong những điều mà tôi có xu hướng sử dụng LỘC là một chút kiểm tra độ tỉnh táo. Nếu tôi thấy mình viết rất nhiều mã, tôi trở nên quan tâm hơn đến LỘC mỗi phương thức, hoặc LỘC trên mỗi lớp, thay vì LỘC trên tất cả. Các phép đo này có thể là các chỉ số mà bạn phải tái cấu trúc thêm nếu bạn cảm thấy một chút OCD về việc mã của bạn sẽ được bao nhiêu. Các lớp rất lớn có thể cần phải được cấu trúc lại thành một vài lớp nhỏ hơn và các phương thức nhiều dòng dài có thể cần được chia thành một số phương thức, các lớp khác hoặc thậm chí có thể chỉ ra một số sự lặp lại có thể được loại bỏ. Lưu ý rằng tôi đã sử dụng từ "có thể" nhiều lần ở đó.

Thực tế là LỘC chỉ cung cấp một chỉ báo khả thi và không có gì đảm bảo thực sự rằng mã của bạn có thể cần thay đổi. Câu hỏi thực sự cần đặt ra là liệu mã có hoạt động theo yêu cầu và như mong đợi hay không. Nếu vậy, câu hỏi tiếp theo của bạn là liệu bạn có thể duy trì mã dễ dàng hay không và liệu bạn sẽ có thời gian ngay bây giờ hay trong tương lai để thay đổi mã làm việc để giảm chi phí bảo trì trong tương lai.

Thông thường, rất nhiều mã có nghĩa là bạn sẽ có nhiều thứ để duy trì sau này, nhưng đôi khi ngay cả mã được bao bọc kỹ lưỡng cũng có thể kéo dài tới hàng trăm dòng mã, và vâng, đôi khi bạn có thể thấy mình viết hàng trăm dòng mã trong một ngày. Tuy nhiên, kinh nghiệm cho tôi biết rằng nếu tôi duy trì sản lượng hàng trăm dòng mã mới mỗi ngày, thì thường có nguy cơ phần lớn mã bị cắt và dán không đúng cách từ một nơi khác và bản thân nó có thể chỉ ra vấn đề với trùng lặp và bảo trì, nhưng một lần nữa điều đó không đảm bảo, vì vậy tôi có xu hướng dựa vào những gì kinh nghiệm và bản năng của tôi nói với tôi dựa trên cách hoàn thành các nhiệm vụ trong tay.

Cách tốt nhất để tránh tình trạng khó xử đặt ra trong câu hỏi của bạn IMHO là quên đi LỘC và tái cấu trúc TẤT CẢ thời gian. Viết kiểm tra mã của bạn trước, thực hiện để thất bại, tái cấu trúc để vượt qua, sau đó xem những gì có thể được tái cấu trúc ở đó và sau đó để cải thiện mã. Bạn sẽ rời nhiệm vụ khi biết rằng bạn đã kiểm tra lại công việc của mình và bạn sẽ không lo lắng về việc tự đoán thứ hai trong tương lai. Nói một cách thực tế, nếu bạn sử dụng cách tiếp cận thử nghiệm đầu tiên như tôi đã mô tả, bất kỳ phép đo LỘC / ngày nào trên mã hoàn thành của bạn sẽ thực sự có nghĩa là bạn đã viết 3-5 lần số đo, với nỗ lực đó được ẩn thành công bằng cách tái cấu trúc liên tục của bạn nỗ lực.


1
+1 400 dòng mỗi ngày có thể là một dấu hiệu của một vấn đề, thật không may, tôi nghĩ rằng cách duy nhất để tìm hiểu là xem xét mã, rất khó đối với nhóm 1 người
jk.

Cảm ơn cho một câu trả lời rất chi tiết :) Tôi nghĩ rằng nó hoàn toàn bao gồm chủ đề.
Max Yankov

@jk. Tôi tin rằng tôi giải quyết bình luận của bạn trong bối cảnh câu trả lời của tôi. Khi độc tấu, cách tốt nhất để bảo vệ chất lượng mã của bạn là tập trung vào cách bạn viết và kiểm tra mã của mình. Một bộ thử nghiệm tốt cùng với tâm lý tái cấu trúc liên tục có thể tốt như đánh giá mã theo nhiều cách. Lưu ý rằng tôi không nói là không có đánh giá nào cả, mà là chúng nên là thứ yếu để đảm bảo sản phẩm của bạn đáp ứng yêu cầu và có phạm vi kiểm tra tốt, cho phép tự tin thay đổi trong tương lai. Câu hỏi đầu tiên của tôi trong quá trình xem xét mã luôn là "Bài kiểm tra này ở đâu?" :-)
S.Robins

+1 Mặc dù bạn không thể chỉ ra các nghiên cứu cho thấy rằng LỘC là một số liệu tồi, nhưng rất dễ tìm thấy các nghiên cứu gặp vấn đề vì họ đã sử dụng LỘC làm số liệu.
daramarak

Hoàn toàn đồng ý rằng LỘC là một số liệu vô dụng. Một số ngày tôi viết hàng trăm dòng mã và nó ổn. Mấy hôm nay tôi bằng không. Một số ngày tất cả tôi làm là loại bỏ mã. :-)
Brian Knoblauch

5

Hoàn toàn không - một số ngày bạn đang sửa một lỗi khó tìm và chỉ thay đổi một dòng. Những ngày khác, bạn đang thêm mã mới và viết vài nghìn dòng.

Daily LOC không cho bạn biết bất cứ điều gì ngoại trừ các nhiệm vụ cho ngày hôm đó có thể được thực hiện với 400 dòng mã.


2

Một số câu trả lời bị thiếu điểm, bạn không sử dụng LỘC làm thước đo năng suất (nếu là bạn thì bạn sẽ không lo lắng về việc quá 'hiệu quả'), điều bạn thực sự đang làm là lo lắng về chất lượng mã của mình bởi vì mã là kẻ thù đây là một điều tốt để lo lắng.

Thật không may, cách duy nhất để biết về chất lượng mã là đánh giá mã, vì bạn là một nhóm một người, điều này sẽ rất khó, ngay cả khi bạn đã dừng xem lại mã của mình (và bạn không thực sự muốn dừng lại, phải không?) mã riêng sẽ không tiết lộ nhiều như đánh giá ngang hàng mã của bạn. Tôi khuyên bạn nên cố gắng để người khác xem xét ít nhất một số mã của bạn để bạn có thể biết liệu 400 LỘC / ngày của bạn có phát ra tiếng vô nghĩa hay không. Ngay cả một đánh giá độc lập về mã một ngày sẽ giúp ở đây


1

Bạn không nên bận tâm với số lượng LỘC bạn sản xuất mỗi ngày.

Nhưng bạn nên bận tâm:

  • nếu mã của bạn không được kiểm tra (ví dụ: nếu bạn không có bài kiểm tra đơn vị)
  • nếu bạn bắt đầu gặp sự cố khi thêm các tính năng mới hoặc thay đổi các tính năng đã triển khai (điều đó có nghĩa là việc tái cấu trúc của bạn không phù hợp)
  • nếu trải nghiệm của bạn không lớn và mã của bạn không được xem xét (cặp mắt phụ có thể phát hiện ra vấn đề)

0

LỘC là thước đo năng suất 'chính thức', nhưng các đối số chống lại giá trị của nó có thể kéo dài (ORM có thể tạo ra 50.000 dòng mã trong 3 phút, tuy nhiên, nếu thiết kế cơ sở dữ liệu sai, tất cả mã đó có thể đi vào thùng).

Tôi đề nghị bạn đo lường tiến độ của mình bằng cách theo dõi% nhiệm vụ đã hoàn thành so với thời gian so với% nhiệm vụ được lên kế hoạch hoàn thành. Đây là những gì được tính. Khách hàng trả tiền cho mã làm việc cung cấp giá trị doanh nghiệp không dành cho các LỘC.

Một số tài liệu tham khảo về LỘC


nhưng anh ta không sử dụng LỘC làm thước đo năng suất
jk.

Có, nhưng như tôi đã nói nó không phải là một biện pháp chính xác. Điều tương tự khi bạn sử dụng "giá trị trung bình 1,2.100" bạn sẽ nhận được mức trung bình nhưng nó sai lệch và không chính xác. Với LỘC, mọi thứ trở nên tồi tệ hơn vì mỗi môi trường phát triển và bộ công cụ có thể phản ánh các con số năng suất khác nhau. Ví dụ: các LỘC không thể so sánh độ phức tạp của mã, chỉ độ dài của mã. Tôi đã sửa đổi bài viết gốc với 2 tài liệu tham khảo mà bạn có thể muốn xem.
NoChance

0

Bạn cũng đang đo số lượng mã trùng lặp ?

Nếu sản lượng cao là do bạn có nhiều bản sao và dán mã của bạn thì bạn nên lo lắng.

Lý do: trong trường hợp có lỗi trong bản sao và dán nguồn của bạn, rất khó và dễ bị lỗi để sửa tất cả các cách sử dụng bản sao và dán


-1

Nếu bạn tin vào mã chức năng đẹp, thì đó nên là biện pháp duy nhất của bạn

"Nó có chảy không? Trông nó có đẹp không?"


3
Biện pháp duy nhất? Nó có hoạt động không? nó có đủ nhanh không
jk.

đó là lý do tại sao tôi nói chức năng :)
Darknight 13/03 '
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.