2 분 소요

전 주석이 많으면 코드가 오히려 눈에 안들어와요.

함수가 있다면 함수선언만 보면 될 것을 왜 코드의 구현을 보는 걸까요? 왜 함수의 실제 구현 코드를 봐야 하고, 함수가 하는 짓을 일일이 추적하며 봐야 할까요?

간단히 답해드리면, 함수선언에는 충분한 정보가 없기 때문입니다. 그래서 함수를 사용하기 전에 의심을 갖게 되고, 구현 코드를 보게 되는 거죠.

다음 멤버 함수의 선언을 한번 봅시다.

1

void Shape::SetAngle(float angle);

대충 뭐하는 함수인지 느낌이 옵니다. Shape형인 개체의 각도를 바꾸는 함수군요. 그런데, 저는 이 함수를 사용하기 전에, 다음이 궁금해서 실제 구현 코드를 봐야 사용할 수 있을 것 같습니다.

  1. angle은 Degree일까요, Radian일까요?

  2. 음수값을 주면 어떻게 될까요?

  3. Degree일때 360보다 큰값을 주면 어떻게 될까요?

  4. 회전의 중심은 어디인가요? Shape의 중심과 같을까요?

  5. Shape이 이미 30도 회전된 것이라면 어떻게 될까요? angle이 상대값일까요, 절대값일까요?

  6. Shape 개체에서 각도값을 저장하는 변수의 값만 Set 하는 걸까요? 아니면 정말 회전까지 시키나요?

  7. Shape을 회전 시켰으면, 화면 갱신도 같이 해주나요?

  8. 리턴값이 void면 정말 항상 성공하는 함수인가요? 절대 오류가 발생하지 않나요?

  9. 정말 예외 발생은 없는 거죠?

내공의 정도에 따라 더 궁금한 사항이 있는 분들이 계실 겁니다.

아무튼 SetAngle 함수를 사용하는데 있어서 여섯 부류의 프로그래머가 있을 듯 합니다.

  1. 아 뭐 각도 바꾸는 거 뭐, 그냥 SetAngle 함수를 그냥 씁니다.

    이 부류의 프로그래머는 상당히 위험하다고 생각합니다. 엄청난 버그를 몰고 다니시는 분이 될 수 있습니다. 자신이 무슨일을 하고있는지 모르고 코딩하는 거니까요.

  2. 뭐하는 함수인지 정확히 파악하기 위해 소스코드를 분석합니다.

    멋진 프로그래머 입니다. 버그는 몰고 다니시지도 않고 꼼꼼하셔서 신뢰가 갑니다. 하지만 생산성은 떨어져 스트레스를 많이 받으실 것 같습니다. 남이 구현한 코드를 보는 것은 역시 상당한 시간이 걸리죠.

  3. 뭐하는 함수인지 구현한 사람에게 물어봅니다.

    동료들이 귀찮아 할 수 있습니다.

  4. 2 번, 3번 중의 한가지 방법으로 SetAngle을 파악한 후 이를 기억하고 다음부터는 기억한 데로 사용합니다.

    약간 위험할 수 있습니다. 자신의 기억을 너무 믿지 마세요. 기억이 정확하더라도 SetAngle 함수는 누군가로부터 이미 변해 버렸을 수 있습니다.

  5. 2번, 3번 중의 한가지 방법으로 매번 소스코드를 파악합니다.

    놀라운 책임감과 신뢰감을 줍니다. 비록 생산성은 떨어지지만 버그를 만드시지 않을 것입니다. 버그 없는 단단한 코드. 우리 모두 좋아 하는 거죠.

  6. 코드도 주석도 리팩토링 합니다.

    2, 3번 과정으로 파악한 후, 함수 선언만 봐도 궁금증이 해소되도록 주석과 코드를 리팩토링 합니다. 예를 들어 상기 SetAngle함수를 분석했더니, angle이 degree로 사용되는 것이라면 다음과 같이 리팩토링 합니다.

    1
2

     // degree : 0~360의 범위를 가지며 그 이외의 값은 스스로 보정한다.
 void Shape::SetAngle(float degree);

    더이상 angle이 Degree 인지 Radian인지 확인하기 위해 구현 코드를 분석할 필요가 없어지죠.

    다만 단점은 있습니다. 누군가가 SetAngle 함수의 구현해서 degree 인자를 Radian으로 처리하게 바꿔놓고, 주석이나 인자명을 수정하지 않고 그대로 degree 로 남겨 뒀다면, 사람들은 0~360의 값을 전달하고 오류를 경험하게 될 것입니다.

    이럴때는 고친 사람을 어떻게든 찾아서, 다음부터는 소스코드를 변경하면, 주석도 같이 리팩토링 해달라고 해보세요. 잘못된 주석은 잘못된 코드보다 더 !!!위험!!!할 수 있습니다.

눈이 어지러우시더라도 코드보다는 주석을 !!!먼저!!! 읽는 습관을 가져 보세요. 코드를 분석하는 것보다 생산성이 향상됩니다. 굳이 주석만 읽으면 될 것을 매번 코드를 일일이 분석하며 시간을 허비하지 맙시다. 지금도 웹년은 빠르게 지나가고 있습니다.

잊지 마세요.

  1. 주석을 읽으면 버그의 위험도 줄고 생산성이 !!!향상!!!됩니다.

  2. 주석은 코드를 분석하는 시간을 !!!단축!!!시켜주는 코딩 테크닉입니다.

  3. 주석은 버그를 !!!방지!!!할 수 있는 코딩 테크닉입니다.

  4. 잘못된 주석은 잘못된 코드보다 더 !!!위험!!!합니다.

댓글남기기