Hacker News 의견

• 개발자가 오랫동안 구축하고 싶어 했던 기능과 유사한 것에 대한 흥미로움

  • 파일이나 파일의 특정 부분에서 과거에 발생한 변경 사항들을 기반으로, 주어진 변경 사항이 문제를 일으킬 가능성을 계산하는 방법의 유용성에 대한 고찰.
  • 각 변경 사항에 대한 위험도 점수를 매기고, 이 점수를 PR(Pull Request)에 연결하여 코드 리뷰어들에게 추가적인 주의가 필요한 코드를 알려주고, 배포 시 위험한 변경 사항을 강조하는 신호로 활용.
  • 코드가 삽입/삭제로 인해 위아래로 이동할 때 동일한 코드 부분을 추적하는 것이 어려움. 단순히 줄 번호에 기반한 알고리즘은 문제가 될 수 있음.
  • 파일 수준에서 이루어지는 작업만으로도 충분히 유용할 수 있음을 시사.

• 특정 서드파티 라이브러리에서의 수정 사항이 누락되었다는 지적

  • 서드파티 라이브러리(예: ffmpeg)에서 발생한 수정 사항 중 일부가 누락된 것 같음. 이러한 수정 사항은 종종 상류에서 먼저 처리되어 추적이 어려울 수 있음.

• 크롬 브라우저 UI의 많은 버그들을 살펴보며 수동 메모리 관리의 성능이 중요하지 않은 데이터의 사용 후 해제(use-after-free) 문제에 대한 고민

  • "파일 선택" 대화 상자의 생명주기와 같은 코드에서 수동 메모리 관리의 성능이 중요하지 않음에도 불구하고 발생하는 use-after-free 문제들에 대한 관찰.
  • 이러한 코드에서는 항상 더 똑똑하고 느린 포인터를 사용하는 것이 더 나을 수 있음을 시사.
  • raw_ptr<T>와 같은 타입이 도움이 될 의도로 보이며, 실제로 [2]에서 발생한 충돌을 방어하는 데 성공했을 가능성에 대한 언급.
  • 프로젝트 내에서 성능에 민감한 코드와 성능을 크게 고려하지 않아도 되는 코드 사이에서 다른 방언(dialect)을 전환하는 방법이 없다는 것이 아쉬움.
  • 성능에 민감한 부분과 비동기 상태가 많아 잘못될 가능성이 높은 부분을 명확히 구분하기 위해 두 가지 다른 언어를 혼합하는 것이 거의 가치가 있을지에 대한 고민.

• 시각화의 효과에 대한 칭찬과 CPU 사용량에 대한 지적

  • 매우 깔끔한 시각화로, 영역을 확장할 때 CPU 사용량이 다소 높음을 언급.
  • 크롬 팀이 내부적으로 유사한 도구를 사용하고 있을 것이라는 기대와 공격 표면을 이해하는 데 유용할 것이라는 의견.

• 아이디어와 실행에 대한 칭찬 및 원시 데이터에 대한 문의

  • 아이디어가 멋지고 실행도 잘 되었다는 칭찬.
  • 원시 데이터에 대한 접근 가능 여부와 선버스트(sunburst) 또는 트리 맵(tree map) 시도의 가치에 대한 언급.

• 특정 파일 유형을 포함하지 말 것에 대한 제안

  • DEPS, AUTHORS, BUILD.gn 파일을 포함하지 말 것을 제안하는 세부적인 지적.

• 변경된 코드 라인 수에 따른 가중치 부여에 대한 제안

  • 변경된 코드 라인 수에 따라 버그에 할당된 '돈'의 가중치를 부여하는 것이 흥미로울 것이라는 의견.
  • 파일 A의 10줄과 파일 B의 1줄이 변경되었다면, 파일 A가 버그의 대부분을 차지했기 때문에 1/11의 '돈'을 할당받는 방식에 대한 제안.

• 파일별 평균 보상을 표시하는 기능에 대한 요청

  • 각 노드에 파일별 평균 보상을 표시하는 기능에 대한 요구.

• 코드 라인 수에 따라 정규화된 금액 표시에 대한 아이디어

  • 코드 라인 수에 따라 금액을 정규화하여 표시하는 버전에 대한 제안.

• 노력을 집중할 영역에 대한 시각적 통찰력에 대한 칭찬

  • 어디에 노력을 집중해야 할지에 대한 시각적 통찰력을 제공하는 것이 매우 멋지다는 평가.