[주간 회고] 22.02. 2주차 🐳👯‍♂️🍸

일기 형태로 작성되었습니다.

 

월, 화요일

22.02.07~08 - 도커 컴포즈, DB, JDBC 🐳

팀원들과 함께 알고 있는 것을 공유했다. bluk insert 방법들을 함께 나눌 수 있어서 유익했다. 앞으로도 배운 것을 나누고 토론해야겠다. 모르는 것을 내게 물어봐주는 팀원들이 많아졌다. 내겐 좋은 일이다. 함께 성장할 수 있기 때문이다. 하지만 나의 한계와 부족함을 느낀다. 이럴 때일수록 모르는 것은 모른다고 이야기해야겠다. 지식을 추정하지 말고 부족함을 인정하자. 모르는 것을 채우고 나누자. DB를 깊이 공부해야겠다.

 

수요일

22.02.09 - 커뮤니케이션과 짝 프로그래밍

커뮤니케이션은 개발뿐만 아니라 삶에도 중요하다. 두 가지를 잊지 말자.

- 상대방을 짐작하지 않기 : 예를 들어 A란 사람이 내 어깨를 치고 뛰어갔다. 저 사람은 왜 내 어깨를 치고 가지? 안 좋은 인상이 남을 수 있다. 하지만 A란 사람은 화장실이 너무 급해 어깨를 친 상황조차 인식하지 못할 수 있다.

- 텍스트가 아닌 컨텍스트를 주고받기 : 예를 들어 상대방에게 “이걸 해주세요" 보다 “이걸 왜 해야 하는지 설명하기"가 효율적인 커뮤니케이션이라는 것이다.

잊지 말자! 상대방을 짐작하지 말고, 컨텍스트로 소통하자.

 

목,금요일

22.02.10~11 - 웹 클라이언트, 소켓 프로그래밍

문제를 해결하기 위해 탑다운과 바텀업 방식 둘 다 익히자. 큰 문제를 작게 만들어야 한다. 작은 문제들을 풀며 패턴을 찾아 큰 문제를 추상화 하자. 문제 해결 방법은 한 가지가 아니다. 다양한 방법을 익히자. 문제 해결 방법이 끝이 아니다 어떻게 해결했는지 사고의 과정을 익히자

 

토요일

책 '소프트웨어의 품격' ch6 테스트를 이용한 신뢰성 향상 파트 스터디를 했다. 이전 내용에서 DbC(계약에 의한 설계)를 공부하며 방어적 프로그래밍에 대한 기본을 알아봤다. 테스트는 DbC의 설계 배척이 아닌 오히려 강화하는 것을 알게 되었다. 특히 블랙박스 테스트 기법 중 입력 도메인 모델링(input domain modeling) 방법이 기억에 남았다. A 메서드를 테스트하기 위해 입력 파라미터들의 집합(모든 경우의 수)을 나누어 테스트 안 하는 부분이 없도록 하는 것이다.  기존에는 하나의 데이터 타입을 고려해 수치 데이터라면 0, 음수, 양수 체크 정도로 생각했다. 이번 기회를 통해 2개 이상의 파라미터에도 모든 경우의 수를 고려해 테스트에 빈 부분이 없도록 테스트 코드 설계해야 한다는 것을 정리했다. Java의 JaCoCo 라이브러리도 알게 되었다. 비록 gradle 빌드에 실패했지만 부담 갖지 말고 차근차근 앞으로 프로젝트들에 적용해보자.

 

일요일

내일부터 호눅스 & 실무 개발진들의 코드 리뷰가 시작된다. 무척 기대되고 떨린다. 리뷰를 위해 어떤 태도를 가져야할까 생각해봤다.

모르는 것을 인정하자. 좌절하지 말자. 배움을 멈추지 말자. 정답 뿐만 아니라 왜 이렇게 생각했는지 과정까지 평가받자. 약은 쓰다. 비판을 달게 받자.  

---

일요일의 여유

단골 커피바에 왔다. 1월을 마친 기분을 내고자 커피 칵테일(B.Leaf)을 시켰다. 에스프레소, 진, 홍차, 레몬, 시럽을 섞은 칵테일이다.

레몬향의 베이스로 시간에 따라 맛이 달라졌다. 처음 거품이 있을 때는 진과 커피 맛이 느껴진다. 나 커피 칵테일이야!  놀랍게도 시간이 지나 거품이 사라진 뒤 맛은 커피가 사라지고 홍차 맛이 느껴진다. 나 사실 홍차였어!

Within의 B.Leaf