오늘 한일

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

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

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

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

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

• 체스 구현

오늘 느낀점

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

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

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

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

내일 할일

• 체스 하자

• 코딩테스트 환경 테스트