Người đàn ông thần thoại tháng 10 dòng mỗi ngày nhà phát triển - gần với các dự án lớn như thế nào? [đóng cửa]

Mọi người luôn nói rằng họ có thể đánh bại "10 dòng trên mỗi nhà phát triển mỗi ngày" từ "Tháng huyền thoại" và bắt đầu một dự án, tôi thường có thể nhận được vài trăm dòng trong một ngày.

Nhưng tại nhà tuyển dụng trước đây của tôi, tất cả các nhà phát triển đều rất sắc sảo, nhưng đó là một dự án lớn, hơn một triệu dòng mã, với các yêu cầu chứng nhận rất khó chịu và giao thoa với các dự án nhiều triệu khác. Vào một lúc nào đó, vì tò mò, tôi đã vẽ các dòng mã trong sản phẩm vận chuyển trong nhóm của mình (không tính các công cụ chúng tôi đã phát triển), và chắc chắn, dần dần, nó đã tăng thêm khoảng 12 dòng cho mỗi nhà phát triển mỗi ngày. Không tính các thay đổi, mã kiểm tra hoặc thực tế là các nhà phát triển không làm việc với mã dự án thực tế mỗi ngày.

Những người khác đang làm thế nào? Và những loại yêu cầu nào bạn phải đối mặt (tôi tưởng tượng nó là một yếu tố)?

Tôi nghĩ rằng số lượng dòng được thêm phụ thuộc nhiều vào trạng thái của dự án, tỷ lệ thêm vào một dự án mới sẽ cao hơn nhiều so với tỷ lệ của một dự án bắt đầu.

Công việc là khác nhau giữa hai người - tại một dự án lớn, bạn thường dành phần lớn thời gian để tìm ra các mối quan hệ giữa các bộ phận và chỉ một lượng nhỏ để thực sự thay đổi / thêm. trong khi đó trong một dự án mới - bạn chủ yếu viết ... cho đến khi nó đủ lớn và tỷ lệ giảm.

Trên một trong những dự án hiện tại của tôi, trong một số mô-đun, tôi tự hào đã đóng góp số lượng dòng âm cho cơ sở mã. Xác định các khu vực mã đã phát triển phức tạp không cần thiết và có thể được đơn giản hóa với một thiết kế rõ ràng và rõ ràng hơn là một kỹ năng hữu ích.

Tất nhiên một số vấn đề vốn đã phức tạp và đòi hỏi các giải pháp phức tạp, nhưng trên hầu hết các khu vực dự án lớn có yêu cầu thay đổi hoặc xác định kém có xu hướng có các giải pháp quá phức tạp với số lượng vấn đề trên mỗi dòng cao hơn.

Đưa ra một vấn đề để giải quyết tôi rất thích giải pháp làm giảm số lượng dòng. Tất nhiên, khi bắt đầu dự án nhỏ, tôi có thể tạo ra hơn mười dòng mã mỗi ngày, nhưng tôi có xu hướng không nghĩ về số lượng mã mà tôi đã viết, chỉ những gì nó làm và nó hoạt động tốt như thế nào. Tôi chắc chắn sẽ không đặt mục tiêu đánh bại mười dòng mỗi ngày hoặc coi đó là một thành tích để làm điều đó.

Tôi thích trích dẫn này:

Nếu chúng ta muốn đếm các dòng mã, chúng ta không nên coi chúng là "dòng được sản xuất" mà là "dòng đã chi". - Edsger Dijkstra

Đôi khi bạn đã đóng góp nhiều hơn bằng cách xóa mã hơn là thêm

Bạn nên ngừng sử dụng số liệu này, nó là vô nghĩa đối với hầu hết các phần. Sự gắn kết, khớp nối và độ phức tạp là các số liệu quan trọng hơn các dòng mã.

Những người khác đang làm thế nào?

Tôi là nhà phát triển toàn thời gian duy nhất tại công ty chúng tôi và đã viết 500.000 dòng mã OCaml và F # trong 7 năm qua, tương đương với khoảng 200 dòng mã mỗi ngày. Tuy nhiên, phần lớn mã đó là các ví dụ hướng dẫn bao gồm hàng trăm dự án riêng biệt, mỗi dự án dài vài trăm dòng. Ngoài ra, có rất nhiều sự trùng lặp giữa OCaml và F #. Chúng tôi không duy trì bất kỳ cơ sở mã nội bộ nào lớn hơn 50kLOC.

