Framework principal v1.6
- 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
- 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