My Dev Log

15장 XP 확장

소프트웨어 개발의 규모는 여러 차원에서 확장될 수 있다.

사람숫자 : 대규모 팀이 꼭 필요하다고 생각하더라도 먼저 작은 팀만으로도 문제를 풀 수 있지 않나 생각해봐야 한다.

투자 : 이 문제는 XP와 관련된 문제가 아니라 소프트웨어 개발을 어떻게 회계처리해야 하는지에 대한 문제다.

조직의 크기 : 조직의 다른 부분과 의사소통할 때에는 그들에게 익숙한 형식이 유지되도록 분명히 해두어야 한다.

시간 : XP는 테스트들이 유지보수에서 자주 생기는 문제를 방지하고 개발 프로세스에 대한 이야기를 들려주므로 프로젝트 기간이 길어도 잘 통한다.

문제의 복잡도 : XP는 전문가들의 긴밀한 협력이 필요한 프로젝트에 가장 이상적으로 맞드며 모든 사람이 다른이들의 전문 영역에 대해 조금씩 배워간다.

해결방안의 복잡도 : 제품을 계속 전달하면서 복잡성을 깎아 나가라.

실패의 결과 : 더 중요한 가치에 대한 실천방법을 팀의 매일 작업에 포함시킨다.

결론 : 늘 깨어 있으며 적절히 적응하기만 한다면, XP에도 분명 확장성이 있다.

16장 인터뷰

XP 를 적용한 회사의 임원 인터뷰

Q : XP를 도입할까 고려하는 다른 임원들에게 해주고 싶은 충고가 있습니까?

A : 꼭 XP를 사용하세요.(중략) 폭포수 방식 개발 안에 XP를 끼워 넣어야만 하는 경우에도, XP를 사용한다면 여전히 많은 이익을 얻을 것입니다.

2부 XP의 철학

17장 창조 이야기

XP의 시작에 관한 이야기

컨설턴트로서 할 일 가운데 하나는 답을 아는 사람을 찾아 그 답을 권력이 있는 사람에게 전달하는 일이다.

여러 팀의 많은 생각과 노고가 XP의 가치, 원칙, 실천방법의 관계를 탐구하고 그 아이디어들을 다듬는 데 들어갔다.

18장 테일러주의와 소프트웨어

테일러는 작업하는데 가장 좋은 단하나의 방법(“the One Best Way”)를 선택하고, 그것을 공장 전체에 표준화했다.

우리는 슬그머니 테일러주의의 사회적 구조를 물려 받았으며, 이것은 소프트웨어 개발에 기묘할 정도로 잘 맞지 않는다.

품질 조직을 별도로 둔다는 점에서 많은 소프트웨어 개발 조직이 바로 테일러주의자다.

품질, 아키텍처, 프레임워크가 소프트웨어 개발에서 중요하지 않다는게 아니라, 너무 중요하기 때문에 테일러주의자의 사회적 구조에 맡겨둘 수 없다.

그것은 변화하는 세상에서, 작동하고 유연하며 비싸지 않은 소프트웨어를 만드는 데 꼭 필요한 커뮤니케이션과 피드백의 흐름을 방해하는 구조이기 때문이다.

19장 도요타 생산 시스템

도요타는 자동차 생산 공정의 모든 단계에서 쓸모없이 낭비되는 노력을 제거한다.

TPS(Toyota Production System)의 정신적 지도자인 오노 다이이치는 과잉 생산의 낭비가 가장 큰 낭비라고 말한다.

만약 어떤 물건을 만들었는데 그것을 팔지 못하면, 그 물건을 만드는 데 들어간 노력은 사라져 버린다.

소프트웨어 개발은 과잉 생산의 낭비로 가득 차 있으며, 낭비를 제거하기 위해 필요한 피드백을 받으려면 우리는 활동들의 결과물을 즉시 사용해야 한다.

예를 들어 요구사항 수집은 요구사항 수집 절차를 더 정교하게 만들 때 개선되는 것이 아니라, 요구사항 세부내용을 만드는 일과 명세된 소프트웨어를 배치하는 일 사이의 경로를 짧게 만들 때 개선된다.

20장 XP 적용하기

XP는 문제를 해결해 주는 것은 아니며, 자신이 자기 방법으로 자기 시간을 들여 XP 환경 또는 (어떤 프로세스를 쓰든) 당신이 쓰는 프로세스의 환경 속에서 문제를 해결하는 것이다.

조직의 변화를 시작하는 방법은 여전히 자신부터 변화를 시작하는 것이다.

