3Q 활동정리

지난 2Q는 횡적인 확장과 JD의 얼라인을 맞추는데 중점을 뒀다면, 3Q는 실제와 종적인 깊이로 다가간다.

무엇을 했는가

Acceptance Test Driven Development

인수 테스트를 배우면서 얻은 것들

1. 테스트의 최종 목적.
2. 코드는 어떻게 작성해야 하는가?
3. JUnit, rich domain, unit test, E2E test, test double.

놀랐던 점 (aka 인지부조화)

1. 이렇게 상세한 테스트를 정말로 나 빼고 모두가 다 해왔다고?
2. 이 많은 테스트를 정말로 다 작성한다고?
3. 말도 안되게 큰 돈을 내고 들어왔는데 아무렇지 않게 중도하차 한다고 ?????

Implementation always comes first

❌ Using middleware ⇢ ✅ Implementing requirements

• 미들웨어로 비롯되는 어쩌구 저쩌구들은 하나도 중요한게 아님. 옛날부터 생각 했던거지만 잘 만들어진 어플리케이션에 미들웨어를 도입하는 것은 엔지니어의 숙련도가 어찌됐건 간에 그냥 장애 포인트.
• 나도 만들어놓고 보니 미들웨어 없이도 이미 요구사항에 맞는 pub-sub 패턴 어플리케이션을 구현 했었음. 나 역시 미들웨어에 집착함.
• 두달 안에 끝낼수 있을줄 알았는데 reactor랑 session 공유 문제로 너무 오래 걸렸다.. 하지만 재미는 있었음.
• 아무한테도 절대 입도 뻥긋 안하고 진행한 프로젝트.

Again… ORM, design, domain

결국 다시 설계

• 직접참조, 간접참조
  • 직접참조 해서 Lazy거는게 능사가 아니였어??
  • 애그리거트 수준에서 분리
• 일급 컬렉션
  • rich domain과 연관있음. 비즈니스 관심사의 분리.

Kotlin

자바랑 비교해서 신기했던 점

• 코드에 명세되는 null 처리 ⇢ 이거 하나만으로도 코틀린의 가치는 증명되는듯?
• extension functions
• closure
• break boilerplate code (singleton, named parameter, type inference)

자바랑 비교해서 별로인점

• 너무 높은 코드 자유도 – inline/infix functions, local functions, componentN, label…
  이런 것들을 아무렇게나 작성해놓고 박스 쳐버리면 깊어지는 디버깅 난이도는 누가 책임져요..?
• companion object
• 자바 코드와 병행을 허락하는 점

벌려놓은 일

• 2월부터 4월까지 꽉차게 달림. (프로젝트B)
• 5월부터 8월 중순까지도 꽉차게 달림. (5월 JVM – 6월 Coding interview – 7~8월 ATDD)

생각 변화

마지막의 마지막에 그만 둘때는 미련없이 떠날 수 있도록 최선을 다하자.

4/4분기 계획

• 프로젝트B
• 프로젝트C
• …runaway

지금까지 한 것

• 프로젝트A: Java, Spring boot, SQL, JDBC
• 프로젝트B: Java, Spring WebFlux, Reactive WebSocket, NoSQL, JPA, Docker
• 프로젝트C: Kotlin, Spring, k8s(에서 비롯되는 백엔드 아키텍처 구현)