No older revisions available
No older revisions available
- 어떤 종류의 책인지?
- 전반적인 내용에 대한 뼈대 & 구성방식
- 장르구분?
- 내용상의 분류
- 책 전체흐름에 대한 abstraction
- 개요
- 저자가 제기하는 질문은? & 책에서의 대답은? ( + )
- 관련 자료 링크
- 읽고난 뒤의 나의 생각
~cpp
Part 3 Programming as an individual activity
Comment on Part 3
My goal was
프로그래머들이 그들의 작업을 하는 방법에 대한 연구 격려
개인 프로그래머들의 실력을 향상시키는 것에 대한 이해를 촉진
25년이 지났지만, 프로그래머 개인은 이전보다 더 적합하진 않음. 비록 생산성은 높아졌지만.
Variations in the programming task
Professional versus amateur programming
Amateur
자기자신의 이용을 위해 작성
try & error 식으로 접근. 프로그래밍전 미리 생각하거나 머릿속으로 그려보지 않음
프로그래밍 뒤에 잊어버린다.
어려움이 닥쳤을때, 문제 자체만을 처리하기를 원한다.
문제에 대해서만 배운다.
Professional
다른 사람들이 이용한다는 것도 고려
추후 변화되는 부분을 확립하거나, 스펙을 명확화한다.
패키지에 저장해놓는다.
문제 자체를 아마추어만큼 심각하게 고민하지 않는다.
문제해결방법을 찾는 여러 방법들을 인식하고 있다. 문제를 이해하기 위한 프로그램을 준비하기도 한다
프로그래밍에 대해 배운다. (문제상황이란 그의 개발 과정중 부수적인 일들)
exam) 2차 방정식 풀이 예
What the programmer is trying to do
case) 물리 교수로부터 해당 메트릭스를 반전하는 프로그램 작성. 한 개발자는 (A) 뭔가 배울 수 있는 좋은 기회라고 생각, buffering 을 이용하여 문제를 해결하려고 함.
각각의 프로그램에는 적절한 레벨이 있다.
성능 : 효과
case2) 4개의 프로그래머 그룹에 해당 일을 맡김.
A : as efficient as possible (빠른 성능 위주)
B : as short a time as possible (빠른 개발 위주)
비교 :
B 그룹이 머신 타임은 2/5 나 1/3 정도만 이용.
B 가 퍼포먼스에서 A 보다 10배 느림.
B - 메소드가 장동하지 앟을때, 그냥 drop 해버리고 다른 것으로 교체버림.
A - 문제발생시 접근방법을 바꾸기 싫어함.(성능을 희생해야 할것이라 생각해버림)
스케줄 예측시에 따른 차이
파킨슨의 법칙 : 일거리는 할당된 시간을 채울만큼 늘어난다.
'목표'로서의 스케줄은 '할당된 시간'에 영향을 줄 수 있다.
Stages of programming work
프로그래밍의 각 부분에 대해 동일한 능력과 수고가 필요하다고 생각하는 것을 잘못이다.
'분석, 플로우 다이어그램 작성, 코딩, 테스팅, 도큐먼트' 로 분리하는 사고는 여러 면에서 프로그래밍을 왜곡시킨다.
* 실제 순서가 고정적이지 않다.
* 모든 절차들이 필요하진 않다.
* 순차적일 필요가 없다.
우리는 이러한 복잡한 행위들을 단순한 하나로 만들어야 한다.
프로그래밍 프로젝트를 정의된 단계들로 세밀하게 나눌 수 있지만, 좋은 아이디어는 아니다.
우리는 프로젝트의 일들을 정리하여 각각의 사람들이 자신이 잘하는 영역에 대해서로 특수화할 수 있도록 할 수 있지만, 적어도 두가지 단점이 존재한다.
* 아무도 도큐먼트 작업을 하려고 하지 않을 것이다.
* 아무도 그렇게 배울 게 없다.
우리는 각각의 프로그래머들이 자신이 잘 못하는 영역에 대해 스페셜리스트가 되게 일을 할당함으로서 학습률을 극대화할 수 있다. 또한, 그가 문제상황이 생겼을때 각가이 다른 작업으로 교체할 수 있는 기회를 가질 수 있다.
프로그래밍 프로젝트에 대한 전체 한바퀴를 돌고 난뒤, 프로그래머들이 작업하는 더 올바른 방법으로 작업을 나누는 것을 시도한다.
exam) 테스팅 단계
에러의 존재를 탐지한다.
에러의 위치를 찾아낸다.
에러를 수정한다.
