조직에는 개발 팀의 의견에 따라 정기적으로 업데이트되는 코딩 지침 / 표준 문서가 있어야합니다. 이 문서는 변수 이름 지정 방법, 코드 형식 지정 방법 등과 같은 세부 사항을 설명 할 수 있습니다. 이 문서는 또한 가독성, 유지 보수성, 정확성, 효율성 및 표준 준수와 같은 것들의 상대적 중요성을 포함하여 프로그래머가 코드 작성시 채택 할 것으로 기대하는 가치를 설명해야합니다.

코드 검토는 해당 코딩 표준 문서를 사용하여 수행해야합니다. 코딩 표준에 따르면 두 사람이 충돌 할 때 프로그래머가 간결성보다 가독성을 선호해야한다고 말하는 경우 “영리한”코드에 대해 논쟁하는 데 약간의 지원이 필요합니다. 표준이 그렇게 말하지 않고 표준을 따라야한다고 생각한다면, 누군가의 자아가 온라인에있을 때이를 파악하려고 시도하기보다는 코딩 표준 회의에서 요약하여 논의 할 수 있습니다.

궁극적으로, 그것은 때때로 판단 요청으로 귀결되며,이 경우 최종 단어는 코드 및 / 또는 제품을 책임지는 사람에게 전달되어야합니다. 일반적으로 선임 개발자, 기술 책임자, 프로젝트 관리자 또는 엔지니어링 책임자와 같은 사람입니다. 담당자이고 특정 코드를 충분히 유지 관리 할 수 ​​없다고 생각하는 경우에는 그렇게 말하지 않아도됩니다. 당신은 그것에 대해 외교적 일 수 있습니다 :

샘, 나는 당신의 독창성에 깊은 인상을 받았지만, 그것이 너무 영리하다고 생각합니다. 나는 이것을 유지하기보다는 지금부터 1 년에 한 번 새로운 개발을 위해 노력할 필요가있다. 나는 그것을 유지해야하는 사람이 그 훌륭함을 완전히 이해하지 못할 수도 있다고 우려한다. 나는 당신이 그것을 싫어한다는 것을 알고 있지만, 우리가 논의 한 간단한 구현으로 되돌아 가면 감사하겠습니다.

반면에, 당신이 담당하는 사람이 아니라면, 당신이 할 수있는 최선의 방법은 당신의 입장을 명확하게 설명하고 팀의 나머지 사람들을 설득하는 것입니다. 관리자의 지원을받지 못하면 전화가 아니라는 사실을 받아들이고 계속 진행하십시오.

답변