게시판 즐겨찾기
편집
드래그 앤 드롭으로
즐겨찾기 아이콘 위치 수정이 가능합니다.
Mastering Programming(KENT BECK)
게시물ID : programmer_17543짧은주소 복사하기
작성자 : 잉어
추천 : 1
조회수 : 748회
댓글수 : 1개
등록시간 : 2016/06/09 02:53:43
Technical Coach인 Kent Beck이 쓴 프로그래밍의 대가들이 업무를 할 때 어떤 패턴으로 일을 하는지에 대해 쓴 글입니다.
레딧으로 보게되어서 발번역이지만 도움이 될까 공유합니다. 아직 프로그래밍 걸음마도 떼지 못한 제가 보기에는 조금 나중에 읽어야 할 글이지만요.
번역이 부족하니 반드시 본문을 참조하시기 바랍니다! (번역 보충해주시면 감사하겠습니다.)

======================================================================
 프로그래밍의 대가들을 봐온 수년간, 나는 그들의 작업 흐름에서 어떤 공통된 패턴들을 봐왔다. 
솜씨가 있는 일반 프로그래머들을 코칭해온 수년간 나는 그러한 패턴들이 없는 것을 봐왔다. 
나는 그 패턴을 도입하는 것이 무슨 차이를 만드는지 알 수 있었다.

 효과적인 프로그래머가 지구에서 그들의 소중한 시간에서 최상의 것을 얻어내는 방법이 여기 있다.

 여기있는 주제는 당신의 사고를 확장시킬 것이다. 
일반 프로그래머는 한 번에 좀 더 많은 문제를 해결함으로써 좀 더 큰 문제를 해결하는 방법을 알고있다. 
프로그래머의 대가는 한 번에 더 적은 문제를 해결함으로써 일반 프로그래머가 해결하는 문제보다 더 큰 문제를 해결하는 방법을 알고 있다. 
세분화가 현명한 방법이다. 분할된 솔루션들을 통합시키는 것은 문제들을 함께 해결하기 보다 더 작은 문제가 되도록 하기 때문이다.


*시간
- 얇게썰기.
 큰 프로젝트를 맡아라, 
그 프로젝트를 얇은 조각들로 썰어라, 
그리고 그 조각들을 너의 상황에 맞게 재배열하라. 
나는 항상 프로젝트들을 더 잘게 세분화할 수 있었다. 
그리고 나는 다른 곳에서도 필요한 조각들의 새로운 치환법을 항상 발견할 수 있었다. (다른 곳에도 통하는 조각들)

- 한 번에 한 가지 것만.
 우리는 너무 효율성에 집중해서 오버헤드를 줄이려는 시도로 피드백 하는 주기를 줄이게 된다. 
이것은 예상비용이 우리가 피하려는 오버헤드 주기보다 더 크게 되어 디버깅하기 어려운 상황을 만든다.

- 쉬운 변화들(?). (change가 정확히 뭘 뜻하는지 모르겠네요..)
 어려운 변화에 직면했을 때, 처음에 그것을 쉽게 만들어라 (경고, 이것은 어려울지도 모릅니다.), 
그리고 나서 쉬운 변화를 만들어라. (예를들어 잘게썰기, 한 번에 한가지 것, 집중, 고립). 잘게써는 것의 예시(?).

- 집중
 만약 당신이 몇가지 요소들을 변화시키려 한다면, 그 변화가 오직 한 가지 요소에만 발생하도록 처음에 코드를 재배열해라.

- 고립
 만약 당신이 오직 한 요소의 한 부분만을 바꾸려 한다면, 전체 하위 요소가 변화하도록 그 부분을만을 추출해라.

- 기준 측정
 그 프로젝트의 현재 상태를 측정함으로써 프로젝트를 시작하라. 
이것은 여러 것들을 수정하는 것을 시작하는 우리의 공학도의 본능과 반대되지만, 
당신이 기준치를 측정했을 때, 당신은 실제로 여러 것들을 수정하고 있다는 것을 알게 될 것이다.


*학습
- Call your shot(너가 짠 것을 회상해라?)
 당신이 코드를 만지기전에 무엇이 일어날지 정확하게 예측해라.

