coursera.org의 functional programming principle in scala의 진행이 끝났다. functional programming이라는 생소한 개념을 배우면서 재미있기도 했고, 강의를 시작하기 직전에 봤던 '자바 개발자를 위한 함수형 프로그래밍'를 읽으면서 제대로 알지 못했던 개념을 좀 더 확실하게 배웠다. 물론 강의와 서적 모두 '입문'에 대한 것이라 의미에 대해 알려면 더 많은 경험이 필요하겠고, 서적과 강의가 지향하는 바가 조금 달라서 내용도 다르지만 서적을 보면서 제대로 이해하지 못했던 개념을 강의를 보면서 이해하는데 도움이 되었고 기초가 있는 상태에서 다시 서적을 읽으면 더 이해가 잘 될 것 같다.

사실 강의를 읽으면서 도움이 된 것은 functional programming에 대한 이해보다 다른 것이다. 물론 functional programming에 대한 기초를 쌓는데도 무척 도움이 되었지만, 그것보다 과제를 진행하는데 있어서 '테스트'의 중요성에 대한 인식이 생겼다.

과제를 진행하는 방식은 이렇다.

1. 테스트 케이스가 주어진다.
2. 작성해야하는 로직이 제외된 코드가 주어진다.
3. 단계별로 로직을 구현하면서 테스트를 통해 작성된 로직이 유효한지 확인한다.
4. 이전 단계에서 구현한 것을 기반으로 다음 단계의 로직을 작성한다.

물론 주어진 테스트 케이스들 중에서 좋은 테스트 케이스만 있는 것이 아니다. 스펙에서 요구되었지만 테스트에서 확인하지 않은 케이스(정렬된 배열을 가져와야하는데 그 종류와 갯수만 확인하는 경우)는 다음 단계의 테스트를 통과하지 못한다. 그럴 경우에는 테스트에 성공한 코드로 돌아가서 수정을 해야하므로 좋은 테스트라고 볼 수 없다. 이런 식으로 좋은 테스트가 적성되어있는 경우에는 그 테스트를 통과하면 다시 그 코드를 수정할 필요가 없고, 성능상의 문제가 있는 경우에는 그 코드를 수정하고 다시 테스트를 통과하면 다른 코드들을 건들이지 않아도 된다.

여기에 대한 전제가 중요하긴 하다. 앞서 이야기했듯이 '좋은(명확한) 테스트가 작성되어 있을 것', 그리고 '확실히 단계별로 구분된 설계가 있을 것'이다. 이 전제들이 참 어렵지만, 반대로 생각하면 이 전제들이 확실한 경우가 있다. 바로 내가 겪었던 것과 같이 '과제'를 작성하는 경우다. 커다란 과제가 주어졌을 경우에 어디서부터 어떻게 접근해야할지 명세서를 봐도 막막한 경우가 있는데 그런 경우에 bottom-up으로 제대로 된 설계에 따라 테스트를 하나씩 거치면서 확실히 눈에 보이는 진척을 확인할 수 있다. 물론 실무에 적용하려면 저 전제들을 만족하기 참 힘들겠지만 말이다. 혹은 퍼포먼스의 이슈가 없거나 종속성이 적은 코드들의 경우에 신입사원들에게 연습시키는 용도로는 확실할 수 있다.

예전에 일하던 회사에서 '시켜서' 억지로 작성한 테스트들이 떠오르며 (사실 잘 떠오르지도 않지만) 부끄러워졌다. 사실 TDD라고 하지만 아직도 TDD가 뭔지 잘 모르겠고, 이해하지 못한 상태에서 작성한 테스트들은 당연히 좋은 테스트일리가 없었다. 이렇게 실무에서 어떻게 테스트를 더 잘 적용시킬 수 있는지에 대해 듣고 싶어서 저번달에 모 컨퍼런스에 다녀왔는데 그냥 '테스트는 의지를 가지고 해야 한다.'라는 말만 반복해서 하더라. 하긴 누군가가 말해줘도 그걸 체득하기는 어렵다. 계기와 경험이 중요한데 나는 일단 이 강의라는 계기를 얻었으니 앞으로 경험을 쌓도록 노력해야지.

참고로 80점 만점에서 60%(48점)만 얻으면 인증을 얻는데 과제를 너무 늦게 시작하는 바람에 1주차에 80% 감점을 받고 시작한 것을 합쳐서 69점으로 통과했다. 만점을 목표로 한 것에 비하면 부끄럽지만 인증을 받은 것만으로도 일단은 만족. 그리고 스칼라 스터디에 한번 참여해보고 싶었는데 영어 실력이 부족하여 참여할만큼 이해한 강의가 없어서 한번도 참여를 못한 것 두가지가 아쉽다.