뻔뻔한블로그

CreateDefaultSubobject :

생성자에서만 실행가능

템플릿으로 <>안에 사용할 컴포넌트를 넣어줌

TEXT()

각각의 컴포넌트를 구분하기 위한 값이 들어간다.

해쉬 값을 생성하기 때문에, 다른 TEXT와 겹치면 안된다.

하위 클래스 셋팅하기

기억할 내용

- "이 애플리케이션을 외국에서 사용하는 일은 절대 없을 텐데 뭐하러 국제화하지?, "count는 음수가 될 수 없어," 로깅은 실패할 리 없어" 이런 식으로 자신을 기만하지 말자, 특히 코딩할때는

- 단정문으로 불가능한 상황을 예방하라

- 물론 그런 일은 절대일어나지 않을 거야' 라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라

- 하지만 오류 처리를 해야 하는곳에 단정을 대신 사용하지는 말라

- 첫 번째 방어선은 가능한 오류를 검사하는 것이고, 그 다음은 그러고 놓친 것을 잡아내기 위해 단정을 사용하는 것이다.

- 프로그램을 출시할 때 단정기능을 꺼 버리는 것은 줄타기 곡예를 하면서 연습으로 한 번 건너 봤다고 그물 없이 건너는 것과 비슷하다.

느낀 점

 실제 서비스를 할때는 예상치 못한 여러가지 이슈가 발생하게된다. 게임은 특히 여러사람들이 동시에 접속하고 상호작용하는 부분들이 많기 때문이다. 그래서 크래시리포트등 발생시점에 기록을 남기는 편이다. 마찬가지로 이러한 부분을 잡아내는데 필요한 방법인것 같다. 절대로 일어날리 없다고 생각했지만 일어난다. 이 단정은 디버깅요소로 활용할 수 있다.

Topic 24 죽은 프로그램은 거짓말을 하지 않는다.

기억할 내용

- '있을 수 없는 일'이 발생했을 때 우리는 그 사실을 알아야 한다. '그런 일은 절대 일어날 리 없어'라는 사고에 빠지기 쉽다.

- 망치지 말고 멈춰라 : 가능한 한 빨리 문제를 발견하면 좀 더 일찍 시스템을 멈출 수 있으니 더 낫다. 

- 어떤 환경에서는 실행 중인 프로그램을 그냥 종료해 버리는 것이 적절하지 못할 수도 있다.(해제되지 않은 리소스, 로그메시지 기록, 트랜잭션 정리, 등)

- 이상 발생하면 이 시점 이후로 하는 일은 모두 수상쩍은 게 된다. 되도록 빨리 종료시키자.

느낀 점

 여기서 말하고자 하는 것은 이슈가 발생하면 그 상황에서 이상하게 통과시키지 말고 그 즉시 종료시키라고 한다. 한번 이슈가 발생된 이후에는 원인 모를 이슈가 계속해서 발생할 수 있기 때문이다. 그렇다고 무조건적으로 종료만 시키는 것은 능사가 아니다. 실제 서비스하고 있는 코드라면 로그를 잡고 프로그램이 죽지 않도록 하게 할 때도 있다. 

Topic 23 계약에 의한 설계

기억할 내용

- 수천 년간 우리가 얻은 해법 중 몇 가지는 소프트웨어를 만드는 데에도 적용할 수 있다. 정직한 거래를 보장하는 최선의 해법 중 하나는

'계약'이다.

- DBC : 계약에 의한 설계(Design By Contrac)

- 정확한 프로그램이란 ...많지도 적지도 않게 딱 그만큼만 하는 프로그램

- 예상이 되는 프로그램

- 선행조건 : 루틴의 선행 조건이 위반된 경우에는 루틴이 호출되어서는 안 된다.

- 후행조건 : 루틴이 자기가 할 것이라고 보장하는 것

- 클래스 불변의 법칙 : 호출자의 입장에서 볼 때는 이 조건이 언제나 참인 것을 클래스가 보장한다.

- tip37 계약으로 설계하라

- '게으름뱅이코드' 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것이다.

- DBC 구현 : 코드를 작성하기 전에 유요한 입력범위가 무엇인지, 경계 조건이 무엇인지, 루틴이 뭘 전달한다고 약속하는지, 혹은 더 중요하게는 생각하는 무엇을 약속하지 않는지 등을 나열하는 것만으로도 더 나은 소프트웨어를 작성하는데 큰 도움이 된다.

느낀 점

 이번주제는 소프트웨어를 설계할 때 조건을 걸면서 좀 더 안정된 설계가 가능하다는 말인 것 같다. 프로젝트가 길어지면서 다양한 함수와 복잡해지는 코드가 많아지게 되는데 이러한 계약의 의한 설계를 함으로써 안정된 설계가 필요하다. 요즘에 느끼는 것도 항상 코드를 작성할 때는 규칙이 있어야 한다. 일관성이 있어야 흐름이 예상이 되기 때문이다.

Topic 22 엔지니어링 일지

기억할 내용

- 일지를 쓰면 좋은 점 3가지

기억보다 더 믿을 만하다

지금 하는 일에 계속해서 집중할 수 있다.

무언가를 쓰기 위해 하던 일을 멈추면 여러분의 뇌도 기어를 바꾼다.

- 수년 전에 여러분이 무엇을 하고 있었는지 돌이켜 볼 수 있다.

-  때때로 수년 전에 여러분이 무엇을 하고 있었는지 돌이켜 볼 수 있다.

- 종이를 사용해라 키보드를 두드리는 것과 다른 무언가 특별한 것이 있다. 