‘지속적인(continuous)’ 개선이란 단어는 약간 잘못 지은 이름이다. 이 말의 의미는 지속적인 깨어있음, 피드백을 수용하기, 개선에 대해 열린 마음이다.

개선의 경로는 평탄하지도 예측하기 쉽지도 않으며, 빠른 전환을 촉진하는 조건은 잘 합의된 가치들, 모두가 함께 겪은 고통이 있다.

XP는 조직의 진짜 가치가 XP의 가치와 어긋날 때에는 효과를 내지 못한다. (그럴땐 쓰지 말아야 한다.)

21장 순수성

우리의 목표는 성공적이고 만족을 주는 인간관계와 프로젝트이지, XP 클럽 회원이 되는게 아니다.

여러분이 XP의 가치를 지키고 여러분의 일상 실천방법들에 XP의 원칙을 주입한다면 여러분은 XPer다.

22장 해외 개발

해외 개발(offshore development)은 소규모 팀이 같은 장소에 함께 앉아 일한다는 XP의 ‘최적 조건(sweet spot)’이 아닌 상황에서  XP의 가치, 원칙 실천방법들을 어떻게 적용할까에 대한 사례 연구가 된다.

격국에는 한곳에 있지 않아서 생기는 낭비가 다른 이익들을 넘어서지 않는지 저울질하는 사업적 결정을 내려야 한다.

나는 효율성 증가와 다중 사업장 개발 때문에 어떤 곳에서 일자리 손실이 생기든 시장이 커져서 그것을 메우고도 남으리라고 믿는다.

23장 시간이 지나도 변치 않는 프로그래밍 방식(Timeless Way of Programming)

함께 일하는 팀은 각 구성원이 혼자 노력한 것을 합친 것 이상을 이룩할 수 있다.

사람은 천천히 바뀌지만 그 변화의 깊이가 깊다.

XP의 도전은 깊은 변화를 북돋우고 개인의 가치와 상호 관계를 새롭게 바꾸어 소프트웨어에게 다음 50년 동안 참여할 자리를 만들어 주는 것이다.

24장 공동체와 XP

공동체는 소프트웨어 개발에서 귀중한 자산이다.

공동체가 중요한 까닭은 누구나 어느 시점에는 도움이 필요하기 때문이다.

공동체일 때 우리는 고립된 상태에서 이룰 수 있는 것보다 더 많은 것을 성취할 수 있다.

25장 결론

자신을 먼저 개선하지 않고서는 개선이란 없다.

여러분의 가치들을 생각해보고, 그 가치들과 조화되는 삶을 살겠다고 의식적인 결정을 내려라.

8장 시작하기

한 번에 하나씩 바꾸는 방식으로 시작하는 것이 쉽다.

변화는 깨달음과 함께 시작되며, 변화가 필요함을 깨달았다면, 변화를 시작할 수 있다.

소프트웨어 개발은 지금 제공하는 것보다 훨씬 많은 것을 가져다줄 수 있다.

9장 보조 실천방법

기본 실천방법을 이미 완전히 하기 전에는 실행하기 어렵거나 실행하면 위험한 실천방법들

다음에 무엇을 개선해야 할지 결정할 때에는 자기의 감을 따른다.

진짜 고객 참여(필요를 채워줄 수 있는 사람들과 직접 연결시켜 노력의 낭비를 없앰), 점진적 배치, 팀 지속성(일정 관리를 단순하게 하기 위해서 관계와 신뢰의 가치를 무시하는 것은 거짓된 경제관념이다), 팀 크기 줄이기(팀의 능력이 신장되면, 작업량은 일정하게 유지하면서 점차 팀의 크기를 줄여라), 근본 원인 분석(5 Whys 와 같은 방법을 사용해서 결함과 원인을 모두 제거하라), 코드 공유(팀 구성원 누구든지 언제라도 시스템의 어떤 부분이든 개선할 수 있다), 코드와 테스트(오직 코드와 테스트만 영구 산출물로 유지하라, 소프트웨어 개발에서 가치 있는 결정은 무엇을 할 것인가, 무엇을 하지 않을 것인가, 우리가 하기로 한 것을 어떻게 할 것인가이다. 쓸모 없어진 산출물들을 제거하는 것이 이 개선을 가능하게 만든다), 단일 코드 기반(코드 흐름은 오직 하나뿐이어야 한다), 매일 배치, 범위 협상 계약, 사용별 지불

10장 전체 XP 팀

XP의 ‘전체 팀’ 실천방법에 따르면, 프로젝트를 더 효율적이게 만들기 위해서는 다양한 종류의 사람들이 서로 의견을 주고 받으면서 함께 일해야 한다.

