일 잘하는 법, 마이크로소프트에서 배운다

Software|2005. 9. 13. 13:01
일 잘하는 법, 마이크로소프트에서 배운다
줄리 빅 지음, 김동헌 옮김 / 한언출판사
나의 점수 : ★★★

원제: All I really need to know in business I Learned at Microsoft

마이크로소프트는 세계 최고의 소프트웨어 회사입니다. 한창 오피스 전쟁이 일어나고 있을 때, 이곳에서 일한 저자가 쓴 글인데, 재밌고 유익합니다. 요즘 우리나라에는 삼성관련 책이 많이 나와있는데, 사실 그다지 체험적이지 않고 삼성이라는 이름을 빌린 듯한 책이 많은데, 이 책은 MS에서 일어나는 사소한 일들도 많이 소개되어 있습니다. 아쉬운 것은 출판된지 거의 10년이 다되서 이미 마이크로소프트도 많이 변해 있기 때문에 책에 있는 내용대로 지금의 현실을 이해한다는 것은 다소 무리가 있습니다. 하여간 어떤 회사에서 일하던지 도움이 될만한 이야기들을 제목만 뽑아 봤습니다.

=전문가만이 살길이다=
예상 답변을 미리 준비하자
업무에 관한 한 모든 것을 속속들이 알아두자
경쟁사를 치밀하게 분석하자

= 효과적으로 일하자=
현명하게 일하라 오래 앉아 있는 것이 능사는 아니다
잘 모르겠습니만 곧 알아보겠습니다.
우기지 말고 웃겨라! 그리고 웃어라
휴식으로 뇌를 재부팅하라
새로운 아이디어는 예상치 못한 곳에서 나오기도 한다
약속을 지킬 수 없다면 다른 사람의 도움을 요청하라

칭찬의 마력, 한 마디의 칭찬이 인생을 바꾼다
집요하게 파고들면 신뢰를 얻는다
메모를 잘 활용하자

여러 책이나 기사를 보다보면 MS 직원들도 야근을 많이 하는 것을 확인할 수 있습니다. 이 책에서도 "일주일에 이틀은 칼퇴근 하자"라고 지은이가 제안할 정도이니까요. 세상을 앞서 나간다는 것은 때론 피곤한 것이도 합니다. 물론 성취감이 있으니까 야근을 밥먹는듯이 하겠죠. 하여간 이것이 효율적이지 못하다면 개인의 금같은 시간을 낭비하는 것이니 가능한 야근하지 않도록 근무시간에 좀더 집중해야겠습니다.

댓글()

나의 조엘 테스트

Software|2005. 8. 10. 23:40
조엘 on 소프트웨어라는 책을 보면 조엘 테스트가 나옵니다. 예전에 한번 보기도 했는데, 괜찮은 테스트이므로 한번 여러분의 소프트웨어 개발 환경에 대해 점검해 보기 바랍니다.

1. 소스코드 관리 시스템을 사용합니까?
cvs, MS visual source safe, rational clear case와 같은 형상관리 툴이 있습니다.

저는 위 3가지 툴을 모두 써봤습니다.
source safe -> cvs -> clear case

source safe는 5년전에 쓰던거라 현재 버전에 대해 뭐라 평가하기는 힘들고 한사람이 소스 파일을 check-out하면 다른 사람은 코들를 수정할 수가 없었습니다. 퇴근하기전 check-in은 필수였습니다. VC++이나 VB에서 기본 제공하므로 가장 쓰기 편했습니다.

cvs는 오픈소스프로젝트에서 사용하고 있는 형상관리툴입니다. 모든 플랫폼에서 안정적으로 동작하면 특히 merge기능은 상용툴인 clear case보다 좋은 것 같습니다. 한번도 실망시킨적이 없습니다.

전반적으로는 상용 제품인 clear case가 좋긴 좋더군요. 물론 서버를 관리해주는 사람이 따로 있다고 가정할 때 말이죠. 특히 소스코드를 서로 다른 프로젝트로 이동하거나 다양한 버전을 유지할 때 그리고 폴더, 파일 이름 변경이 쉬워서 좋았습니다. cvs에서도 서버 접근만 되면 가능하면 쉽게 할 수 있긴하죠.

