2023.2.8 회고

오전에는 세 가지 내용의 강의를 들었다.
1. 우테코에 임하는 자세
우테코는 물고기를 잡을 수 있는 환경을 만들어 준다.
2. 단위 테스트
main method를 테스트 했을 때의 문제점, JUnit, assertion

• 내가 단위 테스트를 작성하는 이유는 무엇인가?

->모든 기능이 잘 작동하는지 테스트하기 위해

• 내가 작성한 좋은 단위 테스트는 어떠한 부분에서 좋은 단위 테스트라 느꼈는가?

-> 예외를 발생시킬 수 있는 값을 예상하여 테스트함

• 위와 같은 좋은 단위 테스트를 작성하기 위해 어떠한 시도를 해볼 수 있는가?

-> 경계값 검증


3. 코드 품질

• 코드 품질이 중요한 이유 중 가장 와닿는 이유는 무엇인가?

-> 보기 좋은 코드. 보기 싫은 코드를 봤을 때 이해를 하기 싫은 경험이 있다. 따라서 보기 좋은 코드가 가장 와닿았다.

• 위 이유를 만족하기 위한 코드를 작성하기 위해 어떠한 노력을 해봤는가? 혹은 할 예정인가?

-> 다른 개발자가 내 코드를 본다는 관점에서 코드를 작성한다.

• 코드 품질을 높은 코드를 작성하는 프로그래머가 훌륭한 프로그래머인가? 그렇게 생각한 이유는 무엇인가?

-> 훌륭한 프로그래머이다. 프로그램의 완성은 런칭이다. 즉, 이제 시작이기 때문에 앞으로 많은 유지보수 작업을 해야함. 앞으로의 작업을 하기 위해 좋은 품질의 코드에서 시작해야 다른 사람이 코드를 이해하고, 수정할 수 있고, 비용도 적어지기 때문


오후에는 페어프로그래밍을 시작했다. 요구사항을 먼저 정리하고 설계는 따로 하지 않고 프로그램의 실행의 흐름대로 프로그래밍하기 시작했다. 오랜만에 코딩을 하니 설계에 너무 무심했다는 생각이 들었다. "객체지향의 사실과 오해"를 다시 읽어보며 객체지향에 대해 다시 고민하는 시간을 가져야겠다.
테스트를 작성하는 과정에서 페어에게 @DisplayName과 @Nested의 사용법에 대해 알려줬다. 코딩을 오랜만에 해서 기억이 잘 나지 않았는데 알려주면서 나도 공부가 되었다.
내가 여러 String을 ,를 구분자로 연결하는 ( ex) a, b, c, d ) 메서드를 작성할 때 StringBuilder 를 사용해서 구구절절 코드를 작성하고 있을 때 페어가 String.join을 사용하는 것을 제안했다. 코드가 한줄로 줄어드는 것을 보고 매우 기분이 좋았다.
로직 오류가 발생했을 때 서로 고민하고 해결하는 과정이 재미있었다.
테스트를 작성할 때 private으로 사용하는 아주 작은 기능에 대한 테스트를 할 것인지, 랜덤 테스트는 어떻게 할 것인지 결정하는데에 어려움을 겪었다.
코딩에 대한 생각이 서로 다를 수 밖에 없으므로 상대에게 나의 생각을 타당한 근거를 기반으로 설득해야한다. 그 과정에서 내가 코딩하는 근거를 확실하게 함으로서 근거가 적절하면 확신이 들고, 그렇지 않으면 적절하지 않을 수 있다는 생각이 들었다.