1편에서 다음에 다루기로 약속한 부분은 다음 기회에..
잘 자다가 밖이 너무 시끄러워서 깼다
난 뭔가 널리 알려진 사실보다는 어떤 문제에 대한 다른 시각에 대해서 글을 쓰는게 더 재밌다.
게임프로그래밍이라기 보다는 일반적인 내용이라 미안..
아무튼 이번에는 주석의 악영향(!)에 대해서 쓰려고 한다.
주석이 왜 필요하고 어떻게 작성해야 하는지는 다 아실테니, 오직 나쁜 점에 대해서만 말하겠다.
1. 당신을 바보로 만든다.
어떤 글이든 쓰려면 대상에 대해 제대로 알아야 한다.
주석도 마찬가지인데, 보통 자신이 잘 아는 내용에 대해 주석을 적는 경우는 적다.
내가 알면 남도 알 것이라고 생각하기 때문일 수도 있고, 너무나도 당연해서 귀찮을 수도 있다.
내가 "모르기 때문에", 또 "나중에도 모를 것"이기 때문에 작성하는 주석이 대부분이라면 반성이 필요하다.
그 때 필요한 것은 주석이 아니라 공부니까.
2. 착한 척을 한다.
정성스럽게 주석을 단 코드와 그렇지 않은 코드가 있다.
둘 중 하나에 오류가 있다.
어느 쪽을 의심할까?
주석은 우리를 안심하게 만든다.
주석이 있고 그 내용이 옳다고 해서 코드가 무결한 것은 아니다.
3. 게으름을 조장한다.
어떤 알고리즘을 구현했는데 눈으로는 이해가 어렵다고 하자.
그 때 우리는 친절하게 주석을 달아 기억력의 한계를 극복하거나 다른 작업자의 시간을 아껴주곤 한다. (별로 도움이 되지 않는다)
곰팡이가 핀 벽이 흉해서 그 위에 벽지를 바르면 어떻게 될까?
이해하기 어려운 코드에 필요한 조치는 주석이 아니라 재작성이다.
이상 좋은 주석을 작성하려면 알아야할 세 가지
ㅂㅂ
잘 자다가 밖이 너무 시끄러워서 깼다
난 뭔가 널리 알려진 사실보다는 어떤 문제에 대한 다른 시각에 대해서 글을 쓰는게 더 재밌다.
게임프로그래밍이라기 보다는 일반적인 내용이라 미안..
아무튼 이번에는 주석의 악영향(!)에 대해서 쓰려고 한다.
주석이 왜 필요하고 어떻게 작성해야 하는지는 다 아실테니, 오직 나쁜 점에 대해서만 말하겠다.
1. 당신을 바보로 만든다.
어떤 글이든 쓰려면 대상에 대해 제대로 알아야 한다.
주석도 마찬가지인데, 보통 자신이 잘 아는 내용에 대해 주석을 적는 경우는 적다.
내가 알면 남도 알 것이라고 생각하기 때문일 수도 있고, 너무나도 당연해서 귀찮을 수도 있다.
내가 "모르기 때문에", 또 "나중에도 모를 것"이기 때문에 작성하는 주석이 대부분이라면 반성이 필요하다.
그 때 필요한 것은 주석이 아니라 공부니까.
2. 착한 척을 한다.
정성스럽게 주석을 단 코드와 그렇지 않은 코드가 있다.
둘 중 하나에 오류가 있다.
어느 쪽을 의심할까?
주석은 우리를 안심하게 만든다.
주석이 있고 그 내용이 옳다고 해서 코드가 무결한 것은 아니다.
3. 게으름을 조장한다.
어떤 알고리즘을 구현했는데 눈으로는 이해가 어렵다고 하자.
그 때 우리는 친절하게 주석을 달아 기억력의 한계를 극복하거나 다른 작업자의 시간을 아껴주곤 한다. (별로 도움이 되지 않는다)
곰팡이가 핀 벽이 흉해서 그 위에 벽지를 바르면 어떻게 될까?
이해하기 어려운 코드에 필요한 조치는 주석이 아니라 재작성이다.
이상 좋은 주석을 작성하려면 알아야할 세 가지
ㅂㅂ
- dc official App
재밌는 이론이네
함수에 주석이 있어야 1. 의도 파악, 2. 패러미터의 의미 3. 리턴값이 의미하는 바. 이런걸 매번 코드 볼때마다 확인할 필요 없게 만들고, 나중에 디버깅 추적하다가 해당 함수에 문제가 있다는걸 발견하면 처음 단 주석의 1번을 보면서 의도와 다르게 짠 부분이 있는지 확인하는게 진짜 개꿀인데..
좀 규모 커지고나면 함수 하나하나까지 기억 못할 레벨까지 가는데 그때 이걸 왜 만들었더라 하고 넘어가다가 나중에 개꼬이는 경우 많이 생겼음
글쓴이의 본문 2번처럼 진짜 주석 달았다고 땡(주석이 있으니 완벽하겠지라는 생각)이 아니라 그걸 나중에 보고 문제를 해결한다 등으로 생각있게 작성해야 좋은 주석일듯
어떤 이는 주석없이 읽어지는 코드가 잘 작성한 코드라지만, 작성 당시엔 읽어져도 보름 지나면 이게 읽힐지 아닐지는 모르는법...ㅠㅠ
본문3의 경우엔, 남이 짠 라이브러리 잘만 가져다 쓰면서 왜 자기가 작성한 (보기 어려운) 알고리즘은 주석이 아니라 다시 짜라고 하는지 이해가 잘 안감. 그거도 입출력만 완벽하다면 라이브러리 가져다 쓰듯 쓰고, 나중에 퍼포먼스의 문제가 있다거나 할 때 리팩토링을 고려하는게 맞다고 봄.
다 개인적인 생각이니 반박 받을게염
일단 지금은 좀 자야겠음
역시 사람 생각하는건 많이 다르구나
제대로 만들어 본적 없는 사람인듯
ㅁㄴㅇ - 고맙 ㅌ징 - ㅎㅎ dd - 맞아요 - dc App
what~// 다른 의견이 없어 반박할 부분이 없네요 본문 마지막줄 유의해주시면 좋겠음ㅎㅎ - dc App
근데 마지막은 좀 다른듯. 내 논지는 첫 술에 배부르겠느냐 한 번 더 신경써라 이거임. 남이 짠 라이브러리는 최소 수개월에서 수년간 불특정 다수의 코드리뷰를 받은 작품임. 그거랑 자기가 방금 짠 알고리즘이랑 비교하는건 잘못됐음. - dc App
그리고 입출력이 완벽하려면 내부 구현이 완벽해야함. 한 번 짠 코드가 그렇게 완벽할 수 있는지 의문임. 게다가 "나중에 퍼포먼스 문제가 발생할 수도 있지만 그때가서 해결할" 코드가 지금 당장은 옳은지 난 잘 모르겠음. 해결하고자 하는 문제에 대해 컨텍스트가 맞춰진 바로 그 순간이 개선의 최적시기라고 말하려는 거임. 나중으로 미루지 말고 - dc App
관심고마워요 ㅎㅎ - dc App
주석보다 재작성이라는 말에 크게 공감함.
1. 의도 파악, 2. 패러미터의 의미 3. 리턴값이 의미하는 바. << 이거는 이름을 잘 지어서 해결하는게 옳다고 봄. 씨샵이면 <summary> 태그 달아서 좀더 설명해도 되고. 하지만 그이상의 주석은 본문의 문제들을 불러올수 있는거같다.
율냥이// 따봉드림ㅎ - dc App
어그로성 논리