0. 일상
- 써야지 하다가 안써벼렸다. 일기에 적는건 출퇴근하다가 일하다 쉬다가 머릿속에서 생각한 것들인데 이걸 타이핑하기가 너무 귀찮다 ㅋㅋ 생각하면 알아서 타이핑되면 좋겠다 ㅋㅋ
1. 와인앱 근황 mlkit
- 와인앱은 mlkit을 이용해서 와인 상품명을 읽어들이는 작업을 진행중이다. 생각보다 인식률이 좋아서 나름 만족한다.
- 카메라 layout을 대폭 축소시키고 인식시킨 글자를 클릭해서 검색하도록만 하면 1차 mvp는 끝난다! 할께 많네..
2. 챕터 일감을 만들 때 어떤걸 고려해야 하나?
챕터 일에는 3종류가 있다.
- 지금 당장 중요해서 해야하는 일
- 나중에 중요해서 토대를 닦는 일 혹은 나중에 크게 도움될 작은 변화들
- 내가 하고싶은 일
당연하겠지만 1 > 2 > 3 순서로 중요하다. 특히 3은 팀원들과 논의도 해야한다. 내가 하고싶은 일이 정말로 도움이 되는지 장기적으로 바라봐야하며 현재의 문제를 해결할 수 있는 일인지도 검토해야 한다. 단순 욕구로 일을 해서는 안되고 객관적으로 바라보고 평가해야한다. 실무에서 개발하는 코드는 테스트배드가 아니다.
3. 팀에 변화를 일으키는건 영향이 크다. 우리는 ROI를 고려해야 한다.
- 당근에 와서 내가 변화를 일으키려고 노력했던게 여러개 있다. 몇 개는 받아들여졌지만 (내가 담당하는 프로젝트 한정) 그렇지 못한것들도 많다. 가장 큰게 유닛테스트인데 여기에 대해 이야기 해보고자 한다. 프로젝트에 테스트를 도입하는건 매우 큰 변화다. 팀원들이 테스트에 대한 중요성은 알지만 경험이 없기에 보통 이런 변화를 별로 달가워하지 않는다. 왜냐하면 "우리 테스트코드를 짜기로 하자!" 정하게 되면 단순히 그렇게 따르는 것 보다 더 큰 노력이 필요하기 때문이다. 여기서 노력은 테스트에 대한 경험이 없기 때문에 따로 시간을 내어 공부하는 노력, 코드를 수정했는데 테스트 코드가 깨졌고 이걸 수정하기 위해 트러블슈팅하기 위한 노력등이다. "우리 디렉터리구조를 이렇게 가져가자!" 를 정하는 것과는 결이 다르다. 들이는 노력이 다르다. 그냥 그렇게 하면되는게 아니라 개인의 시간과 노력이 많이 들어가기 때문이다.
어쩌면 지금까지 테스트코드 없이 개발을 해왔고 거기에 대해 큰 문제가 없 었기 때문에 중요성을 덜 느낄 수도 있다. 문제를 방지하기 보다는 빠르게 모니터링해서 고치는게 더 맞다고 생각하기 때문일 수도 있다. 하지만 테스트코드를 짜는게 그게 다는 아니라는걸 나는 알고 있어도 팀원들을 설득시키기 위해서는 너무나 많은 노력이 필요하다. 한 번에 설득시킬 수는 절대 없고 오랜기간 아주 오랜기간 동안 내가 테스트코드 짬으로써 좋은 경험을 자연스레 심겨줘야 한다.
주제가 잠깐 셌는데 테스트가 중요하다고 해서 그걸 밀어붙히는건 좋지 않다. 팀원이 말해준 ROI라는건 정말 중요하기 때문이다. 지금 테스트를 작성하지 못하는 팀원들이 테스트를 짠다면 ROI는 최악일 테니 말이다. 물론 시간이 지날수록 ROI가 좋아질테고 시도조차 하지 않는다면 절대로 테스트는 작성하지 않을테니 아예 작성하지 말자는 아니다. 조금씩 유닛테스트 부터 사이트이펙트가 없는 함수들 부터 조금씩 쌓아 나가야 한다. 테스트가 중요하고 좋다는걸 자연스럽게 느끼도록 해야한다.
아무튼.. 이런데 요즘 고민이 많다.
누군가는 이렇게 말할 수 있다. FE는 요구사항도 빨리 바뀌니 테스트코드를 짜지 않는게 좋을 것 같다. 빠르게 배포할 수 있으니 테스트코드를 짜는 것 보다 에러를 모니터링하고 빠르게 버그 fix하여 배포하는게 낫다. 솔직히 이렇게 말하는 사람들의 코드가 좋은걸 본적이 없다. 요구사항이 자주 바뀌는게 아닌 유틸함수도 테스트코드를 짜지 않으며 버그가 날까봐 개발을 많이 안하려 하거나 버그 fix는 코드를 개선하고 문제를 완벽히 고치는게 아니라 땜빵코드로 메꾼다.