https://mediawiki.zeropage.org/index.php?action=history&feed=atom&title=1002%2FTPOCP 2026-05-14T09:56:41Z Revision history for this page on the wiki MediaWiki 1.39.8 https://mediawiki.zeropage.org/index.php?title=1002/TPOCP&diff=25727&oldid=prev 2021-02-07T05:22:05Z

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

imported>Unknown