Hacker News 의견

• 테스트가 없으면 문제를 보지 못해 문제가 사라지는 것처럼 보임

  • 테스트를 하면 항상 버그를 발견했음
  • 테스트를 삭제하면 자신을 속이는 것임
  • 페이지를 읽고 나서, 변형/구성 관리에 지쳤다는 인상을 받음
  • 사용자가 많아야 돈을 벌 수 있음

• 테스트와 버전을 포기하면 더 나은 프로그램을 얻었음

  • 2024년에 소스 코드 관리를 사용하지 않는 것은 이해할 수 없음
  • 여러 기기에서 작업하고, 히스토리를 보고, 롤백하고, 브랜치를 만드는 기능이 매우 유용함

• 처음에는 저자가 틀렸다고 생각했지만, 좋은 통찰이 있음

  • 이 워크플로우는 저자에게 잘 맞음
  • Git이나 자동화된 테스트가 생산성을 떨어뜨린 경험이 있을 것임
  • 간단한 대안도 있음 (예: Dropbox, FTP)
  • 저자는 작은 프로그램을 만드는 것을 좋아함
  • 자동화된 테스트는 유용하지만, 저자의 경우에는 가치가 나타나지 않을 수 있음

• 버전 관리와 자동화된 테스트는 실제 문제를 해결함

  • 오늘날 프로젝트를 버전 관리 없이 시작하는 것은 미친 짓임
  • 자동화된 테스트는 최선의 관행임
  • 저자의 특정 사용 사례에서는 합리적일 수 있음

• 큰 프로그램을 작성/리팩토링할 때, 쓰고 버리고 다시 쓰는 것이 중요함

• 이 기사는 혼란스러움

  • 왜 첫 번째로 업보트되었는지 궁금함

• 작은 변화가 프로그램의 적합성을 크게 바꿀 수 있음

  • K9 Mail의 예시가 있음
  • K9 Mail은 비전통적인 UI로 시작했음
  • 많은 사용자가 새로운 UI에 불만을 가졌음
  • 작은 변화가 앱의 적합성을 파괴했음
  • 여전히 오래된 버전을 사용하고 있음

• 혼자 소프트웨어를 만드는 것과 팀에서 만드는 것은 완전히 다름

  • 테스트는 수단이지 목적이 아님
  • 자신감이 있을 때는 테스트를 덜 함
  • 중요한 부분에 통합 테스트를 추가함
  • 새로운 API 디자인에는 단위 테스트가 유용함

• 2022년에 Freewheeling Apps 작업을 시작했음

  • 테스트가 없어서 좌절감을 느꼈음
  • 테스트 스위트는 시스템을 발전시키는 자신감을 줌
  • 기능 복잡성이 증가하면 테스트가 어려워짐
  • 2024년에 모든 테스트를 삭제했음
  • 이 철학은 한 사람에게만 적용됨

• 작은 변화가 프로그램의 적합성을 크게 바꿀 수 있다는 점에 동의하지 않음

  • 단기주의는 작은 변화에 적응하기 위한 것임

• 저자를 좋아하고 Mu 프로젝트를 좋아함

  • 현대적인 Lisp 머신임

• 소프트웨어 엔지니어링의 복잡성에 압도됨

  • 모든 아이디어를 거부하는 것은 해결책이 아님
  • 테스트를 작성하고, VCS를 사용하고, 추상화를 사용해야 함
  • 왜 사용하는지 알고, 이유가 없으면 재평가해야 함