Nhà phát triển C # có thể tạo ra bao nhiêu dòng mã mỗi tháng? [đóng cửa]

Một giám đốc tại nơi làm việc của tôi đã hỏi tôi và nhóm các nhà phát triển của tôi câu hỏi:

Nhà phát triển C # có thể tạo ra bao nhiêu dòng mã mỗi tháng?

Một hệ thống cũ đã được chuyển đến C # và anh ấy muốn biện pháp này là một phần của kế hoạch dự án.

Từ một số nguồn (có vẻ đáng tin cậy), anh ta đã có câu trả lời là "10 SLOC / tháng " nhưng anh ta không hài lòng với điều đó.

Nhóm đồng ý rằng điều này gần như không thể chỉ định vì nó sẽ phụ thuộc vào một danh sách dài các tình huống. Nhưng chúng ta có thể nói rằng người đàn ông sẽ không rời đi (hoặc rất thất vọng về chúng ta) nếu chúng ta không đưa ra câu trả lời phù hợp với anh ta hơn. Vì vậy, ông đã rời đi với câu trả lời tốt hơn nhiều lần về "10 SLOC / ngày "

Câu hỏi này có thể được trả lời không? (trực tiếp hoặc thậm chí với một số phân tích)

Hỏi giám đốc của bạn có bao nhiêu trang hợp đồng mà luật sư của anh ta có thể viết mỗi tháng. Sau đó (hy vọng) anh ta sẽ nhận ra rằng có một sự khác biệt rất lớn giữa việc viết một hợp đồng một trang và viết một hợp đồng 300 trang mà không có sơ hở và mâu thuẫn. Hoặc giữa việc viết một hợp đồng mới và thay đổi một hợp đồng hiện có. Hoặc giữa việc viết một hợp đồng mới và dịch nó sang một ngôn ngữ khác. Hoặc đến một hệ thống luật khác. Có lẽ anh ta thậm chí sẽ đồng ý rằng "các trang hợp đồng trên mỗi đơn vị thời gian" không phải là một thước đo rất tốt cho năng suất của luật sư.

Nhưng để cung cấp cho bạn một số câu trả lời cho câu hỏi thực sự của bạn: Theo kinh nghiệm của tôi, đối với một dự án mới, vài trăm SLOC mỗi ngày và nhà phát triển không phổ biến. Nhưng ngay khi những con bọ đầu tiên xuất hiện, con số này sẽ giảm mạnh.

Nhà phát triển C # có thể tạo ra bao nhiêu dòng mã mỗi tháng?

Nếu họ tốt, ít hơn không.

Chạy theo cách khác ... Bây giờ.

LoC là một trong những số liệu tồi tệ nhất bạn có thể sử dụng.

Các nhà phát triển tồi có khả năng viết nhiều LoC mỗi ngày hơn các nhà phát triển giỏi, nhưng lại tạo ra mã rác.

Tùy thuộc vào độ phức tạp của mã, việc chuyển cổng có thể được thực hiện bằng các quy trình tự động hóa, điều này sẽ dẫn đến hàng ngàn + LoC thay đổi mỗi ngày, trong khi các phần khó hơn trong đó các cấu trúc ngôn ngữ được mã hóa khác nhau được chuyển đến 100LoC mỗi ngày.

Gửi anh ấy để đọc trang Wikipedia trên SLOC . Nếu đưa ra một số ví dụ đẹp và đơn giản về lý do tại sao nó là một số liệu kém như vậy.

Câu trả lời đúng: Không ...

Điều hành này cần được giáo dục, rằng SLOC không phải là số liệu hợp lệ cho tiến trình phân tích

Câu trả lời cẩu thả: Bất kỳ số nào bạn có thể tạo nên.

