초급개발자가 본 어이없는 프로젝트의 진행

KLDP에서 재미있는 글을 하나 발견하곤 읽어봤다.

초급개발자가 본 어이없는 프로젝트의 진행

KLDP의 원문이 삭제되어버렸네요.

글을 쓴 당사자는 얼마나 괴로울까. 자신이 무엇을 만드는지조차 이해하고 있지 못한 파트너와 일을 하게 되었으니.

이해되질 않는 것은 벽돌 역할을 하게 되는 클래스를 제공해주는 파트너이다.

내가 그 내용을 알필요는 없고 파라미터와 리턴값만 확실히 명시하라!

이런 요구사항도 제대로 충족시켜 줄 수 없고, 자신이 만든 클래스를 설명조차 할 수 없다니. 도대체 소스를 어떻게 만들어 내는 것인지 궁금할 지경이다. 그냥 인터넷을 검색해서 그럴듯한 소스를 붙여넣기만 하는 것은 아닌가 의심이 된다.

소스 코드를 작성할 때, 될 수 있으면 주석을 달아놓자. 누군가가 보았을 때 이해하기 쉽도록. 얼마 전 여자친구의 쇼핑몰 디자인을 위한 소스를 봤을 때 이해하기 쉽게 적어놓은 주석에 감동한 적이 있다. 다른 사람이 볼 때뿐만 아니라 자신이 봐도 이해하기 쉬울 것이다. 언젠가부터 나 역시 다른 이가 이해할 수 있는 형태는 아니지만 내 나름대로 암호화(?)된 형태로 메소드, 클래스에 주석을 달아 놓는 습관이 생겼다. 일단 내가 코드를 들여다보기 쉬우니까^^ㅋ 다른 사람에게 코드를 넘겨줄 일이 있을 때는 내 주석만 알아보기 쉬운 형태로 번역(?)해서 넘겨주면 만사 OK~

클래스, 메소드, 변수명은 내용에 연관성이 있는 이름으로 만들자. 수정할 일이 있을 때 자신도 알아보기 쉽고 프로그래밍이 절로 즐거워질 것 같다. 이 작업은 어쩌면 주석을 다는 것 이상으로 코드를 살펴보게 될 다른 이에게 감동을 전해줄지도 모른다. 아마도?

가끔 생각하는 것인데, 정말 누군가를 저주해서 제거해 버리고 싶을 때 이런 방법이 있을 수 있다. 주석 하나 없고 이해하기 힘든 변수명이 나열되어있는 긴 소스 코드에 추가로 어떠한 기능을 더 넣고 싶다는 요구사항과 함께 제거해버리고 싶은 사람에게 넘겨준다. 물론 소스에 대해 어떠한 설명을 해 주어서도 안 되며 기왕이면 들여쓰기를 엉망으로 해서 만들어 준다면 효과는 배 이상이 된다. 중간중간 철자가 틀리거나 세미콜론(;)을 빼 두어서 에러를 유발해도 좋다.

class aA{
  int bb;
flat AA
for(S = DD; S > bb; S++){   ...
  ...
         }
     tackle(h);}

대략 이런 형태이면 매우 만족!! 얼마 지나지 않아 좋은 소식이 올 것이다. 그는 이미 머리가 터져서 피를 쏟으며 쓰러져 있을 것이다. 어쩌면 정보화 사회에서 기업들은 자사의 소스 코드를 보호하기 위해서 이미 위와 같은 방법을 쓰고 있을지도 모르겠다. 다만 치명적인 단점이 있는데, 그것은… 자기 자신이 그 피해자가 될 수도 있다는 것이다. 새벽에 너무 일찍 잠에서 깨 버려서 그냥 한번

---

2007. 8. 11 Update

당시엔 주석을 많이 다는 것이 좋은 것인 줄만 알았는데 그게 아니라는 것을 최근에야 알았답니다. 주석이 없어도 한눈에 어떤 일을 하는 내용인지 알아볼 수 있게 만드는 것이 가장 좋은 방법이지요^^ㅋ 꼭 필요한 주석만 씁니다. 너무 남발한 주석은 오히려 코드의 가독성을 떨어뜨린답니다.

---