철학

이 목록은 프로젝트가 따라야 할 일반적인 가치를 포함한다.
이 목록은 완전하지는 않다. 일부는 자명하지만, 완전성을 위해 명시된다.

프로젝트 관리

• 명확한 기대치 설정. 프로젝트의 의도와 결정을 사전에 공개한다.
  어떤 것도 놀라움이 되어서는 안 된다.

• 결정에 대한 명확한 메시지. 팀은 사적 채널을 통해 옵션을 평가하고 결정을 내릴 수 있다.
  그러나 팀은 GitHub discussions 또는 Discord와 같이 공개 채널을 통해 논의를 시도할 것이다. 사적 점검이 빈번히 이루어질 수 있다.
  사적 채널을 통해 결정이 내려졌을 경우, 팀은 이를 공개 채널을 통해 공지하도록 약속해야 한다.

기술적 측면

• 오류는 가능한 한 수정 방법과 단서를 제안해야 한다. 사용 사례에서 유추하고 필터링하여 무관하거나 도움이 되지 않는 메시지의 출현을 줄여야 한다.

• 고유하고 구체적인 오류 메시지. 일반적인 오류 메시지는 존재하지 않는다.
  이는 사용자가 문제의 원인을 이해하는 데 도움이 되며, 유지보수자에게 디버깅에 필요한 정보와 고유한 진입점 제공을 보장한다.

• API 최적화. 모든 옵션이 존재하는 이유를 질문하라.
  반드시 필요할까? 결합할 수 있을까? 코드 분기 횟수를 어떻게 줄일 수 있을까?

• 코드 문서화. 가능한 한 코드를 문서화하라. 특히 이해하기 어려운 코드나 특수한 로직이 설명이 필요할 때에는 더욱 그렇다.
  잘 문서화된 코드는 유지보수를 용이하게 하며, 여러 사람이 함께 작업할 경우 특히 중요하다. 후속 개발자는 당신의 지식을 활용해 더 나은 결과를 만들 수 있다.

• 전문 용어의 감소. 사용자가 특정 용어를 이해할 것이라고 가정하지 마라.
  전문가와 초보자 모두에게 정확한 의미를 제공하려 노력하라.
  예를 들어, 문법 분석 오류를 생성할 때 기존에 “token”을 사용하는 대신 “character”를 사용하라.

• 명령어 및 옵션 이름에 견고한 표현 사용. 불필요하고 혼란스러운 약어는 사용하지 않는다.

• 포괄적인 용어 사용. 중성적인 호칭을 사용하며, 비난이나 모욕적인 표현은 피한다.
  민감할 수 있는 표현은 사용하지 않는다.

• 일반 클라이언트를 위한 설계. 터미널이 단순히 ANSI 코드로 출력을 소비한다고 가정하지 않는다.
  IDE, 브라우저 또는 기타 환경에서도 시각화할 수 있도록 일반화할 수 있는 추상화를 사용한다.

• 터미널 출력은 명확해야 한다. 터미널 출력을 설계할 때 색상과 같은 형식 신호에만 의존해서는 안 된다.
  항상 형식, 심볼, 공백의 조합을 사용하라.
  모든 ANSI 코드가 제거되어도 결과는 여전히 이해 가능해야 한다.