2. 한방에 빌드를 만들어낼 수 있습니까?
한번 빌드에 다양한 버전에 소프트웨어를 컴파일까지 하고 설치버전까지는 만드는 것입니다. 사실 이 부분은 아직까지 시도해보지 못했습니다. 여러 라이브러리를 쓰면, 라이브러리 따로 컴파일하고 실행파일도 따로 컴파일하고 dll도 따로 빌드하고 이 결과를 가지고 설치 프로그램을 만드는 것은 다소 복잡한 일이기도 하지요. 게다가 버전이 여러가지 유지한다면 분명 실수할 수도 있습니다.

3. 일일 빌드를 하고 있습니까?
일일 빌드라고 말할 수 없지만 수시로 전체 프로젝트를 업데이트해서 각자 빌드는 하고 있습니다. 문제는 실제 타겟용으로 자주 빌드를 해야 하는데, 그렇지 못해서 컴파일이 안되곤 합니다. 임베디드 환경에서는 PC에서 작업을 하고 타겟용으로 다시 컴파일을 하는데, 이때 문제가 자주 발생합니다. PC에서 잘 동작한다고 너무 자신만만해서는 안됩니다. 이것은 꼭 임베디드에 해당하는 것은 아니고 여러 플랫폼을 지원하면 자주 접할 수 있는 문제입니다.

4. 버그 추적 시스템을 운영하고 있습니까?
지금 회사에서도 훌륭하게 운영하고 있었지만 전에는 wiki를 이용하기도 했고 zero board에서 운영한적도 있습니다. 잘만 쓰면 모두 훌륭합니다. 못쓰면 아무리 좋은 툴도 소용이 없습니다.

중요한 것은 다음의 항목이 있어야 한다는 군요.

* 버그를 재현하기 위한 완벽한 단계
* 예상 수행 결과
* 실제 수행 결과
* 수정을 맡을 개발자
* 수정했는지 여부

5. 코드를 새로 작성하기전에 버그를 수정합니다.
이건 정말 중요합니다. 그렇지 못하면 소프트웨어의 위기에 빠지고 맙니다.
하지만 내 마음속에만 숨어있는 버그도 있긴합니다. 거의 발생한 일이 없으므로 아무도 못찾으면 그냥 넘어가기도 하지요.

6. 일정을 업데이트하고 있습니까?
조엘이라는 사람은 MS프로젝트에 대해 좋지 않은 평가를 내리고 있습니다. 저도 MS프로젝트를 이용하고 있지만 처음 작성할 때만 보고 그 후에는 거의 쳐다보지 않게 됩니다.

7. 명세서를 작성하고 있습니까?
정말 중요하다는 사실은 알고 있지만 코딩하는 것 보다 더 어렵습니다. 파워포인트로 아이디어를 정리하고 코딩한 후에 정식으로 문서화를 하고 있습니다.

8. 조용한 작업 환경에서 일하고 있습니까?
한 사무실에 몇십명씩 앉아서 일하는 환경이라면 조용하기가 참 힘들죠. 그 때는 해드폰으로 귀를 막고 모니터에 폭 빠져 일하는 것이 좋습니다. 2-3곡을 무한 반복으로 들으면서 일하면 집중이 잘~ 됩니다.

9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
만약 관리부서 사람들이 제일 먼저 업그레이드 한다면? 그 회사는 머지 않아 망합니다.
다지이너가 제일 먼저 업그레이드를 한다면? 프로그램이 화면발은 죽이지만 버그는 엄청날 수도 있습니다...
개발자에게 LCD 모니터를 사주세요. 정말 일 잘할겁니다.

회사에서 집보다 좋은 환경을 쓰면 그만이겠죠?

10. 테스터를 별도로 두고 있습니까?
출시일이 다가오면 사장님빼고 모두 테스터가 된적도 있습니다. 지금 회사와서 놀란 것은 테스트를 전담해주는 팀이 있다는 사실입니다. 역시 큰회사라 다르군요. 전에 웹브라우저 만들 때, 정말 테스트는 힘든 작업이였습니다. 자동화하기도 힘든 부분이라 일일히 주요 웹페이지를 돌아다니면서 테스트를 했습니다. 개발자가 테스트하면 웬진 비용이 덜 드는 것 같지만 사실 엄청난 비용을 들이는 것입니다.

11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
저도 이런 테스트를 받아본 적도 해본적도 없습니다. 프로그램 결과물과 소스코드를 제출한 적은 있습니다. 사실 이런 테스트를 받으면 잘 할 수 있을지 고민이 되기 합니다.

