2P by neo 2023-11-02 | favorite | 댓글 1개
  • 1989년 Rob Pike의 프로그래밍 5가지 규칙에 대한 기사
  • 규칙 1: 프로그램이 대부분의 시간을 어디에서 보낼지 가정하지 마라, 병목 현상은 예기치 않게 발생할 수 있다. 병목 현상이 입증될 때까지 속도 해킹을 피하라.
  • 규칙 2: 속도를 위해 튜닝하기 전에 항상 측정하라. 코드의 일부가 나머지에 상당한 영향을 미치는 경우에만 최적화하라.
  • 규칙 3: n이 작을 때 복잡한 알고리즘은 느리다. 이는 대부분의 경우이다. n이 자주 큰 경우에만 복잡한 알고리즘을 사용하고, 그럴 때도 먼저 규칙 2를 적용하라.
  • 규칙 4: 간단한 알고리즘과 데이터 구조가 바람직하다. 복잡한 것들보다 버그에 덜 취약하고 구현하기 쉽다.
  • 규칙 5: 올바른 데이터 구조는 프로그래밍에 결정적이다. 데이터가 잘 구성되어 있으면, 알고리즘은 자명하게 될 것이다.
  • Pike의 규칙 1과 2는 Tony Hoare의 격언 "조기 최적화는 모든 악의 근원이다"를 반영한다.
  • Ken Thompson은 Pike의 규칙 3과 4를 "의심스러울 때는 무차별적인 힘을 사용하라"로 다시 표현했다.
  • 규칙 3과 4는 KISS (Keep It Simple, Stupid) 디자인 철학을 구현한다.
  • 규칙 5는 Fred Brooks의 'The Mythical Man-Month'에서의 발언과 일치하며, 종종 "스마트한 객체를 사용하는 멍청한 코드를 작성하라"로 줄여서 말한다.
Hacker News 의견
  • 1989년 Rob Pike의 프로그래밍 규칙에 대한 기사
  • 댓글러들은 프로그래밍의 핵심은 알고리즘이 아닌 데이터 구조라고 동의
  • LeetCode 인터뷰가 알고리즘보다 데이터 구조에 초점을 맞추지 않는 것에 대한 비판
  • n이 작을 때 복잡한 알고리즘이 느리며, 대부분의 경우 n은 작다는 주장
  • 댓글러들은 적절한 데이터 구조 선택과 잘 정리하는 것의 중요성을 강조
  • 데이터베이스의 오용과 ORM 생성 DB 스키마의 부정적 영향에 대한 토론
  • 가이드라인은 과도한 엔지니어링과 성급한 최적화를 방지하는 전략으로 보임
  • 일부 댓글러들은 성능의 소량 낭비가 누적되어 프로그램을 느리게 할 수 있다고 주장
  • "성급한 최적화는 모든 악의 근원"이라는 인용구와 그 맥락에 대한 논쟁
  • 좋은 프로그래머들은 무엇이 느려질지 예측하고 미리 교육적인 내기를 할 수 있다는 일부 댓글러들의 주장
  • 단순한 데이터에 대한 복잡한 알고리즘이 큰 성능 향상을 가져오고 심지어 단순화할 수 있다는 반론
  • 기사가 일부 독자들의 디자인과 복잡성에 대한 접근 방식에 지속적인 영향을 미침
  • 규칙 5의 해석에 대한 토론, "스마트 오브젝트를 사용하는 멍청한 코드를 작성하라"는 구문에 대한 일부 불일치