[세미나]OKKYCON: 2018 TDD 제대로 알기

알림: 다른분들 강의정리 및 자료가 올라오면 참조합시다.

session1. 테스트하기 쉬운 코드로 개발하기 (정진욱)

EOS블록체인 미디어서비스를 개발하시는 분.

테스트하기 쉬운코드?

  1. 같은 입력에 항상 같은 결과를 반환 (유저ID 조회 등 변수가 있다면 테스트하기 어렵다.)
    DETERMINISTIC
  2. 외부상태를 변경하지 않는 코드
    NO SIDE EFFECTS

테스트하기 쉬운코드로 개발하기

c# 기준으로 설명되어있지만 혹시 놓친다면 스토리만 따라와도 충분

방법 1. 테스트하기 쉬운코드와 어려운 코드가 섞여있는 경우에는?
간단하다. 분리하라. 애초에 하나의 함수가 하나의 기능만 동작하게 코딩하면 해결될듯?

TDD 맛보기를 통해 점진적으로 테스트하는 예제를 하나 보았다.

방법 2. 두 부류의 코드(HARD AND EASY)는 어디서 만나야하나?
두 부류의 코드는 최대한 가장자리에 위치! 메서드 내부에 테스트하기 어려운 코드가 위치하면 테스트하기 쉬운 메서드도 테스트하기 어려워진다. 따라서 최대한 바깥부분에서 만나도록해야 테스트하기 수월하다.
방법 3. https://jwchung.github.io/testing-oh-my 참조
테스트하기 쉬운코드와 어려운 코드가 섞여있는 경우 분리하라.
  • 팁: 두 부류 코드를 분리해서 각각 테스트하고 가장자리에서 맞물려 돌아가는 코드는 주로 수동테스트를 진행하신다고 합니다.

목(Mock) 사용

  • 작성된 코드를 강제할 수 있다
  • 장점같지만 생각할 것이 많다. (어떤 녀석을 호출했느냐에 중점을 두게됨)
  • 행위검증의 대표이지만 불필요한 추상화를 유발할 가능성이 있다.
  • 단점. 목을 남발할 가능성이 있으며 적당 수의 목 사용에 대한 답을 찾기 어렵다. (실제 프로젝트에 적용하기 힘듦)

  • 수동테스트:

  • 자동테스트: 상태검증/행위검증

Q&A

  1. private 메서드를 테스트하는 경우 보통 어떤 방식으로 진행?
    테스트를 할 때 대상코드와 접촉하는 면적이 작으면 작을수록 좋다. ..
  2. 레거시코드를 활용해서 리팩토링할 여유가 없을 때 TDD를 적용하는데 목업을 많이 활용한다. 해결할 방법은?
    우선 최대한 레거시코드와 결합도를 낮춘다. 예를들면 인터페이스를 넣고 목업을위한 SEAM을 넣는다. 캐릭터라이제이션(기존에 작성된 코드를 요구사항만 작성하고 진행하는 테스트)

session2. 테스트하기 쉬운 코드로 개발하기 (정진욱)

강의자료 참고! 초반내용있었음 TDD < 리팩토링 일수도 있다.

무조건 연습할 수 있는게 아니다. 테스트하기 쉬운,어려운 코드를 분리하는 능력을 갖추는데 꽤 오랜시간이 걸림.

따라서 어떻게 연습해야하는지를 알려주는데 중점.

1단계: 단위테스트 연습

  • 사용하는 API 사용법을 익히기 위한 학습테스트에서 시작
    • 딱 내가 요수준인거같다.

2단계:

일급콜렉션: 콜렉션을 wrapping하라.

Q&A

  1. 강사님의 컴포트존을 극복하는 방법
    나이, 경력이 찰수록 어렵다. 삶에 여유와 시간이 있어야함. 상당한 스트레스를 주는 활동이므로 에너지와 시간이 있어야 한다.
  2. 테스트코드를 잘 짜고 정상적으로 돌아가는 경우에서 요구사항 변경으로 코드를 변경하야 하는 경우 테스트 코드가 발목을 잡는 경우가 있다. 어떤 방식으로 극복?
    결과적으로 테스트코드를 잘못짠 것. 설계가 잘못된 것이 아닌가라고 거꾸로 생각해볼것

session3. TDD for Code Quality (삼성SDS 한성곤)

강의자료 참고! 초반내용있었음 TDD < 리팩토링 일수도 있다.

session4. TDD 후기(오마이호텔 ~~~)

session5. 테스트코드의 가독성(쿠팡 양완수)

좀 다른내용이네!

