흑백과 디지털

조엘 테스트는 소프트웨어팀 평가테스트 방법입니다.


1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?



우리 회사에 적용해 보도록 하겠습니다.
1. 번은 있지만 좀 부실하고( 그래도 MS용이니 기본은 하는 것 같음)
2. 번은 지키고 있는 것으로 보이긴 하나 단말 빌드의 경우, 좀 거쳐야 하는게 많은 것으로 보임
3. 번은 요즘 잘 지키고 있는 것임
4. 번은 있으나 내 마음에 안 듦
5. 번은 글쎄... 일이 바빠서 못하는 것 같음
6. 번은 잘 모르겠음.
7. 번은 그런 거 없는 것 같음.
8. 번은 아닌 것 같다.
9. 번은 여기에 대해 불만이 많음
10. 번 좀, 더 있었으면 좋겠는데, 있기는 있는 것 같은데
11. 번 대부분 회사가 이런 거 하는 것을 본 적이 없음.
12. 번 내 자신음 믿으므로 안함.

5 ~ 1 점 이라는 말인가??

 문서화 하지 않는 프로그램은 결국, 구전 민요처럼 입에서 입으로 인터페이스나, 설계목적이 알려질 뿐이다.

  어떤 사람들은 XP 프로그래밍이 문서화 하지 않는 것을 의미 한다고 생각한다. 내가 잘 안다고 생각하지 않지만, 그 의미는 다만 주석이나 함수, 변수 이름으로 모든 것이 가독성 있을 때나 통한다고 생각한다. 결국, 사람이 하는 일이다 보니, 그 짧은 공간에 모든 것을 압축해서 설명해 넣을 수 없다. 필연적으로 다른 공간에 적을 수 있게 만든 문서라는게 생기기 마련이다.

 간혹, 사람들이 이 문서라는 것을 너무 어렵게 생각해서, 문서화 하지 않는 것일 수 있다. 포멧을 맞추고, 딱딱한 말투를 사용해야 뭔가 문서 같은 느낌이 나야 한다고 생각하는 것 같다.

 문서라는 것을 그렇게 생각한다면 사람들의 접근성이 떨어지고, 쓰는 사람도 성가시고, 읽는 사람도 지루할 것이다. 굳이 그럴 필요 없이 게시판에 글 쓰는 글 정도로 부드러운 쓴다면 쓰는 사람도 즐겁고, 읽는 사람도 부담 없지 않을까??

 제 블로그는 알려진 블로그가 아니기 때문에 대부분의 경우, 검색을 통해 들어옵니다. (네이버 검색은 robots.txt를 안 지켜서 아예 막아 놓았기 때문에 대부분 구글을 통해 들어옵니다.) 그다지 방문객이 많이 찾아 오는 편도 아니지만, SQLite나 msym(또는 MinGW)를 검색하시고 제 블로그를 방문하시는 비중이 꽤 높군요. 특히, SQLite를 검색해서 들어오시는 분들은 관련 글을 다 뒤져보시는 것 같습니다.
 제가  SQLite를 처음 알게 되었을 때는 한글로 된 메뉴얼은 거의 없었고, 영어로된 메뉴얼도 부실해서 메일 리스트를 뒤져가면서 공부했었는데.(http://nahanmil.egloos.com/2737510). 솔직히 학교에서 DB를 배우지 않아서 DB에 대한 지식도 전혀 없었던 상태였습니다. 그래서 기본적인 것도 몰랐었죠.
 요즈은 SQLite 에 대한 자료가 많이 있더군요. SQLite구조를 분석해 놓은 글도 있고.. 또, 회사에 앉아 있으면 뒤어 있는 사람들이
SQLite 에 대해 이야기 하는 것을 많이 들을 수 있습니다. 아무래도 SQLite가 Public Domain 이니까, 상업적인 용도로는 딱이겠죠.
 SQLite 나 MinGW에 대한 글을 늘리고 싶지만 요즘 회사다니기도 벅차내요.. 요즘은 정상근무(??? : 야근없이 근무하는 것이라는 뜻으로 사용했습니다) 하는 것도 힘들어요. 학교 다닐 때는 공간 시간이 많았는데...

 시간이 나면 이 쪽의 글을 늘리도록 하겠습니다. 저 또한 아직 SQLite가 연구할 만한 가치가 많다고 느껴집니다. 소스코드 레벨에서 분석하는 것도 꽤 좋을 것 같습니다.