Ngoài việc phát triển và duy trì phần mềm của riêng chúng tôi, tôi cũng đã tư vấn cho nhiều khách hàng trong ngành trong 7 năm qua. Đối với khách hàng đầu tiên , tôi đã viết 2.000 dòng OCaml trong 3 tháng, đó là 20 dòng mã mỗi ngày. Đối với khách hàng tiếp theo , bốn người chúng tôi đã viết một trình biên dịch tạo ra hàng triệu dòng mã C / C ++ / Python / Java / OCaml cũng như tài liệu trong 6 tháng, là 2.000 dòng mã mỗi ngày cho mỗi nhà phát triển. Đối với một khách hàng khác, tôi đã thay thế 50kLOC của C ++ bằng 6kLOC của F # trong 6 tháng, đó là -352 dòng mã mỗi ngày. Đối với một khách hàng khác , tôi đang viết lại 15kLOC của OCaml trong F # sẽ có cùng kích thước nên 0 dòng mã mỗi ngày.

Đối với khách hàng hiện tại của chúng tôi , tôi sẽ thay thế 1.600.000 dòng mã C ++ và Mathicala bằng ~ 160kLOC của F # trong 1 năm (bằng cách viết trình biên dịch bespoke) sẽ là -6.000 dòng mã mỗi ngày. Đây sẽ là dự án thành công nhất của tôi cho đến nay và sẽ tiết kiệm cho khách hàng của chúng tôi hàng triệu đô la mỗi năm cho các chi phí đang thực hiện. Tôi nghĩ mọi người nên đặt mục tiêu viết -6.000 dòng mã mỗi ngày.

Không thực sự kiểm tra bản sao "Tháng huyền thoại" của tôi (mọi người đọc bản này thực sự nên có sẵn một bản sao), có một chương trong đó Brooks xem năng suất bằng những dòng viết. Điểm thú vị, với anh, không phải là số dòng thực sự được viết mỗi ngày, mà thực tế là nó có vẻ gần giống nhau trong trình biên dịch và trong PL / I (tôi nghĩ đó là ngôn ngữ cấp cao hơn được sử dụng).

Brooks đã không đưa ra một số loại năng suất tùy ý, nhưng anh ta đang làm việc từ dữ liệu trên các dự án thực tế và với tất cả tôi có thể nhớ rằng họ có thể đã đạt trung bình 12 dòng / ngày.

Ông đã chỉ ra rằng năng suất có thể được dự kiến ​​sẽ thay đổi. Ông nói rằng trình biên dịch khó gấp ba lần chương trình ứng dụng và hệ điều hành cứng gấp ba lần trình biên dịch. (Anh ấy có vẻ thích sử dụng bội số của ba loại riêng biệt.)

Tôi không biết liệu anh ta có đánh giá cao sự khác biệt cá nhân giữa năng suất lập trình viên hay không (mặc dù trong một cuộc tranh luận về thứ tự, anh ta đã đưa ra một yếu tố bảy điểm khác biệt), nhưng như chúng ta biết năng suất vượt trội không chỉ là vấn đề viết nhiều hơn mã, nhưng cũng viết đúng mã để thực hiện công việc.

Cũng có câu hỏi về môi trường. Brooks suy đoán một chút về những gì sẽ làm cho các nhà phát triển nhanh hơn hoặc chậm hơn. Giống như nhiều người, anh đặt câu hỏi liệu các mốt hiện tại (gỡ lỗi tương tác sử dụng các hệ thống chia sẻ thời gian) có tốt hơn các cách cũ hay không (lập kế hoạch cẩn thận cho một cảnh quay hai giờ bằng toàn bộ máy).

Cho rằng, tôi sẽ bỏ qua bất kỳ con số năng suất thực tế nào mà anh ta nghĩ ra là vô dụng; giá trị tiếp tục của cuốn sách nằm ở những nguyên tắc và những bài học tổng quát hơn mà mọi người kiên trì không học. (Này, nếu mọi người đã học chúng, cuốn sách sẽ chỉ mang tính lịch sử, giống như tất cả những lập luận của Freud rằng có một cái gì đó giống như một tiềm thức.)

