Tôi phải chịu trách nhiệm bao nhiêu mã?


12

Thông qua các đồng nghiệp và các cuộc phỏng vấn xuất cảnh, tôi đã nghe nói rằng tại công ty nhỏ của mình, tôi "chịu trách nhiệm" về bất cứ nơi nào từ mã gấp 3-10 lần so với khi tôi làm việc khác. Tôi đang cố gắng tìm kiếm một số loại số liệu mờ mà tôi có thể sử dụng để so sánh khối lượng công việc của mình với các số liệu khác trong lĩnh vực của mình.

Theo "trách nhiệm mã", tôi không có nghĩa là "Tôi là người duy nhất biết khu vực X của cơ sở mã" (thật đáng buồn, điều đó thường đúng trong môi trường khởi động), nhưng lại đề cập đến một số như "code_base_size / number_of_developers ".

Có tài nguyên nào tôi có thể sử dụng để giúp tôi đo chính xác tải công việc của mình hơn là chỉ đếm các dòng mã không?


8
Các dòng mã không nhất thiết là một phép đo chính xác về độ phức tạp hoặc khối lượng công việc.

3
Do đó, câu cuối cùng của tôi :)
Michael

2
@ ThorbjørnRavnAndersen: "Chính xác"? Tôi nghĩ bạn có thể có ý gì khác. Đó là về biện pháp duy nhất thực sự chính xác (và chính xác). Barry Boehm (Kinh tế Kỹ thuật phần mềm) đã chứng minh rằng đó là về biện pháp hợp lý duy nhất. Điều đó làm cho nó vô dụng để ước tính dự án. Nhưng như một biện pháp hồi cứu dự đoán nỗ lực và thời gian, nó tốt hơn nhiều so với bất kỳ biện pháp nào khác.
S.Lott

Câu trả lời:


12

Biện pháp cụ thể duy nhất cho một nhà phát triển được tuyển dụng là số giờ dành cho việc mã hóa và sửa lỗi và số tiền bạn được trả cho việc đó. Nếu bạn ở lại muộn vào ban đêm 6 ngày một tuần với giá 50 nghìn đô la Mỹ một năm, thì bạn có vấn đề. Cho dù sếp của bạn muốn bạn chịu trách nhiệm bao nhiêu dòng mã, bạn sẽ không xử lý nhiều hơn bạn có thể làm, có tính đến chất lượng mã nhất định. Phát triển mã chất lượng kém mà không có kiểm tra đơn vị là một cách tốt để xử lý nhiều mã hơn, nhưng công ty sẽ phải trả giá của một khoản nợ kỹ thuật lớn .

Trong các công ty nhỏ, các nhà phát triển có xu hướng chịu trách nhiệm về mã nhiều hơn so với trong công ty lớn . Yếu tố 3 đến 10 mà bạn đang đề cập có vẻ thực tế đối với tôi.


6

Tôi đã biết một nhóm ba người quản lý một codebase 1,5 triệu dòng và không bị chìm trong đó. Phép đo quan trọng không phải là bạn chịu trách nhiệm về bao nhiêu mã, mà là bạn cần thay đổi bao nhiêu mã trong một khoảng thời gian nhất định.

Ngoài ra còn có góc độ đánh giá rủi ro. Nếu bạn là người duy nhất biết một đoạn mã, chi phí cơ hội sẽ bị mất nếu bạn đi dưới xe buýt là bao nhiêu? Các công ty nhỏ thường không thực hiện đánh giá rủi ro như vậy, nhưng điều này có nghĩa là sự thành công liên tục của doanh nghiệp là cơ hội.


3

mã kích thước cơ sở / số lượng nhà phát triển không liên quan đến khối lượng công việc. Nếu bạn có một cơ sở mã ổn định lớn, số liệu đó sẽ cao. Nếu bạn có một cơ sở mã nhỏ vẫn đang được phát triển, số liệu đó sẽ thấp. các dòng thay đổi trên một đơn vị thời gian trên mỗi nhà phát triển có liên quan nhiều hơn đến khối lượng công việc. Nhưng ngay cả sau đó, tôi đã dành nhiều ngày để theo dõi các lỗi tinh vi có sửa lỗi là một dòng ...


2

Mã phải là trách nhiệm của nhóm không phải của một nhà phát triển. Hỗ trợ nên được ủy thác công bằng mỗi tuần, có vẻ ngu ngốc khi phân bổ nó theo bất kỳ cách nào khác. Nếu đó không phải là trường hợp tôi đề nghị bạn nói chuyện với quản lý của bạn.

Trong tình huống một nhà phát triển mô tả của bạn có thể đang vật lộn để đáp ứng thời hạn vì có một lượng lớn hỗ trợ từ một khu vực nơi các nhà phát triển khác đang làm việc. Đó là một cấu trúc quản lý rất không hiệu quả.

Ngoài ra tôi đề nghị bạn tránh xa việc đo khối lượng công việc trong các dòng mã. Man giờ là số liệu hợp lý duy nhất tôi có thể nghĩ đến

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

Lưu ý Tôi không nói bình đẳng Tôi đang nói một cách công bằng. Nó cũng đáng lưu ý rằng nó tốt để chuyên về các khía cạnh nhất định của cơ sở mã, điều đó xảy ra một cách tự nhiên. Nó chỉ là một vấn đề nếu không ai khác làm việc trên mã đó.


Tôi nên rõ ràng hơn - tôi đã cố gắng tìm cách đo lường khối lượng công việc của mình bằng cách TRÁNH nói rằng "mã này là trách nhiệm của tôi - và tôi một mình duy trì nó." Ví dụ: nếu Facebook có 2 lập trình viên, rõ ràng họ sẽ làm việc quá sức - nhưng bạn sẽ đi đến kết luận đó như thế nào? Đó là loại câu hỏi tôi sẽ đặt ra.
Michael

2

Ví dụ: nếu Facebook có 2 lập trình viên, rõ ràng họ sẽ làm việc quá sức - nhưng bạn sẽ đi đến kết luận đó như thế nào? Đó là loại câu hỏi tôi sẽ đặt ra.

Đây không phải là một câu hỏi lập trình, nó là một câu hỏi quản lý.
Có một vài câu hỏi dễ trả lời và chúng không liên quan gì đến phần mềm.

  1. Bạn làm việc bao nhiêu giờ
  2. Bạn nên làm việc bao nhiêu giờ?
  3. Thời hạn được đáp ứng?

Sau đó, làm theo logic này:

  • Nếu 1> 2, bạn cần nhiều người hơn hoặc thời hạn ít tích cực hơn.
  • Nếu 1 <2, bạn cần ít người hơn hoặc nhiều sáng kiến ​​hơn.
  • Nếu thời hạn không được đáp ứng và 1> = 2, bạn cần thêm người.
  • Nếu thời hạn không được đáp ứng và 1 <2, bạn nên sa thải ai đó.

Đây là một sự đơn giản hóa có hai lỗ hổng rõ ràng.

  • Mọi người không được tạo ra bằng nhau.
  • Có nhiều cách để khiến mọi người sản xuất nhiều hơn (nâng cấp máy tính của họ hoặc một cái gì đó).

Nhưng bạn hiểu ý rồi đấy.

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.