okkycon.md

개요

• 2018 okkycon 에서 강의 들으면서 적은 내용
  • 컨퍼런스 소개 페이지 깨졌을 경우, 아카이빙 페이지
• 이후 내용 보완할 예정

컨퍼런스 후 회고 with RudiaMoon

오전 세션

• ohahohah: 저는 사실 앞 세션이 제가 좀 바로 실천으로 가자! 할 수 있었던 세션이었던거 같은데 못 들어서 아쉬웠어요.
• Rudia: 저도 앞 세션 좀 아쉬움 되게 많이 남아요. 뭔가 재성님 세션 들으면서 계속 코딩 하고 싶은 용기가 생겼어요. 근데 듣기만 하니까 아 빨리 집에 가서 코딩하고 싶다는 생각이 계속 들었어요.
• (인상적이었던 강의내용 보고 이야기하려고 했는데 ohahohah가 못하게 막음. ohahohah: 안보면 기억 안나는건 기억안나는 거죠!)
• R: 인상적이었던 부분은 코드를 15줄에서 10줄로 줄여보자. 내가 장난감 프로젝트로 계속 해봐야 나중에 현업에서 쓸 수 있을 정도로 할 수 있게 된다. 장난감 프로젝트를 많이 해 봐야 된다고 하더라고요.

이혜승 개발자 세션

• R: 그리고 재성님 세션 다음으로 인상깊었던 거는 주니어 개발자분 얘기였어요.
• o: 저도요. 공감 많이 되었고요. 나도 그 부분 어려웠는데, 나도 그렇게 생각하는데, 맞아, 그 부분에서 테스트코드가 있어서 좋았어 하고 귀에 쏙쏙 들어오더라고요.
• R: 회사에서 세미나 간다고 이야기했는데, 회사에서 어? 그럼 발표해요? 라고 물어보더라고요. 저도 언젠간 발표를 하고 싶다고 생각했어요. 근데 그게 굉장히 먼 나중에 기술적으로 자신이 있을때 언젠가 나도 그런 날이 오겠지? 하고 생각했거든요. 근데 이 분 발표를 들으면서 지금 내가 느끼는 것들에 대해서 발표를 할 수 있구나 하고 느겼어요.
• o: 저는 이혜승 개발자의 자료를 본 적이 있어요. DDD 에 대해 정리해서 슬라이드쉐어에 올린 자료였는데요. 저는 솔직히 DDD가 제 수준에서 제대로 이해하기가 까다로운 개념이라고 생각했었는데요. 근데 그 분 슬라이드가 깔끔하게 정리되어있어서 인상깊었어요. 이번 컨퍼런스에서 그 분 발표 듣게 되어서 좋았어요.
• o: 그리고 한편으로는 그동안 내가 들었던 세미나 내용들이 너무 나한테 맞지 않게 어려웠나? 이 생각이 들었어요. 다른 세션을 들을 때에는 내용을 다시 소화해서 제 생각이나 경험,감상을 적기보다는 내용을 받아 적기가 바빴거든요. 내용을 이해하기 바빴었죠. 근데 이혜승 개발자 발표는 제가 느낀 것까지 같이 입체적으로 정리할 수 있었어요. 그래서 아, 좀 더 이해할 수 있는 정도의 거에만 집중해야할 시기가 아닌가 느꼈어요. 뭔가 듣고 나서도 머리 속에서 이렇게 빠져나가는 느낌. 컨퍼런스 내용을 다시 정리하면서 느끼는 내용도 있고 학습하는 것도 많고 자극이 되어서 컨퍼런스를 많이 가려고 하는데 음. 사실 나는 키워드 하나만 건져도 좋다. 내가 뭘 모르고 있었는지 아는게 중요하다 이렇게 생각하지만서도. TDD에서도 그렇고 모르는 게 있는 불확실한 상황이면 한번의 하나씩만 한번에 할 수 있는 단위로 해서 접근하잖아요. 너무 큰 걸 한번에 보려고 했었던 건 아닐까.

그 외 세션

• o: 저는 '코드 품질을 위한 테스트 주도 개발' 세션 에서 재밌었던 부분이 하나 있었어요. 책들을 읽다보면 응집도, 결합도 이야기가 계속 나오잖아요. 근데 제가 막상 코드를 보거나 설계해도 어느정도가 응집도가 높은건지 결합도가 낮은건지 잘 모르겠거든요. 코드를 많이 보고 분석해본 경험의 문제도 있는 거 같은데요. 근데 품질에 대해 이야기 하면서 응집도,결합도를 어떤 요소로 평가하는지 이야기 했잖아요. 그게 절대적인 건 아니겠지만 아 저런 게 중요요소라서 저걸 평가지표로 삼는구나! 하고 그 요소들이 뭔지 알 수 있어서 좋았어요.