Thật dễ dàng để có được một vài trăm dòng mã mỗi ngày. Nhưng hãy thử để có được vài trăm dòng mã chất lượng mỗi ngày và điều đó không dễ dàng gì. Đầu trang với việc gỡ lỗi và trải qua những ngày có ít hoặc không có dòng mới mỗi ngày và mức trung bình sẽ giảm xuống khá nhanh. Tôi đã dành nhiều tuần để gỡ lỗi các vấn đề khó khăn và câu trả lời là 1 hoặc 2 dòng mã.

Sẽ tốt hơn nhiều khi nhận ra rằng việc nói về các dòng mã vật lý là khá vô nghĩa. Số lượng dòng mã vật lý (LoC) phụ thuộc vào kiểu mã hóa đến mức nó có thể thay đổi thứ tự cường độ từ nhà phát triển này sang nhà phát triển khác.

Trong thế giới .NET có một cách thuận tiện để đếm LoC. Điểm trình tự . Điểm thứ tự là một đơn vị gỡ lỗi, nó là phần mã được tô sáng màu đỏ sẫm khi đặt điểm ngắt. Với điểm thứ tự, chúng ta có thể nói về LoC logic và số liệu này có thể được so sánh qua các ngôn ngữ .NET khác nhau. Số liệu mã LoC logic được hỗ trợ bởi hầu hết các công cụ .NET bao gồm số liệu mã VisualStudio, NDepend hoặc NCover.

Ví dụ: đây là phương pháp 8 LoC (điểm chuỗi thứ tự bắt đầu và kết thúc không được tính đến):

Việc sản xuất LoC phải được tính trong dài hạn. Một số ngày bạn sẽ nhổ hơn 200 LoC, một số ngày khác bạn sẽ mất 8 giờ để sửa lỗi bằng cách không thêm một LoC nào. Một số ngày bạn sẽ xóa mã chết và sẽ xóa LoC, một số ngày bạn sẽ dành toàn bộ thời gian để tái cấu trúc mã hiện có và không thêm bất kỳ LoC mới nào vào tổng số.

Cá nhân, tôi chỉ tính một LoC trong điểm năng suất của riêng mình khi:

1. Nó được bao phủ bởi các bài kiểm tra đơn vị
2. nó được liên kết với một số loại hợp đồng mã (nếu có thể, tất nhiên không phải tất cả LoC đều có thể được kiểm tra bằng hợp đồng).

Trong điều kiện này, điểm số cá nhân của tôi trong 5 năm qua mã hóa công cụ NDepend cho các nhà phát triển .NET là trung bình 80 LoC vật lý mỗi ngày mà không làm giảm chất lượng mã . Nhịp điệu được duy trì và tôi không thấy nó giảm bất cứ lúc nào sớm. Nói chung, NDepend là một cơ sở mã C # hiện có trọng lượng khoảng 115K LoC vật lý

Đối với những người ghét đếm LoC (tôi đã thấy nhiều người trong số họ nhận xét ở đây), tôi xác nhận rằng một khi đã hiệu chỉnh đầy đủ, đếm LoC là một công cụ ước tính tuyệt vời . Sau khi mã hóa và đo lường hàng tá tính năng đạt được trong bối cảnh phát triển cụ thể của mình, tôi đã đạt đến mức tôi có thể ước tính chính xác kích thước của bất kỳ tính năng TODO nào trong LoC và thời gian tôi sẽ đưa nó vào sản xuất.

Không có thứ gọi là viên đạn bạc.

Một số liệu như thế là vô dụng.

Ví dụ, tôi có thư viện lớp của riêng tôi. Hiện tại, số liệu thống kê sau là đúng:

Tổng số dòng: 252.682 Dòng
mã: 127.323
Nhận xét: 99.538 Dòng
trống: 25.821

Giả sử tôi không viết bất kỳ bình luận nào, nghĩa là, 127.323 dòng mã. Với tỷ lệ của bạn, thư viện mã đó sẽ khiến tôi mất khoảng 10610 ngày để viết. Đó là 29 năm.

Tôi chắc chắn đã không mất 29 năm để viết mã đó, vì đó là tất cả C # và C # đã không tồn tại lâu như vậy.

