1. Framework
Principal
2013.01

2. Contents
1. 원칙 3 개발 & 테스트
Mission, Vision, Core Values Feedback
행동 원칙 Continuous Integration
2 요구분석 & 설계
4 문서화 및 릴리즈
Commitment
Product Readiness
Benchmarking
Spec by Example
Compatibility
Rapid Prototype

3. 1. 원칙
(Principal)

4. Mission
개발자에게
진정성(Authenticity)있는
가치(Value)를 제공

5. Vision
PC웹, 모바일 웹, 앱, 광고디스플레이, TV
등에 들어가는 웹 어플리케이션에 대해서
하나의 짧은 코드로,
능숙하지 않은 사람이,
최소한의 시간과 노력으로,
세련된 디자인의 컨텐츠를
만들 수 있는 프레임워크

6. Core Values
 의사소통
– 커뮤니케이션을 못하는데 일은 잘하는 사람은 세상에 없다
 단순성
– 복잡한 것은 나쁜 것이다.
– 누군가 복잡한 룰을 만들었다면 그것을 깨는 것은 의무이다.
 용기
– 문제나 미심쩍은 부분이 있다면 스스럼없이 말하라.
– 리팩토링이 필요하면 공식 일정으로 진행하라.
 피드백
– 피드백은 자주, 많이 받을 수록 좋다.
 존중
– 우리는 개발자이기 이전에 인간이다.

7. 행동 원칙(Actions)
 Commitment
– 일정과 품질에 대해서 스스로 약속하라
 Benchmarking
– 법을 만들어내지 말라. 많은 사람이 쓰는 익숙한 것을 찾아라
 Specification by Example
– 예제가 곧 스펙이다. 예제 코드가 마음에 들 때까지 절대 구현에 손대지 말라.
– 구현 후에 만드는 예제는 테스트케이스일 뿐이다.
 Rapid Prototyping
– 프로토타입이 통과되면 책임은 모든 사람이 같이 진다
 Feedback, Feedback, Feedback
– 끊임없이 동료를 귀찮게 하라
 Continuous Integration
– 통합테스트는 따로 없다
 Product Readiness
– 데모 준비는 따로 필요 없다
 Compatibility
– 악법도 법이다. API는 바뀔 수 없다.

8. 2. 요구분석 & 설계
Commitment
API Design
Rapid Prototyping
Feedback, Feedback,
Feedback
Continuous Integration Product Readiness
Compatibility

9. 약속(Commitment)
 PSP(Personal Software Process)
– 코딩 -> 디버깅
예측 불가
– 계획–설계–리뷰–코딩–리뷰-테스트-문서화
예측 가능한 일정으로 “계약”
 리팩토링의 욕구는 공식화
 일의 우선 순위 = 사용자의 Pain 순위
– 결함 > 요구 사항 > 새로운 아이디어

10. API Design Process
 요구사항 수집
– Benchmarking
– 고객요구사항 은 일반화
 스펙 0.1에서 시작
– 곧바로 릴리즈. 그 후에 자신감 생기면 살 붙이기
 API 구현 이전에 먼저 API사용
– Specification by Example
 현실적인 것들을 고려
– 제약사항 존재. 모든 사람 만족 불가. But, 불만족스러운 점은 모든 사람
이 같도록
– 사용상의 실수 예상
– API는 변경될 수 없으나, 진화하는 것은 당연한 일

11. API Design 원칙
 하나의 API는 하나의 일만 수행
– 이름 짓기 어렵다면 좋지 않은 신호
 가능한 작아야 함. 필요이상으로 작아서는 안됨
– 요구사항 만족
– 의심이 생긴다면 내버려두기. API는 절대 못 없앰
 구현이 API에 영향을 줘서는 안됨
– 예제를 미리 작성(Specification by Example)
– 구현에 의해 깔끔한 예제가 영향 받아서는 안됨
 이름이 중요. API는 곧 언어
– 일관성 유지
– 관례를 지키기: 마크업(Markup)의 Best Practice 찾기
– 일반적인 패턴 흉내내기(Benchmarking)

12. API- Markup Best Practice
 Google Search!!!!
 표현(CSS)과 구조(HTML)의 분리는
늘 생각
– CSS에 따라 무엇이든 될 수 있음(반응형)
– 리스트는 <ul><li> 이지만 <ul><li>가
리스트는 아님

13. API- Benchmarking
 API의 저작권? No
– 흉내내기
오픈 소스 API
Java등의 core API
자연 법칙
설명 불가능한 스스로 만든 법칙은 절대 No
-> 구현에 스펙을 맞춘 결과
 작명 센스: DataObject, DataSet?
– 정확한 이름: Object인가? Collection인가?
– 나머지는 Google Search 검색 결과에 맡김

14. API-Spec. by Example
Example #1 구현
Example #2
Example #3 Example #1
Example #4 Example #2(제약)
Example #3(제외)
Example #4(제약)
구현 Example #5(보너스)
예제를 달성하기 예제를 구현에 맞추
기

15. API-Spec. by Example
스펙 문서는 필요 없음.
“예제가 곧 스펙”
구현 한 줄 없어도
“예제는 다다익선”

16. Rapid Prototype
<div data-type=“aaa”data-hello=“bar”>
</div>
-> 이름이 직관적이지가 않네
$(‘foo’).generate(true, false, true);
-> 파라미터가 복잡하군
 구현 한 줄 없이 예제 코드와 제약 사항을
Review
 Review 후 재개발은 Reviewer의 책임
 Review없이 개발 완료 후 재개발은 본인의 책임

17. 3. 개발 & 테스트
Commitment
API Design
Rapid Prototyping
Feedback, Feedback,
Feedback
Continuous Integration Product Readiness
Compatibility

18. Feedback, Feedback, Feedback
 개발하다 보면 제약 사항과 일정 지
연 요소는 반드시 존재
– Feedback과 Review만 하면 됨
– 옆 사람을 귀찮게 할 것
– 스스로 Spec을 낮추지 말 것. 이미
Reviewer와 약속한 Spec임
재검토가 필요

19. Continuous Integration
 통합 테스트는 따로 없음
 Daily Commit되는 소스는 신뢰된 소
스
– 바로 사용 가능

20. 4. 문서화 및 릴리즈
Commitment
API Design
Rapid Prototyping
Feedback, Feedback,
Feedback
Continuous Integration Product Readiness
Compatibility

21. Product Readiness
 문서화는 Kitchen Sink로 단일화
– 개발 과정에 이미 문서화 병행
 데모 준비는 따로 없음
 데모 Application을 만들기 위한 시간
이 오래 걸린다면 이미 제품 철학의
위배

22. Compatibility
 API의 변경은 절대 불가
– 좋지 못한 API가 릴리즈되었다면, 추후
그것을 보완하기 위한 많은 Dirty 코드
가 필요할 것.
 하위 호환성 유지
– 제품이 없어질 때까지

23. Thank
Whooo