오늘 한일

• 포비가 구현한 볼링 코드를 봤다.

  • int 타입같은 primitive을 사용자로 부터 입력으로 받은 후 Pins 같은 타입을 만들어 사용하면 큰 이점이 있다. Pins 객체로 만들면서 입력 받은 값이 서비스에서 이용가능한 유효한 값인지 변환과정에서 확인 하고, 변환이 문제 없이 되었다면 이후의 작업에서는 해당 값이 문제 없는 값이라는 확신을 가질 수 있다. 대신 그만큼 변환과정에서 더욱 엄격하게 유효한 값인지 확인을 해야 할 것 같다.

  • 테스트 코드를 작성하면 작업자한테 생기는 장점들은 지속적인 작업으로 깨우쳐 가고 있었는데, 이번에 포비의 코드를 보면서 미처 깨닫지 못한 장점을 알았다.

  • 남의 코드를 볼때 해당 메소드가 무슨 일을 하는지 단순히 구현부만 보는게 아니라, 테스트 코드를 봄으로써 어떤 입력으로 어떤 결과를 수행하는지 더욱 명확하게 알 수 있다.
    그래도 될진 모르겠지만 경우에 따라선 구현부까지 볼 필요는 없고 전체적인, 혹은 메소드들의 동작(명세?)을 파악할때는 테스트 코드 위주로 파악해도 되지 않을까 싶다.

• 백엔드 과정의 멤버중 한명인 Brian이 aws의 lambda에 대해 강의를 해줬다.

• 체스 구현

오늘 느낀점

• 테스트 코드가 있다면 더욱 효율적으로 메소드들을 파악 할 수 있다는 점을 깨달았다. 빠르고 정확하게 메소드들을 파악한다는건 해당 클래스에 대해서도 빠르게 파악이되고 점점 범위가 퍼져나간다.
  즉, 코드 분석이 효율적으로 가능해진다는 거다. 남의 코드를 보고 분석하는 걸 좋아하는 지라 해당 사실을 깨닫고 오늘 하루종일은 기분이 좀 좋았던거 같다.

• 포비의 코드를 다 파악 하기전에 리뷰를 했던건 좀 아쉽다. 사실 내 코드나 내가 생각하기엔 아직까진 우리가 짠 코드는(모든 사람, 모든 코드를 다 보진 못했지만) 클래스간 결합도가 그렇게 낮았다고 생각되진 않는다.
  근데 이번 포비의 코드 같은 경우는 뭐랄까 결합도가 낮아서 클래스가 각각이 독립적이고 서로 필요한 자료만 넘기며 협력을 하는 느낌이였다. 사실 그런 코드를 많이 보지 못해서 그런지 새로 추가된 클래스들이 어떤 상태/속성을 담고 어떻게 협력하는지 꼬리를 잡는데 시간을 많이 뺏겼다.
  클래스간 관계를 구분 한다음 Score 클래스의 세부 구현을 분석하는 단계에서 리뷰를 하게 되었던거 같다.

• Brian의 lambda 강의 덕에 이전 aws 워크샵에서 따라 했던 내용들이 정리가 된거 같고 lambda가 무엇이며 어떻게 써야할지 알 것 같다.
  덤으로 최근에 슬랙봇 + 라즈베리파이로 서보모터를 조작하는 작업을 했던 경험도 이번에 lambda를 이해하는데 도움이 된거 같다. 일단 이론상으론 이해를 해봤고 만들어 볼려는게 있는데 주말에 시간이 난다면 해 봐야겠다.

• 오늘은 위에 두 좋은 경험때문인지 조금 들떠서 체스는 크게 신경을 못쓴거 같다. 핑계인걸 아니까 내일은 일단 체스 하자.

내일 할일

• 체스 하자

• 코딩테스트 환경 테스트

오늘 한일

• 볼링 구현 사항

  • 모든 사항을 완료하고 pr 보냄

  • 일부 메소드, 필드의 접근 제어자 수정

  • 코드 리뷰 피드백에 따른 개선 작업 진행 완료(마지막 작업은 수정 후 commit, push 이후 기본 branch로 진행했는데 이 부분을 다시 push하는 부분을 확인해보자)

• 이전 화이트 과정을 같이 이수 했던 분이 놀러와서 다함께 치킨을 먹으러 갔다.

오늘 느낀점