Bây giờ, bạn có thể lập luận rằng mã không tốt lắm, vì rõ ràng tôi phải vượt qua 12 dòng một ngày của bạn, và vâng, tôi sẽ đồng ý với điều đó, nhưng nếu tôi đưa dòng thời gian xuống khi 1.0 được phát hành (và tôi đã không thực sự bắt đầu thực hiện cho đến khi 2.0 được phát hành), tức là 2002/02/13, khoảng 2600 ngày, trung bình là 48 dòng mã mỗi ngày.

Tất cả những dòng mã đó có tốt không? Quái gì không. Nhưng xuống tới 12 dòng mã một ngày?

Quái gì không.

Mọi thứ đều phụ thuộc.

Bạn có thể có một lập trình viên xuất sắc hàng đầu tạo ra mã theo thứ tự hàng ngàn dòng mỗi ngày và một lập trình viên trung bình tạo ra mã theo thứ tự hàng trăm dòng mỗi ngày và chất lượng là như nhau.

Và vâng, sẽ có lỗi.

Tổng số bạn muốn là số dư. Số lượng mã thay đổi, so với số lượng lỗi được tìm thấy, so với độ phức tạp của mã, so với khó khăn trong việc sửa các lỗi đó.

Steve McConnell đưa ra một thống kê thú vị trong cuốn sách "Ước tính phần mềm" (tr62 Bảng 5.2) Ông phân biệt giữa các loại dự án (Avionic, Business, Telco, v.v.) và quy mô dự án 10 kLOC, 100 kLOC, 250 kLOC. Các số được đưa ra cho mỗi kết hợp trong LỘC / Nhân viên. EG Avionic: 200, 50, 40 Hệ thống Intranet (Nội bộ): 4000, 800, 600 Hệ thống nhúng: 300, 70, 60

Có nghĩa là: vd. đối với dự án Avionic 250-kLOC có 40 (LỘC / Tháng) / 22 (Ngày / Tháng) == <2LOC / ngày!

Tôi nghĩ điều này xuất phát từ những ngày phát triển thác nước , trong đó giai đoạn phát triển thực tế của một dự án có thể chỉ bằng 20-30% tổng thời gian dự án. Lấy tổng số dòng mã và chia cho toàn bộ thời gian dự án và bạn sẽ nhận được khoảng 10 dòng / ngày. Chỉ chia thời gian mã hóa và bạn sẽ tiến gần hơn đến những gì mọi người đang trích dẫn.

Codebase của chúng tôi là khoảng 2.2MLoC cho nỗ lực khoảng 150 năm. Điều đó làm cho nó có khoảng 75 dòng c ++ hoặc c # cho mỗi nhà phát triển mỗi ngày, trong toàn bộ vòng đời của dự án.

Tôi nghĩ quy mô dự án và số lượng nhà phát triển tham gia là những yếu tố lớn trong việc này. Tôi vượt xa điều này trong sự nghiệp nhưng tôi đã làm việc một mình suốt thời gian đó nên không mất gì khi làm việc với các lập trình viên khác.

Kế hoạch tốt, thiết kế tốt và lập trình viên tốt. Bạn nhận được tất cả các togheter đó và bạn sẽ không mất 30 phút để viết một dòng. Đúng, tất cả các dự án đều yêu cầu bạn dừng lại và lập kế hoạch, suy nghĩ, thảo luận, kiểm tra và gỡ lỗi nhưng với hai dòng mỗi ngày, mỗi công ty sẽ cần một đội quân để có được tetris để làm việc ...

Điểm mấu chốt, nếu bạn làm việc cho tôi với tốc độ 2 dòng mỗi giờ, tốt hơn là bạn nên lấy cho tôi rất nhiều cà phê và kiểm tra lại các món ăn của tôi để bạn không bị sa thải.

Một người nghi ngờ bit kẹo quản lý lâu năm này được đặt ra khi mọi thứ đều là ứng dụng sys được viết bằng C bởi vì nếu không có gì khác, số ma thuật sẽ thay đổi theo thứ tự độ lớn tùy thuộc vào ngôn ngữ, quy mô và tính chất của ứng dụng. Và sau đó bạn phải giảm giá bình luận và thuộc tính. Và cuối cùng ai quan tâm đến số lượng dòng mã được viết? Bạn có định hoàn thành khi bạn đạt đến 10 nghìn dòng không? 100K? Thế là tùy tiện.

Nó vô dụng.