느낀 점

 메모하는 습관이 중요하다는 것은 이미 알고 있지만, 무언가를 쓸 때 뇌는 기어를 바꾸며, 내가 지금 무엇을 하고 있는지 되돌아볼 수 있는 시간이 될 수 있다는 등, 뭔가 머릿속에 추상적으로만 (메모하니까 좋겠지~) 생각했던 것들이 구체적으로 어떤 효과가 있는지 알게 되었다. 

Topic 21 텍스트 처리

기억할 내용

- 프로그래밍에서 텍스트 처리 언어는 목공에서'루터'와 같다. (루터 절단 기계) => 적절히 사용하면 놀라운 효과를 낸다.

- 유틸리티를 뚝딱 만들어 낼 수도있고, 아이디어를 프로토타입해 볼 수도 있다.

- 전통적인 언어를 사용하다보면 다섯 배에서 열 배 가까이 더 오래 걸릴 것이다.

- tip35 텍스트 처리 언어를 익혀라

느낀 점

 이번 주제는 주로 프로그래밍에 사용하는 언어 외에 텍스트 처리 언어를 사용해 업무의 생산성을 높이자 라는 의미가 있다. 여기서 제시한 연습문제에서는 소스파일에서 반복적으로 작업을 하는 기능을 처리하는 스크립트를 만들라 하는데 유용할 것같다. awk, sed에 대해서도 알아봐야겠다.

Topic 20 디버깅

기억할 내용

- 디버깅의 심리 : 단지 문제 풀이일 뿐이라는 사실을 받아들이고, 그런 마음으로 공략하라.

- 다른 사람의 버그를 발견 후, 그 버그를 만들어 낸 부정한 범죄자를 비난하는 데에 시간과 노력을 쏟지말고 ... 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중해야 한다.

- Tip29 비난 대신 문제를 해결하라.

- 버그가 여러분의 잘못인지 다른 사람의 잘못인지는 중요치 않다. 어쨌거나 그 버그를 해결해야 하는 사람은 여러분이다.

- 디버깅 사고 방식 : 가장 속이기 쉬운 사람은 자기 자신이다. - 애드워드 불워 -리턴

- 버그를 목격하거나 버그 신고를 보는 순간의 첫 반응이 '그건 불가능해'라면 여러분은 두말할 필요 없이 틀렸다.'정말 그럴 리가 없는데'로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라.

- 특정한 증상만 고치지 말고 항상 문제의 근본 원이을 찾으려고 노력 하라

- 실마리 찾기 : 우연에 의해 오도되기 쉽다. 우리는 우연한 사건을 디버깅하느라 시간을 낭비할 여유가 없다. 일단 정확하게 관찰해야 한다. 

디버깅 전략 

- 버그 재현하기 : 재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 확인할 수 있겠는가?

- Tip31 고치기 전에 실패하는 테스트부터

- Tip32 그놈의 오류메시지 좀 읽어라

- 이상한 결과 : 실패하는 테스트를 이용하여 문제를 재현하라 

- 메모를 하면 도움이 될 때가 많다. 추적을 시작할 때 우리가 어디에 있었는데 메모를 남겨 두지 않았다면 원래 자리로 돌아오느라 시간을 많이 소모했을 것이다.

- 로깅과 트레이싱 : 트레이싱 구문은 '여기까지 도달'이나 'x값 = 2'와 같이 화면 혹은 파일에 출력하는 작은 진단용 메시지를 일컫는다.

- 트레이싱은 여러 프로세스가 동시에 작동하는 경우, 실시간 시스템, 이벤트 기반 애플리케이션 등, 시간 자체가 중요한 요소가 되는 시스템에서 이루 말할 수 없이 소중하다.

- 고무오리 : 문제의 원인을 찾는 방법에는 그냥 누군가에게 설명하는 방법이 있다.

- 문제를 설명하게 되면 혼자 코드를 살펴볼 때는 당연히 여기고 지나갈 것을 명시적으로 이야기해야 한다.

- 소거법 : 사람들이 작성한 애플리케이션 코드, 외부 제품(데이터베이스나 네티워크, 웹 프레임워크, 특화된 통신 방식, 알고리즘 등) 플랫폼 환경(운영체제, 시스템 라이브러리, 컴파일러)이 뒤섞여 있을 것이다. 하지만 처음부터 그런 생각을 하지는 말라

- 발굽 모양을 보면 말을 떠올려야지 얼룩말부터 떠올리지 말라

- 가정하지 말라, 증명하라

느낀 점

 이번 주제는 내용도 많고, 개발할 때 중요하게 생각했던 것들이라 생각된다. 공감이 되는 부분이 꽤나 많았다.  발하다 보면 버그가 발생하는데 이 버그가 누가 만들어 냈는지 궁금할 때가 많은데, 그럴 시간에 문제를 해결하려고 노력하는 것이 맞다. 그리고 다른 사람의 의해 나의 작업물에 버그가 보고 되면 그 부분에서는 그럴 리가 없는 데를 얘기한 내가 부끄러웠다.(그럴 리가 없는데, 발생했잖아). 

버그를 추적할 때 메모장을 사용하기, 누군가에게 설명하기, 로깅과 트레이싱(은 몰랐던 용어라 찾아봄)등 디버깅에 필요한 방법들을 제시해주고 있어 실제로 버그 발생 시 적용해 볼만 것들이 많았다.

Topic 19 버전 관리

기억할 내용

- 버전 관리 시스템은 일종의 거대한 '실행 취소'키와 같다.

- 버그 추적이나, 감사, 성능관리, 품질 관리를 해야 할 때 매우 귀중하다.

- 언제나 버전 관리 시스템을 사용하라