- 구체적인 가설.
 프로그램이 잘못 행동하고 있을 때, 수정하기 전에 너가 생각한 것이 틀린 것이라고 정확하게 말해라. 
만약 두가지 이상의 가설을 가지고 있다면 차이가 날 수 있는 진단 방법을 찾아라.

- 관계없는 세부사항을 제거하라.
 버그에 대해 보고할 때, 가장짧은 복제 단계를 찾아라. 
버그를 격리시키려할 때, 가장 짧은 테스트 케이스를 찾아라. 
새로운 API를 사용하려 할 때, 가장 기초 예시부터 시작하라. 
"모든 것이 중요할 수는 없다."라는 말은 잘못된 상황에서는 비싼 추측이다.
   -> 예시, 모바일에 있는 버그를 보아라, 그것을 curl로 복제하라.

- 다양한 scales (scale의 의미를 잘 모르겠네요)
 자유롭게 scales 사이를 움직여라. 
아마도 이것은 테스트 문제가 아니라 디자인 문제이다. 
아마도 그것은 기술 문제가 아니라 사람 문제이다.(가짜같지만, 이것은 항상 사실이다.)


*Transcend Logic(초월논리?)
- Symmetry(대칭)
거의 같은 것들은 똑같은 부분과 명확하게 다른 부분으로 나뉘어질 수 있다.

- Aesthetics(미학)
 아름다움은 등산하기에 아주 좋은 경사이다. 그것은 또한 무시하기에는 자유롭게 하는 경사이다. 
  (예시. 여러가지 기능들을 한 개의 거대한 집합으로 구성하는 것)

- Rhythm(리듬)
 올바른 순간이 올 때까지 기다리는 것은 에너지를 보존하고 어지러운 것을 피하는 것이다. 움직일 시간일 때 집중력있게 움직여라.

- Tradeoffs(교환)
 모든 결정들은 교환에 지배를 받는다. 오늘 어떤 답을 골라야 할 지 아는 것 보다는(또는 어제 당신이 골랐던 답) 
그 결정이 의존하는 것을 아는 것이 더 중요하다. 


*위험
- Fun list
 관계없는 아이디어가 떠올랐을 때, 그것들을 기록하고 빠르게 업무로 돌아가라. 
너가 쉬어야 하는 지점에 왔을 때, 이 목록들을 다시 훑어보라.

- Feed Ideas(아이디어에게 밥주기)
 아이디어들은 겁먹은 작은 새들과 같다. 
너가 그 작은 새들을 겁주어 쫓아버리려 한다면, 그들은 당신 주위로 오지 않을 것이다. 
너가 아이디어가 있을 때, 그것에게 조금씩 먹이를 주어라. 
가능한한 빠르게 그것이 틀렸다는 것을 입증해라, but from data not from a lack of self-esteem.(자존심 부족이 아닌 자료로 틀린 것을 알아내어라?)

-80/15/5
 당신의 시간의 80%를 저위험/합리적인 보수의 일에 써라. 
당신의 시간의 15%는 관련된 고위험/높은 보수의 일에 써라. 
당신의 시간의 5%는 보수와 상관없이 당신을 재미있게 하는 것에 써라. 
다음 사람에게 너가 하는 80% 일을 하는 법을 가르쳐라. 
누군가가 너의 일을 이어받을 준비가 되었을 즈음에, 
당신의 15% 실험중의 하나 (또는 덜 빈번하게 한것들, 당신의 5% 실험중의 하나들)가 성과가 있을 것이고 당신의 새로운 80%가 될 것이다. 반복해라.


*결론
 이 글은 시간을 관리하고 학습을 늘림으로써 위험을 제거하는 것부터 
너의 모든 머리를 쓰고 아이디어를 빠르게 분류함으로써 세심하게 위험을 무릅쓰는 것까지에 관해서 쓰였다.
출처 https://www.prod.facebook.com/notes/kent-beck/mastering-programming/1184427814923414
전체 추천리스트 보기
새로운 댓글이 없습니다.
새로운 댓글 확인하기
글쓰기
◀뒤로가기
PC버전
맨위로▲
공지 운영 자료창고 청소년보호