개발자의 일상은 문제 해결의 연속 이다. 그 문제 해결을 위해서 구글링은 필수. 그 구글링을 잘하는 법에 대한 힌트가 있을까하여 세미나에 참여했다. 김환규님께서 세미나를 통해 얻고 싶은 것을 물어보셨는데, 그 중에 나는 디버깅을 효율적으로 하는 법, 검색 방법에 대한 구체적인 팁, 그리고 검색되어 나온 결과를 잘 적용하는 법에 대해 알고 싶었다.

문제 해결을 하는 법을 말함에 앞서, 김환규님의 ‘질문’과 ‘답변’에 대한 철학을 간단히 들을 수 있었다. 김환규님은 질문자에게 항상 고맙다고 한다. 혼자서는 1000가지의 질문을 할 수가 없는데, 여러 사람의 질문을 통해 늘 새로운 주제에 대해 탐구할 기회를 얻게 되고, 그 질문에 답을 함으로써 자신의 실력을 키울 수 있게 되기 때문이라고 한다. 매번 다른 문제에 대해서만 답변을 하신다고. 김환규님은 문제를 해결하는 과정 자체를 즐기는 분이라고 느껴졌다. 김환규님이 스스로 말씀하신 내용 중에도 초보란 경험이 부족한 사람이지만, 문제 해결에서 즐거움을 느낀다면 충분히 고수가 될 수 있는 새싹이라고 표현하셨다.

세미나를 진행하기 전 받은 사전 질문에 대해 말씀해주셨다. 거기에서 이 세미나를 통해 답을 줄 수 있는 것과 없는 것에 대해 설명해주셨는데, 대체로 플랫폼에 특화된 답이 필요한 부분들 - 에러 메시지를 제대로 읽고 활용하는 법, 디버깅 시간 줄여주는 법과 같은 - 은 이번 시간을 통해 답이 어렵고, 공통적으로 적용이 가능한 ‘구글 검색에 대한 노하우와 디테일한 팁, 문제를 파악하고 해결 방법을 찾는 법, 알고 싶은 내용을 효율적으로 검색하는 법, 많은 정보 중 좋은 정보를 선별하는 법, 무엇을 모르는지 모르는 상황에서도 효율적으로 검색하는 법 등등’의 질문에 대한 답을 제시하겠다고 하셨다.

problem

다음의 내용은 철저히 김환규님의 경험에 의거해 도출된 ‘문제 해결에 대한 가설’ 이다.

  1. 과거에 알았던 것은 전부 잊어라. 현재 기술의 트렌드는 빠르게 변한다. 따라서 과거에 알았던 지식과 경험들이 시간이 지나면 도리어 방해가 된다. 과거의 것은 깨끗이 잊고, 새로이 검색하고 새로이 익혀라.
  2. 문제를 해결하는 과정은 문제의 본질을 이해하는 과정 이다.
  3. 모든 분야를 다 잘하는 사람은 없다. 외국의 경우, 특정 분야를 깊이 있게 다룰 줄 아는 사람들이 무척 많다. 그에 비해 한국은 이것저것 다 잘하는 사람이 많이 필요한 실정이다. 한국에서 개발을 하다보면 다양한 것을 해야할 상황이 올 것이다. 조급해하지 말고, 한가지 분야를 한번이라도 깊이 다뤄본다면 그것이 다른 분야를 익힐 때에도 도움이 될 것이다.
  4. 키워드(검색)를 많이 알게 되는 것은 영어를 잘하는 것과 유사하다. 지속적으로 꾸준히 노력해 키워드를 찾아가야 한다.
  5. 해결책을 금방 알 수 있다면 어려운 문제가 아니다.
  6. 문제마다 해결시간은 차이가 많이 날 수 있다. 그러니 모든 문제를 빨리 해결하겠다는 것은 맞지 않는 전제다. 문제 해결 과정 자체를 즐겨라! (김환규님은 무려 7개월을 질문에 답을 하기 위해 고민하신적이 있다고...)
  7. 검색 후 나타나는 답을 순차적으로 적용하지 말 것! 처음 나온 답변을 적용하느라 고생했는데, 잘못된 해결법인 경우 시간낭비! 몇가지의 방법을 찾은 후, 그 중 가장 반응이 좋고 정리가 잘 된 답변을 골라 적용 하는 것이 결과적으로 빠르다.

※참고 : ‘좋은 답변을 선별하는 방법’

  • 불성실한 답변자의 답변은 무시하라. 코드 한줄 없이 잔소리만 하는 경우, A to Z가 아닌 A to C까지만 답하는 경우, 시도해보니 되지 않아 다시 질문을 남겼는데 그 이후로 답이 없는 경우 등이 이에 해당 - 질문자를 존중하는 답변자를 찾아라.