• 볼링이 생각 보다 오래 걸렸다. 이럴줄은 나도 몰랐는데… 초반에는 ‘엄청’ 잘짜고 싶은 욕심에 너무 진행을 못했고, 나중 가서는 걸린 시간도 있어서 그런지 크진 않았지만 압박감이 있었던거 같다.(스트레스를 받거나 힘들고 그런 정도까진 아니였다)

• 마지막 부분 구현하면서 느낀게 확실히 생각해보고 일단 짜보는게 중요한거 같다. 당연히 ‘적당한’ 고민은 해야겠지만 말이다. 이번 작업하면서 git 덕에 편했던게 git reset 을 통해서 작업하다 현재의 작업이 잘못 되었다는 걸 파악하면 가장 최신의 commit으로 돌아 가 다시 작업 할수 있었다.

• 볼링 작업을 하면서 Frame을 상속받는 클래스들을 만들면서 접근제어자를 잘못 쓴 부분들이 있었다. 그렇게 쓰면서 “음..이건 확실히 아닌거 같은데?? 일단은 되니까 이렇게 하고 로직 구현 부터 하고 나중에 바꾸지 뭐” 이런식으로 작업을 했다. 덤으로 양심고백 하자면 마지막 Result 클래스를 추가하는 부분에 대해서는 테스트 코드도 제대로 작성하지 않았다. 학습을 하면서 작은 것도 소홀히 하지 말고 배울때 제대로 배우고 해당 내용들을 적용하며 코딩 해서 좋은 습관들을 만들자고 다짐 했었다. 그런데 이번에 스스로가 의식적으로 안지켰다. 반성하자. 배우는 도중이니 쉽게 갈려고 하지말자 버릇 든다.

• 요번달엔 5~6번 약속이 있어서 저녁에 공부를 못했다. 특히나 요번주에 친구를 한번 더 볼 수도 있는데 버리는 시간 없이 좀 더 집중해서 작업해야 겠다.

• 요즘들어 웹에 관련된 지식이 없는거 같아 해당 부분에 대해서는 자신감이 떨어진다. 모르는 용어, 행위(?) 등이 너무 많다. 그러한 차원에서 aws 워크샵도 참가해서 해당 서비스를 이용하는 것 자체에 대한 두려움은 사라졌지만 무얼 어떻게 해준다는건지에 대한 느낌이 크게 안온다. 게임이나 전자제품, IT기술들은 좋아해서 해당 기사, 토픽들은 옛날부터 많이봐서 몇몇 키워드에 대해서는 어느정도 익숙했다.(코딩 공부를 하기로 마음 먹었던 이유도 이거다. 관심이 많았고 재미있다.) 덕북에 정말 아예 이 분야가 처음인 사람보다는 나은건 확실하지만 6~7월에서야 데이터센터가 서비스가 돌아가는 서버가 아니란걸 알고, 화이트코스 전까진 웹도 직접 tcp/ip 소켓을 구현해서 하는 줄 알았다. 그래도 다행인건 좀더 웹의 기초가 되는 부분들은 생활코딩, 포비의 수업과 추천해줬던 책들(그림으로 보는 http…,프로가 되기 위한 웹…)을 읽으며 어느정도 차곡차곡 쌓아 온거 같다. 몰라서 불안감을 느끼는 부분이 좀더 정확히는 점점 발전해서 나온 분야인거(예를 들면 aws) 같다. 이 부분들을 필요할때, 궁금할때 알아가고 싶긴 한데 주변에선 다들 대강은 알고 있으니 이런 것들에 대해 공부를 해야 할지 고민이 된다.

내일 할일

• 다음 레벨 작업

• 상담을 무엇을, 언제 할지 체크

오늘 한일

• 볼링 구현 사항

  • 점수 계산 구현 완료

  • 플레이어 인원, 이름, 쓰러트린 볼링 핀 갯수 입력 구현 완료

  • 결과 출력부 작업 중

• 컨디션이 많이 안좋았다가 저녁이 될수록 괜찮아졌다. 상당히 긴 기간 애먹었던 점수 구현부를 그냥 싹 날리고 다시 시작해서 1시간만에 마무리 한거 같다. 레벨테스트때 구현했던 방식을 차용해서 흡족스럽진 않지만 이전보단 깔끔해진거 같다.

내일 할일

• 콘솔 볼링 게임 마무리(진짜) 및 pr 보내기

• 상담 날짜 체크하기

• 몸 상태 나아지기

오늘 한일

• 볼링 구현 사항

  • 마지막 Frame 부분 말고 Frame, State 생성 및 쓰러트린 핀들 입력 구현 완료.

  • 점수 계산 일부 구현.

