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

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

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

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

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

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

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

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

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

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

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

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

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