- 혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도, 나중에 '버리기로 한' 프로토타입일지라도, 심지어 열분이 작업하는 것이 소스코드가 아닐지라도, 모든 것을 버전 관리 아래에 둬라. 각종 문서, 전화번호 목록, 외부 업체에 보내는 메모, makefile, 빌드와 릴리스 절차, 로그 파일을 정리하는 작은 셸 스크립트까지 모두 다.

- 브랜치 사용하기

- 

느낀 점

 프로젝트에서 버전관리 시스템은 필수라고 생각한다. 이번 주제에서 '특정 브랜치에서 푸시를 하면 시스템을 빌드하고 테스트를 수행한 다음, 테스트가 성공하면 새로운 코드를 서비스에 배포한다.'라는 내용이 있는데, 현재 회사에서도 이렇게 당연히 진행되어야 하는 반복적인 작업을 자동화 하는 방법을 진행하고 있다. 내가 직접 만들어 본적은 없어서 이런 작업이 어떤식으로 진행되는지 알아 볼 필요가 있어 보였다.

Topic 17셸 가지고 놀기 , Topic 18 파워 에디팅

Topic 17셸 가지고 놀기

기억할 내용

- GUI는~ 자신에게 꼭 맞는 '매크로 도구'를 만들 수 없다.

- GUI에 장점은 WYSIWYG(What You See Is What You Get)보는 것이 여러분이 얻는 것이라면, 단점은 WYSIAYG(Waht You See Is All You Get, 보는 것이 전부다. 111p

- 자신 만의 셸 만들기

- GUI에서 수동으로 하는 작업있으면 자동화할 수 있는 법 알아보기

느낀 점

 수동적인 작업을 할때 자동화를 하고 싶거나, 커스텀한 동작을 단축키 하나로 할 수 있는 방법이 있을까 이런 생각을 한 적이 있었는데, 이 방법이 아닐까 생각이 들었다. 

Topic 18 파워 에디팅

기억할 내용

- 에디터를 유창하게 쓸 쑤 있게 해라

- 유창해지는 것의 가장~ 생각이 자유롭게 흐를 것이고 프로그래밍에 큰 도움이 될 것이다.

- 어떤 것이 '유창'한 것인가.

- 텍스트를 편집할때 문자, 단어, 줄 문단 단위로 커서를 이동하거나 내용을 선택하라

- 코드를 편집할 때 반대쪽 괄호로 이동하거나, 함수, 모듈 등 다양한 문법 단위로 커서로 이동하라

- 변경한 코드의 들여쓰기를 자동으로 맞춰라

- 무엇가 같은 일을 반복하는 것을 발견할 때마다 이렇게 생각하는 습관을 들여라, '분명 더 나은 방법이 있을 텐데.' 그리고 더 나은 방법이 있는지 찾아보라.

- 에디터 성장시키기

- 명백한 한계에 봉착한다면 필요한 기능을 추가하는 확장 기능을 찾아보라

- 사용하는 에디터의 확장 기능 언어를 파헤쳐라 보라. 여러분이 늘 하는 반복적인 일을 자동화할 방법을 연구해 보라

느낀 점

 작업을 할 때 마우스가 아닌 키보드로 화면을 자유재자로 이동하거나 커서를 쉽게 이동하는 사람들이 있다. 키보드와 마우스를 왔다 갔다 하는 시간을 단축시키고, 수동으로 반복적인 일들을 자동화하는 방법으로 작업 능률이 늘어난다고 생각이 들었다. 여기서 제시한 도전 과제를 연습해야겠다는 생각이 들었다.

Topic 16 일반텍스트의 힘 

기억할 내용

- HTML,JSON,YAML,HTTP, SMTP, IMAP 등이 일반텍스트이다. 106p

- 지원 중단에 대한 보험 (형태의 데이터와 그 자체만으로 의미가 드러나는 데이터는 다른 어떤 형태의 데이터보다, 심지어 그 데이터를 생성한 애플리케이션보다 더 오래 살아남을 것이다.) 107p

- 기존 도구의 활용 (버전 관리 시스템에서 에디터, 명령 줄 도구에 이르기까지 컴퓨터 세계의 거의 모든 도구는 일반 텍스트를 다룰 수 있다. 108p

- 더 쉬운 테스트 (시스템 테스트에 합성 데이터를 일반 텍스트로 표현하면 특별한 도구를 만들 필요 없이 간단하게 테스트 데이터를 추가하거나 수정할 수 있다.) 109p

- 최소 공통분모 (널리 퍼져있고, 미래에도 살아 남을 것이다.)
 

느낀 점

 일반 텍스트가 무엇인가 했지만, 사람이 직접 읽고 이해할 수 있는 형태의 인쇄가능한 문자로 이루어진 텍스트를 말하는 것이다. 더 나은 테스트를 하고, 더 쉬운 테스트 환경을 만들기 위해서는 이번 주제와 Topic 17(셀 가지고 놀기)을 잘 다룰 줄 알아야겠다는 생각이 들었다. 하지만 이런 부분도 단점은 존재한다. 보통 포맷형태가 공간을 많이 차지한다. 바로 읽기가 쉬워 보안에는 약할 수 있다. 

Topic 15 추정

기억할 내용

- 추정하는 법을 배우고 측정 능력을 계발하여 ~ 직관적으로 이것이 가능한지 판단할 수 있게 된다. 94p
- 얼마나 정확해야 충분히 정확한가? ~ 무언가를 끝내는 데 근무일 기준으로 약 130일 동안 일해야 한다고 말하면 드는 사람은 실제 소요 기간이 추정과 상당히 비슷하리라 기대할 것이다. 하지만 "아, 대략 6달 정도 걸리겠군요"라고 말하면 지금부터 5~7달 사이 언젠가쯤 끝날 것 이라 여길 것이다. 두 숫자는 같은 기간을 이야기하지만 '130일'은 실제 여러분의 느낌보다 더 정확도가 높으이라는 인상을 풍길 수 있다. 95p
- 추정치는 어디에서 나오는가?
1. 그 일을 해본 사람에게 물어보라
2. 무엇을 묻고 있는지 이해하라
3. 시스템의 모델을 만들어라 ( 기본적인 것만 갖춘 개략적인 모델을 만들어 보라, 조직이 개발하는 동안 사용할 발판, 밑그림이 될것이다.) 97p
4.모델을 컴포넌트로 나눠라
5. 각 매개 변수에 값을 할당하라 (결과에 가장 큰 영향을 미치는 매개 변수를 찾아서 이 매개 변수의 값을 최대한 정확하게 산출해 내는 것이다.) 98p
6. 여러분의 추정 실력을 기록하라 (나중에 이 값이 실제 결과에 얼마나 가까웠는지를 평가해 보면 정말 좋을 것 이다.)
- 프로젝트 일 추정하기
1. 미사일에 페인트 칠하기(숫자 하나로 대답해야만 하는 상황이 아니라면 숫자 하나가 아니라 여러가지 시나리오로 추정한다.)
2. 코끼리 먹기(단계를 작은 단위로 나누어 점증적으로 )
- 계산한 추정치를 기록으로 남겨라. 그리고 각 추정치가 얼마나 정확했는지 기록으로 남겨라. 오차가 50%이상이라면 잘못된 추정치를 내게 된 원인이 무엇인지 찾아보라
 

느낀 점

 실제로 작업을 할때는 일정을 추정하기가 쉽지 않았다. 작업을 진행하다가 예상치못한 요인 코드뿐만 아니라 외부 요인까지..내기 해보진 않은 일이라면 더더욱 어려웠다. 여기서 제시한 방법을 활용하며 일정산정 방법을 가다듬고 결과에 따라 정확도가 얼마나 떨어지는지 점검해보는 연습을 해야겠다. (뭐든지 사실 생각만 하는 것보다는 실제로 적용해보아야 안다.)

Topic 13 프로토타입과 포스트잇

기억할 내용

-  프로토타입 ~ 위험 요소를 노출시킨 후, 이를 매우 저렴한 비용으로 바로잡을 기회를 얻는 것이다. 80p

-  프로토타입은 빠르게 개발할 수 있다.  ~ 여러분에게 당장 중요하지 않은 세부사항이라면 추후에 사용자에게 매우 중요해질지도 모르지만 일단 무시하면서 코딩할 수 있다.

- 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜로 프로토 타입을 만들고 있는 게 맞는지 자문해 보라.

- 프로토 타입 대상은 ~ 증명되지 않았거나, 실험정이거나, 의심이 가는것, 마음이 편하지 않은 것 모두가 프로토타이핑의 대상이 될 수 있다. 81p

- 프로토타이핑의 가치는 생산한 코드에 있는것이 아니라 이를 통해 배우는 교훈에 있다.

- 아키텍처를 프로토타이핑할 때는 코드를 작성하지 않고 화이트보드, 포스트잇, 인덱스카드 등을 사용해도 된다. 83p

- 프로토타팁임을 모르는 사람에게는 오해를 살 정도로 매력적일 수도 있기 때문에 ~ 이 코드는 폐기할 것이고, 불완전하며, 완성할 수 없다는 사실을 분명히 주지시켜야 한다.

느낀 점

- 이책에서 말하는 예광탄, 프로토타입 각각 장단점이 있고, 요구되는 목적, 특성에 따라 선택이 필요하다. 나는 평소에 프로토타입이라고 생각했지만 예광탄에 가까운 작업을 선 작업을 했던 것 같다. 프로토타입은 없어질 코드이며, 코드는 남지 않고 작업하면서 이를 통해 배우는 교훈에 있다는 말이 포인트라고 생각했다. 

Topic 12 예광탄

기억할 내용

- 프로젝트를 개발할때는 ... 수 많은 미지의 것과 맞닥트리게 된다. 72p

- 어둠 속에서 빛을 내는 코드 : 탄환이 순식간에 목표물에 도달하기 때문에 기관총 사수는 즉각적인 피드백을 얻을 수 있다. 73p

- 요구 사항으로 부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무엇인가를 찾아야한다. 

- 예광탄은 한번 쓰고 버리는 코드를 만드는것이 아니다. 75p

- 모든 기능이 들어있지 않을 뿐 / 시스템을 구성하는 요소를 모두 연결해 놓은 후 목표물에 얼마나 근접했는지 확인할 수 있으며. 조정도 가능하다

- 변경 요청과 기능 추가 요청은 언제나 게속 들어오기 마련이다. 76p

- 예광탄 장점 : 1. 사용자가  뭔가 작동하는지 일찍 볼 수 있다. 2. 개발자가 들어가서 일할 수 있는 구조를 얻는다. 3. 통합 작업을 수행할 기반이 생긴다. 4.보여줄 것이 생긴다. 5.진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

- 예광탄 vs 프로토타입 : 예광탄은 기능은 없지만, 완결된 코드이며, 골격이다. 프로토타입은 예광탄을 발사전에 수행하는 정찰이나 정보 수집과 같다. 79p

느낀 점

이번 내용으로 예광탄은 프로젝트 작업을 시작할때 골격을 만드는 시스템구조와 같다고 느꼈다. 프로토타입과 혼동될 수 있지만. 이 둘은 다르며, 장단점을 가지고 있다. 나는 예광탄은 작업을 시작하면 꼭 필요한 작업이라고 생각이들었다. 먼저 골격을 만든 후 살을 (기능) 붙이는 방법이 여러모로 큰 장점을 가지고 있다고 생각했다.

Topic 11 가역성

기억할 내용

- 당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다. 66p

- DRY원칙, 결합도 줄이기, 외부 설정 사용하기를 따른다면 중요하면서도 되돌릴 수 결정의 수를 가능한 줄일 수 있을 것이다.

- 되돌릴 수 없는 결정을 줄여야 하는 까닭은 우리가 프로젝트 초기에 늘 최선의 결정을 내리지 못하기 때문이다. 68p (많은 외부요인)

- 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

- Tip18 최종 결정이란 없다. 69p

- 유연한 아키텍처 : 아키텍처, 배포, 외부 제품과의 통합 영역을 유지하는 데에도 관심을 기울일 필요가 있다.

- 누구도 어떤 미래가 펼쳐질지 알 수없다. 70p

느낀 점

프로젝트를 진행하다 보면 예상치 못하는 이슈가 생기기 마련이다. 단순히 코드설계에서만 생기는 것이 아닌, 외부요인들 언제 어디서나 나타나게 된다. 이번 주제에서는 이런 예상치 못한 일들이 생긴다면 그때 어떻게 효율적으로 복귀할 수 있을까, 그리고 왜 그렇게 해야만 하는가를 설명해 주는 내용이었다. 지금까지 거의 반복된 내용이라면 ETC, DRY원칙을 다시 한번 중요하다고 느꼈다. 

• 기억할 내용
  • '직교성' 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다.
  • 비직교적 예시 => 헬리콥터 조종
  • TIP.17 관련 없는 것들 간에 서로 영향이 없도록 하라
  • 직교성의 장점
    생산성 향상 => 자족적인 컴포넌트들을 작성하는 것이 하나의 커다란 코드 덩어리를 만드는 것보다 쉽다.
    리스크 감소 => 위험의 크기를 감소시켜준다. (코드 격리, 테스트 용이 등)
    계층 구조적 설계는 모듈 간에 의존성이 폭증할 위험을 줄인다.
    '특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?'
    코딩 => 코드의 결합도를 줄여라, 전역 데이터를 피하라, 유사한 함수를 피하라
  •  자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라. 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라(리팩터링)
  • 단위 테스트를 빌드하고 실행하기 위해 어떤 작업이 필요한가? 나머지 시스템 중 상당 부분을 불러와야 하지는 않는가? 만약 그렇다면 모듈과 나머지 시스템 사이의 결합도를 충분히 줄이지 못했다는 뜻이다.
• 느낀 점
  • 이번 파트에서는 많은 부분에 공감이 됐다. 이미 작업이 끝난 코드에 새로운 기능이 추가될 때나 변경이 될 때 많은 부분을 고려하며 작업을 해야 했었던 경험, 특정 부분을 바꿨을 때 예상치 못한 다른 곳에서 문제가 발생했던 경험, 모듈, 컴포넌트화를 통해 직교성의 장점을 살리며 작업하도록 해야겠다.

• 기억할 내용
  • 효과적인 소통 없이는 아무리 훌륭한 아이디어라도 고립되고 만다. 28p
  • 개발자로서 우리는 여러 입장에서 소통해야 한다.
  • 코드를 작성하는 것은 우리의 의도를 기계에게 전달하는 것이지만, 생각을 기록하여 다음 세대의 개발자들에게 전달하는 것이기도 하다.
  • 청중을 알라. 29p
    • 청중의 요구와 관심, 능력을 이해해야 한다. (어떤 난해한 기술의 장점에 대해 긴 독백을 읊조리는... 단 지껄임 일뿐. 짜증 나는 일이다)
    • 변경 사항을 청중에 따라 각각 다른 방법으로 제시할 수 있다.(ex 영업부, 마케팅, 유지보수팀)
  • 말하고 싶은 게 무언지 알라 30p
    • 말하고자 하는 것이 정확히 무엇인지 생각해 내는 것은 어려운 일이다.
    • 무엇을 말할지 미리 계획하라
  • 때를 골라라
    • 청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야 한다.
  • 스타일을 골라라
  • 멋져 보이게 하라
  • 청중을 참여시켜라 ( 독자가 문서 초안에 참여하도록 하라) 32p
  • 경청하라
  • 응답하라 33p
  • 문서화 (노력을 중복으로 들이거나 시간을 낭비하지 말고 문서를 늘 손에 닿는 가까운 곳에 두면 된다.)
    • 기계적인 주석은 오히려 코드 유지 보수를 어렵게 만든다(모든 함수, 자료 구조, 타입 정의)
    • 어떻게 동작하는지는 코드가 이미 보여주고 있기 때문에 이런 주석은 사족이다.
    • 코드 주석은 프로젝트에서 쉽게 누락되는 다른 곳에서 문서화할 수 없는 부분을 문서화하기에 최적의 기회다.
• 느낀 점
  • 게임 클라이언트 개발자로서 여러 사람들과 소통하는 경우가 많다. 기획자, 아트, 서버 등등 다양한 사람들과 대화할 때 어떤 식으로 소통해야 하며, 또, 소통에는 문서화를 통해 어떻게 소통하는지도 알게 되었다. 어떻게 보면 뭐든 적극적으로 참여하는 마음이 중요해 보인다. 또 이 책에서는 이번 주제 마지막에서 온라인 의사소통에 예절도 가르쳐 준다.ㅎㅎ

• 기억할 내용
  • 지식에 대한 투자가 언제나 최고의 이윤을 낸다. -벤저민 플랭클린 19p
  • 지식과 경험이야말로 가장 중요하고 날마다 쓰이는 전문가 자산이다.
  • 하지만 불행히도 이 자산은 '기한이 있는 자산' 이다. (빠르게 변화하는 기술 시장) 20p
  • 새로운 것을 배우는 능력은 가장 중요한 전략 자산이다.
  • 지식의 포트폴리오
    • 주기적인 투자 : 정기적으로 이용할 계획을 마련하라
    • 다각화 : 오늘 인기 있는 기술이 내일이면 거의 쓸모없어지거나 그 정도는 아니어도 수요가 없어지기도 한다.
    • 리스크 관리 : 달걀을 한 바구니에 담지 말라
    • 싸게사서 비싸게 팔기
    • 검토 및 재 조정
  • 목표
    • 매년 새로운 언어를 최소 하나는 배워라
    • 기술 서적을 한 달에 한 권씩 읽어라
    • 기술 서적이 아닌 책도 읽어라
    • 수업을 들어라
    • 다른 환경에서 실험해 보라 : 윈도우,리눅스.
    • 요즘 흐름을 놓치지 말라 : 다른 기술을 다루는 뉴스와 온라인 게시물을 읽어라
• 학습의 기회 : 답이 뭔지 전혀 알지 못할 땐 인정하고 거기서 멈추지 말라 24p
• 비판적 사고 : 읽거나 듣는 것에 대해 비판적으로 생각하는 것이다. 25p
  • 왜냐고 다섯 번 묻기
  • 누구에게 이익이 되나?
  • 어떤 맥락인가? (전제 조건은 무엇이고 그 결과의 장기, 단기적 여파는 무엇인가?)
  • 언제 혹은 어디서 효과가 있을까?
  • 왜 이것이 문제인가?

• 느낀 점
  • 지식의 포트폴리오를 쌓아야 한다. 언제 어떤 기술이 트렌드가 될지 모르고 당장 필요가 없어지는 기술이 있을 수 있다. 이것은 아무도 모르기에 항상 준비를 해야 한다. 이번 주제에서는 그것을 준비하는 과정, 방법들이 소개됐다. 당장 없어지고 유망하지 않다고, 가만히 있는 것보다는 그것들을 배우는 과정에서 성장한다는 것이다. 

• 기억할 내용
  • 우리는 종종 나아지게 하려다가 괜찮은 것마저 망친다. - 셰익스피어<리어왕> 15p
  • '적당히 괜찮은'이라는 표현은 너절하거나 형편없는 코드를 의미하지는 않는다. 16p
  • 타협 과정에서 사용자를 참여시켜라
    • 불가능한 시간약속을 하거나 데드라인에 맞추기 위해 기본적인 걸 빼 버리거나 하는 것 역시 똑같이 전문가 답지 못하다.17p
  • 오늘의 훌륭한 소프트웨어는 많은 경우 환상에 불과한 내일의 완벽한 소프트웨어보다 낫다.
  • 사용자에게 뭔가 직접 만져 볼 수 있는 것을 일찍 주는것이 낫다.(피드백) 17p
  • 멈춰야 할 때를 알라
  • 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라
• 느낀 점
  • 나는 '적당히 괜찮은'이라는 표현을 보고 무슨 말인가 했다. 적당하게? 어느 정도의 적당함을 말하는 걸까. 완벽을 추구하며 작업을 하는 것이 맞지 않을까? 책에서는 완벽한 소프트웨어는 현실적으로 불가능하기에. 적당하게 단, 형편없는 코드는 아니란 말이었다. 그리고 제작 단계에서 필요한 사용자를 참여시켜 요구조건에 맞는 소프트웨어 사용하는 사람에게 정확한 요구 사항을 파악하여 품질을 결정해야 한다는 말도, 공감이 많이 됐다.

전쟁 직후 돌멩이 수프로 마을 사람들의 호기심으로 음식재료를 얻었다는 이야기처, 눈앞에 빤히 그려지는 시스템이 있어도 그 시스템이 옳다는 것을 알아도! 막상 일에 착수하려고 허락을 구하는 때부터, 복잡해지기 시작한다. 모든 사람이 각자 자신의 자원을 지키려고 할 것이다. 이걸'시작의 피로'라고도 부른다. ---

작업을 원활히 진행하기 위해서 이런 것들이 필요한 것들이라 생각한다. 빠르게 프로토타입을 보여준다 던 지, 너무 큰 요구를 하기보다는 간단 요구부터 요청한다던지 말이다. 또 이 책에서 말하기로는 돌멩이 수프하나만 바라보고 다른 것을 놓치게 되는 마을사람들의 행동에 대해서 얘기한다. 우리는 매일 이런 상황에 처해있다. 우리도 모르는 새 서서히 상황이 악화된다고, 너무 작아 알아채기 힘들 정도의 문제에서부터, 혹은 이 정도는 괜찮겠지라고 생각하며 넘기게 되는 것들이 나중에 쌓여서 프로젝트의 서서히, 하지만 가차 없이 구제불능인 상태가 되어 버린다. 이것을 개구리 수프라고 표현한다. 뜨거운 물에 개구리를 넣으면 바로 튀어 나가지만, 서서히 온도를 높이면 그것을 감지 못하는 것처럼. 원활한 일을 시작하기 위한 촉매의 돌멩이 수프인지, 나도 모르게 악화되는 개구리 수프인지!

큰 그림에 늘 주의를 기울이고 당장 하고 있는 일에만 정신을 쏟지 말고, 이것이 돌멩이 수프인지 개구리 수프인지 잘 판단해야 한다. 주변에서 무슨 일이 벌어지는 늘 살펴야겠다.

Topic 3 소프트웨어 엔트로피

소프트웨어의 무질서도가 증가할 때 우리는 이를 '소프트웨어의 부패'라고 한다. 

이를 보다 그 정적인 표현인 '기술 부채'라고 부르기도 한다. 은연중에 언제 가는 갚을 수 있다는 뉘앙스를 풍기면서 말이다. 하지만 아마 갚지는 않을 것이다.  미래에 시간을 당겨다 쓰는 느낌이랄까..? 

여기서 말하기를 소프트웨어가 부패하는 데에는  많은 요소가 관여되는데 가장 중요한 것은 프로젝트에서 발생하는 심리학적 혹은 문화적 요소라고 한다. 이 심리는 이미 쓰레기가 넘치는 코드에 내 쓰레기 하나 더 버리는 건 괜찮다는 생각을 갖기 쉽다는 내용이다. 결국 이런 부정적인 생각은 팀원들에게 퍼져 악순환이 된다.

말하기를 깨진 창문을 내버려 두지마라

나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라, 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라. 더 이상 손상을 예방하기 위해 "아직 구현되지 않았음"이라는 메시지라도 표현하자. 그 조치로 관리되고 있다는 것을 알리자. 

공감이 많이 됐다. 쉽고 빠르게 구현하기 위해 작성했던 코드들이 나중에 유지보수가 불가능한 코드가 되어 개선 작업이 힘들었던 경험. 이미 깔끔하지 않은 코드 위에 깔끔하지 않은 코드 한 줄 추가하기에는 쉽지만, 누가 봐도 잘 정돈된 코드 위에는 조금 더 신경 써서 코드를 작성하려 했던 경험.

우선, 망가트리지 말자

문제를 해결하기 위해 부가적인 피해를 일으키지 마라. 깨진 창문은 하나라도 충분하다.

정확한 확신 없이는 오히려 건들지 말자.

당장 부패한 코드를 작성하지 말자. 미래에도 바꾸지 않는다.

Topic 2 고양이가 내 소스 코드를 삼켰어요.

실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것이다. 

주제만 봐도 핑계를 대는 사람의 모습이 보인다. 그건 바로 책임감과 연결된다. 이번 주제에서는 실용주의 프로그래머라면 자신의 경력 개발, 자신의 학습 및 교육, 자신의 프로젝트, 자신의 일상업무에 대해서 책임을 지고, 자신의 실수나 무지도 주저 없이 인정한다. 책임을 지는 것은 프로그래밍에서 가장 즐거운 부분은 아니지만, 자주 일어나는 것이다. 잘 나가는 프로젝트에도 철저한 테스트, 훌륭한 문서화, 탄탄한 자동화 등에도 불구하고 뭔가 잘못되는 일이 있다. 예상치 못했던 기술적 문제가 발생한다. 이런 일이 일어나면 우리는 가능한 전문가답게 처리하려고 노력한다. 이는 정직하고 솔직해져야 한다는 것이다. 

이 내용을 읽고 내가 느꼈던 것은 주어진 일정 안에 기획된 내용을 개발하지 못했을 때, 팀장님에게 내가 어떤 식으로 얘기를 했었지? 한번 떠 올렸다. 말도 안 되는 핑계를 되지는 않았는지, 해결하지는 못했지만 적절한 대안은 제시했는지. 과연 팀장님이 보기에 전문가처럼 얘기를 했는지..

팀 내 신뢰

여러분의 팀이 여러분을 믿고 의할 수 있어야 한다. 여러분도 다른 팀원 누구에게나 편하게 의지할 수 있어야 한다. 팀원끼리 신뢰하지 않는다면? 서로 의지할 수 없는 관계가 형성된다. 그리고 이런 신뢰에 구멍이 뚫리면 원상복구가 힘들다.

나는 이런 부분에서 신뢰를 쉽게 깨지지 않을까 생각한다. 당연히 테스트해야 하는 것들, 너무 간단한 시퀀스에도 쉽게 나오는 버그, 귀찮다고 그냥 넘어가는 것들... 이것들부터 신뢰를 지키는 중요한 시작이라고 생각한다.

책임지기

책임은 최선을 다하는 것이 전부가 아니다. 통제할 수 없는 위험 요소가 있지 않은지 상황을 분석해야 한다. 결과에 대한 책임을 지기로 했다면 나중에 그 결과를 감당해야 한다. 실수를 저지르거나(누구나 실수를 한다) 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력하라. 다른 사람 혹은 무언가를 비난하거나 변명을 만들어 내지 말라. 모르면 모른다고 얘기하고 그지만 찾아본다고 얘기해 전문가답게 책임을 지는 모습을 보여주자

내가 맡은 업무가 있다면 책임지고 해결하자. 안좋은 결과가 일어났다면, 그 결과를 좋은 결과로 바꾸기 위해 노력해야 한다. 변명이나 비난은 아무 의미가 없고, 내가 해결하지 못한다고 판단되면 일찍이 도움을 요청하자

나는 첫 번째 회사에서 2년 정도 경력을 쌓고 현재 직장인 이곳으로 이직을 했다. 좋은 프로젝트를 개발부터 출시까지 했다. 지금도 많은 것들을 경험하면서 배우고 있다. 내가 이 책을 처음 읽게 된 계기는 당시 팀장님과 첫 면담에 이런저런 얘기를 주고받았고, 짧은 시간이었지만 정말 배울 점이 많다고 생각했다. 그리고, 서점에서 이 책을 사주셨다. 사실 나는 프로그래밍이란 책은 언어문법이나 패턴정도의 책들만 몇 권 봤었지, 이런 종류의 책은 처음이었다.

이 책을 처음 읽을때는 이해하지 못하는 부분이 많아, 그냥 가볍게 읽었었다. 그 당시에 내년에 다시 한번 읽어봐야겠다'라는 생각을 했고, 올해 이 책을 다시 읽기 시작했다.  확실히 작년에 읽었을때 느끼지 못했던 것들이 있었다. 물론 지금도 저자가 예시를 드는 내용이며, 용어며.. 생소하고 이해하지 못하는 게 많다. (그럼 1년, 2년 후에는 점차 이해하는 부분들이 많지 않을까?) 이번에는 책의 내용들을 체득화하기 위해 내용을 정리하고, 내 생각들을 포스팅을 해보고 싶었다.

Topic 1 당신의 인생이다.

당신의 인생이다. 당신의, 당신이 사는, 당신이 만드는 인생이 있다. 

첫 번째 주제부터 확 와닿았다. 이 책에서 말하는 '불만 많은 개발자'를 얘기가 나는데. 공감이 됐다. 대학교를 다닐 때나, 학원에 다니며 공부하고 있을 때 불만이 많은 친구들이 꼭 있었다... 책에서 말하기를 이런 사람들은 변화를 귀찮아 피하고, 내가 발전하지 못하는 이유를 회사가 교육을 시켜주지 않는다고 투덜댄다고 한다. 내가 느끼기에도 이런 사람들은 무슨 어떠한 상황이 주어져도 불만을 갖으며, 그 이유를 동료 탓, 회사 탓으로 핑계를 댄다. 원하는 게 있으면 요구를 하고 내가 바꿀 수 없는 상황이라면 차라리 회사를 옮기는 것이 맞다.(근데 아마 이것도 귀찮아할 것이다.)

이 시점(현재 경력)에서 이런 글을 작성하는데 시간을 쓰는 것보다, 자료구조 공부 또는 알고리즘 문제를 한 문제 더 푸는 것이 더 좋다고 생각도 했지만 하지만 이렇게 나의 생각을 한 번쯤은 정리해보고 싶은 생각이 들었다. 

좋은 코드를 작성하는 방법은 무엇일까?

좋은 코드란? 좋은 코드는 빠르게 읽히고 유지보수가 쉬우며 수정사항이 있을 때 몇 개의 함수 호출로 원하는 기능을 수정/추가가 가능한 코드일 것이다.

하지만 기업에서 많은 사람들의 협업을 통해 업무가 진행되는 프로그램에서 이런 코드는 현실적으로는 힘들어 보인다.

버그를 수정할 때는 현재 수정하려는 부분에서 코드들의 한 줄 한 줄 의미를 파악해야 하며 수정했을 때 발생할 사이드 이펙트에 관해서도 꼼꼼히 살펴야 한다. 이 코드는 그럴 것이다~ 또는 누군가가 작성한 함수의 이름만 믿고 그런 기능을 하는 함수겠지 하는 생각으로 대충 리딩하고 버그를 수정하다 보면 나중에 크게 데일수 있다.. 그렇기 때문에 우리는 좋은 코드를 작성하려고 노력해야 한다.

이런 좋은 코드들이 나중에 프로그램이 실제로 서비스됐을 때 버그 수정에서도 빠르게 수정이 됐었고, 그 좋은 코 드위에서 작업을 할 때도 그렇지 않은 코드보다 훨씬 시간이 감축됐다. (어느 위치에, 어느 함수에 있어야 할 기능이 딱딱 있었다.)

좋은 코드를 작성하는 방법은 주어진 상황에 맞는 판단하여 작성하는 코드가 아닐까 한다. 

서비스하려는 프로그램을 만들다 보면 당연히 현재 코드가 실제 서비스됐을 때 새로운 기능은 쉽게 수정/추가/제거가 가능한지, 발생 가능한 이슈들을 예상하며 만들게 된다. 이러한 코드 작성은 당연히 시간이 많이 소요된다.

근데, 이 상황에서도 우리가 지향하는 좋은코드로 작성하는 게 맞을까?

예를 들어, 나에게 업무가 할당됐다. 그 업무는 이틀 안에 3가지 프로토타입을 발표하고 그중에서 선택받은 프로그램으로 본격적인 개발을 하기로 했다. 

그런데 미래 확작성을 고려한 베이스 코드부터 여러 기능을 미리 만들어 놓고 유지보수도 생각하면서 개발하다 설계과정에서부터 많은 시간이 소요돼 기한 내에 업무를 처리하지 못할 수 있다. 정작 결국에 사용하지 않을 코드나 기능을 만드는데 시간을 쓴 것이다. 그렇다면 코드로만 봤을 때 좋은 코드일 수는 있어도 좋은 코드 작성방법에서는 맞지 않는다고 생각한다. 

당연히 프로토타입을 만드는 과정에서도 수정사항과 여러 이슈가 발생할 수 있다.

말하고 싶은것은 작성하려는 상황에서 개발 속도와 그 상황에 어느 정도 예상되는 유지보수성까지만 살려 적절하게 작성하는 것이다.

시간이 돈으로 연관되는 이런 상황에서 이 두 개의 중점을 잡기는 힘들다. 업무를 하면서 이런 판단을 해야 할 일들이 많았고 또, 그 판단 결과가 만족스럽지 않은 적이 많았다. 이런 판단을 하려고 노력하다 보면 이 경험들이 점차 좋은 판단력을 얻어지지 않을까 생각한다.