예측은 하지 말고, 철저히 증거를 따라가라!

문제를 해결하는데 있어서 가장 중요한 것은 현학적인 예측은 버리고 철저히 증거주의를 따르라는 것이다. 우리에게 가장 큰 증거는 Error Message다. 그 Error Message를 그대로 활용하자. 또한 영어로 검색할 경우, 그 검색 결과는 백배 더 많다는 것을 기억하자. 이 영어 키워드를 찾고 배치하는 것이 구글링을 잘하는 첫번째 팁이다.

더 좋은 해결책을 찾기 위해서는 영어식으로 사고하는 것이 도움이 된다. 처음에는 잘못된 단어로 검색을 하더라도, 제시된 답변들을 잘 살펴보면 올바른 키워드를 찾아낼 수 있다. 영어로 질문하면 답변이 영어일 것을 두려워 할 필요는 없다. 영어로 질문해도 번역 기능이 활성화 되어 있기 때문에 해당 답변에 대한 한국어 답변도 많이 올라와 있다.

※원하는 결과를 얻어낼 가능성이 높은 검색어 구성※

“언어 + 타게팅 플랫폼 + how to + 원하는 기능”

ex.

  1. Visual studio how to export a project into another name
  2. C# how to split a string
  3. LINQ how to get query count

※원하는 내용과 일치되는, 보기 좋은 답변을 찾아내는 방법 ※

“Stackoverflow의 SEO(Search engine optimization)기능을 활용!검색어의 맨 앞에 ‘Stackoverflow’를 추가”

ex. Stackoverflow linq join with group by nested query

Stackoverflow의 설명이 가장 정확한 편이라, 그 안에서 답을 찾지 못한다면 다른데서 찾기 힘들것이라고 한다.

※그래도 원하는 답변이 나오지 않을 경우※

  • “더 큰 유사 플랫폼을 검색”
  • ex. OpenCV의 경우, windows나 unix 기반으로 출발한 플랫폼이다. 최근 안드로이드나 iOS가 나오면서 openCV for android, iOS가 나온 것. 따라서 똑같은 질문에 대한 답이 없으면 더 큰 플랫폼에서 검색하고, 해당 함수와 똑같은 함수를 reference에서 찾아서 사용할 수 있다.

※원하는 답변을 찾기 위해 올바른 키워드로 진화해가는 과정의 예시※

“목표 : 메모리 사용을 줄이기 위해 glide 라이브러리 활용하는 법”

  1. Android how to use glide
  2. Stackoverflow android how to use glide
  3. Stackoverflow android how to use glide for drawable
  4. How to handle memory with glide
  5. Android glide how to reduce memory usage
  6. Stackoverflow android glide how to reduce memory usage
    • 최종 : Recyclerview cardview glide android sample
    • 처음과 달라지는 키워드들이 보이는가? 키워드 검색을 통해 얻어낸 답변들에서 내가 원하는 결과를 얻기 위한 키워드에 대한 힌트를 연속적으로 얻어낸다. 그러다보면 내가 원하는 결과를 얻게 해줄 답변을 찾아낼 수 있을 것!

아직 시도해보지 않은 과제에서 어려워 보이는 문제. 어떻게 해결할까?

개발에 들어가기 전, 어떠한 기술을 활용해 개발을 해야할지, 혹은 어떠한 방법으로 당면한 문제를 해결할 수 있을지 고민이 될 때가 있다. 그럴 경우, 해당 문제를 해결한 케이스를 먼저 찾아본다. 충분히 몇시간, 혹은 몇 일을 소비해서라도 검색에 공을 들인다. 검색된 케이스 중 가장 책임감 있어보이고, 실제로 실행해 보았을 때 실행이 되는 케이스를 뽑는다. 그렇게 추려진 케이스들이 최종 후보가 된다. 이 작업은 기본적으로 시간이 꽤 걸리는 작업이라는 것을 염두해두자. 추려진 케이스들로 프로토 타입을 제작해본 후, 서비스를 개발하자.

키 포인트는 다양한 대안을 마련하라는 것 이다! 첫번째로 발견한 솔루션이 있다고 해당 솔루션으로 성급하게 개발하면, 더 나은 해결책이 제공해 주는 기술적인 이득을 포기하는 것이다. 또한, 가급적 심플한 대안을 선택하는 것이 좋다. 고심 끝에 적용한 솔루션에서 특정 기능이 동작하지 않으면 또 다른 솔루션을 고려해야 할 상황이 올 수 있다. 되도록 심플한 솔루션일수록 수정이 편하다.