Chỉ cần cho anh ta một số, bạn và nhóm của bạn có thể dễ dàng làm cho số đó lên. (Bằng cách đặt trừ khi dòng, dòng trống, bình luận, v.v., chỉ để cho phép anh chàng này tiếp tục sống trong thế giới tưởng tượng của mình, và ám ảnh một đội khác và tiếp tục chu kỳ củng cố đau khổ tạo nên một câu chuyện cho thed Dailywtf.

Không đẹp, nhưng có thể.

Ngay từ cái nhìn đầu tiên, câu hỏi này trông hoàn toàn ngu ngốc, và mọi người ở đây chỉ trả lời cho phần C # LoC ngu ngốc của nó. Nhưng có một sắc thái quan trọng - đó là câu hỏi về hiệu suất chuyển . Cách đúng để đặt câu hỏi này là hỏi, có bao nhiêu dòng mã của dự án nguồn (dự án được chuyển) mà một nhà phát triển có thể xử lý trong một đơn vị thời gian nhất định. Đó là một câu hỏi hoàn toàn hợp lý, vì tổng số dòng mã được biết đến, và đó chính xác là số lượng công việc phải hoàn thành. Và cách đúng để trả lời câu hỏi này là thu thập một chút dữ liệu lịch sử - làm việc trong một tuần và đo lường hiệu suất của từng nhà phát triển.

Tôi chỉ có một điều để nói:

Đo lường tiến trình lập trình theo dòng mã giống như đo tiến độ chế tạo máy bay theo trọng lượng.

- Bill Gates

Sau đó, bạn có thể lập luận rằng Bill Gates đã không biết cách tạo ra phần mềm thành công;)

Lưu ý: SLOC là một thước đo rất tốt về độ phức tạp của mã cơ sở!

I 
can
write
large
numbers
of
lines
of
code
per
month.

Trên thực tế, tỷ lệ thuận với số lượng từ.

Bạn thấy quan điểm của tôi?

Tôi có thể có lập trường hơi khác về vấn đề này, nhưng tôi nghĩ tôi có thể hiểu tại sao giám đốc điều hành tìm kiếm thông tin này nếu họ hiện đang lập kế hoạch dự án. Vì khó có thể ước tính thời gian dự án sẽ diễn ra trong bao lâu, một trong những phương pháp được sử dụng (xem: Ước tính phần mềm: Làm sáng tỏ nghệ thuật đen ) là ước tính dự án sẽ mất bao lâu trên cơ sở số lượng SLOC trong các dự án tương tự và bây giờ có thể các nhà phát triển sản xuất trung bình. Trong thực tế, điều này có nghĩa là được thực hiện bằng cách sử dụng các hồ sơ lịch sử mà nhóm có trong tay cho các dự án tương tự với các nhà phát triển tương tự hoặc tương tự.

Tuy nhiên, điều đáng giá là những ước tính này chỉ có ý nghĩa đối với việc lập kế hoạch dự án cơ bản và thực sự không có ý định thiết lập tốc độ của các nhà phát triển cho dự án vì mọi thứ thay đổi từ ngày này sang ngày khác. Do đó, hầu hết những gì bạn đọc khi sử dụng SLOC làm công cụ ước tính là chúng sẽ hoạt động tốt trong thời gian dài nếu bạn đã có kiến ​​thức tốt, nhưng tệ hại khi sử dụng hàng ngày.

Nói chung là một ý tưởng tồi khi gọi sếp của bạn là một thằng ngốc, vì vậy các đề xuất của tôi bắt đầu bằng việc hiểu và thảo luận về các số liệu, thay vì từ chối chúng.

Một số người không thực sự được coi là kẻ ngốc đã sử dụng các số liệu dựa trên các dòng mã. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan và Steve McConnell đều sử dụng chúng. Bạn có thể đã sử dụng chúng ngay cả khi chỉ để nói với đồng nghiệp, mô-đun Thần này là 4000 dòng, nó cần được chia thành các lớp nhỏ hơn.

Có dữ liệu cụ thể liên quan đến câu hỏi này từ một nguồn mà nhiều người trong chúng ta tôn trọng.

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http: //www.codinghorror.com/blog/2005/08/are-all-programming-lacular-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

Tôi nghi ngờ rằng việc sử dụng dòng mã tốt nhất cho mỗi giờ lập trình viên là để cho thấy rằng trong suốt vòng đời của dự án, giá trị này sẽ bắt đầu khá cao, nhưng khi các lỗi được tìm thấy và sửa chữa, các dòng mã mới sẽ được thêm vào để giải quyết các vấn đề không phải là một phần của ước tính ban đầu và các dòng mã được loại bỏ để loại bỏ trùng lặp và cải thiện hiệu quả sẽ cho thấy LỘC / giờ chỉ ra những thứ khác ngoài năng suất.

