2021-05-21(Fri)

Facts (사실, 객관)

• 스파르타42 회의에 참여하였다.

• humansOf42 회의에 참여하였다.

• 코드숨 3주차 테스트 리팩토링을 진행하였다.

Feelings (느낌, 주관)

• 단순히 코드, 커밋, PR jira 사용 컨벤션 외에도 할게 남았으니, 먼저 개발 환경을 통일하는 이슈가 남았다. 이전 협업 땐 Rails로 웹 서비스만 개발했기 때문에 docker-compose로 도커라이징한 환경에서 코드만 공유하면서 개발해도 충분했다. 그런데 지금은 인프라 팀, 프론트엔드 팀과 iOS 팀과 한꺼번에 협업하는 상황에서 스프링을 써야하니만큼 좀 더 많은 고려가 필요하다. 우선 각 팀은 IDE까지도 통일하는 것을 추천 받았다. 특히 동적 언어를 쓰는 팀들은 디버깅 고려했을 때 젯브레인 제품을 쓰는 것이 확실히 좋은듯. 흠 live 배포서버만 돌릴게 아니라, 프론트엔드 팀, iOS 팀이 소통할 개발 서버를 따로 돌려놓을 필요가 있고, 각 팀을 전담마크할 백엔드 팀원을 따로 정할 필요가 있다. 한편 인프라 팀에는 우리가 배포하는 방법을 전달해서, 단계별로 쪼개고 자동화할 수 있도록 지원해줘야 한다. 정말 백엔드 팀이 해줄게 많은 것 같군. 알아야할게 넘나 많다는게 새삼 또 느껴진다.

• humansOf42는 바빠져서 많이 참여하지는 못하게 되었지만, 비상주 멘토님들도 인터뷰 대상으로 넣게되어 기대된다. 일터 찾아가서 수다해보면 배우는 것도 많겠지.

• 테스트 코드에 D-C-I 패턴을 도입하고 나니 코드 작성이 즐겁다. 더 잘하고 싶다. javaDoc도 어서 작성해보고 싶은데, 테스트 코드 작성하는 것도 인풋이 많이 들어가서 이번 주에는 어렵지 않을까 싶다.

• 오전 시간을 효율적으로 쓰지 못해서 아쉽다.

Findings (배운 점)

• create를 했다면 이게 성공적인지 확인하기 위해 Read를 쓰고, Read를 확인하기 위해 Create를 활용하는 묘한 상황이 있기 마련이죠.

  마치 순환참조 같은 이 상황이 고민스러웠는데, 비슷한 고민을 한 동료와 좋은 답변을 해주신 트레이너 분들 덕에 나름 감 잡을 수 있었다.

  1. 충분히 테스트된 검증된 쪽을 기준으로 삼고 테스트를 준비한다.

     • 이 때 찝찝하다면, 충분히 테스트가 안된 것.

  2. 덜 망가지는 쪽을 기준으로 삼고, 망가질 우려가 큰 쪽을 테스트한다. 테스트를 작성하기 전에 테스트 대상들이 어떤 관계에 있는지 파악하거나, 반대로 일단 이들을 모두 만들고 한발 떨어져서 상황을 파악한 뒤에 정리하는 일이 필요하다.이런 관계에 대한 고민도 테스트 작성의 소득이다.

• 계층적으로 테스트 클래스를 만들었다면, 테스트도 계층적으로 진행하자. 가독성, 코드 재사용성이 좋아진다.

Affimation (자기 선언)

• 오전에 해야겠다고 적어 놓은 일은 오전에 확실히 달성해낸다.

• 후회 없이 성장하는 하루를 만든다.