object AndroidRule {
private const val FIRST_RULE = "모르는거 충분히 고민하고 물어보기!!"
private const val SECOND_RULE = "물어볼 때는 1) 문제 상황 2) 어떤 방식으로 시도해봤는지 와 함께 말해주자!"
private const val THIRD_RULE = "날카로운 말투 금지, 비하, 비난 금지. 상대방의 코드도 존중해주자!!"
private const val FOURTH_RULE = "서로 칭찬, 격려 많이해주자:)"
}
"먼저 스스로 검색하고 해결해봐야 합니다." 만약 '1+1'이라는 더하기 문제를 어린아이가 묻는다면 기특하고 웃음이 저절로 납니다. 아이에게는 어려운 문제일 수 있으니깐요. 그런데 개발자가 이런 기초적인 질문을 한다면 즉 다시 말해 충분히 혼자 해결 가능한 것들을 묻는다면 사실 기분이 매우 나쁩니다. 간단한 구글링을 통해서도 해결 가능한 걸 묻는다는 건 본인이 순간적인 답답함을 못 이겨 답변자를 이용하는 것처럼 비치기 때문입니다. 질문하기 전에 충분히 도전해봤지는 생각해봐야 합니다.
"문제를 요약하여 제목으로 작성하기" 요약이 필요합니다. 명확하게 어떤 화면에서, 어느 소스에서, 몇 번째 줄이 어떤 문제를 일으키고 있는지 명확하게 설명할 수 있게 요약을 해야 합니다. 두괄식이란 결론을 먼저 말하고 그것을 여러 문장으로 서술해 나가는 글쓰기로 방식을 말합니다. 이는 보고서나 제안서를 쓸데 많이 사용하는 양식입니다. 읽는 이에게 글의 핵심과 논지의 흐름을 쉽게 알 수 있게 합니다. 질문도 이처럼 두괄식으로 해야 합니다. 그러기 위해서는 현재 문제에 대해 요약하여 제목으로 정할 수 있어야 합니다. 오프라인에서 직접 물을 때도 두괄식으로 먼저 정확한 문제를 이야기하고 도움을 요청해야 합니다.
"문제를 재현하도록 준비하기" 디버깅은 직접 눈으로 확인하고 수정하는 과정이 필요로 합니다. 유지보수에서도 특정 컴퓨터에서만 나는 오류가 갑장 잡기 어렵고 수정하기 애매합니다. 이처럼 나의 문제에 대해 정확한 도움이 필요하다면 오류를 재현할 수 있도록 준비하는 게 효과적입니다. 만약 도움을 받아야 하는 사람의 컴퓨터에서 똑같이 오류를 흉내내기 어려울 때가 있습니다. 이때는 화면을 캡처하여 이미지를 출력해가서 어떻게 문제가 생겼는지 재현하는 방법이 필요합니다. 이런 과정 없이 도움을 요청하면 답변자는 문제를 파악하기 위한 일부터 시작하게 됩니다. 그리고 개발자는 언제나 바쁩니다. 최대한 도움의 시간을 아낄 수 있도록 해줘야 합니다.