• Khi mã được viết nhanh, cẩu thả, cồng kềnh và không có bất kỳ nỗ lực tái cấu trúc nào, hiệu quả rõ ràng sẽ ở mức cao nhất. Đạo đức ở đây sẽ là bạn phải cẩn thận cho những gì bạn đo lường.
• Đối với một nhà phát triển cụ thể, nếu họ thêm hoặc chạm vào số lượng mã lớn trong tuần này, tuần tới có thể có một khoản nợ kỹ thuật phải trả về việc xem xét mã, kiểm tra, gỡ lỗi và làm lại.
• Một số nhà phát triển sẽ làm việc với tỷ lệ đầu ra phù hợp hơn so với những người khác. Có thể thấy rằng họ dành nhiều thời gian nhất để có được những câu chuyện hay của người dùng, quay vòng rất nhanh và thực hiện các bài kiểm tra đơn vị tương ứng, sau đó quay lại và nhanh chóng tạo mã chỉ tập trung vào các câu chuyện của người dùng. Điều đáng nói ở đây là các nhà phát triển có phương pháp có thể sẽ quay vòng nhanh, sẽ viết mã nhỏ gọn và làm lại thấp vì họ hiểu rất rõ vấn đề và giải pháp trước khi bắt đầu viết mã. Có vẻ hợp lý rằng họ sẽ viết mã ít hơn vì họ chỉ viết mã sau khi họ nghĩ thông qua, thay vì trước và sau.
• Khi mã được đánh giá cho mật độ khiếm khuyết của nó, nó sẽ được tìm thấy là ít hơn thống nhất. Một số mã sẽ chiếm phần lớn các rắc rối và khiếm khuyết. Nó sẽ là một ứng cử viên để viết lại. Khi điều đó xảy ra, nó sẽ trở thành mã đắt nhất bởi vì mức độ làm lại cao. Nó sẽ có tổng số dòng mã cao nhất (được thêm, xóa, sửa đổi, như có thể được báo cáo từ một công cụ như CVS hoặc SVN), nhưng các dòng mã thấp nhất mỗi giờ được đầu tư. Điều này cuối cùng có thể là sự kết hợp của mã hoặc thực hiện vấn đề phức tạp nhất hoặc giải pháp phức tạp nhất.

Bất kể cuộc tranh luận về năng suất lập trình viên trong các dòng mã hóa ra như thế nào, bạn sẽ thấy rằng bạn cần nhiều nhân lực hơn khả năng của mình và hệ thống sẽ không bao giờ được hoàn thành kịp thời gian. Bạn công cụ thực sự không phải là số liệu. Họ đang sử dụng phương pháp ưu việt, nhà phát triển tốt nhất bạn có thể thuê hoặc đào tạo và kiểm soát phạm vi và rủi ro (có thể bằng phương pháp Agile).

Cung cấp cho anh ta một số liệu tốt hơn để làm việc với

Thay vì LỘC , giải thích đây là những số liệu tồi tệ nhất để sử dụng. Sau đó, đưa cho anh ta một sự thay thế:

Số chức năng / Tính năng cho mỗi tính năng / Yêu cầu chức năng -> NOFF / RFF

Bạn có thể cần thêm trọng số / chuẩn hóa lên trên NOFF / RFF, để phục vụ cho số lượng yêu cầu mỗi tuần.

:) rõ ràng ở trên được tạo thành, nhưng bất cứ điều gì, tốt hơn SLOC ...

Tôi có thể nói với bạn rằng một khối lượng các nhà thầu cho một dự án lớn đã viết 15000 LỘC (mỗi) trong một năm. Đó là một câu trả lời cực kỳ khó hiểu, nhưng nó rất hữu ích với chúng tôi khi chúng tôi có 400.000 C ++ LoC hiện có và chúng tôi có thể hình dung rằng việc chuyển đổi tất cả thành C # sẽ khiến chúng tôi mất khoảng 26 năm để hoàn thành. Cho hoặc nhận.

