OKKYCON 2018 참석 후기

 회사에서 세미나를 간다고 하니 직접 발표 하냐고 해서 "언젠가 발표할거예요."라는 생각을 하면서 어떤 연차에 이런 발표를 할 수 있는 사람이 될까 싶었다. 그러나 '테알못 신입은 어떻게 테스트를 시작했을까?'라는 세션에서 신입이어도 자기 삽질기와 현재 궁금한 점을 세마나 한 것을 보고 '아 나도 지금 시점에 언제든 발표할 수 있구나'라는 생각을 하면서 언젠가 이런 세미나에서 발표할 날들을 기다리게 된다.

 

 여기서 가장 인상적인 건 역시 자바지기라는 명칭을 가지신 박재성님 어떠한 세미나 세션보다도 짧지만 강렬한 임팩트를 주었다. 아침마다 TDD를 할 때 문자열 계산기라는 문제를 푼적이있는데 사실 설계하고 자신이 없는 정규식에 들어가면서 TDD실습이 힘들었다. 어떠한 방식이냐면 아침마다 30분씩 TDD를 한다. 세명 이서 하다 보니 실시간으로 코드 공유가 필요했고 처음엔 AWS Cloud를 할 생각 이였으나 세팅과정이 오래 걸려서 좀 더 간단하지만 하드한 방법 Team Viewer를 두명씩 원격접속하고 5분간 턴하는 방식으로 진행하였다. 나머지 한명은 행아웃 화면공유로 TDD를 하였다. 이걸 매일 아침 반복하다보니 세팅하면서 대기시간이 생기고 또 그러다보니 다시 루즈해진상황. 그래도 우여곡절 끝에 문자열 계산기를 마무리했고 이걸 만들 긴했는데 현업에선 어떻게 써야하나 이런 생각만 들었다.

 

'의식적은 연습으로 TDD, 리팩토링 연습하기' by 박재성

TDD는 Test Fails, Test passe, Refactor 이과정이있는데 처음 시도하기 위해선 여유를 가지고 토이 프로젝트와 Test Fail, Test passed 먼저 하자

Test Fails, Test passes, Refactor 보기에는 엄청 단순하지만 test fail과 test pass 이것만 연습하자. 리팩토링 한번에 한려면 힘들다.라고 하셨다.

그러면서도 리팩토링에 대한 규칙 또한 빼놓지 않으시고 알려주셨다.

 

리펙토링 규칙

1 메소드 분리 후 클래스 분리

1. 리팩토링은 기능상 변경은 없어도 좀 더 읽기 좋은 코드로 변경

3. 한 메서드에 오직 한 단계의 들여쓰기만 한다. 메서드를 분리한다.

4. else를 쓰지 마라.

5. 로컬변수가 정말 필요한가? return 문에 바로 넣기.

6. 한 번에 모든 원칙을 지키면서 리팩토링하려고 연습하지 마라.

7. 한 번에 한 가지 명확하고 구체적인 목표를 가지고 연습하라.

8. 메서드를 15라인 -> 10라인으로 줄여가면서 연습하는 것.

 

cf) 객체지향 생활체조, http://refactoring.com/category 로 참조해서 좀 더 규칙을 세세하게 작업해보자!

 

연습하기 좋은 예.

[] 로또

[] 사다리 타기

[] 볼림 게임 점수판

[] 체스 게임

[] 지뢰 찾기 게임.

 

TDD연습을 위해선 같은 과제를 반복적으로 구현할 수 있는 인내력과 가보지 않는 길에 꾸준히 도전할 수 있는 용기가 필요하다고 말한다.

 

현업에선 이제 새로운 사업이 아닌 유지 보수 능력도 중요하게 보고 있다고 한다. 그래서 1~2년만 친구들 덜 만나고 이거 하나만 노력한다면 그럼 성장하게 되어있다.

 

"압박감이 있으면 창의적인 생각이 안 떠오른다."라고도 말씀하셨다. 이 말에 공감이 된 건 퇴근 시간되는데 다른 사람들은 퇴근하고 기한이 임박한 작업이 남아있으면 초조함이 생겨서 작업에 집중이 안 된다.

그럴 때 최근에 했던 방법은 일단 집에 가면서 설계를 다시 시작한다. 이 로직엔 이런 방식이 필요해. 얼마나 걸릴까? 어떻게 구현해야할까? 한 가지씩 해볼까? 이런 생각 후에 다시 집에 가서 작업하면 훨씬 작업을 능동적으로 하게 되었다.

TDD를 통해서 창의적인 생각이 생겨서 좀 더 좋은 개발자가 되고 싶다.

 

Q&A

Q: 현업에선 당장 소스 수정이 필요하게 되는데 이럴 때 테스트 케이스가 다 꼬여서 못 하게 된다. 이럴 떤 어떻게 하시나요?

A : 이러한 상황 자주 발생하게 된다. 그러나 테스트할 항목이 꼬이고 테스트가 잘 못 되어있다면 요구사항 변경이 문제이다. 당장 급한 불 끄고 다음에 Test코드 고치자 이러면 다음엔 시간은 절대 안 하게 된다. 따라서 싸워서라도 전문가로써 시간을 확보하는 형태를 설득하여 테스트 케이스 확보시간 갖는 게 중요하다.

 

'코드 품질을 위한 테스트 주도 개발' by 한성곤

 

이걸 코딩하려면 어떻게 하는가?

*

**

 

보통사람들은 for문을 돌려서 사용을 한다. 그러나 초고 수는 prints로 처리한다.

이러한 게 TDD라고 생각한다. 이걸 구현하기 위해서 처음엔 임의의 테스트 값을 넣고 실행하여 결과물을 본다.

 

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

인상적인 건 Test케이스를 작성할 때 테스트할 때 필요 없는 것도 만들었던 과정이 인상적 이였다. 테스트에서 중요하지 않는 사항은 나중에 PPT나오면 다시 설명할 계획이다.

 

'당신들의 TDD가 실패하는 이유' by 이규원

다른 사람들이 TDD를 사용하지 않더라도 혼자서 꾸준해 해왔다 그리고 레거시 코드가 있는 상태에서 개발하게 될 때, adapter형태로 묶어서 진행한 방식이 와 닿았다.

그리고 Spring이라는 프레임워크에 종속되지 말고 예를 들어 'Spring엔 이러한 디자인 방식이 필요해'라고할 때 도메인 모델을 플랫폼과 독립적으로 진행하자.

작업을 시작하기 전에 목적을 먼저 두고 그림을 그려서 서로 커뮤니케이션을 하고 설명을 하다가 비지니스 로직에 문제가 있다면 거기에 다시 문의를 하고 진행해서 원초적으로 문제 된 걸 제거하고 서로 협의하여 진행 하고 있다.

 

Q&A

Q: 주니어 개발자 코찔찔이가 어떻게 스페셜 쥬니어로 될 수 있었던 것은?

A : 페어프로그래밍이 가장 효과적이였다. 또한 코딩 페어프로그래밍 뿐만 아니라 태스크를 아주 작은 단위로 페어링하면서 스페셜 주니어로 성장하게 되었다.

 

 훌륭한 세미나였다. 반면에 이 세미나에서 아쉽고 개선되어져야 할 부분이 있다면 세미나 준비가 전날 혹은 당일 날 급하게 준비했다 라는 강의자의 말이 좀 실망스러웠다. 내가 급하게 준비한 세미나를 듣기위해서 시간을 낸건 아닌데 조금 더 준비를 성실하게 준비해주면 좋을 것 같다.  그리고 라이브코딩만 있어서 다같이 실습해보는 것도 있으면 재미있을 것 같다.