타인의 코드를 대하는 자세

• 이전에 작성하다가 만 코드를 받을 경우가 많이 있어요.
  • SM의 경우 당연히 누군가 만들어 놓은 소스코드로 운영하는 거니까요.
  • SI의 경우 중도 퇴사의 경우 이런 경우가 많죠.
• 이 코드를 어디까지 믿을 수 있을까요?
  • 저는 "믿지 마세요" 라고 보통 말합니다.
  • 코드를 거쳐간 사람들도 모두 "사람" 입니다.
  • 논리적인 헛점이 없이 프로그램을 작성하고 있다고는 생각 못하지요.
• 대부분의 소스코드는 꽤나 지저분합니다.
  • 이건 원래 프로그램을 작성한 사람의 "실력"이 없어서가 아니에요.
  • 소스코드는 여러번 변경되었을 것이고, 변경에 대한 히스토리가 남아있어서에요.
  • 처음에는 그렇게 작성한 이유가 있었을 꺼에요.
• 이전 코드를 받아서 작업하는 경우 그냥 레퍼런스로만 생각하세요.
  • 특히 기존 기능을 수정하는 것이 아니라, 새로운 기능을 만드는데 다른 기능과 비슷한 것이라면 더더욱 더요.
  • 이럴 때 참고해야 하는 건 소스코드 복사가 아니라, 기본적인 프로젝트의 아키텍쳐 정도에요.
  • 카피 앤 페이스트는 우리를 코딩 몽키로 만들 가능성이 높아요.
• 남의 소스 분석하는 시간보다 직접 만드는 게 더 나을 때가 많아요.
  • 그렇다고 해도 남의 소스는 반드시 분석하세요.
  • 왜냐하면 코딩에 정답같은 건 없기 때문이에요.
  • 타인의 소스가 내 스타일이 아니라고 해도, 그게 잘 못 작성한 코드라는 뜻은 아니에요.
  • 물론 너무 한심한 코드를 작성한 경우에는 리팩토링도 가능하겠지요.
  • 하지만 리팩토링은, 그 코드 베이스를 모두 이해했을 때 하는 것이 안전하다는 건 꼭 명심하세요.
• 하지만 어떤 경우에도, 수정할 내용을 숙지하기 전까지는 수정을 하지 마세요.
  • 처음에 코드를 보았을 때는 이해하지 못했던 것들이, 나중에 다른 것들과 엉켜서 돌아가고 있음을 깨닫는 일이 꽤나 많을 것이라 생각해요.
• 요새 버전 관리 시스템(Version Control System) 은 충분히 좋아요.
  • 변경을 해야 한다면 반드시 브랜치를 사용해서 작업하세요.
  • svn도 git도 브랜치가 있어요.
    • 코드가 의심스럽다면 더더욱 더 브랜치를 잘 사용하세요.