일본 친구가 mixi에 링크해 준 칼럼인데 공감*100이라서 올려봅니다.

요 아래는 원문이구요

http://dotmac.rationalmind.net/2010/08/some-lesser-known-truths-about-programming/

요 아래는 일문 번역입니다.

http://www.tommyjp.com/2010/08/blog-post_1710.html

그리고 요 밑에 간단한 한글 번역을 달겠습니다.

(오늘 작성한 제 블로그 글입니다만 퍼왔습니다.)

소프트웨어를 개발하는 경험에서 얻은  몇가지 교훈이 있습니다. 코드를 작성하는 데 있어서, 

사람들이 놀랄만한 몇가지를 여기에 소개합니다.

1. 프로그래머가 가지는 스킬이나 레벨을 불문하고, 대부분의 프로그래머는 전시간의 10~20%정도만 코드를 작성하는데 사용합니다. 대부분의 프로그래머는 프로그램을 완성하는데 하루에 10 에서 12줄 정도의 코드를 작성합니다. 우수한 프로그래머는 나머지 90%의 시간의 대부분을 생각하고, 조사하고, 최고의 설계를 발견하기 위한 검증작업에 사용합니다. 나쁜 프로그래머는 나머지 90%의 시간의 대부분을 디버깅하고, 소소한 의미없는 코드를 수정하는데 사용합니다.

"위대한 선반 기술자는 평범한 선반 기술자에 비해 몇배의 가치가 있다. 하지만 위대한 프로그래머는 평범한 프로그래머에 비해 만배의 가치가 있다." - 빌게이츠

2. 우수한 프로그래머는 일반적인 프로그래머에 비해 10배의 생산성이 있습니다. 그리고 그보다 탁월한 프로그래머는 20~100배의 생산성이 있습니다. 이건 과장이 아닙니다. 1960년대 부터 계속된 수많은 연구들이 이 사실을입증하고 있습니다. 나쁜 프로그래머는 생산적이지 않은것 뿐만 아니라, 일을 더욱더 복잡하게 만들어서, 다른사람들이 고쳐야 하는 수많은 문제와 두통의 씨앗을 여기저기에 심어놓습니다.

3. 위대한 프로그래머는, 제품이 완성되는 시점까지 코드를 작성하는데는 정말 약간의 시간밖에 사용하지 않습니다. 시간의 대부분을 코딩하는데 사용하는 프로그래머는 매우 게으르거나, 뭘 모르거나, 너무 거만하기 때문에, 고전적인 문제에 예전부터 있어왔던 당연한 해결책을 발견해내지 못합니다. 위대한 프로그래머는 공통적인 패턴을 발견해서 재이용하는 달인입니다. 우수한 프로그래머는, 이상적인 설계에 도달하기 위해서 지금까지 작성한 코드를 리팩터링(재검토 하고 재설계하여 다시 작성하는 것) 하는 것을 두려워하지 않습니다. 나쁜 프로그래머는 컨셉의 통일성이나 계층, 패턴이 결여되거나 중복이 있는 리팩터링이 굉장히 어려운 코드를 만들어냅니다. 잘못된 코드는 변경하는 것보다 버리고 처음부터 다시 시작하는 것이 훨씬 낫습니다.

4. 소프트웨어는 다른 것과 마찬가지로 엔트로피 법칙을 따릅니다. 끊이지 않는 변경은 소프트웨어를 망가뜨립니다. 당초 설계에 있었던 컨셉의 통일성을 무너뜨립니다. 물론 약간의 설계 수정을 항상 피할 수는 없지만, 컨셉의 통일성을 고려하지 않는 프로그래머는 소프트웨어를 조금씩 좀먹게 만들어 결국 완성되어도 전혀 쓸모없는 소프트웨어를 만들어 버립니다.  이러한 컨셉의 통일성 문제는 대부분의 프로젝트를 실패하게 만드는 가장 큰 원인이라고 생각합니다. (2번째로 가장 큰 원인은 고객이 원하지 않는 기능을 개발해버리는 경우인 것 같습니다.) 소프트웨어를 좀먹게 만드는 이런 현상은 진척상황을 현격히 느리게 만들어, 종래에는 프로젝트를 끝내기도 전에 스케쥴이나 예산의 핍박에 직면하게 만듭니다.

5. 2004년의 한 조사에 의하면, 대부분의 소프트웨어 개발 프로젝트의 51%는 중요한 기능이 부족하거나, 15%는 실패했습니다. 31%가 실패했던 1994년의 상황보다는 조금 나아졌습니다.

6. 대부분의 소프트웨어는 팀에 의해서 작성됩니다만, 민주적인 활동과는 거리가 멉니다. 통상, 단 한명이 설계를 맡고, 나머지 사람들이  각 파트를 담당합니다.

7. 프로그래밍은 힘든 일입니다. 격렬한 고강도의 정신노동을 요구합니다. 우수한 프로그래머는 연중 대부분의 시간을 일만 생각합니다. 제일 중요한 코드를 침대 속이나 샤워실에서 생각해 냅니다. 가장 중요한 일은 키보드에서 떨어진 곳에서 일어납니다. 따라서, 소프트웨어 개발 프로젝트는 사무실에서 근무하는 시간을 늘린다거나 투입 인원을 늘린다고 해서 작업 스피드를 올릴 수 없습니다.