문제를 해결하고자 적극적으로 도움을 구하는 자세
신규 안테나의 제약사항 때문에 미션을 수행할 수 없는 구간이 생기는 문제가 있었다. 하드웨어 엔지니어로부터 미션이 안되는 구간을 감안하고 운영하겠다는 이해할 수 없는 대답을 듣고 마음이 어려웠던 기억이 난다. 그 날 일기를 쓰면서 문제를 해결하겠다는 마인드를 가지고, 내가 할 수 있는 적극적인 도움을 요청해 보자고 다짐했던 기억이 난다. 아래는 그 날의 일기글 일부이다. 그리고 몇 일뒤 나는 정말 저런 메일을 보냈고 2주 정도 지나서 대안이 있다며 검토해 달라는 답변을 받았다. 그리고 오늘 그 알고리즘을 직접 검증하고 구현해서 미션을 수행할 수 없는 구간을 제거할 수 있었다. 뿌듯하다. 해결하고자 하는 마음으로 도움을 요청했고, 도움을 준 또 다른 동료가 있었고 나는 그것을 소프트웨어적으로 구현할 수 있었다. 감사하다.
문제를 해결하겠다는 자세로 적극적으로 도움을 요청해 보는 게 낫겠다. "하드웨어의 제약사항이 있어 이런 문제가 생겼는데 소프트웨어적으로 커버할 수 있는 방법이 있으면 적용해 보고 싶습니다. 관련해서 제가 알기 힘든 내용들이 많은데 대안에 대해 함께 고민해 주시면 소프트웨어를 구현하는 부분은 적극 도와드리겠습니다. 예를 들면 OOO하는 방법을 적용할 수도 있을 것 같은데 해당 신호의 특성에 맞는 부분인지 확인해 주시면 좋겠습니다."
네거티브 테스트는 필수다
성공 테스트 완료 후, 일부러 테스트 데이터에 오류를 넣어 테스트가 실패하는지 확인해 보았다. 성공이다. 이런! 파라미터 중 하나를 비교하지 않는 버그가 있었다. 벌써 두 번째 경험이다. 이건 습관이 되어야겠다. 네거티브 테스트는 반드시 해야겠다. 왜 이런 버그를 미리 잡지 못했나 질문해보면 네거티브 테스트를 하지 않아서 였다.
황당한 버그로 2시간
메서드의 파라미터로 넘어온 객체를 참조하지 않고, 공유하는 멤버 객체를 바라보는 버그가 때문에 2~3시간을 날린 것 같다. 테스트 클래스를 처음 작성할 때는 @BeforeEach 메서드에서 테스트 관련 설정을 하고 실제 테스트에서 객체를 공유하려고 만들었는데 테스트가 점점 고도화되면서 기본 설정을 벗어나는 객체가 생기기 시작한 것 같다. 공유 객체의 편리함 때문에 테스트 클래스 나누기를 미루어 왔기 때문에 오늘 같은 버그가 생긴 것이 아닌가 싶다. 테스트 클래스가 너무 커졌다. 조금 나누어 볼 필요가 있겠다.
이외 생각들
- 나와 맞닿아 있는, 조금 더 가까운 영역에 집중해야 겠다는 생각을 했다.
- 버그가 발견되어 버그를 드러내는 코드를 작성했다.
- 사용자 코드 먼저 작성했어야 깔끔한 코드가 나왔을 것 같다.
- 테스트를 실패하게 한 직접적인 원인을 제공한 코드에서 문제가 리포트 되게 하자.
