얼마나 많은 코드를 책임 져야합니까?

13

동료와 퇴사 인터뷰를 통해 저는 소규모 회사에서 다른 직장에있을 때보 다 3-10 배 더 많은 코드에 대해 "책임"이 있다고 들었습니다. 내 워크로드를 내 분야의 다른 워크로드와 비교하는 데 사용할 수있는 일종의 퍼지 메트릭을 찾으려고합니다.

"코드 책임"이라는 말은 "코드베이스의 X 영역을 아는 유일한 사람"이라는 의미는 아니지만 (슬프게도 시작 환경에서는 사실임) "code_base_size"와 같은 숫자를 의미합니다 / number_of_developers "

코드를 세는 것보다 작업 부하를보다 정확하게 측정하는 데 사용할 수있는 리소스가 있습니까?

metrics

— 남자 이름
소스

8

코드 줄이 복잡성이나 작업량을 정확하게 측정 할 필요는 없습니다.

3

마지막 문장 :)

— Michael

2

@ ThorbjørnRavnAndersen : "정확한"? 다른 의미가 있다고 생각합니다. 실제로 정확하고 정확한 유일한 측정 방법입니다. Barry Boehm (Software Engineering Economics)은 이것이 유일하게 합리적인 척도임을 입증했습니다. 따라서 프로젝트 추정에 쓸모가 없습니다. 그러나 노력과 지속 시간을 예측하는 후 향적 조치로서 다른 것보다 훨씬 낫습니다.

— S.Lott

12

고용 된 개발자를위한 구체적인 방법은 버그를 코딩하고 수정하는 데 소요되는 시간과 그에 대한 비용입니다. 연중 무휴로 일주일에 6 일 밤 늦게 머물러 있다면 문제가있는 것입니다. 상사가 책임지고 싶어하는 코드 줄 수에 관계없이 특정 코드 품질을 고려하여 할 수있는 것보다 더 많은 것을 처리하지는 않습니다. 단위 테스트없이 품질이 낮은 코드를 개발하는 것은 훨씬 더 많은 코드를 처리하는 좋은 방법이지만 회사는 큰 기술 부채 비용을 지불해야합니다 .

소규모 회사 에서는 개발자가 대기업 보다 훨씬 더 많은 코드를 담당하는 경향이 있습니다 . 당신이 언급하는 요소 3-10은 나에게 현실적으로 보입니다.

— 패트릭 스카 치아-NDepend dev
소스

6

150 만 라인 코드베이스를 관리하고 익사하지 않은 3 인 팀을 알고 있습니다. 중요한 측정은 사용자가 담당하는 코드의 양이 아니라 특정 시간 단위로 변경해야하는 코드의 양입니다.

위험 평가 각도도 있습니다. 코드를 아는 유일한 사람이라면 버스를 타면 기회 비용이 어떻게됩니까? 소규모 회사는 일반적으로 그러한 위험 평가를 수행하지 않지만 이는 비즈니스의 지속적인 성공이 우연히 남아 있음을 의미합니다.

— 조리 세브 레흐트
소스

3

코드베이스 크기 / 개발자 수는 작업량과 관련이 없습니다. 매우 안정적인 코드 기반이있는 경우 해당 메트릭이 높아집니다. 개발중인 작은 코드 기반이있는 경우 해당 메트릭이 낮습니다. 개발자 당 시간 단위당 줄 변경은 작업량과 더 관련이 있습니다. 그러나 그때까지도 수정이 한 줄의 미묘한 버그를 추적하는 데 며칠을 보냈습니다 ...

— 프로그래머
소스

2

코드는 한 개발자가 아닌 그룹의 책임이어야합니다. 지원은 매주 공정하게 위임되어야하며 다른 방법으로 할당하는 것은 어리석은 것 같습니다. 그렇지 않은 경우 경영진과 상담하시기 바랍니다.

상황에 따라 한 개발자가 다른 개발자가 작업중인 한 영역의 많은 지원으로 인해 한 개발자가 마감일을 맞추기 위해 고심하는 데 어려움을 겪을 수 있습니다. 매우 비효율적 인 관리 구조입니다.

또한 코드 단위로 워크로드를 측정하지 않는 것이 좋습니다. 맨 아워는 내가 생각할 수있는 유일한 합리적인 척도

코드 라인으로 프로그래밍 진행률을 측정하는 것은 무게로 항공기 건물 진행률을 측정하는 것과 같습니다-Bill Gates

NB. 나는 공정하게 말하는 것이 똑같지 않다. 또한 자연스럽게 발생하는 코드베이스의 특정 측면을 전문화하는 것이 좋습니다. 아무도 그 코드를 다루지 않는 경우에만 문제가됩니다.

— 톰 스콰 이어스
소스

더 명확 했어야합니다. "이 코드는 내 책임입니다. 그리고 혼자서도 유지합니다."라는 말을 피함으로써 작업 부하를 측정 할 수있는 방법을 찾고있었습니다. 예를 들어, 페이스 북에 프로그래머가 2 명이라면 분명히 과로 할 것입니다. 그러나 어떻게 그 결론에 도달 할 수 있습니까? 그것이 내가 추구했던 질문의 유형입니다.

— Michael

2

예를 들어, 페이스 북에 프로그래머가 2 명이라면 분명히 과로 할 것입니다. 그러나 어떻게 그 결론에 도달 할 수 있습니까? 그것이 내가 추구했던 질문의 유형입니다.

이것은 프로그래밍 질문이 아니라 관리 질문입니다.
이에 대한 몇 가지 쉬운 질문이 있으며 소프트웨어와는 아무런 관련이 없습니다.

몇 시간 일하십니까?
몇 시간 일해야합니까?
마감일이 지났습니까?

그런 다음이 논리를 따르십시오.

1> 2이면 더 많은 사람이 필요하거나 공격적인 마감일이 줄어 듭니다.
1 <2이면 더 적은 인원이나 더 많은 이니셔티브가 필요합니다.
마감일이 맞지 않고 1> = 2이면 더 많은 사람이 필요합니다.
마감일이 맞지 않고 1 <2이면 누군가를 해고해야합니다.

이것은 두 가지 눈부신 결함이있는 지나치게 단순화 된 것입니다.

사람들은 평등하지 않습니다.
사람들의 생산성을 높이는 방법은 여러 가지가 있습니다 (컴퓨터 나 다른 방식으로 업그레이드).

그러나 당신은 아이디어를 얻습니다.

— 사용자
소스