Note: 다음 2편에선 ‘답변자는 답변을 해줌으로써 얻는 이득이 무엇인가!’,’개념이 잘 잡히지 않는 기술을 어떻게 정확히 익힐 것인가’,그 외 세미나 참여자들의 질문에 대한 답변으로 이루어진 팁들을 정리해보고자 한다.

2편

지난 번 1편에 이어 마저 담지 못한 이야기들을 2편을 통해 담으려 한다. 지난 1편에서는 문제 해결의 단계, 실질적인 구글 검색 노하우와 해당 케이스, 좋은 답변을 찾는 법, solution provider가 되기 위해 지니고 있어야 할 마인드에 대해서 이야기했다. 이번 2편에서는 답변자들이 답변을 통해 얻는 이득, 개념이 잘 잡히지 않는 기술을 정확히 익히는 법, 참여자들의 질문과 답을 정리해보고자 한다.

강연의 이유

꼭 개발에 한정된 이야기는 아닐 것이다. 인터넷 세상에서는 ‘질문하는 자’와 ‘답변하는 자’로 나뉜다고 해도 과언이 아닐만큼 수많은 정보를 찾는 사람과 제공하는 사람들이 존재한다. 예전에 나도 이런 생각을 했었다. 도대체 이 사람들은 왜 이렇게 다른 사람들이 궁금해 하는 것에 대한 답변을 해주는 것인가, 혹은 왜 자신이 알고 있는 정보를 시간과 에너지를 써가며 올리는 것인가.

사람들마다 그 목적은 다를 수 있다. 김환규님이 답변을 하게 만드는 원동력은 ‘자신의 실력을 키우는 방법’ 의 하나라고 여기기 때문인 것으로 느껴졌다. 1편에서도 언급했듯, 김환규님은 자신은 미처 생각하지 못했던 질문을 올려주는 이들에게 고마움을 느낀다. 왜냐하면, 자신은 하지 못한 고민을 그들의 질문을 통해 하고, 이로써 더욱 많은 것을 탐구하고 알아갈 수 있는 기회를 얻기 때문이다. 스스로 고민해 보지 않는 한, 질문자는 계속 질문자로 남아 실력을 키울 수 없고, 답변자는 계속해서 더욱 잘하게 된다. 회사 내에서도 마찬가지. 계속해서 문제 해결을 하는 사람이 실력이 올라간다. 이것은 내가 얼마전 면접 때 들었던 한 대표님에게서도 들었던 이야기이다. 그 대표님이 회사를 다니던 시기, 아무도 하고 싶지 않아하는 어려운 문제를 맡아 해결하는 과정을 통해 실력을 쌓을 수 있었고, 그것을 인정 받아 많은 연봉을 받고 높은 지위도 얻을 수 있었다고. 그래서 자신이 제일 중요하게 여기는 것은 다른 무엇보다 배움, 그리고 어려운 문제를 스스로 해결해보려는 의지라고 했다.

그래서 이들은 조언한다. 10가지의 문제에 닥쳤다면 딱 1문제만이라도 자신이 스스로 해결해보라 고. 날밤을 새더라도, 몇날 며칠을 고민하더라도 해보라고. 설사 그 문제가 해결되지 않더라도, 그래서 결국 다른 사람에게 물어보게 되더라도 스스로 고민하고 해결하려 시도 했느냐 아니냐는 큰 차이가 난다고 말한다. 처음에는 1가지의 문제로 시작하다가 점차 범위를 넓혀나가다 보면, 어느새 나도 누군가의 문제를 대신 풀어줄 수 있을 만큼의 실력자가 되어 있을지도 모른다.

생각: 묻지만 말고, 스스로 해결해보자. 쉽게 풀릴 문제는 문제도 아니다. 어려우니 문제다. 내가 어려우면 다른 사람들도 어렵다. 시간이 걸리는 것을 두려워 말자.

개념이 잘 잡히지 않는 기술을 정확히 익히는 법