테스터는 구현을 시작하기에 앞서 고객이 자동화된 시스템 차원의 테스트를 선택하고 작성하는 일을 돕고, 프로그래머에게 테스트 관련 기법을 지도한다.

상호작용 설계자는 시스템의 전반적인 메타포를 선택하고, 스토리들을 작성하고, 새로운 스토리를 찾아낼 기회를 잡기 위해 이미 배치된 시스템의 사용 양상을 조사한다.

아키텍트는 대규모 리펙터링을 찾아내고 실행하는 일, 아키텍처를 집중 테스트하는 시스템 차원의 테스트를 작성하는 일, 스토리를 구현하는 일을 한다.

프로젝트 관리자는 팀 내 의사소통이 용의하도록(facilitate)하고 고객과, 공급자와 그리고 조직의 다른 부분과의 의사소통을 조정한다.

제품 관리자는 스토리를 작성하고, 분기별 주기에서 주제와 스토리들을 고르고, 일주일별 주기에서 스토리들을 고르고, 구현 과정 중 스토리에서 완전하게 명세되지 않은 부분들이 드러날 경우 질문에 답변하는 일을 한다.

임원은 XP 팀에게 용기, 자신감, 책임감을 불어넣는다. (* 웅성거림은 팀이 건강하다는 징표이고, 침묵은 위험이 점점 쌓여가는 소리다.)

테크니컬 라이터는 기술적 출판물을 통해 기능에 대한 빠른 피드백을 제공하는 것과 사용자들과 더 긴밀한 관계를 맺는 역할을 한다.

사용자는 스토리를 작성하고 고르는 일을 돞고 개발 중에 문제영역(domain)에 관련된 결정을 내린다.

프로그래머는 스토리와 과업을 추정하고, 스토리를 과업들로 나누고, 테스트를 작성하고, 기능을 구현하는 코드를 작성하고, 지겨운 개발 프로세스를 자동화하고, 시스템의 설계를 점진적으로 개선한다.

개발팀이 XP를 시작할때 인적자원부에는 평가와 채용에 대한 고민이 필요하다.

서로 존중하는 새로운 인간관계가 팀 구성원 사이에 확립되면, 고정된 역할은 모든 사람이 최선을 다하도록 만든다는 목표에 방해가 된다.

목표는 추상적인 역할들에 사람을 채우는 것이 아니라, 팀 구성원 개개인이 자신이 할 수 있는 한껏 팀에 기여하는 것이다.

11장 제약 이론

‘제약 이론(Theory of Constraints)’은 전체로서의 시스템 처리능력을 살펴보는 접근방법 가운데 하나다.

제약 이론에 따르자면 시스템에는 한 지점에 제약 지점이 하나(가끔은 두개) 존재한다.

전체 시스템의 처리 능력을 키우려면 먼저 제약 지점을 찾은 다음, 그 지점이 확실히 현재 가능한 한 최대 속도로 가동하도록 한 다음에 제약 지점의 성능을 향상시키거나, 그것의 작업량 중 일부를 다른 비 제약 지점으로 덜어주거나, 제약 지점을 완전히 제거할 방법을 찾아야 한다.

제약이론의 단점은 그것이 단지 ‘모델'이라는 점이다. 하지만 제약 이론은 여러분 자신이 사용하는 프로세스를 의식하게 해줄 좋은 방법이다.

12장 계획 짜기: 범위를 관리하기

상호 동의된 계획이면서 현실의 변화를 반영할 필요가 있을 때 조정되기도 하는 계획은, 서로 존중하며 상호 간에 가치가 있는 인간관계를 나타낸다.

계획은 미래의 예측이 아니다. 이것은 기껏해야 내일 무슨 일이 일어날지에 대해 여러분이 현재 아는 모든 것을 표현해 놓은 것일 뿐이다.

계획 짜기는 모두 함께 해야 하는 일이다. 계획을 짜고 조화롭게 일할 때, 우리는 팀이 된다.

스토리들의 (일정)추정치를 경험에 비추어 수정해야 하며, 마틴파울러가 ‘어제의 날씨’라는 이름을 붙인 방법으로 어떤 주의 할 일의 양을 정확히 지난주에 성취한 일의 양만큼 하기로 계획을 짜는 방법도 있다.

일이 잘 풀리지 않을 때야말로 우리의 가치와 원칙을 고수하고, 우리의 실천방법들이 최대한 효율적으로 되도록 수정할 필요가 절실한 때이다.

13장 테스트: 일찍, 자주, 자동화

결함은 효율적인 소프트웨어 개발에 필요한 신뢰를 파괴한다.