Vì vậy, bây giờ chúng ta đã biết thứ tự lớn về độ lớn, chúng ta có thể lập kế hoạch tốt hơn cho nó - nhận 20 dev và ước tính công việc một năm cho tất cả chúng sẽ ổn. Trước khi đếm, chúng tôi không biết phải mất bao lâu để di chuyển.

Vì vậy, lời khuyên của tôi dành cho bạn là hãy kiểm tra tất cả các mã bạn đã viết trong một khoảng thời gian cụ thể (tôi may mắn có một dự án mới để làm việc), sau đó chạy một trong nhiều công cụ số liệu mã trên đó. Chia số cho thời gian và bạn có thể cho anh ta một câu trả lời chính xác - bạn thực sự viết bao nhiêu LỘC mỗi ngày. Đối với chúng tôi, nó xuất hiện ở 90 LỘC mỗi ngày! Tôi đoán chúng tôi đã có rất nhiều cuộc họp và tài liệu về dự án đó, nhưng sau đó tôi đoán chúng tôi cũng sẽ có rất nhiều cuộc họp và tài liệu về cuộc họp tiếp theo :)

Âm thanh về chính xác.

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

Nếu bạn tính đến việc gỡ lỗi, tài liệu, lập kế hoạch, vv Nó trung bình khoảng 10 dòng mã mỗi ngày. Trên thực tế tôi sẽ đánh giá 10 dòng một ngày ở phía cao (tức là một nhà phát triển rất năng suất).

Mặc dù bạn có thể tạo ra vài trăm dòng trong một ngày (điều này không bền vững). Nó không phải là mã chất lượng cho đến khi bạn đã thêm tất cả các đơn vị kiểm tra tài liệu và tất nhiên đã gỡ lỗi mã sau khi kiểm tra đơn vị của bạn hiển thị các lỗi. Sau khi hoàn thành, bạn trở lại 10.

Tôi đoán là, một nhà phát triển làm việc với một ngôn ngữ như C # sẽ có thể viết / tạo khoảng 10K LoCs / ngày. Tôi cho rằng, tôi có thể làm điều đó. Tôi chỉ không bao giờ sẽ.

Những gì bạn muốn của một nhà phát triển là, để hoàn thành công việc của mình trong 10 LoC / ngày. Ít mã hơn luôn luôn tốt hơn. Tôi thường bắt đầu sản xuất một số lượng lớn mã và sau đó cắt đi cho đến khi tôi đạt đến mức tối đa đơn giản, vì vậy tôi thực sự có những ngày có LoC âm.

Theo một nghĩa nào đó, mã hóa giống như thơ. Câu hỏi không phải là, một nhà thơ có thể viết bao nhiêu dòng, mà là anh ta có thể truyền đạt bao nhiêu trong 14 dòng sonnet.

Hãy để người quản lý của bạn xử lý nó, hoặc bắt đầu săn việc.

Nói một cách nghiêm túc, bạn có thể dành thời gian cho những gì cuối cùng có thể là một nỗ lực vô vọng trong việc giải thích cho giám đốc điều hành các phương pháp đúng đắn và không chính xác để đo lường tiến độ của dự án để hoàn thành. Trong tất cả thực tế, những gì các nhà quản lý kỹ thuật và dự án là dành cho.

Mặt khác, các tình huống như vậy mà người điều hành nghi vấn là kỹ sư và / hoặc người quản lý dự án của bạn. Bạn có nhiều vấn đề lớn hơn và cơ bản hơn để giải quyết, ngay cả khi chúng chưa tự tiết lộ. Trong trường hợp này, một vấn đề như thế này có thể đóng vai trò là "phát súng cảnh báo" cho những vấn đề lớn hơn sắp xảy ra.

Các câu trả lời khác là chính xác, đó là một câu hỏi ngớ ngẩn và câu trả lời không có nghĩa là một điều chết tiệt. Tất cả đều đúng, nhưng tôi tình cờ biết được tôi đã tạo ra bao nhiêu dòng mã trong khoảng một tháng.

Đó là khoảng 3000 dòng mã C # không có XML-doc. Tôi đã thực hiện chức năng mới và kết thúc với số tiền này trong một tháng hoặc một tháng và một tuần. Đó là tất cả những gì kết thúc trong kiểm soát nguồn, rất nhiều mã được viết và sau đó được cấu trúc lại hoặc xóa.

