Embed Size (px)
Citation preview
Framework Principal
2013.01
Contents 1. 원칙
Mission, Vision, Core Values
행동 원칙
2 요구분석 & 설계
Commitment
Benchmarking
Spec by Example
Rapid Prototype
3 개발 & 테스트 Feedback
Continuous Integration
4 문서화 및 릴리즈 Product Readiness
Compatibility
1. 원칙 (Principal)
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 #4
구현
구현
Example #1 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 Continuous Integration Product Readiness
Compatibility
Feedback, Feedback, Feedback
개발하다 보면 제약 사항과 일정 지연 요소는 반드시 존재
– Feedback과 Review만 하면 됨
– 옆 사람을 귀찮게 할 것
– 스스로 Spec을 낮추지 말 것. 이미 Reviewer와 약속한 Spec임
재검토가 필요
Continuous Integration
통합 테스트는 따로 없음
Daily Commit되는 소스는 신뢰된 소스
– 바로 사용 가능
4. 문서화 및 릴리즈
Commitment API Design Rapid Prototyping
Feedback, Feedback, Feedback Continuous Integration Product Readiness
Compatibility
Product Readiness
문서화는 Kitchen Sink로 단일화
– 개발 과정에 이미 문서화 병행
데모 준비는 따로 없음
데모 Application을 만들기 위한 시간이 오래 걸린다면 이미 제품 철학의 위배
Compatibility
API의 변경은 절대 불가
– 좋지 못한 API가 릴리즈되었다면, 추후 그것을 보완하기 위한 많은 Dirty 코드가 필요할 것.
하위 호환성 유지
– 제품이 없어질 때까지
Thank Whooo