세션2. 박재성 연사

Q. 기존 테스트가 오히려 발목을 잡는 거 같다. 수정해서 배포해야하는데 시간이 없고. 개발 시간을 갉아먹거나 테스트코드를 빡빡하게 짜면 짤 수록 나중에 수정을 많이 해야해서 발목을 잡는 기분이다.

A. 왜 그럴까? 를 생각해봄. 요구사항 변경보다 테스트코드 자체가 잘못 짜여있는 경우가 있다. 그럼 요구사항이 변경되었을때 테스트코드를 많이 변경해야한다면 설계가 제대로 되어있는지를 생각해보자. 설계를 개선하고 테스트코드를 새로 짜야한다. 시간이 없으면 뒤에 절대 시간은 나지 않는다. 전문가라면 싸워서라도 시간확보를 해서 고치자. 나중에는 오지 않는다.

세션3. 코드품질을 위한 테스트주도 개발 - 한상곤

• 코드레벨의 품질을 지표로 측정하고 현장에 적용하는 일을 하고 있음. 티디디,클린코드 관련 사내교육을 하면서 이 자리에 서게 됨

• 지금 당장 중요하지 않아보이는(동작하는데 필요없어보이는) 것들로 괴롭히는거 아니야? 할 수도 있음.

• 중요하다고 알고 있지만 우선순위에서 밀리는게 현실임

• 정량적인 코드품질 측정에 대해서 깊게 생각해본 적이 없는데 여러 코드품질 측정요소에 대해 보면서 어떤 걸 코드품질의 중점적인 요소로 생각하는지 알 수 있었음

TDD는?

• Red -
• 리팩터의 대상은 테스트코드도 포함이다.
• 스펙 정의 후 디자인 Design by example
• 스펙에 대한 구체적인 사례, 예제를 가지고 테스트코드를 만들고 적용

TDD의 세가지 룰

테스트의 장점

• 두가지 관점으로 나누어서

• 리팩토링(외부에 대한 기능 개선 없이 내부 개선)을 하는 도구

• 테스트코드 작성 자체에 대한 의미가 있음. 테스트 코드를 작성하면서 프로그램의 이해도가 높아짐

• 테스트를 하는 건 많은 노력과 공수가 필요함. 장기적인 관점에서는 개발생산성이 높아짐

• 빠른 피드백을 받을 수 있음

• 디버깅에 대한 수행시간이 거의 없어짐.

  • 보통 오류 재현이 어려운데 테스트코드가 있으면 이걸하기 쉬워짐

• KATA?

• 과정을 설계하고 테스트코드를 만듦.

• 테스트 커버리지 와 품질 관계 - sonarqube 예시

  • 오픈소스를 대상으로 분석한 것이기 때문에 프로덕트 코드가 아니라는 거 참고

Think about more TDD

• 소프트웨어 품질이란?
• 보통 funtional qualiity 에 집중하는 경향이 있는데 external~ 과 함께 internal~도 중요하다
• 서비스의 규모가 커지고 사용자의 요구사항이 점점 늘어날수록 internal qualluty 도 중요하다

7가지

• '적절한' . 코드로 커버가능한 건 주석말고.

code quality Metrics

• 신기. 궁금했는데 특히 결합도와 응집도에 대해서 개념적으로만 이야기를 하고 실제로 어떤 기준이 있는지 확인할 수 있었음.
• 프레임워크를 사용하면 복잡도가 낮음 (복잡도 전가)

전설의 개발자

• 요구사항에 충실하게 작성하고, 주어진 요구사항이 변경되었을떄 그떄 변경하라

노트

• jetbrain - MPS

TDD 를 성공하기 위헤 하는 고민들

테알못 신입은 어떻게 테스트를 시작했을까? - 이혜승

• 테스트하기 쉬운 코드 어려운 코드를 구분하는 것부터 쉽지가 않음 - 동의, 목업 만들고 할때 엄청 헷갈렸음.
• 테스트하기 쉬운 코드로 먼저 시작하자 like 순수함수
  • 유틸리티성 함수로 시작하는게 처음 접근하기 쉽다
• 기존 코드에 테스트 도입하기에 대한 내용
  • TDD 로 작성하거나 기능테스트 정도로 테스트를 작성했었음.
  • 자연스럽게
• 원래 코드를 건드리지 않고 -> 테스트 코드를 만든다 -> 테스트코드를 건드리지 않고, 리팩토링한다
  • 한번에 하나씩 이라는 내용이 반복적으로 나온다. 동사에 다 하지말고 단계별로 나눠서 설명한게 인상적이었다.