Tôi là một nhà phát triển C # và tôi đang cố gắng để giỏi về nó, nhưng tôi không thể nói cho bạn biết tôi khách quan đến mức nào. Tôi đã cố gắng viết mã tốt và nỗ lực rất nhiều để làm cho nó dễ bảo trì. Tôi chỉ đưa ý kiến ​​một hoặc hai lần trong mã này.

Tôi không biết rằng đó là quá nhiều hoặc quá ít dòng mã và tôi phải nói rằng tôi không thực sự quan tâm. Đó là một phần dữ liệu vô nghĩa và nó không thể được sử dụng một cách an toàn để ngoại suy theo bất kỳ cách nào. Nhưng tôi tình cờ biết dữ liệu này nên tôi quyết định chia sẻ.

Chà, tôi đến bữa tiệc này hơi muộn như thường lệ, nhưng đây thực sự là một điều thú vị. Ban đầu tôi cũng có suy nghĩ giống như hầu hết câu hỏi của giám đốc điều hành. Tuy nhiên, tôi đã đọc câu trả lời của SK-logic và nhận ra rằng đó là một câu hỏi hợp lý được hỏi theo cách vô nghĩa. Hoặc, đặt khác nhau, có một vấn đề hợp lệ đằng sau câu hỏi.

Các nhà quản lý thường cần phải cố gắng xác định tính khả thi, tài trợ, nhân sự, vv cho một dự án. Đây là một vấn đề hợp lý. Đối với một cổng Straightford, một ước tính dựa trên các dòng mã được chia cho các dòng mã trung bình ước tính cho mỗi nhà phát triển mỗi ngày là đơn giản, nhưng sẽ thất bại vì tất cả các lý do được đưa ra trên trang này.

Một cách tiếp cận hợp lý hơn sẽ là: -

1. Đối với ước tính tại chỗ, hãy hỏi các nhà phát triển có nhiều kinh nghiệm nhất với mã để ước tính ruột về thời gian cần thiết. Điều này chắc chắn là không chính xác vì nhiều lý do mà tôi sẽ không đi vào đây, nhưng đó là điều tốt nhất mà họ sẽ có thể làm ngay từ đầu. Ít nhất họ nên có một ý tưởng cho dù nó sẽ được thực hiện dễ dàng trong một tuần hoặc nhiều năm ngay cả với các nguồn lực bổ sung. Nếu đã có bất kỳ cổng hoặc phần công việc có kích thước tương tự được thực hiện, họ có thể sử dụng điều này như một hướng dẫn.
2. Ước tính cổng theo thành phần để có tổng kích thước. Các nhiệm vụ không liên quan trực tiếp đến cổng cần được đưa vào, chẳng hạn như thiết lập cơ sở hạ tầng (máy móc, hệ thống xây dựng, v.v.), điều tra và mua phần mềm, v.v.
3. Xác định các thành phần rủi ro nhất của cổng và bắt đầu với các thành phần đầu tiên. Chúng có khả năng thổi bay ước tính nhiều nhất, vì vậy nên được thực hiện trước nếu có thể để có những bất ngờ hạn chế vào cuối cảng.
4. Theo dõi tiến trình so với kích thước được thực hiện trong bước 2 để liên tục tính toán thời lượng dự kiến ​​của cổng. Khi dự án di chuyển về phía trước, điều này sẽ trở nên chính xác hơn. Tất nhiên, số lượng dòng mã đã được chuyển (các tính năng trong cơ sở mã gốc hiện có trong mã được chuyển) cũng có thể được sử dụng làm số liệu và thực sự hữu ích để đảm bảo rằng sản phẩm ban đầu được chuyển chứ không phải là một loạt các chức năng mới thú vị được thêm vào trong khi không xử lý cổng thực tế.

Đây sẽ là những bước chân thực, tất nhiên có nhiều hoạt động khác xung quanh việc này rất hữu ích như điều tra các công cụ porting và khung có thể cắm, tạo nguyên mẫu, xác định những gì thực sự cần được chuyển, sử dụng lại các công cụ kiểm tra và cơ sở hạ tầng, v.v.