By Kesus Kim

이런 저런 정리되지 않은 단편적인 생각을 기록해놓은 글입니다.

설계가 개발보다 훨씬 중요하다

무언가를 해야 할 때에는 어떻게 해 나갈지 생각을 많이 하고, 대략적으로라도 계획을 세운 후에 개발을 하자.

설계에 비하면 개발은 쉽다. 지금 느낌상으로는 설계와 개발의 비율이 7:3 정도는 되는 듯.

개발은 그냥 키보드 두들겨서 동작하게만 만들면 되는데, 설계는 환경 구성부터 배포까지, 전체적인걸 구상해서 개발해야 한다.

동작한다고 해서 개발이 끝난것이 아니다

개발에서 동작하게 하는건 쉽다. 요즘에야 인터넷이 워낙 발달되어 있으니 그냥 인터넷에서 갖다 붙히면 동작한다.

제일 중요한게 문제를 해결하는 것이고 동작한다는 것은 가장 중요한 미션을 마무리 지은 것이지만, 그것으로 개발을 끝내기에는 짚고 넘어가야 할 부분이 있다.

리팩토링이 되지 않은 코드, 간결해지지 않은 코드는 동작한다고 해서 개발이 끝난 코드가 아니다.

그 상태로 다른 일을 진행한다면, 추후에 그 코드를 다시 보아야 할 때에는 상상 이상의 시간이 더 들어갈 것이다.

문서화는 당신이 생각하는 것보다 더 어렵고 중요하다

리팩토링을 아주 열심히 해서 코드 스스로 굉장히 직관적인 경우를 제외하고는, 문서가 없다면 당신의 코드의 가치는 굉장히 낮아진다.

기본적으로 코드를 개발한 당신 외에는 다른 개발자들도 사용자라고 생각하고 문서를 제공해주어야 한다. 일반 소비자보다 똑똑한 소비자일뿐, 개발자도 사용자임을 명심하자. 다른 개발자들도 문서 없으면 코드 이해 못한다고 생각해야 한다. 가급적 자세하고 상세하게, 요소 단위에서, 이 문서나 주석을 읽을 사람을 생각해서 문서화를 하자. 예를 들어 사내에 공유하는 코드의 경우 사내 직원이 이해할 수 있도록 작성하고, Github 등에 올라가는 오픈 소스 프로젝트의 경우 좀 더 범용적으로 작성하도록 하자.

테스트 되지 않은 코드는 쓰레기에 불과하다

기능 개발을 했다면 최소한 개발자 수준에서 테스트를 해보는 것이 정상 아닐까? 만든 사람이 만든 대로 동작했는지 확인하는 것은 당연할 것이다.

테스트 되지 않은 상태의 코드, 검증되지 않은 코드는 아직 신뢰할 수 없는 코드이고, 내 개인적인 생각으로는 아직은 개발자의 생각에 불과한, 잠재적으로 논리적 허점 투성이일 가능성이 존재하는 쓰레기에 불과하다.

최소한 TDD 를 도입하지 않더라도 테스트는 하고 git push 를 하자. :( 진짜.

그리고 가급적 TDD 를 도입하자.

TDD 도입 시점?

내 생각에 아예 맨 처음부터 TDD를 도입하는 것은 좀 아닌 것 같다. 시간이 너무 걸리니까 뭐가 안 나오기 때문에 그렇다 (속도가 너무 빠르신 분을 제외하고요… 저는 안 그러던데 ㅠㅠ). 경험상 어느 정도 코드 베이스가 차고, 라인 수가 1000 ~ 2000 라인 정도가 될 때 즈음이 적당한 시점인 것 같다. 그 때 즈음 되면 뭔가 하나 수정할 때마다 연관 기능 다 테스트 해보기가 엄청 빡세다. 테스트 코드 작성하기에도 충분히 테스트 할 코드가 많이 있어서 바쁘게 일을 할 수 있다. 맨 처음부터 하면 테스트 할 코드 조차 없으니 솔직히 뭘 할지 모르겠다. 대체 처음부터 TDD 는 어떻게 도입하는걸까? (진짜 궁금하다) 가능 하긴 한걸까? 코드를 테스트하기 위해 작성한 테스트 코드는 어떻게 신뢰한단 말인가?…

Over Engineering 은 위험하다

개발하다보면 이것 저것 결정해야하는 순간이 오는데, (나를 포함해서) 생각이 깊은 개발자라면 공감하겠지마는, 아는게 많을 수록 고민할 것이 많아진다. 알고리즘을 만드는게 아니라면, 너무 과도한 엔지니어링은 좋지 않다. 적당한 선에서 일정에 맞추어 끊고, 생각을 정리해서 코드 내에 TODO 주석으로 남겨놓은 후 문서에도 몇 마디 정리해 놓고 넘어가는 것이 더 낫다.

예시) 이 로직은 서버가 하나일 때만 동작하는데. 여러 개일때 동작하도록 분산 설계 하려면 DB 구조도 바뀌어야 하고. (DB 구조를 바꿀 방법이 떠오른 경우) DB 구조에는 반영을 시켜놓고, 코드에는 주석처리해놓자. (방법이 떠오르지 않을 경우) 팀장님에게 말씀 드리고, 문서에 명확하게 적어놓자.