12. 무작위 사용 편의성 테스트(hallway usabiliy test)를 수행하고 있습니까?
해당 소프트웨어에 대해 문외한인 사람에게 테스트를 맡기는 것이라고 하네요. 영업부나 관리부 직원이면 적당할 것 같습니다.

댓글()

프로그램 테스트

Software|2005. 2. 22. 12:45
그동안 소프트웨어 개발에 있어서 자동화된 테스트에 대해 무지했던 것 같다.
지난 프로젝트에 자동화된 테스트를 도입했다면 밤샘근무와 야근도 많이 줄였을텐데..

테스트는 코딩이 끝난 후에 하는 것이 아니라 개발하기전에 시작해야한다고 한다.

지금은 특정 모듈 개발이 끝나면 바로 테스트 프로그램을 작성하여 어느정도 테스트를 진행하면 신뢰성이 생기면 다음 단계로 진행하게 된다. 이렇게 하면 각 모듈간의 독립성이 높아지고 버그도 많이 줄어들게 된다.

특히 이 모듈 저 모듈이 통합되면서 생기는 골치 아픈 버그를 상당히 줄일 수 있다.

사실 테스트 프로그램을 만들고 테스트하는데 많은 시간이 필요하다. 때로는 실제 개발한 모듈보다 테스트 프로그램이 더 긴경우도 있다. 하지만 테스트를 자동화하는데서 얻는 잇점은 많다.

- 새로운 기능이 추가될 때, 테스트를 빨리 완료할 수 있다.
- 일일히 사람이 테스트하지 않고 자동화 하므로 퇴근후에도 테스트가 가능하다.

아직은 테스트툴을 직접 만들어서 사용하지만 좋은 툴도 많이 나와있다.

Java, C++용으로 개발된 것이 있는데, 한번 사용해 보면 좋을 것 같다.

관련 URL
http://occam.n4gate.com/tt/index.php?pl=62

http://reiot.com/blog/index.php?pl=126

http://www.gamesfromwithin.com/articles/0412/000061.html

댓글()

하버드 아키텍쳐와 폰 노이만 아키텍쳐

Software|2004. 12. 26. 18:01
폰 노이만 아키텍쳐
컴퓨터 아키텍쳐의 한 종류로서 데이터는 메모리에서 읽거나 메모리에 쓰기도 하는 반면, 명령어는 메모리에서 읽기만 하는 구조를 말한다. 이를 처음 고안한 폰 노이만의 이름을 따서 폰 노이만 아키텍쳐라고 부르며 현대 컴퓨터는 거의 대부분 이 방식을 따른다.

특징
1. 프로세서에게 메모리 특정 지점부터 실행하도록 지시할 수 있다. 이 때 데이터와 명령어 사이에 뚜렷한 구분이 없어서 주어진 내용을 무조건 실행한다.
2. 데이터 자체에 고유 의미가 없다. 즉, 이를 해석하는 프로그램에 의해 의미가 달라진다.
3. 데이터와 명령어는 메모리를 공유한다. 특정 프로그램에서 명령어인 내용은 다른 프로그램에서 데이터일 수 있다.

하바드 아키텍쳐
하바드 아키텍쳐는 명령어와 데이터 통로를 저장공간과 물리적으로 분리한 컴퓨터 아키텍쳐를 말한다. 이 용어는 릴레이를 기반으로한 하바드 마크1이란 초기 컴퓨터에서 나온 것이다. 마크1는 명령어를 펀치 테이프에 데이터를 relay latche에 저장한다.
폰 노이만 아키텍쳐와 다르게 CPU는 메모리로 부터 명령어를 읽거나 데이터를 읽기/쓰기가 동시에 가능하다. 그러나 명령어와 데이터가 같은 신호 통로와 메모리를 동시에 사용하지 않는다.

특징
1. 하바드 아키텍쳐 컴퓨터에서는 CPU는 메모리로부터 명령어와 데이터를 동시에 사용할 수 있다.
2. 현재 명령을 마치는 것과 동시에 다음 명령을 가져올 수 있기 때문에 속도가 더 빠를 수 있다.

참고문헌
John Catsoulis, Designing Embedded Hardware, O’Reilly(한빛 미디어)
http://en.wikipedia.org/wiki/Harvard_architecture
http://en.wikipedia.org/wiki/Von_Neumann_architecture

댓글()