프로그래밍 심리학(the Psychology Of Computer Programming)
제랄드 M. 와인버그 저/조상민 역
인사이트(insight)
원제 The Psychology of Computer Programming (silver anniversary edition)
2008년 01월
페이지 524
ISBN : 978-89-91268-36-4
1부 인간 행위로 보는 프로그래밍
1장 프로그램 읽기
* 코드 리딩에 대한 예기.
1-1. 기계의 한계
- 프로그래머는 기계의 한계를 무의식중에 엄연한 사실로 인정해 버리는 경향이 있다.
1-2. 언어의 한계
1-3. 프로그래머의 한계
1-4. 역사의 흔적
- 미연방 사회보장국 예
1-5. 명세
1-6. 요약
- 어떤 프로그램이 현재의 모습을 갖게 된 데에는 다 이유가 있다.
2장 좋은 프로그램이란 무엇인가?
- 프로그래밍 심리학 연구에서 프로그램의 우수성을 평가할 절대적인 척도는 없다.
- 우리는 어떤 프로그램을 다른 프로그램과 비교해 상대적으로 평갛기보다는 개발에 관련된 모든 상황에 비추어 그 프로그램을 평가해야 한다.
- 우리가 원하는 것은 요구 명세에 부합하는 프로그램이다.
* 아래 차례의 순서가 중요도의 순서이다. 요구명세에 부합해야 하는게 가장 중요하단 얘기.
1-1. 요구명세
- 예상되는 범위 내의 입력을 주면 정확한 출력을 내야 한다는 것이다.
1-2. 일정
1-3. 적응성
- 프로그램 수정의 용이성
1-4. 효율성
* 효율성의 기준역시 절대적인게 없다.
- 기계가격의 하락은 시간이 지날수록 하락하므로 효율성보다는 효용성이 더 중시될 것이다.
1-5. 2장에 보내는글
- 많은 관리자가 아직도 모든 것을 원하는 것 같다. 보유한 능력 범위 안에서 최선의 제품을 만들려면 무언가를 얻는 대신에 다른 무언가를 희생해야 하는 즉, 적절한 트레이드오프(trade-off)가 필요함을 여전히 모른다. 마치 뉴욕 양키스 감독이 할 일이라곤 타자에게 매 타석 홈런을, 투수에게 매 이닝 3자 삼진 아웃을 요구하는 것뿐이라는 식이다.
3장 프로그래밍이란 행위를 연구할 방법은 무엇인가?
3-1, 내성법
3-2. 관찰
- 관찰로 사람들이 무엇을 하는지는 알 수 있지만 무엇을 절대 할 수 없는지를 알 수 없다.
- 관찰의 2번째 문제점은 관찰은 관찰일 뿐이라는 것이다.
- 세번째 문제점은 관찰자와 피 관찰자 사이에 생기는 간섭 현상이다.
- 실험에 영향을 미치지 않으려면
- 명인간이 되거나 , 은밀히 관찰해라
3-3. 실험
- 관찰해서 생긴 자료가 지나치게 방대하기 때문에 소요되는 비용을 줄이는 방법 가운데 실험 설계가 있다.
- 실험이 지나치게 정제되어 가장 흥미로운 자료를 얻는데 실패할 수도 있다는 점이다.
- 실험 상황이 너무 제약되어 피험자가 자연스러운 상황에서는 절대 하지 않을 행동을 할 수도 있다.
3-4. 심리학의 측정법
- 심리학은 다른 어떤 과학보다도 측정이 필요할 수도 있는 항목이 많다.
"무엇을 측정할 것인지 아는것이 아는것이다."
- 측정할 가치가 있는 것이 무엇인지 알기 때문에 물리학자들은 연구의 범위를 그만큼 한정시킬수 있다.
- 프로그래밍 심리학의 현재 수준에서는 "질문을 찾는것"이 주된 작업이다.
3-5. 인간행동학의 기존 연구자료 이용
3-6. 요약
심리학 연구의 통상적인 함정들
1. 검증없이 내성법을 사용하는것
2. 지나치게 한정된 대상을 관찰하는것
3. 잘못된 변수를 측정하는 것 또는 옳은 변수를 측정하지 못하는것
4. 관찰 대상의 행동에 개입하는 것
5. 자료는 과도하게 모으고도 저오는 충분히 얻지 못하는것
6. 실험에 지나치게 많은 제약을 가하는것
7. 과도하게 초보 프로그래머들만 연구 대상으로 삼는것
8. 집단 효과와 집단 행동을 연구하지 못하는것
9, 측정하기 쉬워서 측정하는것
10. 검증되지 않은 정밀도를 사용하는 것
11. 기존 연구의 결과를 적절치 못한 대상에 적용하는 것
- 최대 실수는 바로 지나친 신중함이다.
2부 사회활동으로 보는 프로그래밍
- 프로그래머는 보통 고립된 상태에서 일하지 않는다.
* 이책의 가장 중요한 단원이다. 프로그래밍 조직 관리를 하는데 있어서 고려해야 할 사항들에 대해서 나와 있다. 나중에 이 부분을 집중적으로 다시 봐야 할 것이다.
4장 프로그래밍 그룹
4-1. 공식 조직과 비공식 조직
- 관리자에게는 조직도가 재미있는 장난감이겠지만, 프로그래머 간의 상호관계가 조직도를 있는 그대로 따라 그 좁고 단선적인 통로를 통해서만 형성된다면 프로그래밍 작업에 진척이 있을리 없다.
- 사람 사이의 상호관계는 켤고 좁지도 단선적이지도 않다.
- 공식적인 구조만이 어떤 조직 내의 유이란 구조라는 생각이 수많은 커다란 실수들을 빚어왔다.
- 비공식적인 조직은 항상 존재하며 그것을 깊이 이해하지 않은 상태에서 바꿔 버리면 위험하다는 것이다. 원할하게 돌아가던 전체 시스템을 교란시키는 꼴이되기 때문이다.
- 그런 교란 가운데 많은 경우가 물리적인 배치를 변경하여 발생한다.
4-2. 물리적 환경과 사회적 조직
4-3. 프로그램의 오류와 프로그래머의 자아
- 프로그래머의 고립성은 종종 너무 지나칠 때가 있다. 프로그래머는 사람들에게서 고립되는 대신에 자신의 프로그램에 애착을 둔다. 프로그램을 자신의 외연으로 여기기까지 한다.
누구의 것이냐를 중시하는 프로그래밍에서 나타나는 실질적인 문제점에는 또 다른 원인이 있다. 어떤 프로그램이 열등하다는 생각은 적어도 잠재적으로 객관적인 증명 또는 반증이 가능하다. 최소한 우리는 프로그램을 컴퓨터에서 실행해 나오는 결과를 볼수 있다.
- 표면상 컴퓨터의 판단에는 의심할 여지가 없다. 그렇다면 자기 프로그램에 대한 프로그래머의 애착은 자화상에 심각한 손상을 남길수 있다.
- 자신의 프로그램이 자아의 외연이라고 진심으로 믿는 프로그래머는 프로그램에 있는 모든 오류를 찾아내려 하지는 않을것이다. 오히려 그 프로그램의 정확성을 증명하려 노력할 것이다.
* 외연이 강할 프로그래머일수록 인지 부조화 현상이 일어나기 쉽다.
4-4. 비자아적 프로그래밍
* 비자아적이란 의미는 애자일의 공동소유와 유사하다.
- 자아의 문제는 사회적 환경과 더불어 프로그래머들의 가치 체계를 재구성함으로 극복해야 한다.
- 인간으로서 자신이 지닌 한계를 인식하는 바로 그 능력에서 출발했다.
- 자신의 코드를 읽어야 하는 모든 사람을 위해 프로그램을 명확하고 이해하기 쉽게 만들려고 항상 노력했던것이다.
4-5. 프로그래밍 환경의 조성과 유지
4-6. 요약
5장 프로그래밍 팀
5-1. 팀을 어떻게 조직할 것인가?
- 팀 구성원의 능력과 가용 시간에는 작업을 수행하는 데 요구되는 최소치가 있다.
- 개념상,목적한 시스템을 개발하는 데 필요한 최소의 전문 기술과 최소의 시간이있다.
- 최단 일정은 오로지 최고의 팀을 프로젝트에 투입할 때에만 달성 가능하며, 팀의 인원을 최소로 투입하려면 프로젝트 일정이 늦어짐을 각오해야한다.
- 최소의 비용으로 최고의 프로그래밍을 원한다면, 가능한 한 최고의 프로그래머들을 구하고 그들에게 최소한의 인원으로도 문제가 없을 만큼 충분한 시간을 주어야 한다.
- 시스템의 구조에 접근하는 방식은 다양할 수 있는데 반해 그 일에 투입할 수 있는 프로그래머들은 한정된 경우가 많기 때문에, 팀 구성원 개개인이 지닌 강점과 약점을 잘 살릴 수 있는 조직 구조로 선택하는 경우가 많다.
물론 이상적으로는 이와 반대 방향으로 이상적인 프로그램 구조를 먼저 계획하고나서 그 작업을 가장 잘 수행할 수 있는 사람들을 모으는 것이 옳은 순서이다.
5-2. 목표의 수립과 확인
- 팀이 프로젝트의 구조와 업무 분배에 대한 완전한 합의를 이끌어내기 전에 너무 성급하게 일을 시작한다면 어떤 형태로든 문제가 발생할 것이다.
- 사회 심리학자들은 맥락은 좀 다르지만, 한명 이상의 구성원이 그룹의 목료를 공유하지 못하면 그룹 전체의 업무 효율에 악영향을 미친다는 사실을 증명했다.
- 그룹의 목표에 대한 진정한 합의를 얻기 위해서는 그 그룹이 목표를 직접 설정하도록 하는 것이 가장 좋은 방법이다.
- 목표 설정에 참여하면 목표를 한 층 분명하게 이해 할 수 있다.
5-3. 팀 리더쉽과 팀 리더
무지몽매한 관리자들의 사례
- 전형적인 반응 중 하나는 원칙대로 일하는것 (근무시간 엄수, 비품 소비량 조사 등)
* 근본적인 원인을 해결하지 않고 표면적인 부분을 변경하면 역효과가 발생하게 된다.
- 리더십이란 사람들에게 영향을 주는 능력이다.
- 프로그래밍을 전공하지 않았지만, 상부의 결정으로 프로그래밍 팀을 맡게 된 리더는 기술적인 문제에 대한 자신의 무능력을 공개적으로든 아니든 인정하지 않는 한 끊임없이 말썽에 휘말리게 된다.
- 외부의 힘에 의해 임명된 리더는 팀 내부에 걸맞는 영향력을 행사할 능력을 갖추고 있지 못한다. 그런 공식적인 리더는 팀 외부 세계의 목표를 대변한다. 경영자 특과는 어떤 타혐도 있을수 없다고 전제하는 한, 경영자와 팀 간의 갈등에 대한 유일한 해결택은 팀을 굴복시키는 것뿐이다.
* 결국 팀은 형편없는 결과만을 가져오게 된다.
- 민주적인 집단 활동에서 중요한 요소는 모든 구성원이 동등한 리더십을 행사하는 것이 아니라, 외부의 영향을 받지 않고 내부의 현실 상황에 맞쳐 리더십이 정해지는 것이다.
- 외부에서 임명된 리더는 팀과 팀의 목표를 좌지우지하려는 외부 세력사이에서 정보를 전달하는 매개자이다.
그는 외부와 접촉하면서 특별한 경로를 통해 팀원들은 모르는 정보를 얻을 수도 있고, 좀 더 강력한 리더십을 강화하는 수단으로 그 정보를 이용할 수도 있다. 만약에라도 그가 자신에게 유리하도록 외부 정보를 왜곡했음을 팀원들이 알게 된다면 팀 리더로서 실질적인 생명은 끝나는 것이다.
팀리더가 명심해야할것
1. 경영자가 약속 이행을 아무리 강하게 요구한다 해도, 진정으로 원하는 것은 결과물 자체다.
2. 팀 전체가 참여하여 설정한 목표를 추구한다면 결과물을 훨씬 더 쉽게 얻을 수 있다.
- 리더쉽이지닌 역설 중 하나가 바로 이것이다. 언제든 물러날 준비가 되어 있는 리더만이 진정한 성공의 열쇠를 쥐고 있다.
5-4. 팀의 위기
업무지향적: 팀 목표를 성취하려고 수행하는 일
관리자향적: 위기가 닥쳤을때 팀을 효율적으로 유지하고 관리하고자 행하는 일
리더 또는 팀원의 교체
- 민주적으로 조직된 팀은 구성원을 잃을때 받는 축격을 더 잘 견디는 경향이 있다.
* 팀의 업무를 공유하고 있으므로
- 팀원 중 누군가가 맡은 몫을 제대로 해내기에는 능력이 모자람을 다른 팀원이 알아차리는 순간, 또 다른 종류의 위기가 나타난다.
- 민주적인 팀에서는 각 팀원이 서로 작업 결과를 검토할 기회가 많으므로 무능력함이 금방 드러나기가 쉽다.
* 권위적으로 처리하는 방식이 효과적이지만 팀에는 긍정적인 영향을 주지만은 않는다.
- 동료보다 뛰어난 팀원인 경우 반사회적 행동을 할 가능성이 내재되어 있다.
- 자신의 사회적 행동이나 의사소통 방법을 개선할 만큼은 안되지만, 프로그래밍을 하기에는 너무나 똑똑한 사람인 것이다.
- 프로젝트에 강력한 리더 후보가 여러명 있는 경우에는, 팀 형성 과정에서 일어날 갈등을 피하기 위해 리더 후보가 적은 경우보다 더 잘게 분할 할 필요가 있다.
5-5. 요약
6장 프로그래밍 프로젝트
6-1. 변화를 통한 안정
- 어떤 의미에서 프로그래밍 프로젝트 또는 팀은 강과 같다. 물은 계속 바뀌지만 강은 그대로라는 점에서 말이다.
- 많은 프로젝트 관리자는 프로젝트의 구조를 가옥과 비슷하다고 생각한다. 기중 하나가 없어지면 전체가 무너진다고 본다. 특히, 이른바 핵심 인력을 대하는 태도에서 잘 나타난다.
- 대부분은 자신의 지식을 적용해 볼 기회가 없다면 불만족 스러워 한다. 따라서 관리자는 프로젝트가 일종의 프로그머 생산 공장으로 기능하도록 만들어야 한다. 즉, 초보자라는 신선한 재료를 공급 받아 숙련된 리더를 생산하는 것이다.
- 절대 없어서는 안 될 프로그래머가 있다면, 한시라도 빨리 그를 프로젝트에서 제거하라.
* 실제로 제거하라는 의미가 아니라 그 사람에 의해서 프로젝트가 좌지우지 되지 않도록 하라는 의미
6-2. 성과의 측정
- 극단적인 값을 평범한 값으로 조작하는 경향이 지닌 심리적 원인을 찾아야 한다.
* 성과의 측정을 양 극단에 있는 값들은 주목을 받을 가능성이 큼으로 이들 값들은 조작될 가능성이 크다
영향을 주는 요소들
- 요동치는 진척도에 대한 관리자의 인지 부조화
- 상부로부터의 압력
- 동료로부터의 압력
- 프로그래밍 프로젝트의 진척도 측정과 같은 어렵고 주관적인 판단을 할 때 동료들의 영향을 받는 현상을 쉽게 목력할 수 있다.
=>다른 사람이 모두 잘못된 선택을 하지만 한 명만은 정확한 선택을 하도록 미리 약속했을 경우 진짜 피 실험자가 받는 사회적 압력은 모두 사라진다.
=> 데블스 어드버킷(devil's advocate)
매 회의 때 나머지 참석자가 모두 동의하는 듯한 의견에 대해 모든 가능한 부정적인 명을 들추는 것이다.
-> 사람들은 어드버킷의 역활을 망각하기 쉽다.
-> 매번 사람을 바꾼다.
6-3. 프로젝트의 구조
- 조직이 개편하려 할때 어떤 사람과 일하려하기 않거나 특정업무를 거부하거나 하는 현상
- 테스트 그룹과 다른 그룹이 섞여서 있는데도 그들간에는 상호작용이 하나도 이루어 지지 않는 현상
* 이 두가지 다 각 그룹간에 존재하는 차별에서 오는 문제점들이다.
* 특히 테스트 그룹 예시는 현재 내가 처해 있는 상황과 매우 흡사해서 상당히 흥미롭다.
- 프로젝트 내에의 자연스런 반목은 경영진과 프로그래머라는 수직 계층사이에서도 발생한다.
->팀 목표의 수립이 민주적으로 이루어 지지 않아 프로그래머들이 프로젝트는 물론이고 자신의 팀에도 충성심을 갖기 어려워진다.
6-4. 대부모 프로젝트에서 공통적으로 발생하는 사회문제
- 프로젝트가 커지면 실무자를 관리하는 1차 관리자 말고 이런 1차 관리자들을 관리하는 N차 관리자가 존재하게 된다.
N차 관리자의 문제
- 기술에 대한 현실 감각이 떨어져 있다.
- 관리자가 스스로 이해하지 못하는 일을 감독할 때는에는 언제나 실무자를 평가하는 기준이 일 자체가 아니라 일하는 모습이 된다.
- 승진 사다리를 오르는 과정에서 관리자는 점점 더 기술적인 우월성을 확보하기가 어려워지고 그렇기에 자신에게 관위를 주는 지위의 상징에 집착하게 된다.
(하찮은)지위의 상징들
- 전산실 출입허가
- 프로그램 실행의 높은 우선 순위
- 예쁜 여비서
- 여자에 대한 편견
->여자끼리 대화하고 있으면 잡담하는 것이다.
6-5. 요약
3부 개인 행위로 보는 프로그래밍
7장 프로그래밍 작업의 다양성
7-1. 프로그래밍의 프로와 아마추어
- 가장 큰 차이는 아마도 누가 그 프로그램을 사용할 것이냐에 있을 것이다.
아마추어는 자신이 프로그램의 사용자, 프로는 잘 포장해서 냉혹한 세상으로 내보내야 한다.
- 아마추어는 스스로 정한 목적을 달성할 특정 프로그램의 결과만 얻으면 되기 때문에 프로그램을 어떻게든 만들면 된다. 프로에게는 눈앞의 문제를 우회할 여러가지 방책이 있으며, 일단 그중 하나를 통해 급한 불을 끌 수도 있다. 그러나 그의 일은 거기서 멈추지 않고 오히려 시작된다. 자신이 왜 이해하지 못하는지를 이해해야만 하기 때문이다.
- 아마추어는 주어진 문제에 대해 배운다. 반면에 프로는 자신의 직업(프로그래밍)에 대해 배운다.
7-2. 프로그래머가 하려는 것은 무엇인가?
* 적절한 수준
- 적절한 수준 이상으로 작업하는 것을 차라리 그 이하로 작업하는 것보다 더 프로답지 못하다.
- 작업 수준을 적절히 조절하지 못하는 사람은 프로가 되기에는 항상 실격이다.
- 목표에 대한 인식 차이가 프로그래머가 어떤 일을 수행할 때에 행동 차이를 낳는다는 사실은 알 수 있었다.
- 목표를 명확히 수립하면, 우선 프로그래머는 다른 목표를 희생해서라도 그 명확한 목표를 달성하려 한다. 그리고 그 목표를 얼마나 잘 충족시킬지를 훨신 더 보수적(또는 정확하게)추정한다. 강조되지 않은 목표에 대한 프로그래머가 제시한 추정치는 믿을게 못된다.
- 일이 주어진 시간을 다 채울때까지 늘어날 수 잇는 이유는 일정에 대한 다른 목표들의 상대적 중요성이 명확하지 않기 때문이다.
7-3. 프로그래밍 작업의 단계
오해, "프로그래밍은 단일한 재능이 요구되는 단일한 작업이다."
- 문제 정의와 분석, 흐름도 작성, 코딩, 테스트, 문서화로 이어지는 일련의 과정으로 묘사된다.
프로젝트를 명확하게 정의하는 경우의 폐해
- 한시기에 한 종류의 작업만 진행한다면, 그 외의 다른 재능들은 한 동안 썩히는 셈이 된다.
- 이상적인 프로젝트에서는 모든 인력을 동시에 프로그래밍의 특정 단계로 몰아넣지 않아야 한다. 즉 일종의 경계허물기가 필요하다.
- 프로그래머가 하는 작업들을 제대로 세분화해보자
* 분리한 각 부분별로 그 특성에 맞는 인원일 배치하는것이 중요하다.
7-4. 요약
8장 개인의 성격
8-1. 미치광이 파괴자
- 프로그래밍에 초보인 기술자는 교육과정을 수강하도록 조치해 문제를 해결했다.
- 그러나 전문가에게 교육은 답이 될 수 없다. 절대적인 자부심이 있기에 교육을 받거나 다른 사람의 조언을 들으려 하지 않는다.
* 즉 미치광이 파괴자는 초보자보다는 전문가일 가능성이 크다.
8-2. 변하는 성격
8-3. 변하지 않는 성격
8-4. 프로그래머에게 꼭 필요한 성격
- 프로그래밍에는 지능보다는 성격이 더 중요하다고 단언할 수 있다.
- 스트레스가 많은 상황을 어느 정도의 기간 동안 견딜 수 있는 능력
- 잦은 변화에 잘 적응하지 못하는 성격은 부적합
- 겸손함, 작은 성공에 자만하지 않을 정도.
- 자신감, 장애물을 피하거나 타파할 수 있는 정도.
- 융통성없는 성격 부적합
8-5. 성격 검사
8-6. 프로그래머에 대한 성격 검사
8-7. 요약
- 성격 검사로 어떤 사람이 좋은 프로그래머가 될지 판별할 수 없다.
9장 지능 또는 문제해결력
9-1. 심리적 자세
9-2. 문제 해결의 여러 측면들
9-3. 프로그래밍을 위한 지능의 여러 측면
- 몇몇 고정된 규칙으로만 수행되는 행위는 사람보다는 기계가 수행하는 편이 낫다.
* 기계의 힘을 빌린건 빌리고
- 컴퓨터든 기억력이던 현재 가진 것을 최대한 활용해야 한다.
* 상황에 맞게 활용할 수 있는 것을 쓰자
- 디버깅 단계에서는 상호 보완적인 정신 능력의 거의 몯느 조합이 필요한다.
* 디버깅 능력
- 더 드문것은 문서를 잘 쓴 사람이다.
* 문서화 능력
9-4. 프로그래머를 대상으로 하는 적성 검사
- 검사가 전혀 쓸모없지는 않지만 실제 업무에서는 단순 적성보다 더 중요한 요소들이 있다는 뜻이다.
9-5. 요약
- 지능보다는 성경이나 업무습관,훈련이 더 관련 있다고 믿는다. 그렇다면 문제는 어떤 사람을 프로그래머로 뽑느냐가 아니라 어떻게 프로그래머를 양성할 것인가로 바뀐다. 즉 좋은 프로그래머는 태어나는 것이 아니라 양성된다. 따라서 훈련과정에 관심을 가져야 한다.
10장 동기 부여와 훈련,경험
10-1. 동기 부여
- 동력을 높이면 처음에는 능률이 최대치까지 올라가지만 그 이상의 동력을 가하면 오히려 능률이 0까지 빠르게 떨어진다는 점이다.
- 프로그래머에게 빨리 버그를 없애라고 압박하는 것은 최악의 나력이다. 그러나 이것이 지금까지 가장 일반적인 전략이었다.
10-2. 훈련과 수업, 교육
- 교육은 일반적인 원칙과 기술의 습득을
- 훈련은 특수한 기술의 습득을 의미한다.
10-3. 학습을 저해하는 요인들
성인은 학습에 대한 장벽을 가지고 있다.
- 약점인정
- 실수에 관대해야 하나 관찰자의 존재가 그걸 방해 한다.
- 상실에 대한 두려움
10-4. 프로그래밍을 학습하는 방법
- 뭔가를 학습하는 방법을 배우는 첫 단계는 자신이 무엇을 알고 있고 무엇을 모르는지를 배우는 것이다.
- 뭔가 필요한 시기만큼 배움에 적합한 시기는 없다. but 일정이 있고 관리자가 있기 때문에 실패에 대비해야 한다.-> 새로운 기술을 적용해 보고 실패하면 그 이유를 조사하는 데 어느 정도의 시간을 쓰고, 만약 성과가 없다면 기존의 기술로 대체하여 문제를 일단 무마한다. 대신에 나중에라도 다시 시도할 수 있도록 테스트 케치스를 만들어 놓는다.
10-5. 요약
프로그래머의 성과를 향상시키는 요소
- 일을 하고 싶어하는 마음 : 동기부여
- 업무를 수행하기 위해 필요한 지식 : 훈련, 교육
4부 프로그래밍 도구
* 이장은 다른 장과는 달리 심리학이 부 주제 정도로 다뤄지는 부분이다. 컴파일러 얘기를 꺼내기 위해서 심리학 부분을 가져다 놓은 듯한 느낌.
11장 프로그래밍 언어
11-1. 프로그래밍 언어와 자연언어
11-2. 프로그래밍 언어 설계
12장 프로그래밍 언어 설계에 필요한 원칙
12-1. 일관성
12-2. 간결성
12-3. 근접성과 순차성
우리는 공감각적이고 순차적인 것일 잘 기억한다.
- 공감각적 특징인 근접성은 프로그램에서 서로 관련있는 부분이 모두 한 장소에 나타나는 성질을 의미한다.-> 압축 -> 서브루틴
12-4. 전통과 혁신
12-5. 특수 목적 언어, 범용 언어, 장난감 언어
13장 그외의 프로그래밍 도구들
13-1. 프로그램 테스트 도구
13-2. 운영체제
13-3. 시분할(time-sharing 대 배치(batch)
13-4. 문서화
5부 에필로그
- 이 책으로부터 큰 영향을 받은 독자는 컴퓨터의 운영체제가 아니라 자신의 CPU 즉, 머리를 감독하는 운영체제에 신경쓰기 시작할 것이다.
EOF
POCP from yes24
제랄드 M. 와인버그 저/조상민 역
인사이트(insight)
원제 The Psychology of Computer Programming (silver anniversary edition)
2008년 01월
페이지 524
ISBN : 978-89-91268-36-4
1부 인간 행위로 보는 프로그래밍
1장 프로그램 읽기
* 코드 리딩에 대한 예기.
1-1. 기계의 한계
- 프로그래머는 기계의 한계를 무의식중에 엄연한 사실로 인정해 버리는 경향이 있다.
1-2. 언어의 한계
1-3. 프로그래머의 한계
1-4. 역사의 흔적
- 미연방 사회보장국 예
1-5. 명세
1-6. 요약
- 어떤 프로그램이 현재의 모습을 갖게 된 데에는 다 이유가 있다.
2장 좋은 프로그램이란 무엇인가?
- 프로그래밍 심리학 연구에서 프로그램의 우수성을 평가할 절대적인 척도는 없다.
- 우리는 어떤 프로그램을 다른 프로그램과 비교해 상대적으로 평갛기보다는 개발에 관련된 모든 상황에 비추어 그 프로그램을 평가해야 한다.
- 우리가 원하는 것은 요구 명세에 부합하는 프로그램이다.
* 아래 차례의 순서가 중요도의 순서이다. 요구명세에 부합해야 하는게 가장 중요하단 얘기.
1-1. 요구명세
- 예상되는 범위 내의 입력을 주면 정확한 출력을 내야 한다는 것이다.
1-2. 일정
1-3. 적응성
- 프로그램 수정의 용이성
피셔의 기본정리(Fisher's Fundamental Theorem)
한 유전자 시스템이 특정환경에 많이 적응되어 있을수록 다른 새로운 환경에 적응하기는 더 어렵다.
1-4. 효율성
* 효율성의 기준역시 절대적인게 없다.
- 기계가격의 하락은 시간이 지날수록 하락하므로 효율성보다는 효용성이 더 중시될 것이다.
1-5. 2장에 보내는글
- 많은 관리자가 아직도 모든 것을 원하는 것 같다. 보유한 능력 범위 안에서 최선의 제품을 만들려면 무언가를 얻는 대신에 다른 무언가를 희생해야 하는 즉, 적절한 트레이드오프(trade-off)가 필요함을 여전히 모른다. 마치 뉴욕 양키스 감독이 할 일이라곤 타자에게 매 타석 홈런을, 투수에게 매 이닝 3자 삼진 아웃을 요구하는 것뿐이라는 식이다.
3장 프로그래밍이란 행위를 연구할 방법은 무엇인가?
3-1, 내성법
* 내성 사전적의미
introspection
內省 안내, 살필성
자신을 돌이켜 살펴봄.
자기반성.
3-2. 관찰
- 관찰로 사람들이 무엇을 하는지는 알 수 있지만 무엇을 절대 할 수 없는지를 알 수 없다.
- 관찰의 2번째 문제점은 관찰은 관찰일 뿐이라는 것이다.
- 세번째 문제점은 관찰자와 피 관찰자 사이에 생기는 간섭 현상이다.
호손효과
피험자들이 실험에 참가하고 있다는 사실을 의식해서 평소와는 다른 행동을 함으로써 결과에 영향을 미치는 현상을 말한다.
- 실험에 영향을 미치지 않으려면
- 명인간이 되거나 , 은밀히 관찰해라
3-3. 실험
- 관찰해서 생긴 자료가 지나치게 방대하기 때문에 소요되는 비용을 줄이는 방법 가운데 실험 설계가 있다.
- 실험이 지나치게 정제되어 가장 흥미로운 자료를 얻는데 실패할 수도 있다는 점이다.
- 실험 상황이 너무 제약되어 피험자가 자연스러운 상황에서는 절대 하지 않을 행동을 할 수도 있다.
3-4. 심리학의 측정법
- 심리학은 다른 어떤 과학보다도 측정이 필요할 수도 있는 항목이 많다.
"무엇을 측정할 것인지 아는것이 아는것이다."
- 측정할 가치가 있는 것이 무엇인지 알기 때문에 물리학자들은 연구의 범위를 그만큼 한정시킬수 있다.
- 프로그래밍 심리학의 현재 수준에서는 "질문을 찾는것"이 주된 작업이다.
3-5. 인간행동학의 기존 연구자료 이용
3-6. 요약
심리학 연구의 통상적인 함정들
1. 검증없이 내성법을 사용하는것
2. 지나치게 한정된 대상을 관찰하는것
3. 잘못된 변수를 측정하는 것 또는 옳은 변수를 측정하지 못하는것
4. 관찰 대상의 행동에 개입하는 것
5. 자료는 과도하게 모으고도 저오는 충분히 얻지 못하는것
6. 실험에 지나치게 많은 제약을 가하는것
7. 과도하게 초보 프로그래머들만 연구 대상으로 삼는것
8. 집단 효과와 집단 행동을 연구하지 못하는것
9, 측정하기 쉬워서 측정하는것
10. 검증되지 않은 정밀도를 사용하는 것
11. 기존 연구의 결과를 적절치 못한 대상에 적용하는 것
- 최대 실수는 바로 지나친 신중함이다.
2부 사회활동으로 보는 프로그래밍
- 프로그래머는 보통 고립된 상태에서 일하지 않는다.
* 이책의 가장 중요한 단원이다. 프로그래밍 조직 관리를 하는데 있어서 고려해야 할 사항들에 대해서 나와 있다. 나중에 이 부분을 집중적으로 다시 봐야 할 것이다.
4장 프로그래밍 그룹
4-1. 공식 조직과 비공식 조직
- 관리자에게는 조직도가 재미있는 장난감이겠지만, 프로그래머 간의 상호관계가 조직도를 있는 그대로 따라 그 좁고 단선적인 통로를 통해서만 형성된다면 프로그래밍 작업에 진척이 있을리 없다.
- 사람 사이의 상호관계는 켤고 좁지도 단선적이지도 않다.
- 공식적인 구조만이 어떤 조직 내의 유이란 구조라는 생각이 수많은 커다란 실수들을 빚어왔다.
- 비공식적인 조직은 항상 존재하며 그것을 깊이 이해하지 않은 상태에서 바꿔 버리면 위험하다는 것이다. 원할하게 돌아가던 전체 시스템을 교란시키는 꼴이되기 때문이다.
- 그런 교란 가운데 많은 경우가 물리적인 배치를 변경하여 발생한다.
4-2. 물리적 환경과 사회적 조직
4-3. 프로그램의 오류와 프로그래머의 자아
- 프로그래머의 고립성은 종종 너무 지나칠 때가 있다. 프로그래머는 사람들에게서 고립되는 대신에 자신의 프로그램에 애착을 둔다. 프로그램을 자신의 외연으로 여기기까지 한다.
누구의 것이냐를 중시하는 프로그래밍에서 나타나는 실질적인 문제점에는 또 다른 원인이 있다. 어떤 프로그램이 열등하다는 생각은 적어도 잠재적으로 객관적인 증명 또는 반증이 가능하다. 최소한 우리는 프로그램을 컴퓨터에서 실행해 나오는 결과를 볼수 있다.
- 표면상 컴퓨터의 판단에는 의심할 여지가 없다. 그렇다면 자기 프로그램에 대한 프로그래머의 애착은 자화상에 심각한 손상을 남길수 있다.
인지부조화(congnitive dissonance)
피험자들은 평소에는 절대하지 않을 행동을 해야 한다. 자신이 믿지 않는 것을 주장하는 행동을 위선이라 한다. 위선은 사회적으로좋게 평가되지 않는다. 따라서 부조화 상황이 발생한다. 사람은 이런 부조화 상타에서 매우 불편하고 불안함을 느낀다. 따라서 어떤 식으로든 빨리 해소해야한다. 부조화를 해소하려면 그것을 이루는 요소 중 하나 이상을 포기해야 한다. 어떤 요소가 희생 될지는 상황에 따라 다르겠지만, 일반적으로 볼때 개인의 자화상만은 절대로 포기하지 않는다.
20달러 받은 사람들은 자신의 부조화 상황을 쉽게 해소한다.
"단지 돈을 벌려고 그랬을 뿐이야"
1달러를 받은 사람들은 사정이 다르다.
1달러는 그리 의미 있는 돈이 아니다. 그들을 부조롸를 다른 방법으로 해소해야 한다. 그들 대다수에게 가장 쉬운 방법은 자신이 반대하는 의견에도 어느정도 타당성이 있음을 인정하는 것이다. 그래서 그런 글을 쓴건 위선이 아니라, 양쪽 의견을 모두 살핌으로써 공평하고 정직한 마음을 기르려는 훈련이었다고 주장한다.
- 자신의 프로그램이 자아의 외연이라고 진심으로 믿는 프로그래머는 프로그램에 있는 모든 오류를 찾아내려 하지는 않을것이다. 오히려 그 프로그램의 정확성을 증명하려 노력할 것이다.
* 외연이 강할 프로그래머일수록 인지 부조화 현상이 일어나기 쉽다.
4-4. 비자아적 프로그래밍
* 비자아적이란 의미는 애자일의 공동소유와 유사하다.
- 자아의 문제는 사회적 환경과 더불어 프로그래머들의 가치 체계를 재구성함으로 극복해야 한다.
- 인간으로서 자신이 지닌 한계를 인식하는 바로 그 능력에서 출발했다.
- 자신의 코드를 읽어야 하는 모든 사람을 위해 프로그램을 명확하고 이해하기 쉽게 만들려고 항상 노력했던것이다.
4-5. 프로그래밍 환경의 조성과 유지
4-6. 요약
5장 프로그래밍 팀
5-1. 팀을 어떻게 조직할 것인가?
- 팀 구성원의 능력과 가용 시간에는 작업을 수행하는 데 요구되는 최소치가 있다.
- 개념상,목적한 시스템을 개발하는 데 필요한 최소의 전문 기술과 최소의 시간이있다.
- 최단 일정은 오로지 최고의 팀을 프로젝트에 투입할 때에만 달성 가능하며, 팀의 인원을 최소로 투입하려면 프로젝트 일정이 늦어짐을 각오해야한다.
- 최소의 비용으로 최고의 프로그래밍을 원한다면, 가능한 한 최고의 프로그래머들을 구하고 그들에게 최소한의 인원으로도 문제가 없을 만큼 충분한 시간을 주어야 한다.
- 시스템의 구조에 접근하는 방식은 다양할 수 있는데 반해 그 일에 투입할 수 있는 프로그래머들은 한정된 경우가 많기 때문에, 팀 구성원 개개인이 지닌 강점과 약점을 잘 살릴 수 있는 조직 구조로 선택하는 경우가 많다.
물론 이상적으로는 이와 반대 방향으로 이상적인 프로그램 구조를 먼저 계획하고나서 그 작업을 가장 잘 수행할 수 있는 사람들을 모으는 것이 옳은 순서이다.
5-2. 목표의 수립과 확인
- 팀이 프로젝트의 구조와 업무 분배에 대한 완전한 합의를 이끌어내기 전에 너무 성급하게 일을 시작한다면 어떤 형태로든 문제가 발생할 것이다.
- 사회 심리학자들은 맥락은 좀 다르지만, 한명 이상의 구성원이 그룹의 목료를 공유하지 못하면 그룹 전체의 업무 효율에 악영향을 미친다는 사실을 증명했다.
- 그룹의 목표에 대한 진정한 합의를 얻기 위해서는 그 그룹이 목표를 직접 설정하도록 하는 것이 가장 좋은 방법이다.
- 목표 설정에 참여하면 목표를 한 층 분명하게 이해 할 수 있다.
5-3. 팀 리더쉽과 팀 리더
무지몽매한 관리자들의 사례
- 전형적인 반응 중 하나는 원칙대로 일하는것 (근무시간 엄수, 비품 소비량 조사 등)
* 근본적인 원인을 해결하지 않고 표면적인 부분을 변경하면 역효과가 발생하게 된다.
- 리더십이란 사람들에게 영향을 주는 능력이다.
- 프로그래밍을 전공하지 않았지만, 상부의 결정으로 프로그래밍 팀을 맡게 된 리더는 기술적인 문제에 대한 자신의 무능력을 공개적으로든 아니든 인정하지 않는 한 끊임없이 말썽에 휘말리게 된다.
- 외부의 힘에 의해 임명된 리더는 팀 내부에 걸맞는 영향력을 행사할 능력을 갖추고 있지 못한다. 그런 공식적인 리더는 팀 외부 세계의 목표를 대변한다. 경영자 특과는 어떤 타혐도 있을수 없다고 전제하는 한, 경영자와 팀 간의 갈등에 대한 유일한 해결택은 팀을 굴복시키는 것뿐이다.
* 결국 팀은 형편없는 결과만을 가져오게 된다.
- 민주적인 집단 활동에서 중요한 요소는 모든 구성원이 동등한 리더십을 행사하는 것이 아니라, 외부의 영향을 받지 않고 내부의 현실 상황에 맞쳐 리더십이 정해지는 것이다.
- 외부에서 임명된 리더는 팀과 팀의 목표를 좌지우지하려는 외부 세력사이에서 정보를 전달하는 매개자이다.
그는 외부와 접촉하면서 특별한 경로를 통해 팀원들은 모르는 정보를 얻을 수도 있고, 좀 더 강력한 리더십을 강화하는 수단으로 그 정보를 이용할 수도 있다. 만약에라도 그가 자신에게 유리하도록 외부 정보를 왜곡했음을 팀원들이 알게 된다면 팀 리더로서 실질적인 생명은 끝나는 것이다.
팀리더가 명심해야할것
1. 경영자가 약속 이행을 아무리 강하게 요구한다 해도, 진정으로 원하는 것은 결과물 자체다.
2. 팀 전체가 참여하여 설정한 목표를 추구한다면 결과물을 훨씬 더 쉽게 얻을 수 있다.
- 리더쉽이지닌 역설 중 하나가 바로 이것이다. 언제든 물러날 준비가 되어 있는 리더만이 진정한 성공의 열쇠를 쥐고 있다.
5-4. 팀의 위기
업무지향적: 팀 목표를 성취하려고 수행하는 일
관리자향적: 위기가 닥쳤을때 팀을 효율적으로 유지하고 관리하고자 행하는 일
리더 또는 팀원의 교체
- 민주적으로 조직된 팀은 구성원을 잃을때 받는 축격을 더 잘 견디는 경향이 있다.
* 팀의 업무를 공유하고 있으므로
- 팀원 중 누군가가 맡은 몫을 제대로 해내기에는 능력이 모자람을 다른 팀원이 알아차리는 순간, 또 다른 종류의 위기가 나타난다.
- 민주적인 팀에서는 각 팀원이 서로 작업 결과를 검토할 기회가 많으므로 무능력함이 금방 드러나기가 쉽다.
* 권위적으로 처리하는 방식이 효과적이지만 팀에는 긍정적인 영향을 주지만은 않는다.
- 동료보다 뛰어난 팀원인 경우 반사회적 행동을 할 가능성이 내재되어 있다.
- 자신의 사회적 행동이나 의사소통 방법을 개선할 만큼은 안되지만, 프로그래밍을 하기에는 너무나 똑똑한 사람인 것이다.
- 프로젝트에 강력한 리더 후보가 여러명 있는 경우에는, 팀 형성 과정에서 일어날 갈등을 피하기 위해 리더 후보가 적은 경우보다 더 잘게 분할 할 필요가 있다.
5-5. 요약
6장 프로그래밍 프로젝트
6-1. 변화를 통한 안정
- 어떤 의미에서 프로그래밍 프로젝트 또는 팀은 강과 같다. 물은 계속 바뀌지만 강은 그대로라는 점에서 말이다.
- 많은 프로젝트 관리자는 프로젝트의 구조를 가옥과 비슷하다고 생각한다. 기중 하나가 없어지면 전체가 무너진다고 본다. 특히, 이른바 핵심 인력을 대하는 태도에서 잘 나타난다.
- 대부분은 자신의 지식을 적용해 볼 기회가 없다면 불만족 스러워 한다. 따라서 관리자는 프로젝트가 일종의 프로그머 생산 공장으로 기능하도록 만들어야 한다. 즉, 초보자라는 신선한 재료를 공급 받아 숙련된 리더를 생산하는 것이다.
- 절대 없어서는 안 될 프로그래머가 있다면, 한시라도 빨리 그를 프로젝트에서 제거하라.
* 실제로 제거하라는 의미가 아니라 그 사람에 의해서 프로젝트가 좌지우지 되지 않도록 하라는 의미
6-2. 성과의 측정
- 극단적인 값을 평범한 값으로 조작하는 경향이 지닌 심리적 원인을 찾아야 한다.
* 성과의 측정을 양 극단에 있는 값들은 주목을 받을 가능성이 큼으로 이들 값들은 조작될 가능성이 크다
영향을 주는 요소들
- 요동치는 진척도에 대한 관리자의 인지 부조화
- 상부로부터의 압력
- 동료로부터의 압력
- 프로그래밍 프로젝트의 진척도 측정과 같은 어렵고 주관적인 판단을 할 때 동료들의 영향을 받는 현상을 쉽게 목력할 수 있다.
=>다른 사람이 모두 잘못된 선택을 하지만 한 명만은 정확한 선택을 하도록 미리 약속했을 경우 진짜 피 실험자가 받는 사회적 압력은 모두 사라진다.
=> 데블스 어드버킷(devil's advocate)
매 회의 때 나머지 참석자가 모두 동의하는 듯한 의견에 대해 모든 가능한 부정적인 명을 들추는 것이다.
-> 사람들은 어드버킷의 역활을 망각하기 쉽다.
-> 매번 사람을 바꾼다.
6-3. 프로젝트의 구조
- 조직이 개편하려 할때 어떤 사람과 일하려하기 않거나 특정업무를 거부하거나 하는 현상
- 테스트 그룹과 다른 그룹이 섞여서 있는데도 그들간에는 상호작용이 하나도 이루어 지지 않는 현상
* 이 두가지 다 각 그룹간에 존재하는 차별에서 오는 문제점들이다.
* 특히 테스트 그룹 예시는 현재 내가 처해 있는 상황과 매우 흡사해서 상당히 흥미롭다.
- 프로젝트 내에의 자연스런 반목은 경영진과 프로그래머라는 수직 계층사이에서도 발생한다.
->팀 목표의 수립이 민주적으로 이루어 지지 않아 프로그래머들이 프로젝트는 물론이고 자신의 팀에도 충성심을 갖기 어려워진다.
6-4. 대부모 프로젝트에서 공통적으로 발생하는 사회문제
- 프로젝트가 커지면 실무자를 관리하는 1차 관리자 말고 이런 1차 관리자들을 관리하는 N차 관리자가 존재하게 된다.
N차 관리자의 문제
- 기술에 대한 현실 감각이 떨어져 있다.
- 관리자가 스스로 이해하지 못하는 일을 감독할 때는에는 언제나 실무자를 평가하는 기준이 일 자체가 아니라 일하는 모습이 된다.
- 승진 사다리를 오르는 과정에서 관리자는 점점 더 기술적인 우월성을 확보하기가 어려워지고 그렇기에 자신에게 관위를 주는 지위의 상징에 집착하게 된다.
(하찮은)지위의 상징들
- 전산실 출입허가
- 프로그램 실행의 높은 우선 순위
- 예쁜 여비서
- 여자에 대한 편견
->여자끼리 대화하고 있으면 잡담하는 것이다.
6-5. 요약
3부 개인 행위로 보는 프로그래밍
7장 프로그래밍 작업의 다양성
7-1. 프로그래밍의 프로와 아마추어
- 가장 큰 차이는 아마도 누가 그 프로그램을 사용할 것이냐에 있을 것이다.
아마추어는 자신이 프로그램의 사용자, 프로는 잘 포장해서 냉혹한 세상으로 내보내야 한다.
- 아마추어는 스스로 정한 목적을 달성할 특정 프로그램의 결과만 얻으면 되기 때문에 프로그램을 어떻게든 만들면 된다. 프로에게는 눈앞의 문제를 우회할 여러가지 방책이 있으며, 일단 그중 하나를 통해 급한 불을 끌 수도 있다. 그러나 그의 일은 거기서 멈추지 않고 오히려 시작된다. 자신이 왜 이해하지 못하는지를 이해해야만 하기 때문이다.
- 아마추어는 주어진 문제에 대해 배운다. 반면에 프로는 자신의 직업(프로그래밍)에 대해 배운다.
7-2. 프로그래머가 하려는 것은 무엇인가?
* 적절한 수준
- 적절한 수준 이상으로 작업하는 것을 차라리 그 이하로 작업하는 것보다 더 프로답지 못하다.
- 작업 수준을 적절히 조절하지 못하는 사람은 프로가 되기에는 항상 실격이다.
- 목표에 대한 인식 차이가 프로그래머가 어떤 일을 수행할 때에 행동 차이를 낳는다는 사실은 알 수 있었다.
- 목표를 명확히 수립하면, 우선 프로그래머는 다른 목표를 희생해서라도 그 명확한 목표를 달성하려 한다. 그리고 그 목표를 얼마나 잘 충족시킬지를 훨신 더 보수적(또는 정확하게)추정한다. 강조되지 않은 목표에 대한 프로그래머가 제시한 추정치는 믿을게 못된다.
파킨슨 법칙
일은 주어진 시간을 다 채울때까지 늘어난다.
- 일이 주어진 시간을 다 채울때까지 늘어날 수 잇는 이유는 일정에 대한 다른 목표들의 상대적 중요성이 명확하지 않기 때문이다.
7-3. 프로그래밍 작업의 단계
오해, "프로그래밍은 단일한 재능이 요구되는 단일한 작업이다."
- 문제 정의와 분석, 흐름도 작성, 코딩, 테스트, 문서화로 이어지는 일련의 과정으로 묘사된다.
프로젝트를 명확하게 정의하는 경우의 폐해
- 한시기에 한 종류의 작업만 진행한다면, 그 외의 다른 재능들은 한 동안 썩히는 셈이 된다.
- 이상적인 프로젝트에서는 모든 인력을 동시에 프로그래밍의 특정 단계로 몰아넣지 않아야 한다. 즉 일종의 경계허물기가 필요하다.
- 프로그래머가 하는 작업들을 제대로 세분화해보자
* 분리한 각 부분별로 그 특성에 맞는 인원일 배치하는것이 중요하다.
7-4. 요약
8장 개인의 성격
8-1. 미치광이 파괴자
- 프로그래밍에 초보인 기술자는 교육과정을 수강하도록 조치해 문제를 해결했다.
- 그러나 전문가에게 교육은 답이 될 수 없다. 절대적인 자부심이 있기에 교육을 받거나 다른 사람의 조언을 들으려 하지 않는다.
* 즉 미치광이 파괴자는 초보자보다는 전문가일 가능성이 크다.
8-2. 변하는 성격
8-3. 변하지 않는 성격
8-4. 프로그래머에게 꼭 필요한 성격
- 프로그래밍에는 지능보다는 성격이 더 중요하다고 단언할 수 있다.
- 스트레스가 많은 상황을 어느 정도의 기간 동안 견딜 수 있는 능력
- 잦은 변화에 잘 적응하지 못하는 성격은 부적합
- 겸손함, 작은 성공에 자만하지 않을 정도.
- 자신감, 장애물을 피하거나 타파할 수 있는 정도.
- 융통성없는 성격 부적합
8-5. 성격 검사
8-6. 프로그래머에 대한 성격 검사
8-7. 요약
- 성격 검사로 어떤 사람이 좋은 프로그래머가 될지 판별할 수 없다.
9장 지능 또는 문제해결력
9-1. 심리적 자세
9-2. 문제 해결의 여러 측면들
9-3. 프로그래밍을 위한 지능의 여러 측면
- 몇몇 고정된 규칙으로만 수행되는 행위는 사람보다는 기계가 수행하는 편이 낫다.
* 기계의 힘을 빌린건 빌리고
- 컴퓨터든 기억력이던 현재 가진 것을 최대한 활용해야 한다.
* 상황에 맞게 활용할 수 있는 것을 쓰자
- 디버깅 단계에서는 상호 보완적인 정신 능력의 거의 몯느 조합이 필요한다.
* 디버깅 능력
- 더 드문것은 문서를 잘 쓴 사람이다.
* 문서화 능력
9-4. 프로그래머를 대상으로 하는 적성 검사
- 검사가 전혀 쓸모없지는 않지만 실제 업무에서는 단순 적성보다 더 중요한 요소들이 있다는 뜻이다.
9-5. 요약
- 지능보다는 성경이나 업무습관,훈련이 더 관련 있다고 믿는다. 그렇다면 문제는 어떤 사람을 프로그래머로 뽑느냐가 아니라 어떻게 프로그래머를 양성할 것인가로 바뀐다. 즉 좋은 프로그래머는 태어나는 것이 아니라 양성된다. 따라서 훈련과정에 관심을 가져야 한다.
10장 동기 부여와 훈련,경험
10-1. 동기 부여
인간은 어떤 자극에 반응하고 어떤 자극은 무시할지, 또 어떤 정보를 배우고 나머지는 버릴지를 스스로 결정한다고 말할 수 있다. 따라서 이난에게는 일종의 원동력이 내재한다는 가정을 세울 수 있다. 이 내적 원동력이 우리가 흔히 말하는 동기다.- 관리자는 부족한 내적 원동력을 보충할 외적 동력을 프로그래머에게 부여하려한다. 사실 프로그래머에게 동기가 적어서라기보다는 너무 문제가 많은 상황인데도 말이다.
- 그레치(Krech), 크러치필드 리버슨 공저 심리학 교과서 첫머리 -
- 동력을 높이면 처음에는 능률이 최대치까지 올라가지만 그 이상의 동력을 가하면 오히려 능률이 0까지 빠르게 떨어진다는 점이다.
- 프로그래머에게 빨리 버그를 없애라고 압박하는 것은 최악의 나력이다. 그러나 이것이 지금까지 가장 일반적인 전략이었다.
10-2. 훈련과 수업, 교육
- 교육은 일반적인 원칙과 기술의 습득을
- 훈련은 특수한 기술의 습득을 의미한다.
10-3. 학습을 저해하는 요인들
성인은 학습에 대한 장벽을 가지고 있다.
- 약점인정
- 실수에 관대해야 하나 관찰자의 존재가 그걸 방해 한다.
- 상실에 대한 두려움
10-4. 프로그래밍을 학습하는 방법
- 뭔가를 학습하는 방법을 배우는 첫 단계는 자신이 무엇을 알고 있고 무엇을 모르는지를 배우는 것이다.
- 뭔가 필요한 시기만큼 배움에 적합한 시기는 없다. but 일정이 있고 관리자가 있기 때문에 실패에 대비해야 한다.-> 새로운 기술을 적용해 보고 실패하면 그 이유를 조사하는 데 어느 정도의 시간을 쓰고, 만약 성과가 없다면 기존의 기술로 대체하여 문제를 일단 무마한다. 대신에 나중에라도 다시 시도할 수 있도록 테스트 케치스를 만들어 놓는다.
10-5. 요약
프로그래머의 성과를 향상시키는 요소
- 일을 하고 싶어하는 마음 : 동기부여
- 업무를 수행하기 위해 필요한 지식 : 훈련, 교육
4부 프로그래밍 도구
* 이장은 다른 장과는 달리 심리학이 부 주제 정도로 다뤄지는 부분이다. 컴파일러 얘기를 꺼내기 위해서 심리학 부분을 가져다 놓은 듯한 느낌.
11장 프로그래밍 언어
11-1. 프로그래밍 언어와 자연언어
11-2. 프로그래밍 언어 설계
12장 프로그래밍 언어 설계에 필요한 원칙
12-1. 일관성
12-2. 간결성
12-3. 근접성과 순차성
우리는 공감각적이고 순차적인 것일 잘 기억한다.
- 공감각적 특징인 근접성은 프로그램에서 서로 관련있는 부분이 모두 한 장소에 나타나는 성질을 의미한다.-> 압축 -> 서브루틴
12-4. 전통과 혁신
12-5. 특수 목적 언어, 범용 언어, 장난감 언어
13장 그외의 프로그래밍 도구들
13-1. 프로그램 테스트 도구
13-2. 운영체제
13-3. 시분할(time-sharing 대 배치(batch)
13-4. 문서화
5부 에필로그
- 이 책으로부터 큰 영향을 받은 독자는 컴퓨터의 운영체제가 아니라 자신의 CPU 즉, 머리를 감독하는 운영체제에 신경쓰기 시작할 것이다.
EOF