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

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

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

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

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

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

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

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

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

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

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

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

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

15 comments

  1. 제거 하고 싶은 사람에게 보낸다에 동감.
    그 사람이 얼마나 포기를 잘하냐에 따라서 약간씩 조절해서 보내면 되겠군요.
    잘 포기하는 사람에게는 애매한 주석을 조금 달아주고. 등등.

    연구하다가 먼저 피토하는 것 아닌지 모르겠네요. ^^

    1. 애매한 주석을 조금 달아주는 것은 미처 생각을 못해봤었는데, 시노님은 무척이나 예리하시군요!!^^

  2. 아주 흥미로운 쓰레드라.. 재밌게 읽고 있던중…
    ‘얼마전 여자친구의 쇼핑몰 디자인을 위한 소스를 봤을때 ‘
    이 문장을 보고..
    글을 읽는것을 멈췄습니다.

    그렇습니다.
    전 이성이라곤 눈꼽만치 없는 솔로부대였습니다. OTL.

    개인적인 생각으론 저런식으로 일을 나누는것은 좋지 않다고 생각합니다.

    디자인이라던가… 그런거야.. 디자이너가 따로있으니…
    뭐 그렇다 치더라도..
    한 프로세스는 한사람이 하는게 좋다고 생각합니다.

    코딩후 커뮤니케이션하는시간이 더걸리거든요…. 쩝..

    1. 커뮤니케이션이 가장 큰 문제이긴 합니다. 원문에서도 파트너가 도무지 커뮤니케이션 하는것을 싫어했으니까요.

  3. 더 지독한짓은 ‘무개념이지만 센스는 있는’ 하지만
    ‘그의 이상과 사상은 이해하기 어려운’ 게임 기획자와
    팀을 이루게 해주는 회사입니다. 죽고싶습니다.
    게임 개발자와 게임 기획자 사이에 낀 저같은
    게임 디자이너는 더더욱이 –; 죽고싶습니다……ㅠㅠ

    시노님의 애매한 주석은 최고 ㅡㅜb

    1. 역시 가장 어려운건 사람인가봅니다…..;;
      Poisoner님께 그런 어려움이 있으신줄 몰랐습니다..ㅜㅜ

  4. 함수명이나 클래스명을 오타로 치거나 3중 루프에 3중 포인터등을 두루 거치는 것도 한 방법입니다.

    “간간이” 잘못된 주석 다는 것도 잊지 마시고~ 제대로 된 주석도 있어야 빛을 발합니다~

    1. 3중 루프와 3중 포인터!!
      지금 저 감동했습니다.

      “분명 그것이라면 상대방의 생명을 단축시키는 시간이 빨라진다!!”
      느껴버렸습니다(?)..

      주석을 아예 없애는것 보다 간간이 잘못된 주석으로 혼란을 유도하는게 더 효과적일지도 모르겠습니다.

  5. perl이 깔끔합니다. 아예 접근할 엄두를 못낼만한 코드도 충분히 만들수있으니까요. -_-;;
    회사에서 짜를래야 짜를수가 없지요

    1. perl은 잘 모르지만 이래서님의 댓글을 보니 분명 정상적인 코드조차 미로가 아닐까 생각이 됩니다.
      회사에서 오래 살아남기 위한 방법으로는 자바, php 이런것 보다 perl을!!

  6. 저는 vi로 개발하고…

    맘에 안드는 사람에게 넘겨줄때…한가지 방법을 사용하고 싶습니다.

    :1,$ s/\t//g
    :1,$ s/ //g

    더 이상하면 너무 잔인해 지므로… 생략을..;;

    한때 우리 회사에서 화일에 암호를 걸어서 주는 것도 유행했습니다.

    :X

    1. 트랙백 걸어주신 글 재미있게 읽었습니다^^ㅋ
      사실 VI의 기능들을 잘 알지 못해서 반정도만 이해했는데, 그래도 재미있는데요~

  7. 재미 있는 생각이나서..
    이글을 참조로 새로운 포스팅을 했습니다.^,.^
    글은 트랙백으로 남기겠습니다…

    글에 주소를 남겨 두었지만…..
    가능하시다면 트랙백도 좀 부탁드리겠습니다.

댓글 남기기