• 공감이 많이 됨
• 오픈소스나 보통 테스트코드를 보고 파악하는데, 스펙문서기능. 사내 스터디하면서도 어떻게 테스트코드를 활용하는가에 대해서 이야기를 나눴었는데, 기능파악(지금 회사에서는 테스트코드를 만들어져있는 경우가 거의 없다)할떄 테스트코드부터 만들고 시작한다는 이야기를 했었음.
• 테스트가 단언하고 있는 내용이 사용자에게 가치없을때 테스트 하지 않는다

노트

• 컨퍼런스나 세미나 가면 멍~하고 있는 경우도 많은데, 이번 세션은 들으면서 공감하는 부분도 많아서 편안하고 재밌게 들을 수 있었다. 그동안 내가 듣는 세미나 수준이 너무 높은게 아닌가 하는 생각이 들었음.
• 자바스크립트라서 알긴 아는데 현업에서 잘 테스트안하는 부분이라서 예사에 대한 흥미가 좀 떨어졌다.
• 검증력이 떨어지는 테스트의 경우를 나눠서 설명함. 예를 들면 테스트코드가 여러 가능성을 열어두고 있다라던가
• 어떤 부분에서 테스트 빈틈이 셍기는지 - 예. 테스트 제목과 검증의 불일치
• 공감포인트가 넘 많았음
• 테스트 데이터가 길어진다 이걸 어떻게 관리해야할까?

테스트를 돌보기 위한 매우 간단한 실천 방법들, 그리고 효과 - 양완수

• 테스트코드 귀찮다. 릴리즈 시간은 다가오는데 테스트코드 언제 만들고 있나, 비자발적인 테스트코드 만들기 등등
• 예전에 고민했엇던건데, 하나의 테스트코드 클래스에서 setup 메소드가 너무 길어지는 경우 - 주로 여러 인스턴스를 만들어내고 설정을 하기 때문에
• 응집력이 떨어지는 helper method를 변경함. 적절한 helper method 사용

마지막 세션. 당신들의 TDD가 실패하는 이유 - 이규원 연사

• 많은 경우 충분히 준비되지 않은 상태에서 시작한다

우리가 보호해야하는 것

• 비즈니스 핵심인 도메인

우리가 제어할 수 없는 것

구현테스트

• Mock 잘못 쓰면 이런 식(실제 코드는 동그라미 인데 테스트코드는 네모)의 테스트케이스가 많이 일어남
  • 리팩토링할 설계

Information Hiding

• 단순히 getter,setter 라는게 아니다
• 테스트는 인터페이스만 가지고 설계를 한다

팀이 TDD 에 실패하는 이유

• 고민되는 부분임
• 가능한 이른 시점에서 실패하자

반복주기

• 계획,실행,평가 : 실행만 함

• 목표를 공유

도메인모델 - 플랫폼

• 기승전스프링? 도메인모델과 플랫폼을 분리하자. 예를 들면 카프카와 비즈니스 로직이랑 분리하자는거다
• 도구에 대한 디펜던시를 줄이자

노트

• 사용자에게 어떤 가치를 전달할 것인지에 대해 구체적인 목표, 가치가 유용할 것이라는 근거가 있어야함
• 지금 개인프로젝트 UI 스토리보드를 시연자료처럼 플로우를 그리는거를 적용해봐야겠다
• (동일주제로 듣는 강의에서) 내 집중력은 몇 분이 한계일까?
• QnA 질문 답변 좋았음
  • 페어링
  • 요구사항 태스크 나누고 테스트하기
  • 단위테스트만으로는 불안할 수 있다. functional test 등의 테스트도 추가로 함

패널토의

참고자료

• 정진우님 블로그 참고
• 참고도서 by 정진우 연사님
  • alter unit test
  • xUnit Patterns
    • 실제 테스트하면서 겪는 어려움 맞게 만들고 있나? 이런거를 확인하고 더 나은 방법을 찾을떄 도움이 되었다
  • Goo?
• 책 - 리팩토링(마틴 파울러 저)
• 책 - TDD(켄트 벡 저)
• youtube에 refactoring TDD + kata 검색
• 테스트는 종합적(디자인 패턴 등등)으로 파악해야 좋은 테스트가 가능. 애정과 열정을 가지고 정진하자
• 레거시에 대해
  • 어떤 레거시를 처리할 것인가?
  • 개발자들 일할때 ROI 를 생각하자. 비즈니스적으로 가치가 있는지를 판단해야함
  • 사람들이 고쳐야한다는 걸 공감을 하느냐? 앞으로 지속적으로 혜택을 받을 수 있나? 를 기준으로 잡자
    • 소마왕 대마왕 사례