결함은 비용이 많이 들지만 그것을 제거하는 일에도 비용이 많이 든다. 하지만 대부분의 결함은 그것을 막기 위해 들어갈 비용보다 더 비용이 들기 마련이다.

XP는 테스트의 비용 효율을 높이기 위해 두 가지 원칙을 적용한다. 재확인(double-checking, 두가지 방법으로 확인하여 결과를 일치시킴)과 결함 비용 증가(Defect Cost Increase, DIC, 결함을 일찍 찾을수록, 고치는 비용이 적게 든다)가 그 두 원칙이다.

재확인은 전혀 다른 생각의 흐름이 동일한 결과를 내놓을 때 가장 제대로 된 것이다.

XP에서 테스트의 즉각성(immediacy)은 테스트가 반드시 자동화되어야 한다는 점을 의미한다.

소프트웨어는 가상 세계이기 때문에 ‘테스트’를 먼저 하나 나중에 하나 똑같이 이치에 맞는다.

XP에서 테스트는 프로그래밍만큼 중요하며, 테스트는 팀 내부의 신뢰와 고객과의 신뢰를 강화함으로써 개발에 기여한다.

14장 설계하기: 시간의 가치

점진적 설계(incremental design)는 고객에게 기능을 빨리 전달하고 프로젝트의 생애 내내 매주 계속 기능을 제공하기 위한 방법이다.

설계란 ‘상생관계를 가진 요소들의 시스템’이라고 생각한다.

소프트웨어에서 점진적 설계가 가치 있는 이유 가운데 하나는 우리가 어떤 애플리케이션을 최초로 작성하는 경우가 많다는 것이다.

딱 피드백을 얻을 정도만 설계하고, 얻은 피드백을 이용해서 그 다음 피드백을 얻을 정도까지만 설계를 개선하기 위해서는 좋은 솜씨가 필요하다.

XP에서 소프트웨어 설계의 목적은 설계한다는 행위 차체가 아니다. 설계는 기술 쪽 사람과 비즈니스 쪽 사람 사이에 신뢰 관계를 맺는 일에 봉사해야 한다. 요청 받은 기능을 매주 전달하는 것이 이 관계의 초석이다.

요약하면, XP 방식 설계로 옮겨가는 것은 설계 결정을 내리는 시점을 옮기는 것이다. 경험을 바탕으로 설계할 수 있을 때까지 그리고 결정 내용을 즉각 사용할 수 있을 때까지 설계를 미룬다.

1장 XP란 무엇인가?

XP는 오래되고 효과가 없는 사회적 습관들을 버리고 효과 있는 새로운 습관들을 채택하는 것이다.

XP는 오늘 내가 기울인 모든 노력에 대해 자신을 인정해 주는 것이다.

XP는 내일은 좀 더 잘해보려고 애쓰는 것이다.

XP는 팀 전체가 공유하는 목표에 내가 얼마나 기여했는지를 잣대로 자신을 평가하는 것이다.

XP는 소프트웨어 개발을 하는 중에도 여러분의 인간적 욕구 가운데 일부를 채우겠다고 요구하는 것이다.

“이 책을 읽고 적용하면서 자신이 왜 소프트웨어 개발을 하게 되었고, 어떻게 이 일에서 만족을 찾을 것인지 더 깊이 이해하게 되기를 바란다."

1부 XP 탐험하기

2장 운전하는 법 배우기

XP의 패러다임은 "깨어 있고 적응하며 변하는것"이다.

3장 가치, 원칙, 실천방법

가치는 어떤 상황에서 우리가 좋아하고 좋아하지 않는 것들의 근원이다.

원칙은 특이한 영역에서 영원한 지침이 되는 것이다.

실천방법은 우리가 실제로 하는 것들이다.

4장 가치

중요한 것은 한 개인이 어떻게 행동하느냐가 아니라 그 개인이 팀의 일원이나 조직의 일원으로서 어떻게 행동하느냐다.

XP는 개발을 이끌기 위한 의사소통, 단순성, 피드백, 용기, 존중의 다섯 가지 가치를 포용한다.

그 외 다른 가치들을 선택할 수도 있으며, 제일 중요한 것은 팀이 신봉하는 가치에 팀의 행동이 어울리도록 만드는 것이다.

5장 원칙

가치는 너무 추상적이라 행동의 직접적인 지침으로 삼을 수가 없다. 효과적인 행동은 부분적으로는 상황에 따라, 부분적으로는 지적인 원칙(intellectual principle)에 따라 달라진다.

