어떤 주석을 말하는지 모르겠지만
책에서 배운 내용과는 다르게 현대 프로그래밍에서 주석은 가급적이면 안다는게 좋다고 생각하는 편입니다.
바꿔말하면 주석을 달지않고도 충분히 이해되는 코드가 가장 좋은 코드라고 생각합니다.
그러기 위해서는 명명법에 많은 신경을쓰고 변수, 메서드, 클래스 이름을 함부로 짓지 않아야 합니다.
그럼에도 불구하고 주석이 없을 경우 이해하기 어려울 경우에 주석을 달아야 하죠.
클래스의 사용이나 이런 주석이 아닌 그냥 '뭐하는 메서드' 이딴식의 주석은 필요가 없습니다. 메서드명으로 그 의미를 명확하게 하면됩니다.
어디까지나 개인적인 경험입니다. 저의 경험으로는 여태 일하여 개발자들의 주석과 코드를 봤을 때
주석을 잘 다는 개발자 보다 주석을 굳지 달지 않아도 되는 코드를 만드는 개발자가 월등히 더 유능하며 실제로 가보면 이런 개발자일 수록 코드로 이해하기 어려운 상황에는 매우 친절하게 주석을 달아 놓는 경우가 많습니다.
반대로 주석을 덕지덕지 다는 스타일의 개발자의 경우 코드가 개판인 경우가 더 많고. 그리고 주석의 갱신도 일루어지지 않고 주석의 내용과 코드가 어긋나는 경우가 허다하였습니다.
어디까지나 개인적인 경험이지만 15년 넘개 개발하면서 이 법칙을 벚어나는 경우를 못 봤습니다. 특히 주석을 강조하는 개발자일수록 코드의 질이 떨어지는 경우가 많았습니다. 이는 코드의 질을 높여서 이해를 높이는 방법보다 그냥 주저리 글을 쓰면 이해가 쉽다고 생각하는 것이 기인하지 않나 생각해봅니다.
그리고 실제 코드로 이해를 하기 쉽도록 하기 위해서는 상당히 공을 많이 들어야 합니다. 그냥 메서드 이름 하나지만 고민하고 통상적인 방법이 무엇인지 대부분의 대가들은 왜 이거 쓰는지 나름의 철학을 가지고 만드는 경우가 많았고 사용자 입장에서 사용하기 쉽게 메서드를 만들기 위해서 온갖 객체지향 테크닉이 다 활용되는 경우가 더 많았습니다. 하지만 주석 맹신론자들은 메서드명하나 이해하기 쉽게 짓지 못하는 경우가 허다 했습니다. 가령 getXXX 메서드를 쓰면서 반대변에 대입될 변수조차 있지 않고 하지만 작동이 되는코드를 볼때 참.. 한심하다 싶을 정도 였습니다. 뻑하면 'Check 뭐시기' 변수명이 허다하고 영어는 분명 동사가 먼저고 명사가 뒤에 있음에도 메서드 명에 명사 먼저 동사 후를 붙여 쓰지를 않나 전치사 전치사를 붙여서 명명하지 않나 암튼 생각하기 싫을 정도로 하수들이 널렸던 기억이 대다수입니다.
그리고 하이라이트가 주석 맹신론자보다 코드로 주석을 대체하도록 개발하는 사람들의 코드에 있는 주석은 쓸모있는 주석이라 느껴지는 경우가 99%라면 주석맹신론자들의 주석은 거즘 5%이하 정도만이 주석이 주석다운 가치를 가지고 있었습니다.
어디까지나 개인적인 견해이고 경험이지만 저는 아직 이 룰을 벗어나는 개발자를 본적이 없어서 주석을 강요하는 개발자는 솔직히 색안경을 쓰고 볼 것 같습니다.
그리고 읽기좋은 코드가 주관적이라고 하는데 코드니까 주관적일 수 있지만 솔까말 코드 좀 보면 실력 다 나오지 않습니까?
상대방의 코드가 이해가 가지 않는다고 느껴진다면 솔직하게 저의 경험으로는 상대보다 실력이 낮은 경우였습니다. 그렇기 때문에 주석을 달아야 한다고 한다면 그 의견에는 반대합니다.
팀내 동료들의 코드 수준이 다 다르기 때문에 하양편준화를 하는 것에는 찬성하지 않는 이치와 같습니다. 하지만 코드는 이해가나 왜 이렇게 했는지 당위성이 느껴지지 않는 코드를 만드는 개발자와 대화를 해보면 저보다 한수 아래였습니다. 뭐 한수 아래 위가 중요한 것 아닙니다. 사고방식이 유연한가 아닌가가 더 중요한 가치라 생각합니다.
바꿔말하면 주관적이라서 개개인이 다르다고 하는데 어느정도 수준이상이 되면 무조건 주관적으로 보이지않다고 생각하는 편입니다.
특히 하수들은 코드에 당위성이 없습니다. 왜 이 이름을 써야되고 이런 클래스가 만들어졌는지 자신의 코드에 그런 맥락이 없습니다. 잘 못된 구성이라도 맥락이 있어야되는데 그런 맥락이 없는 코드를 만드는 개발자들 대다수들이 주석맹신론자였기 때문에 저는 주석 맹신론에 좀 반대의견을 표하고 싶습니다.
