�ݺ�ߣ

Framework
Principal
2013.01

Contents
1. 원칙 3 개발 & 테스트
Mission, Vision, Core Values Feedback
행동 원칙 Continuous Integration

2 요구분석 & 설계
4 문서화 및 릴리즈
Commitment
Product Readiness
Benchmarking
Spec by Example
Compatibility
Rapid Prototype

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

Vision
PC웹, 모바일 웹, 앱, 광고디스플레이, TV
등에 들어가는 웹 어플리케이션에 대해서

하나의 짧은 코드로,
능숙하지 않은 사람이,
최소한의 시간과 노력으로,
세련된 디자인의 컨텐츠를

만들 수 있는 프레임워크

Core Values
 의사소통
– 커뮤니케이션을 못하는데 일은 잘하는 사람은 세상에 없다

 단순성
– 복잡한 것은 나쁜 것이다.
– 누군가 복잡한 룰을 만들었다면 그것을 깨는 것은 의무이다.

 용기
– 문제나 미심쩍은 부분이 있다면 스스럼없이 말하라.
– 리팩토링이 필요하면 공식 일정으로 진행하라.

 피드백
– 피드백은 자주, 많이 받을 수록 좋다.

 존중
– 우리는 개발자이기 이전에 인간이다.

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

2. 요구분석 & 설계

Commitment
API Design
Rapid Prototyping
Feedback, Feedback,
Feedback
Continuous Integration Product Readiness
Compatibility

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

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

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

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

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

API-Spec. by Example
Example #1 구현
Example #2
Example #3 Example #1
Example #4 Example #2(제약)
Example #3(제외)
Example #4(제약)
구현 Example #5(보너스)

예제를 달성하기 예제를 구현에 맞추
기

API-Spec. by Example
스펙 문서는 필요 없음.
“예제가 곧 스펙”

구현 한 줄 없어도
“예제는 다다익선”

Rapid Prototype
<div data-type=“aaa”data-hello=“bar”>
</div>
-> 이름이 직관적이지가 않네

$(‘foo’).generate(true, false, true);
-> 파라미터가 복잡하군

 구현 한 줄 없이 예제 코드와 제약 사항을
Review
 Review 후 재개발은 Reviewer의 책임
 Review없이 개발 완료 후 재개발은 본인의 책임

3. 개발 & 테스트

Commitment
API Design
Rapid Prototyping
Feedback, Feedback,
Feedback
Compatibility

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

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

4. 문서화 및 릴리즈

Commitment
API Design
Rapid Prototyping
Feedback, Feedback,
Feedback
Compatibility

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

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

�ݺ�ߣ

Framework principal v1.6

More Related Content

Framework principal v1.6