LOC / 일 비율이 너무 높으면 귀찮게해야합니까? [닫은]

현재 인디 프로젝트를 진행 중이므로 인간 테스트 또는 외부 코드 검토 전반에 걸쳐 사치가 없습니다. 그러나 현재 코드에 어려운 버그가 표시되지 않습니다. , 대부분은 잘못된 필드 이름과 같은 것으로 1 ~ 2 분 안에 수정해야합니다.) 푸시하기 전에 기능을 구현 한 후 테스트합니다. 최근 내 LOC 번호는 하루에 약 400 (레코드는 C #)였으며 새로운 시스템을 구현할뿐만 아니라 이미 작성한 것을 다시 작성하고 버그를 수정합니다.

귀찮게해야합니까? 내가 지금까지 작성한 모든 코드를 중지하고 검토하고 리팩토링해야한다는 신호입니까?

LOC는 아마도 가장 악용되는 지표 중 하나 일 수 있으며, 결과적으로 더 쓸모없는 코드 품질 측정 및 더 쓸모없는 프로그래밍 노력 측정 중 하나 일 수 있습니다.

예, 그것은 대담한 진술입니다. 아니요, 저는 당신이 내 요점을 증명하는 연구를하도록 지시 할 수 없습니다. 그러나 나는 당신이 작성한 코드의 양에 대해 걱정하기 시작할 때 잘못된 문제에 대해 걱정하고 있다는 어려운 경험을 가지고 말할 수 있습니다.

먼저 측정하거나 증명하려는 것이 무엇인지, 그리고이 증거가 관심의 대상이 아닌지, 또는보다 광범위한 품질 개선을 지원할 것인지, 그리고이 정보를 사용하여 팀으로부터 구매하기 위해 필요한 위치를 스스로에게 묻어 야합니다. 그것에 대해 뭔가를 할 수 있습니다.

LOC를 사용하는 경향이있는 것 중 하나는 약간의 온전한 점검입니다. 많은 코드를 작성하는 경우 LOC보다는 메소드 당 LOC 또는 클래스 당 LOC에 더 관심이 있습니다. 이러한 측정 은 코드가 얼마나 잘 팩토링되어야하는지에 대해 약간의 OCD를 느끼는 경우 추가 리팩토링해야한다는 지표 일 수 있습니다. 매우 큰 클래스는 수도 작은 몇 개의 클래스로 리팩토링 할 필요가 있고, 긴 여러 줄 방법이 할 수 있는 몇 가지 방법, 다른 클래스로 분류해야하거나 제거 할 수있는 몇 가지 복을 표시도 할 수있다. 나는 거기에 "할 수도있다"라는 단어를 여러 번 사용했습니다.

실제로 LOC는 가능한 표시기 만 제공하며 코드를 변경해야 할 수도 있습니다. 실제 질문은 코드가 필요에 따라 예상대로 동작하는지 여부입니다. 그렇다면 다음 질문은 코드를 쉽게 유지 관리 할 수 ​​있는지 여부와 현재 또는 미래에 유지 보수 오버 헤드를 줄이기 위해 작업 코드를 변경할 시간이 있는지 여부입니다.

종종 많은 코드는 나중에 유지 관리해야 할 것이 많지만 때로는 잘 짜여진 코드조차 수백 줄의 코드로 확장 될 수 있으며, 때로는 하루에 수백 줄의 코드를 작성하는 경우도 있습니다. 그러나 경험에 따르면 매일 수백 줄의 새로운 코드가 출력되면 많은 코드가 부적절하게 잘라 다른 곳에서 붙여 넣어 져 자체적으로 문제가 발생할 위험이 있습니다. 복제와 유지 보수가 보장되는 것은 아니지만, 다시 한 번 보장 할 수는 없습니다. 따라서 현재 진행중인 작업이 어떻게 완료되었는지에 따라 제 경험과 본능이 무엇을 말하는지에 의존하는 경향이 있습니다.

IMHO 질문에 제기 된 딜레마를 피하는 가장 좋은 방법은 LOC를 잊고 항상 리팩터링하는 것입니다. 먼저 코드 테스트를 작성하고, 실패로 구현하고, 리 팩터를 전달한 다음 리팩토링 된 것을보고 코드를 개선하십시오. 당신은 이미 작업을 재확인했다는 것을 알고 작업을 떠날 것이고, 앞으로 자신을 다시 추측하는 것에 대해 걱정하지 않을 것입니다. 사실, 앞에서 설명한대로 테스트 우선 접근 방식을 사용하는 경우 완성 된 코드에서 LOC / 일 측정을 수행하면 측정 된 양의 3-5 배를 작성했으며 실제로는 계속해서 리팩토링에 의해 숨겨져 있습니다. 노력.

전혀 아닙니다-며칠 동안 버그를 찾기 어려운 문제를 해결하고 한 줄만 변경합니다. 다른 날에는 새 코드를 추가하고 수천 줄을 작성합니다.

Daily LOC는 그 날의 작업을 400 줄의 코드로 수행 할 수 있다는 것을 제외하고는 아무것도 말하지 않습니다.

이러한 답변 중 일부에 요점이 빠져 있습니다 .LOC를 생산성 측정 수단으로 사용하지 않고 있습니다 (그렇다면 너무 '생산적'에 대해 걱정하지 않을 것입니다). 실제로하는 일은 코드 품질에 대해 걱정하기 때문입니다. 코드는 이것이 걱정 할만한 적 입니다.

불행히도 코드 품질에 대해 아는 유일한 방법은 코드 검토입니다. 한 사람이 팀이기 때문에 코드 검토를 중단하고 (정말 중단하고 싶지 않더라도) 까다로울 수 있습니다. 자신의 코드는 코드를 검토하는 동료만큼 공개하지 않습니다. 400 LOC / day가 횡설수설을 일으키고 있는지 아닌지를 알 수 있도록 다른 사람이 귀하의 코드 중 적어도 일부를 검토하도록 제안하는 것이 좋습니다. 일일 코드를 독립적으로 검토하더라도 여기에 도움이 될 것입니다

하루에 생산하는 LOC 수에 신경을 쓰면 안됩니다.

그러나 당신은 귀찮게해야합니다 :

• 코드가 테스트되지 않은 경우 (예 : 단위 테스트가없는 경우)
• 새로운 기능을 추가하거나 구현 된 기능을 변경하는 데 문제가있는 경우 (리팩토링이 잘못되었음을 의미)
• 경험이 크지 않고 코드를 검토하지 않은 경우 (추가 눈이 문제를 발견 할 수 있음)

LOC는 생산성에 대한 '공식적인'측정치이지만 그 가치에 대한 논쟁은 길 수 있습니다 (ORM은 데이터베이스 설계가 잘못되면 3 분 안에 50,000 줄의 코드를 생성 할 수 있습니다).

완료된 작업과 시간 대비 완료된 작업의 비율 (%)을 추적하여 진행 상황을 측정하는 것이 좋습니다. 이것이 중요합니다. 고객은 LOC가 아닌 비즈니스 가치를 제공하는 작업 코드에 대한 비용을 지불합니다.

LOC에 대한 일부 참조

• 반대 : LOC-대부분의 의미 측정

• 어느 정도 중립 : Wiki-LOC

• 프로 (대부분의 의견에 동의하지 않지만 살펴볼 수는 있습니다) : 규모의 비경제 및 코드 라인

또한 코드 중복 수를 측정하고 있습니까?

높은 출력이 코드에 많은 복사 및 붙여 넣기 를 가지고 있기 때문에 걱정할 필요가 있습니다.

이유 : 복사 및 붙여 넣기 소스에 오류가있는 경우 복사 및 붙여 넣기의 모든 사용법을 수정하기가 어렵고 오류가 발생하기 쉽습니다.

당신이 아름다운 기능 코드를 믿는다면, 그것은 당신의 유일한 척도가되어야합니다

"흐르나요? 아름답게 보입니까?"