GN⁺: - 2007년, 2000줄의 코드

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

• 1982년 초, Lisa 소프트웨어 팀은 향후 6개월 내에 소프트웨어를 출시하기 위해 막바지 작업에 집중하고 있었음.

• 관리자 중 일부는 매주 각 엔지니어가 작성한 코드의 양을 추적하는 것이 좋은 아이디어라고 생각하고, 매주 금요일마다 제출해야 하는 양식을 만들었는데, 이 양식에는 그 주에 작성한 코드 라인 수를 기입하는 필드가 포함되어 있었음.

• Quickdraw의 저자이자 주요 사용자 인터페이스 디자이너인 Bill Atkinson은 코드 라인 수가 소프트웨어 생산성을 측정하는 어리석은 방법이라고 생각했으며, 이는 단지 지저분하고 부풀려진, 오류가 있는 코드를 작성하도록 장려하는 것이라고 여겼음.

• Atkinson은 최근 Quickdraw의 영역 계산 기계를 최적화하기 위해 작업하고 있었고, 더 단순하고 일반적인 알고리즘을 사용하여 영역 엔진을 완전히 다시 작성했는데, 이는 몇 가지 조정 후 영역 작업을 거의 6배 빠르게 만들었음.

• 이 재작성 작업은 부수적으로 약 2000줄의 코드를 절약하는 결과를 가져왔음.

• 최적화 작업의 마무리 단계에서 처음으로 관리 양식을 작성할 때가 되었고, 코드 라인 수 부분에 도달했을 때 잠시 생각한 뒤, 그는 숫자 -2000을 기입했음.

• 관리자들이 어떻게 반응했는지 확실하지 않지만, 몇 주 더 지난 후, 그들은 Atkinson에게 양식 작성을 요구하는 것을 중단했고, 그는 기꺼이 이에 따랐음.

GN⁺의 의견

• 이 기사는 소프트웨어 개발에서 코드의 양이 진정한 생산성을 나타내지 않는다는 중요한 교훈을 제공함. 코드 라인 수를 기준으로 성과를 측정하는 것은 효율적이지 않을 뿐만 아니라, 때로는 역효과를 낼 수 있음을 보여줌.
• Bill Atkinson의 예는 소프트웨어 최적화의 중요성을 강조함. 더 적은 코드로 더 빠른 성능을 달성하는 것은 소프트웨어 엔지니어링의 핵심 원칙 중 하나임.
• 이 이야기는 현대의 개발 관행, 특히 애자일 방법론과 지속적인 통합/배포(CI/CD)와 같은 접근 방식이 왜 중요한지를 이해하는 데 도움이 됨. 이러한 방법론은 코드의 양보다는 품질, 유지 보수성, 그리고 사용자 경험에 더 많은 가치를 두고 있음.
• 업계에서는 코드 품질을 측정하고 개선하기 위해 다양한 도구와 메트릭을 사용함. 예를 들어, 정적 코드 분석 도구, 코드 리뷰 프로세스, 테스트 커버리지 추적 등이 있음.
• 이 기사는 개발자들에게 코드의 양보다는 품질에 집중하고, 불필요한 복잡성을 피하며, 성능을 최적화하는 것이 얼마나 중요한지를 상기시켜줌.

[neo]

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 달리기라고 하지 않는 것처럼, 코드 라인 수도 마찬가지라는 견해를 표현함.

• 직원으로서의 역할

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