Test-Driven Coding

언제부터인지 그렇게 된 듯 하다. 재미있는 것은 연역적 사고에 점점 자신이 없어지면서라는 것이다. 어느정도 사고를 하다가 감으로 코드를 구현하고 일단 돌려보게 되는 것이다. 그러니까 약 70%정도의 확신으로 돌려본다. 대개는 예상결과와는 다르게 오답이 나온다. 그러면 이리저리 생각을 해보면서 수정하고 반복하면서 다시 돌려보게 된다. 역시 70%정도의 확신만을 가지고 돌려보는 것이다.

배경은 이러하다. 코드를 복잡하게 구현하고자 하는 생각은 없지만 계속되는 Refactoring과정에서 코드의 구조가 불가피하게 복잡하게 되는 듯 하다. 개인적으로 리팩토링의 목적은 Optimization이며 이는 결국 중복된 로직을 최소화하는 작업을 의미한다.

점점 코드가 복잡해지면 사실 나도 개략적인 구조 외에는 세부적인 연관성에 대해서 확신을 못하게 되는 듯 하다.

생각해보면 100%의 확신을 가지고 코드를 짠다는 것은 단지 이상일 뿐일 것이다. 결국 90%의 확신 혹은 70~80%정도의 확신 그 사이에서 균형을 잡아가며 테스트를 반복해 보는 것이라는 생각을 해 보았다. 70%이하의 확신으로 무작정 테스트만을 수행하는 것은 바람직하지 못하다고 생각한다. 왜냐하면 테스트를 통과하더라도 코드의 무결성에 대해서 확신을 하기 위해서는 어느정도 코드에 대한 리뷰 및 이해가 필요하다고 생각하기 때문이다.