<3탄>스프링 부트를 사용한 마이크로 서비스 개발 (로컬 환경) | 페어 프로그래밍 데모 (테스트 작성)
이번 세션에서는 Spring Boot를 사용한 웹 애플리케이션 개발에 대해 소개합니다. 이때 제작되는 애플리케이션은 Pivotal에서 풀타임으로 사용하고 있는 페어프로그래밍을 통해 테스트부터 작성하는 핑퐁 페어등을 소개합니다. 두명이 함께 코드를 작성하는 환경을 통해 빠른 사업환경의 변화를 수용할 수 있는 개발 업무가 Pivotal에서는 어떻게 다른지 살펴봅니다.
5. Spring Projects
https://spring.io
• Spring Framework
• Spring Boot
• Spring Cloud
• Spring Cloud Data
Flow
• Spring Data
• Spring Integration
• Spring Batch
• Spring Security
• Spring HATEOAS
• Spring REST Docs
• Spring for Android
• Spring AMQP
• Spring Mobile
• Spring Web Flow
• Spring Web Services
• Spring Session
• Spring Shell
• Spring LDAP
• Spring FLO
• Spring Kafka
• Spring StateMachine
• Spring IO Platform
6. The Big 4
Spring Framework, Spring Boot, Spring Cloud and Spring Cloud Data Flow
8. 애플리케이션 설정 패턴, 마이크로 서비스 컨테이너
• 스프링의 기본 설정값 변경을 쉽고 편리하게 제공
• 강화된 CoC (Convention over Configuration), XML 없음, 코드 생성
없음, 자동 설정
• 독립 실행 가능한 JAR 패키징
• 자동 설정 / 앱 서버를 임베드
• 클라우드 파운드리를 위한 자동 설정
• 실 운영을 위한 스위치를 제공
• start.spring.io 를 사용한 프로젝트 생성
• 자바, 스프링, 그루비, 코틀린
15. Spring Initializr
스프링 부트 애플리케이션의 시작
• Java, Kotlin, Groovy 중
하나의 언어를 선택 가능
• Maven, Gradle 중 선택
가능
• Java Version 은 최하
8이상을 사용 해야 함
16. Spring Initializr
스프링 부트 애플리케이션의 시작
• 스프링의 다양한 프로젝트 사용
가능
• 스프링 프레임워크 코어
이외에도 리액티브 웹, 다양한
NoSQL 과 SQL, 그리고 아마존
웹 서비스, 마이크로소프트 애저
및 구글 클라우드 플랫폼등의
클라우드 서비스에서 제공하는
서비스를 사용 가능
17. eXtreme Programming
The five values of XP are communication, simplicity,
feedback, courage, and respect and are described in
more detail below.
18. Communication
XP stresses the importance of the appropriate kind of communication – face to face
discussion with the aid of a white board or other drawing mechanism.
Simplicity
Simplicity means “what is the simplest thing that will work?” Simplicity also means
address only the requirements that you know about; don’t try to predict the future.
Feedback
Identify areas for improvement and revise their practices. Simple design. Your team builds
something, gathers feedback on your design and implementation, and then adjust your product
going forward.
19. Courage
Kent Beck defined courage as “effective action in the face of fear” (Extreme Programming
Explained P. 20). This definition shows a preference for action based on other principles so
that the results aren’t harmful to the team. You need courage to raise organizational issues
that reduce your team’s effectiveness. You need courage to stop doing something that
doesn’t work and try something else. You need courage to accept and act on feedback, even
when it’s difficult to accept.
Respect
The members of your team need to respect each other in order to communicate
with each other, provide and accept feedback that honors your relationship, and to
work together to identify simple designs and solutions.
20. Practices
• The Planning Game
• Small Releases
• Metaphor
• Simple Design
• Testing
• Refactoring
• Pair Programming
• Collective Ownership
• Continuous Integration
• 40-hour week
• On-site Customer
• Coding Standard
29. ! 아침을 거르고 출근
! 뇌는 아직 깨어있지 않은 상태에서 커피를 마시며 뉴스, 주식, 메일을 확인
! 오전 끝. 점심 시간
! 점심을 먹고 나면 포만감에 쉽게 피로해 짐
! 피곤한 상태에서 해결해야 하는 문제에 대해 검색, 연구
! 오후 3시 이후에 본격적으로 업무
! 6시까지는 주어진 일을 마감하기에 시간이 부족
! 늦은 시간까지 야근
(실리콘 밸리) 대부분 회사의 (혼자)업무 패턴
41. TDD에서의 페어프로그래밍 - example
핑-퐁 페어
핑퐁 페어는 멤버간 키보드 점유 순서를 돌아가며 작업하는 것
1. Member A writes a test and ensures it fails as expected
2. Member B fixes the test and writes the next failing test
3. Member A fixes the test and writes the next failing test
4. Repeat previous 2 steps forever (or at least until lunch)
100% Code Review with Pair
43. TDD in Pivotal
TDD에서의 테스트에 대한 피보탈의 정의는?
• "Executable description of code behavior". 코드 동작의 실행 가능한 설명
• "Description of how code should behave". 코드가 어떻게 동작해야 하는지에 대한 설명
TDD에서 프로덕션 코드에 대한 피보탈의 정의는?
• "An implementation that satisfies all tests at a given time" 특정 시점에서 모든 테스트를 만족하는 구현
• "That that is sufficient for the tests to pass" 테스트들을 충분히 통과한 코드
44. TDD를 적용하는 이유는?
• 오버 엔지니어링을 피하기 위해
• 테스트 불가능한 코드 작성을 원천 봉쇄
• 오브젝트 인터페이스를 고려하도록 강제
• 언제 끝났는지를 알기 위해
• 높은 커버리지를 유지하기 위해
• 다른 팀원과 소통하기 위해
• 점진적/연속적 진전을 위해
• 매뉴얼(수동) 테스트에 소비하는 시간을 줄이기 위해
• 코드를 보다 테스트 가능한 상태로 만들기 위해
• Because it's easier to describe how something
*should* work than to *make* it work.
TDD in Pivotal
• 요구 사항에 집중하기 위해
• 디버깅을 줄이기 위해
• 디버깅을 더 쉽게 하기 위해
• 버그가 있는 경우 쉽게 찾아내기 위해
• 오브젝트들이 서로 더 유기적으로 동작할 수 있도록
• 더 좋은 오브젝트 오리엔티드 의존성 디자인을 위해
• 실제로 사용가능한 문서를 유지하기 위해
• 리팩토링을 지원하기 위해
• 코드에 안전장치를 적용하기 위해
• 변화를 능동적으로 수용할 자신감을 가지기 위해
45. TDD in Pivotal
왜 테스트를 나중에 작성하지 않는가?
• 그런 방식은 동작하지 않기 때문:
◦ 지루하고
◦ 언제 끝날지 도무지 알 수가 없으며
◦ 일반적으로 많은 테스트 케이스를 놓치게 되며 이로 인해 매우 불량한 커버리지를 가진 상태가 되기
때문에: 작성돈 코드는 테스트를 가져야 함
• 테스트를 작성하는데 있어 비현질적인 원칙을 적용하지 않기 위해