Hacker News 의견

• 여러 구현을 피하기 위해 매개변수를 사용하는 것이 좋음. 매개변수를 개선하는 것이 여러 구현을 통합하는 것보다 쉬움.

  • "이상한 매개변수"를 피할 수 없다면, 코드를 분리하는 것이 좋음. 불리언 플래그와 여러 개의 열거형 매개변수를 피해야 함.
  • 복잡한 함수 서명은 유지보수를 어렵게 만듦.

• 코드 복사는 한 번은 괜찮지만, 두 번째부터는 중복을 피해야 함. 충분한 데이터 포인트가 있을 때 좋은 추상화를 만들어야 함.

  • 코드가 처음에는 같더라도, 변화가 필요할 때 함께 변화해야 하는지에 집중해야 함.
  • 코드 중복을 피하는 것이 목표가 아니라, 함께 진화해야 하는 코드를 함께 유지하는 것이 목표임.

• DRY(반복하지 말라)나 WET(모든 것을 두 번 작성하라)는 절대적인 규칙이 아님. 코드 중복과 통합의 시점을 이해하는 것이 어려운 문제임.

• 작은 커밋의 대안으로, 큰 커밋을 되돌리지 않고 버그를 수정하는 새로운 커밋을 추가할 수 있음.

  • 큰 리팩토링이 왜 나쁜지 명확하지 않음.
  • 독립적인 구조를 만드는 것이 기존 모듈에 억지로 넣는 것보다 나음.
  • API 설계 시, 유닛 테스트 대신 디자인 세션을 가질 수 있음.

• 테스트 가능성은 좋은 설계와 관련이 있음. 쉽게 테스트할 수 없는 것은 설계 변경이 필요하다는 신호일 수 있음.

  • 테스트 코드는 다른 방식으로도 검토되어야 함.

• 프레임워크의 기능을 테스트할 때 주의해야 함. 프레임워크는 시간이 지나면서 변할 수 있음.

  • 의존성을 업그레이드할 때 안전한지 확인하는 것이 테스트의 중요한 역할임.

• 커밋 크기에 대해, 특정 변경을 되돌려야 할 때를 대비해 쉽게 되돌릴 수 있는 커밋을 목표로 해야 함.

• 회사들은 안정적인 코드베이스를 원하지만, 지속적인 리팩토링이 필요함. 이는 안정성과 상충될 수 있음.