XP의 지침이 되는 원칙에는 인간성, 경제성, 상호 이익, 자기유사성(self-similarity), 개선, 다양성, 반성(reflectuion), 흐름(소프트웨어를 흐르듯이 끊임없이 제공하는것), 기회(모든 문제를 배움과 개선의 개회로 전환), 잉여, 실패, 품질, 아기 발걸음(작은 단계를 빠르게 밟기), 받아들인 책임(accepted responsibility)이 있다.

원칙을 이용한다면 실천방법들을 더 잘 이해할 수 있으며, 새로운 실천방법을 고안해낼 수도 있다.

6장 실천방법

가치를 통해 목적을 불어넣지 않은 실천방법은 기계적으로 따르는 규칙일 뿐이다.

실천방법은 상황에 따라 달라져야 한다. 원칙의 경우에는, 문제 영역(domain)이 달라졌다면 새로운 원칙을 몇개 추가해야 할지도 모른다.

어떤 실천방법을 적용하기로 결정하는 것은 여러분의 선택이다.

7장 기본 실천방법

XP를 적용하기 시작할때 안전하게 사용할 수 있는 실천방법들

다시 본 팀 죽이기 - 동기 부여를 위한 장식품들(슬로건이 쓰여 잇는 머그잔, 액자, 핀 상패 같은 물건들)은 본질을 무시하고 형식에 집착하는 태도를 가장 극명하게 보여 준다. 초과 근무 또한 건강한 팀을 방해하는 팀 죽이기의 요소를 갖고 있다. (* "사람들이 초과 근무를 하는 이유는 과제를 주어진 시간안에 끝마치기 위해서라기보다는, 일을 정해진 기간까지 끝마치지 못했을 때 비난 받게 될 것을 우려해 자신을 보호하기 위함이다.")

과도한 경쟁은 단결을 해친다 - 기업의 팀은 스포츠 팀 보다는 합창단이나 성가대 같은 팀이어야 한다. 즉 '서로 조화를 이루고 있는 업무 그룹' 에 가깝다. 정말 중요한 것은 개인의 성공이 전체의 성공과 밀접한 관계에 있음을 회사 사람들이 이해하도록 하는 것이다.

프로세스 개선 프로그램 - 가장 해볼 만한 가치가 있는 프로젝트는 당신 회사의 프로세스 레벨(CMM)을 완전히 한 등급 낮춰 줄 그런 프로젝트이다.

변화를 두려워하지 말라 - 사람들은 변화를 싫어한다. 변화에 대한 사람들의 반응은 본질적으로 이성적인 것이 아니라 감정적인 것이다. 하지만 전혀 변화하지 않는다면 발전은 없다. 

사람에게 투자하자 - 직원들에게 적절한 투자를 하는 기업은 장기적으로 번창하게 될 것이다. 지식 노동자들로 구성된 회사들은 가장 중요한 것이 인적 자본에 대한 투자임을 깨달아야 한다.

조직 학습이 필요하다 - 조직 학습 중심지로 가장 적당한 곳은 중간 관리자들 사이에 있는 공간, 즉 화이트 스페이스이다. 이 공간이 의사 전달 과정을 위한 훌륭한 경로가 된다면, 중간 관리자들이 조직을 재정비하는 사람으로서 협동하고 그에 따르는 위험을 같이 공유한다면 학습을 통해 생겨나는 이득은 실현 될 것이다.

궁극적으로 관리자가 저지르는 죄 - 궁극적으로 관리자가 저지르는 죄는 직원들의 시간을 낭비하게 한다는 것이다.

때론 무질서가 필요하다 - 약간의 무질서를 허용해서 직원들이 스스로 처리하여 무질서한 상태를 질서 정연하게 만드는 재미를 느끼도록 한다. 실험 프로젝트, 프로젝트 대회, 브레인스토밍, 극기 훈련, 연수,여행, 회의, 휴양지 등으로 직원들을 내보내는 방법이 있다.

자유 전자적 속성을 지닌 사람들 - 뛰어난 관리자의 지표는 바로 균형 잡힌 시각과 성숙함을 갖추고 있는 중요한 몇몇 인물들을 뽑아서 그들이 자유롭게 일하도록 풀어주는 능력에 달려 있다.

전체는 부분의 합보다 더 크다 - 팀의 목표는 목표의 달성이 아니라 목표의 일치이다.

블랙팀의 교훈 - 팀 내의 공감대 형성이라는 궁극적 목표를 이루어낸 단결된 팀의 가치는 매우 크다. 팀원이 변해도 팀은 살아남아 그들의 에너지와 성격을 그대로 간직하게 된다.

