read

얼마나 유용하게 쓸지 알 순 없지만, 개인 개발 환경을 만들어 두면 좋을 것 같다는 생각이 들었다.

그럼 어떤 것들이 필요할까? The Joel Test 를 한 번 살펴보면,

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

개인 개발 환경이니 3, 6, 8, 9, 10, 11, 12 등은 크게 상관이 없을 것 같고, 2, 5 은 execution 의 문제가 될 것 같으니 모두 제외하면,

  1. Do you use source control?
  2. Do you have a bug database?
  3. Do you have a spec?

이렇게 요약되네. 소스 컨트롤 쓰냐? 스펙 쓰냐? Bug database 는 있냐? 되겠다. 이제 각각에 맞는 적절한 툴들을 구비해 놓으면 될 터인데.

Spec

스펙은 Windows live Skydrive 에 원노트를 이용해서 간단히 해결. 문서 draft 를 만들 때 원노트 만큼 쉽고 편한 게 없는데다 Skydrive 에서 브라우저로 바로 편집도 간단히 되니까 급할 때 사용할 수도 있다. 스펙 라이브러리는 이걸로 해결보고.

Source control

소스 컨트롤 선택에서 가장 큰 고민은 Centralized vs Decentralized 중에 선택하는 것이다. 여태 사용해 본 것들은 모두 중앙에 서버가 존재하는 Centralized 였고, 요즘 유행하는 Git 이니 Mercurial 이니 하는 것들은 분산 처리 방식이다. 선택에 결정적 영향을 준 StackOverflow 에서 본 글.

… Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours…

http://stackoverflow.com/questions/871/why-is-git-better-than-subversion

그래서 Git 을 사용해 보기로 결정.

Issue Tracker

이슈 트래커는 사실 하기 나름이다. 관리에 자신이 있다면 텍스트 파일 하나 만들어서 관리해도 되고, 엑셀로 시트를 하나 만들어서 관리해도 된다. 개인으로 하는 프로젝트들이 얼마나 복잡해질지 모르겠다마는 일단은 보류. Git 과 통합작업이 용이한 것 중 하나가 되지 않을까 싶은데 Redmine 이라는 것을 물망에 올려놨다.

다만 이 경우 서버 호스팅이 필요해지는데, 지금 쓰고 있는 블로그랑 같은 곳에서 호스팅이 가능한지 여부를 따져봐야 한다. 그렇지 않으면 부가 비용을 더 내고 서버를 하나 더 구해야 됨.

 

일단 이 정도로 정리하고 세팅해봐야 겠다.

Blog Logo

Ki Sung Bae


Published

Image

Gsong's Blog

Developer + Entrepreneur = Entreveloper

Back to Overview