기본 콘텐츠로 건너뛰기

3월, 2016의 게시물 표시
A/B Testing : Test Your Own Hypotheses & Prepare to be Wrong - Stuart Frisby at Booking.com Booking.com의 선임 디자이너인 Stuart Frisby가 2015년도에 O'Reilly 컨퍼런스에서 발표한 A/B 테스팅과 관련된 발표 자료에 대한 대략적인 설명입니다. - 왜 테스트해야 하는가? 1. 우리가 '좋다'라고 생각하는게 대부분은 틀린 경우가 많다. 2. 우리가 추가하는 feature들이 생산적이었으면 좋겠다. 3. 제품의 개발이 이루어지기 위해서는 고객들의 의견이 필요하기 때문이다. 4. 사실에 기반한 제품 생산을 원하기 때문이다. - 왜 테스트 하면 안되는가? 1. 아직 충분한 트래픽이 없을때 2. 아직 key metrics가 준비가 되지 않았을때 => 테스트에 대한 결과를 증명할만한 key metrics가 있어야 한다. 3. 당신이 어느 분야의 '전문가'라고 자처한다면 하지 마라. => 중립적인 입장에서 데이터를 통해 분석할 줄 알아야 한다. - A/B 테스팅의 일반적인 실수들 1. Big Shot AB Testing   쉽게 접하는 가장 일반적인 실수이다. 전체 페이지를 다 바꾸고, 모든걸 다 변경한 후에 테스트를 하고 나서 지표가 좋아졌다고 하더라도 정확히 어떤 요구사항을 만족시켜서 지표가 좋아졌는지 정확히 판단하기 어렵다. 2. Fringe AB Testing   명확하고 구체적인 것에 포커싱 해야 한다. sign up을 늘리기 위해서 landing page를 redesign하는 것도 좋지만이 business metrics에 기반한 분석이 가능하도록 목적을 명확하게 하고 좀 더 작게 테스트를 하는 것이 좋다. 3. Assumed Reproducibility   테스트의 결과가 다른 곳에도 똑같이 생산적으로 반영될 것이라고 생각하지 말아라. 햄버거 메뉴같은 경우에도 어...

[JAVA] 코딩시 고려해야 할 점 (작성중)

개인적으로 코딩을 하면서 문제발생을 야기했거나, 가독성을 해치는 코드를 만들었던 케이스들을 정리하고 지킬수 있도록 합니다. [한번쯤 생각해 볼만한 Coding Convention] AOP나 intercep등 횡단 관심사의 공통 처리 로직의 경우 최대한 가볍게 만든다. 다수의 query문이나 복잡도가 높은 로직을 실행할 경우 이슈가 발생할 소지가 높다. (게다가 이후에 성능문제가 발생했을때 찾기도 어렵다) switch~case나 try~catch 문등의 묶음 단위로 처리되는 구문안에 들어가는 행을 짧게 만든다. 로직이 길어질경우 break;를 누락하거나 return;문을 누락하는 경우가 매우 많다.한눈에 들어오도록 만들수 있도록 한다. (private나 적절하게 기능을 다른 class에 위임하도록) Controller -> Service -> Repository의 레벨은 될 수 있으면 지키자. 내가 만든 Service의 경우 (예를들면 MemberService)에 개념적으로 다른 부분의 영역을 호출할 경우 (예를들어 Profile)에는 Repository를 직접 가져다 쓰기 보다는 Service를 가져다 사용하도록 한다. CheckedException과 RuntimeException을 잘 구분해서 사용한다. 호출하는 쪽에서 복구처리가 필요하거나 반드시 재처리 해줘야 하는 경우에만 CheckedException을 사용한다. (CheckedException은 남용하지 않는다.) 기본제공되는 Exception을 잘 활용한다. (IllegalArgumentException등..) 다중 if문, 다중 for문은 지양한다. 다중 if문은 가독성을 낮추고(code complexity를 높인다), 다중 for문은 성능에 영향을 미칠 가능성이 높다. (기본적인 Collection 자료구조를 잘 활용하면 이중 for문은 거의 사용하지 않을 수 있다.) private안에 private메소드는 될 수 있으면 지양한다. ...