기술은 변한다. 새로운 개념은 계속해서 나온다. 그러나 그 개념을 정확히 이해하기란 쉽지 않을 때가 많다. 어떻게 하면 이 개념들을 잘 익힐 수 있을까? 처음 접하는 개념, 기술을 최대한 정확하게 익히기 위해서 초반에는 조금 더 공을 들여야 하는 것 같다. 김환규님의 방법은 이러하다. 일단 처음 시도해보는 기술의 경우 무작정 쓰기보다는 쓰기 전 해당 플랫폼이나 기술을 왜 쓰는지, 어떤 장점이 있는지 등등을 최대한 이해하려 노력한다. 그 방법중의 하나는 유투브 동영상 강의를 찾아보는 것이다. 팁은 이와 같다.

  • 컨셉 이해를 위해서는 초보를 위한 강의를 들어라. (김환규님이 즐겨듣는 어떤 강의자의 경우, 깊은 내용과 기술을 다루지는 않지만 초보적인 지식을 짧게 전달함으로써, 그 컨셉을 익히기에 좋았다고 한다.)
  • 동영상은 3~5분 이내에 어떤 샘플이 돌아가는 형태를 찾아라. 따라했을 때, 동작하는 형태로 끝나는 것. 한시간짜리는 지루해서 다 보지도 못하고 따라하지도 못한다!
  • 대체로 좋은 강의는 영어로 이루어지는 것이 많다. 유투브 자동자막 기능(ASR. Automatic Speech Recognition)을 활용해라.
  • 직접 타이핑하라. 툴을 활용하지 말고, 손수 하나하나 타이핑하고 적어보는 것이 좋다. 구조적인게 파악이 되면 기본 베이스가 쌓이면서 응용력이 생긴다.
  • 자신 있는 언어의 경우에도 훌륭한 강의들이 많다. 해당 언어를 사용하는 새로운 트렌드에 대한 강의도 있으니, 꾸준히 찾아보고 공부할 것.

Q&A

Q1.개발시 작성하면 좋은 문서들의 샘플을 얻기 위해 검색해 본 적 있으신지?

A) 사람이 적은 개발 환경에서는 효율성이 중요하다고 생각한다. 따라서 주로 공유가 필요한 부분들만 구글닥스나, 구글 슬라이드로 간단히 작성해 공유하는 편이다. 특히나 내가 참고한 링크나 검색했던 키워드 같은 것들 위주로. 일정 관리는 아사나(ASANA) 나 인스타간트(Instagantt) 툴로 관리한다. 프로젝트의 프로세스를 보여주기 좋아서 쓴다. 디자이너와 커뮤니케이션 하는 경우, 제플린(Zeplin) 을 즐겨 쓴다. 어떤 요소를 수정해달라는 요구를 할 때, 만나서 하지 않아도 되게 해주는 툴이라 생각한다. 리포트가 중요한 프로젝트의 경우, uml 도구로는 스타UML(StarUML) 을 활용하고, DB 툴로는 ER-Diagram을 자동으로 만들어주는 DBeaver 를 쓴다.

Q2. 오픈소스 적용 시 책임 소재 때문에 선택 시 소심해진다. 오픈소스 적용의 기준은 무엇인가?

A) 쓰는 것을 두려워 하기 보다는, 처음 고를 때 사용자들의 선호도를 최대한 고려한다. 그러나 고민보다는 적용을 해보는 게 빠를 수도 있으니, 써보고 그 느낌을 느끼고 쓴다. 해당 오픈 소스를 적용해 개발했는데 중간에 요구사항이 바뀌었고 해당 오픈소스는 요구사항을 적용할 수 없을 경우, 요구사항을 받지 않거나 먼저 쓴 것은 나중에 도움이 될거라 생각하고 새로운 오픈소스를 찾아 적용한다. 새로운 오픈소스를 빨리 적용하려면 최대한 많이 써봐야 한다. 그 속도를 높이는 것이 중요하다 생각한다.

Q3. 답변을 다는데 7개월이 걸렸다는 질문은 무엇이었는지?

A)’Http upload, download 만드는 방법 설명해주세요….’였다. 당시 다른데에서는 돈을 주고 파는 것이었는데, 오픈 소스를 직접 만들어 무료로 풀어 좋은 호응을 얻었다.

Q4.답변을 달다가 회의감이 드는 경우는 없나? 예를 들면 답변을 해주었는데, 질문자가 도움이 되지 않는다고 불만을 갖는다던지…

A) 경험상 질문자가 만족하지 못하는 경우는, 내가 말을 너무 어렵게 했거나, 질문자가 따라해봤는데 되지 않는 경우라고 생각 한다. 코드가 백줄이면 설명이 백줄이어야 한다고 생각한다. 용어는 최대한 쉽게 쓰고, 화면을 일일이 캡쳐한다. 소스도 전체를 공개한다. 그럼 추가 질문이 거의 오지 않는다. (회의감은 들지 않으셨나봐요..ㅎㅎ)

태그:

업데이트:

댓글남기기

참고