팀 죽이기 - 팀을 단결시키도록 만드는 것은 불가능 하며 단지 그러기를 바랄 수 있을 뿐이다. 단결된 팀은 만드는 것이 아니며 형성되는 것이고, 그러한 방법을 찾는것은 매우 어려워 반대로 팀 형성을 불가능하게 만드는 방법을 소개한다. 방어적 관리법(신뢰를 하지 않고 업무에 간섭함), 관료주의(과도한 서류작업), 팀을 따로 떨어뜨려 놓기(상호 교류 방해), 오직 한 번에 하나의 업무만(여러 개의 단결된 팀에 속할 수는 없음), 품질이 저하된 제품(자존심에 상처를 입게 됨), 거짓 데드라인(반복되는 거짓은 믿지 않게 되며, 신뢰받지 않고 있다는 느낌을 줌), 소집단 관리(팀이라는 개념에 대한 낮은 인식 수준 때문에 팀에 대해 불안감을 갖고 있음). 대부분의 조직들은 의식적으로 팀을 죽이려 하지 않는다, 단지 조직의 운영 방식이 그럴뿐이다.

스파게티 회식 - 최고의 관리자는 팀원들이 '관리되고 있다'라는 느낌 을 받지 못하는 가운데 끊임없이 이런 기회들을 제공하는 사람이다. 

서로 신뢰하는 문화 - 단결된 팀을 가장 잘 형성할 수 있는 것은 신뢰의 태도이다. 뛰어난 관리자들은 관리 분야에 대해 자신이 갖고 있는 자연스러운 권위를 보여 줌으로써 사람들을 관리한다. 신뢰감 넘치는 분위기는 팀이 단결할 수 있는 최적의 조건이다.

혼블로워 효과 - 가장 중요한 것은 처음부터 적합한 인물을 선택하는 것이다. 가장 성공적인 관리자는 비록 회사의 기준에서 벗어날지라도 유능한 사람들을 데려오고, 기업내의 엔트로피를 줄이는 사람이다.

직원을 제대로 뽑으려면 - 포트폴리오를 요구하거나 오디션을 보는 방법을 활용하라.

여기서 일하는 것에 만족합니다 - 이직은 명백한 비용이다. 최고의 조직은 의식적으로 최고가 되기 위해 노력한다. 최고가 되는 것이 바로 공통적인 방향을 설정해 주고 만족감을 주며 강력한 결속력을 제공해 주는 목표이다. 그러한 곳에서는 지속성을 중시한다. 재교육은 지속성을 위한 좋은 방법이다.

비생산적인 작업환경 - 획일적인 칸막이 같은 공간이 능률 향상에 도움을 주는지 방해를 하는지에 대해서는 아무도 관심을 갖지 않는다. 직원들이 시끄럽고 삭막하며 불안을 일으키는 사무 환경에서 일하고 있다면 사무 환경을 개선하는 것이 가장 시급한 문제이다.

도대체 여기선 일할 수가 없어요 - 업무 환경의 특징들에 대해 태만히 대처해서는 안된다. 당신이 정신 노동직에 종사하는 사람들과 일하거나 그들을 관리해야 한다면 업무 환경은 바로 당신이 책임져야 한다.

사무실 시설비 아끼기 - 직원 한 명에 대한 총투자 비용은 사무실 시설비의 20배가 넘는다. 사무실 시설비를 많이 들이지 않아 아끼게 되는 비용은 열악한 사무 환경으로 인해 생겨날 위험 요소와 비교해보면 소소한 것이다.

머리로 일한 시간, 몸으로 일한 시간 - 조용한 사무실에서는 작업에 대해 생각할 수 잇는 기회가 있다. 일터가 조금이라도 조용하고 차분해진다면 그들은 아무 조건 없이 두뇌를 사용하여 자기 일을 열심히 할 수 있을 것이다.

전화로부터 벗어나자 - 어떤 혁신적인 도구보다도 중요한 것은 태도를 바꾸는 것이다. 사람들은 때때로 전화를 받지 않아도 된다는 것을 배워야 하며 시간이 - 시간의 양이 아니라 질이 - 중요하다는 사실을 알아야 한다.

사무실에 다시 문을 달자 - 경영은 직원들이 자신에게 적합한 업무 공간을 만들 수 있도록 프라이버시를 보장해 줄 수 있는 방법을 제공하고, 충분한 공간과 조용한 분위기를 만들어 주는 것이어야 한다. 그러므로 통일성을 중시하는 태도를 고집해서는 안된다. 적절한 사무공간이 누구에게나 정확히 똑같은 모양일 수는 없다.

