Hacker News 의견

• Microsoft와 IBM의 코드 라인 수 충돌

  • PBS TV 시리즈 "Accidental Empires"에서 스티브 발머가 OS/2 공동 개발 당시의 경험을 설명하는 장면이 있음. Microsoft는 작은 회사의 태도로 일을 처리하는 반면, IBM은 내부적으로 코드 라인 수(천 줄 단위, KLoC)를 프로그래머 생산성의 척도로 삼는 데 집중했다고 함. 발머는 IBM이 코드의 질보다는 양에만 관심을 가졌다고 비판함.

• 이전 토론 링크들

  • 코드 라인 수를 생산성 지표로 사용하는 것에 대한 토론은 자주 나타남. 2010년부터 2022년까지 다양한 논의가 있었음을 보여주는 링크들이 제공됨.

• 코드 라인 수를 생산 지표로 삼는 것은 매우 어리석음

  • 한 줄의 코드로 해결할 수 없었던 20년 된 버그를 해결하거나, 'order by'로 3년 된 버그를 해결한 경험을 언급하며, 한 줄의 코드가 미치는 영향을 어떻게 측정할 수 있는지에 대한 의문을 제기함. 나쁜 프로그래머가 더 많은 코드를 작성한다는 경험을 공유하며, Microsoft 개발자가 IBM 코드 33,000자를 220자로 재작성한 사례를 소개함. 이로 인해 Microsoft의 작업이 '부정적'으로 평가받는 상황이 발생했다고 함.

• 간단한 질문이 때로는 가장 큰 영향을 미침

  • 어떤 기능을 구현할지에 대한 간단한 질문("X를 어떻게 처리할 것인가?")이 그 기능을 만들지 않는 결정으로 이어질 수 있으며, 이는 시도하는 데 드는 모든 비용을 절약하는 결과를 가져옴. 이러한 기여는 수치로 측정할 수 없으며 때로는 적을 만들 수도 있지만, 그럼에도 불구하고 이를 감행하는 이들에게 경의를 표함.

• 초기 경력에서의 코드 최적화 경험 공유

  • 10,000줄 이상의 C 프로그램을 500줄 미만으로 최적화한 경험을 공유함. 이전 개발자가 함수 사용이나 SQL 쿼리에 변수 데이터를 제공하는 방법을 모르고 있었을 수 있다는 단순한 가정 하에, 같은 SQL 문을 반복적으로 인라인으로 작성한 것을 발견함. 함수 호출로 SQL 콜을 재작성하고, 변경된 바인드 값들을 배열에서 가져와 루프 안에서 함수를 호출하는 방식으로 중복 코드를 대체함.

• 프로젝트 시작 시 명확한 방향성 부족

  • 프로젝트를 시작할 때 정확한 방향을 모르는 경우가 있으며, 프로젝트에 몰두하면서 문제와 원하는 답을 더 잘 이해하게 되고, 그 결과로 큰 부분을 빼내고 더 작고 나은 것으로 대체할 수 있음. 이러한 상황에서 64KB의 ROM에 모든 것을 포함시켜야 했던 개발자들은 코드를 더 작게 만들기 위한 강한 압박을 받았음.

• 코드 제거를 지표로 삼는 것에 대한 사고 실험

  • 관리자가 이 기사를 읽고 단순하게 코드 제거 라인 수를 측정 지표로 삼기로 결정한다면, 상황이 나아지거나 악화될지에 대한 사고 실험을 제안함.

• 빌 앳킨슨의 Atkinson Dither

  • 빌 앳킨슨과 그의 Atkinson Dither 기법에 대한 링크 제공.

• 코드 라인 수에 대한 인식

  • 코드 작성 시 '추가된 라인 수 - 제거된 라인 수'를 사용하는 것에 대한 의문을 제기함. 같은 장소에서 시작해 같은 장소에서 끝나는 10km 달리기를 0km 달리기라고 하지 않는 것처럼, 코드 라인 수도 마찬가지라는 견해를 표현함.

• 직원으로서의 역할

  • 아인슈타인만큼 똑똑하더라도 여전히 직원이며, 직원으로서 해야 할 일들이 있다는 교훈을 공유함.