• 포비의 스트림 수업

  • distinct() : 중복 제거

  • java sorted( (a,b) -> Integer.compare(b.length(), a.length()))

    문자열 길이를 비교하여 긴순으로 정렬

  • numbers.stream().reduce(0, (x, y) -> x + y);

    리덕션 연산으로서 스트림 요소들을 다른 방법으로 결합하고 싶은 경우 사용. 현재의 경우 0부터 스트림 내부의 값들을 더해간다. 지금 형태는

    numbers.stream().mapToInt(Integer::valueOf).sum()

    으로 변경 가능 하다.

  • 함수형은 내부적으로 사이드 이펙트가 안생기게 막혀 있다.(새로운 객체를 생성하며 작업)

  • 스트림 연산은 원본을 변경하지 않는다. 대신 결과를 담은 새로운 스트림을 반환한다.

  • synchronized를 사용하면 대기하는 프로세스 때문에 프로그램이 느려진다. 큐같이 꼭 synchronized가 필요한 부분만 사용하는 것이 좋다.
• 친구가 이번주에 세미나때문에 강남을 와서 오랜만에 만났다. 다시 전주에 가기전에 한번쯤 더 볼 듯 싶다.

오늘 느낀점

• 간단한 stream 작성은 금방하는데 stream을 사용할 때 많은 양의 데이터를 처리하면 얼마나 느려지는지 궁금해졌다. 지금은 말고 여유가 생겼을때 테스트 코드를 이용하여 확인 해 보자.

• 날씨가 갑자기 추워져서 감기 기운이 약간 있다. 감기 안 걸리게 조심하고, 컨디션 관리차 오늘은 일찍 자자.

내일 할일

• 콘솔 볼링 게임 마무리

• 알고리즘 토의

오늘 한일

• 백준에 백설공주 문제 숏코딩 순위권 들기 도전

• Stream을 이용한 프로그래머스 최솟값 만들기, 행렬의 곱셈 알고리즘 문제 풀이

• 볼링 구현 사항

  • 현재 단계상에서 State 생성 및 점수 입력 부 완료

오늘 느낀점

• 어제 새벽에 자기 전에 Stream을 이용한 백설공주 풀이 코드를 조금 더 손을 봤다.

  public static void main(String[] args) {
    Scanner sc = new Scanner(System.in);
    List<Integer> peoples = new ArrayList<>();
    for (int i = 0; i < 9; i++)
      peoples.add(sc.nextInt());
    peoples.stream().sorted()
        .filter(people -> !peoples.stream().filter(secondPeople -> people != secondPeople)
            .anyMatch(secondPeople -> people + secondPeople == peoples.stream()
            .mapToInt(Integer::intValue).sum() - 100)).forEach(System.out::println);
  }
  

  손을 본 방향은 코드량을 줄여서 숏코딩 순위권에 들기였는데 위의 코드로 2등을 했다.(1등은 저 코드에서 변수명을 a,b 같은 형태로…. 한 내 코드) 그건 그렇고 숏코딩을 하다보니까 변수를 만들고 재활용 하는 것에 대해 좀 더 깊이 생각해 볼 수 있었다.

• 위의 Stream이야 억지로 푼 문제여서 한눈에도 안들어 오고 작성하는 것도 힘들었는데 오늘 푼 다른 문제 중

  for (int i = 0; i < size; i++) {
  			answer += A[i] * B[size - 1 - i];
  	}
  

  answer = IntStream.range(0, size).map(index -> A[index] * B[size - 1 - index]).sum();
  

  이처럼 간단한 문제는 수월하게 작성하게 된거 같다. 확실히 요 몇일 Stream을 많이 사용해봤는데 잘만 사용하면 불필요한 코드량도 줄고 가독성에서도 큰 이점이 있을거 같아 매력적이다. 익숙해진거 같긴해도 아직 모르는 부분이 너무 많은데 Stream의 학습 비용이 크다는게 어떤건지 알 것 같다.

• 볼링을 많이 볼까 하다가 Stream을 좀더 사용하고 싶어서 조금은 쉬었다.

• 경기창조혁신센터에서 공부하다가 중간에 집중이 잘 안되서 잠깐 쉴려는 타이밍에 인프런 대표님을 만났다. 열심히 하는 다른 사람을 보니 자극이 되서 다시 집중 해서 공부를 했다. 덜도 말고 더도 말고 내 노력하는 사람의 롤 모델인 형만큼 할 수 있게 노력하자.

내일 할일

• 콘솔 볼링 게임 리팩토링

• 포비의 Stream 강의