기술 문제가 아니라 사람 문제다 - 업무에서 발생하는 문제들은 대부분 기본적으로 기술의 문제가 아니라 조직사회학의 문제다. 사람들이 업무의 인간적인 측면보다 기술적인 측면에 주로 매달리는 가장 큰 이유는 기술적인 부분이 더욱 중요하기 때문이 아니라 거기에 매달리는 것이 훨씬 더 쉽기 때문이다.

햄버거 마인드 - 현상 유지만 하는 일은 이미 실패한 일이다.

진정한 생산성의 의미 - 시간에 쫓기며 일하는 사람들은 일을 더 잘하는 것이 아니라 단지 더 빠르게 일할 뿐이다.

여유 시간이 있어야 품질을 따진다 - 사람들은 자존심을 자신이 생산하는 제품의 질과 관련시키는 경향이 있다. 실 사용자가 요구하는 것 이상의 품질을 추구해야 생산성을 향상시킬 수 있다.

다시 본 파킨슨 법칙 - 업무는 그에 할당된 시간만큼 늘어지는 경향이 있다는 개념. 허나 실상은 그렇지 않으며, "회사 일정에 쫓겨 일을 해야 할 때" 직원들은 근무 시간만 채우도록 일을 늘이는 경향이 있다.

es6에 대한 관심(http://sett.ociweb.com/sett/settApr2014.html?utm_source=javascriptweekly&utm_medium=email)도 가져야할 것 같고, 최근 TodoMVC를 traceur-compiler를 이용해서 구현(http://addyosmani.com/blog/traceur-todomvc/)한 사례도 있어, 공부겸 traceur-compiler를 사용해 es6를 써 본 느낌을 간단히 정리 ~

es6 개발을 위한 준비 (IDE의 빨간줄이 보기싫다면 ...)

intelliJ 설정에서 javascript 버전을 es6로 변경한다. (스크립트 파일을 다시 파싱하느라 잠깐 멈추지만 죽은건 아니다 ㅡㅡ;;)

jshint 옵션에서 esnext: true, strict: false 를 추가한다.

개발 중 발생한 이슈들

intelliJ가 종종 이상해진다. 일부 단축키가 탭키 안먹음, 빠르게 타이핑 하다보면 es6 분석을 제대로 못하는 듯 하다.

브라우저에 traceur.js를 넣어서 개발했더니 디버깅이 힘들다. ㅠㅠ

브라우저에서는 es6 > es5로 실시간으로 컴파일해서 실행하려다 보니 속도가 느려서 온로드 후에도 파싱을 완료하지 못하여 종종 js 에러가 난다. ㅡㅡ;; (모바일에서는 더 자주나는 듯)

grunt-traceur 플러그인 들이 쓸만한 게 없다. traceur node api 로 각 파일, 모듈들을 컴파일 해서 합쳐줘야 하는데 node api로 수동으로 해본 것과 결과물이 달라 곤란하다. 좀 해보다가 필요하면 만들어야 할 듯 ...

TDD를 하려면 es5로 컴파일 후에 테스트 해야 할 듯 하다. watch를 걸어놓고 매번 컴파일을 해야할지도 ...?

사용해본 es6 스펙 & 주의할 점

Modules : import, export만 사용해봤는데, traceur 에서 dependency 들을 불러와서 하나의 파일로 만들어줘서 편리하다.

Classes : get, set을 사용하는 경우에는 class의 외부함수가 있어서는 안된다.  (jshint error) 모듈을 사용하여야 할 듯

Arrow Functions : parameter에 괄호 안쓰면 컴파일이 안된다. (ex. size => this._render(size); >>> (size) => this._render(size);    : 게다가 쌩뚱맞은 에러남...)

Default Parameters : 좋다.

Template Literals : 템플릿 안의 변수들을 호출하는 메서드가 생기는 것 같은데, 아직 잘 사용하는 법을 모르겠음

Block Scoped Binding : let 정도만 간단히 사용해봐서 딱히 장점은 아직 모르겠다.

한참 삽질하면서 해봤는데, 생각보다 지원되는 툴들도 많고, 사용할 수 있는 환경이 갖추어진 것 같다. 개인적으로는 보수적인 편이라 es6 개발완료한 모듈은 es5로 바꿔서 사용할 예정이긴 하다 ㅡㅡ;; 

https://developers.google.com/events/io/sessions/361772634

다 볼때쯤 되니 내용이 하나도 기억이 안나서 다시 보고 정리

Design Suggestions

터치 인터페이스는 넓은 영역의 타겟이 필수

hover에 의존하지 말 것

Avoiding Common Problems

터치 스타트와 마우스 다운을 구분하는 방법을 사용하지 말고 둘 다 지원해야 함

터치 이벤트 타겟팅은 마우스의 그것과 다르므로 (touchstart 엘리먼트에 타게팅 됨) move와 end, cancel 이벤트 바인딩을 주의해야 함

작은 부분 터치가 힘듬. 크롬은 "touch adjustment"를 제공, touch adjustment가 잘 작동하도록 하기 위해서는 클릭 가능하고 이벤트 핸들러를 가져야 함

제스처 API 는 브라우저 특화 됨. 크롬은 제스처 API 아직 지원 안한다. 표준화 된 API를 지원할 것임. Hammer.js 같은 라이브러리를 사용해서 해결하라.

모바일 기기의 클릭 이벤트 딜레이 (300ms delay) 문제. 좋은 fast click 라이브러리를 사용해라. 크롬에선 user-scalable=no 일 경우 no delay

터치 무브는 렌더링 속도보다 빠르게 fire 될 수 있다. 이벤트 (터치무브) 핸들러에서 비용이 많이 드는 명령을 피해라, rAF를 사용해서 개선할 수 있다.

Touch 핸들러는 scroll jank를 발생시킬 수 있다. 크롬은 scroll은 GPU thread에서 처리, 이벤트 핸들링은 main thread에서 처리하므로 터치 핸들러가 있다면 스크롤 후 이벤트 발생 시 event.preventDefault 를 만날때까지 기다리게 됨. 불필요한 터치 이벤트 핸들러를 피하고, 터치 이벤트 영역을 작게해라.

Future of touch on the web

Drag&Drop API 등 지원으로 터치 이벤트 직접 사용을 줄이도록 해줄 것

개발자가 브라우저 기본 동작을 좀 더 컨트롤 가능하도록 해 줄 것

더 나은 크로스 브라우징 지원

https://plus.google.com/114552443805676710515/posts/3KhSm1Ugx53

Chrome 에 stale-while-revalidate 지원을 고려중이라고...

Cache-Control: max-age=60, state-while-revalidate=240

이렇게 사용하면 response의 받은 후 0s ~ 60s 구간에서는 cached response를, 60s ~ 300s (240s) 구간에서는 cached (stale = no longer fresh) response 를 보여주되 background update를 통해 resource를 refresh 한다.

http://lawsonry.com/2014/05/diy-angularjs-seo-with-phantomjs-the-easy-way/?utm_source=javascriptweekly&utm_medium=email

human 과 bot 을 구분해서, bot 일 경우에는 PhantomJS 를 이용한 snapshot 페이지를 보여주는 좀 더 쉬운 방법.

여전히 이 문제를 해결할 나이스한 방법은 없는 것 같다.

위와 같은 방법의 단점은 아래에 잘 정리되어 있다. 맨 아래의 제품홍보는 무시 ~

원문 : http://alistapart.com/article/people-skills-for-web-workers

"함수형 프로그래밍은 값을 추상화의 단위로 바꾸는 기능을 하며 결국 바뀐 값들로 소프트웨어 시스템이 만들어진다."

호기심에 보고있긴 한데 -_- 1/3 정도 읽어서는 아직 감이 전혀 안 옴.

원문을 읽어도 와닿을 것 같지는 않지만, 번역서로도 이해가 잘 안되는 부분들은 오히려 원문이 궁금하다 ...

ES6 TODOMVC 에 사용된 ES6 문법 몇가지

1. Destructuring Assignment : 배열과 오브젝트 형태로 변수를 한번에 할당 가능, 편리하긴한데 왠지 어색한 이 느낌은 기분 탓?

2. Block Scope : let 을 사용해서 block scope 사용 가능, function scope로 해도 별 문제 없는것 같은데 왜 추가했을까? function scope가 더 버그 발생확률을 높인다거나 하는 이유는 설마 아니겠지 ...

3. Class Syntax : 있어서 좋긴 함, prototype 은 prototype 이고, class를 흉내내는 것과 keyword 가 있는 것은 다른문제 인것 같다.

4. Module Syntax : 이제 CommonJS 나 AMD 없이 통합 모듈시스템을 쓸 수 있겠군 !!

5. Spread Operator & Rest Parameter : arguments 컨트롤이 용이해짐. 기존에도 다른방식으로 충분히 가능하긴 하지만, 훨 편리. 이런걸 syntax sugar 라고 하는 건가?

6. Arrow Function : => 로 anonymous function 사용이 편리해짐. callback 같은 경우에 타이핑이 많이 줄어들 듯.