부정확한 결과를 '계속해서' 만들어내는 Program은 안 만드느니만 못하지 않을까?
채용 과제로 csv 파일을 json 형태로 바꾸는 Program을 만든적이 있다.
csv 파일이 450mb 정도의 크기였는데 두가지 당황을 겪었다.
- 파일의 row가 너무 많아서 excel로 열리지 않는다.(900만 row 이상)
- 그래서 내용을 console에 찍어보려했는데 10분이상을 계속 찍고 있음...
아니 확인도 안되는 Data를 어떻게 변환까지 하지???
우여곡절 끝에 1일치씩 Data를 끊어서 요구사항의 json 형태로 변환하는 Code를 제출했다.
그리고 면접중 이런 질문을 들었다.
'근데 왜 Test Code가 없죠?'
나는 거기에서 거기까지는 요구사항에 써있지 않아 미처 생각하지 못했다며
평소 Test Code의 중요성은 들어왔으며 전에 포비(자바지기)님 영상(https://www.youtube.com/watch?v=cVxqrGHxutU)을 보고 junit도 써봤다고
변명했다.
그리고 다음 질문을 들으니 할 말이 없었다.
'그럼 이 json 결과가 정확하다는 것을 어떻게 신뢰 할 수 있죠?'
맞다 엑셀로 열지 못해 제대로 확인도 못한 큰 크기의 Data를
마음대로 주물럭 주물럭해서 변환해놓고 이게 정확하다?
이건 기도메타에 가까웠다.(형태가 비슷하니까니까 맞을꺼야! 라고 믿고 싶다)
이후 면접 과정에 많은 것을 깨닫고 배울 수 있었지만 결과는...ㅜ
하지만 진심으로 감사하게 느끼는 것은 내가 부족한 부분들을 파악할 수 있었고
개발에 있어서 새로운 방향성을 깨달았다는 것이다.
(위에 새는 그래도 날기는 한다...)
전에는 좋은 Code와 나쁜 Code가 가독성과 성능의 차이 정도라고 생각했다.
그런데 이제 나쁜 Code는 덜 좋은 정도가 아니라 위험한 Code라는 생각이 들었다.
내가 면접은 본 기업은 금융권이었다. 하루에도 몇억, 몇십억의 돈이 오고 갈 것이고
그 사이에서 0.02 차이는 위와 같다면 몇백 몇천억의 차이가 날 수 있겠다는 생각이 들었다.
참조 : 회사를 한 순간에 부도 시킨 오타들(https://brunch.co.kr/@nsung/1)
그래서 TestCode(TC)에 대해 더 알아봐야겠다는 생각이 들었다.
그리고 내가 한 과제에 TC를 추가하려 시도해보았다.
그러나...
내 Code들은 위의 Jenga처럼 너무 한 덩어리로 되어있었고
억지로 추가한 TC들은 'TC를 위한 TC' 같았다. (원하는 값에 결과 값을 끼워넣는 식?)
이를 통해 Test하기 좋은 Code를 작성한다는게 왜 필요한지 느꼈고
이를 위해 개발 -> Test가 아니라 Test -> 개발 방식의 TDD를 더 알아보고 싶어졌다.
켄트 백이 테스트 주도 개발을 설명하면서 강조하는 진짜 가치는 '어려운 일을 작은 단계로 쪼갤 수 있는 능력' 입니다.
https://siyoon210.tistory.com/143 에서 발췌
위 글에서 많이 배울 수 있었는데 TDD는 단순히 Test를 위해 하는 것이 아니라 이를 통해
큰 문제를 작은 문제로 쪼개가면서 더 독립적인 모듈들을 만들 수 있다는 것을 알게되었다.
여기서 TDD는 단순히 Code의 작성 순서 문제가 아니라 설계와 연결된다는 생각이 들었다.
독립적인 모듈들이라는 말에서 OOP를 떠올리게 되었다.
OOP의 중요한 특성인 강한 응집력과 약한 결합력을 지향한다는 점에서
독립적인 모듈들을 만들어 낼수 있고 독립적인 모듈들은
Test하기 좋은 코드가 아닐까라는 생각으로 이어지게 되었다.
(함수형 프로그래밍이 Test하기 좋다는데 일단 Java로 OOP를 단단히 하고 싶다)
글이 너무 의식의 흐름대로라 정리하자면
1. TestCode가 없는 프로그램은 신뢰하기 어려우므로, TestCode를 작성해야 한다.
2. TestCode를 잘 작성하려면, TestCode를 작성하기 좋은 Code를 작성해야 한다.
3. Test하기 좋은 Code를 작성하려면, OOP적인 개발이 필요하다.
위와 같이 정리할 수 있겠다. (의견 있으신 분은 조언 부탁드립니다!)
TDD(TestCode)가 필요한 이유(Why)는 위험한 폭탄을 정성스레 만들고 싶지 않기 때문이다.
다음으로 이를 어떻게(How)라는 차원에서 OOP를 좀 더 공부하고 싶고
기존 내 포트폴리오(What)를 추가 개발하면서 이를 적용해보고 싶다.
포비님은 Test하기 좋은 Code를 알아보고 작성하는 것에 5년이 걸렸다고 한다.
"TDD는 죽었다"(https://sangwook.github.io/2014/04/25/tdd-is-dead-long-live-testing.html)라는 글이 퍼졌을 정도로 시간과 비용에서 비효율적이라는 의견도 있다.
(기존에서 2.5배의 코드를 작성해야 한다는 말도 있다.)
그럼에도 불구하고 마틴 파울러의 리팩토링(feat.TestCode) 강연(https://www.youtube.com/watch?v=mNPpfB8JSIU)에 따르면
장기적인 관점에서 리팩토링은 장인정신의 차원이 아니라 경제성이라는 측면에서 중요하며 안정적인 리팩토링을 위해서는 이를 뒷받침할 TestCode의 필요성을 설명한다.
개발자라면 누구나 완벽한 Program을 만들고 싶겠지만
여건이 허락하지 않는다면 현실과 조화를 이루는 것이 맞다고 생각한다.
그래도 완벽을 추구하는 태도 그 자체가 적어도 더 나은 개발자가 되는 길이라 생각하며
그러한 점에서 TDD(TestCode)가 필요하다고 글을 마친다.
