실무에서 경험한 리팩토링 능력.

실무자들의 리팩토링의 차이점은 경험에 밑 바탕을 두고 있습니다. 초보자들이 실수 할 수 있는 부분들이 어느날 1~2년 전 개발 소스를 볼 때, 손발이 오그라드는 경험을 해보셨을꺼라 생각이 됩니다. 왜 이렇게 했지, 또는 주석이 없어서 본인이 개발을 해놓고도 무슨 말이야 고민을 해야되고, 웃지 못할 상황이 한 두가지가 아니였습니다.

1. 경험에 따른 리팩토링

 말 그대로 개발한 내용을 가지고 리팩토링을 하나 둘씩 적용해 보는 경우 입니다. 개발된 소스를 가지고 이해가 안가는 부분들이 있으면, 현재 개발하고 있는 내용에 개선하도록 노력하는 것입니다. 주석이 부족하다던지 당시 경험 또는 실력 부족으로 인한 내용을 하나 둘씩 적용하고 그에 따른 내용을 정리하는 것입니다.  이 부분에 대해 어느정도 동의 하실꺼라 생각이 됩니다. 제가 모셨던 팀장님이 그런 말을 하였습니다. 모르는 것은 죄가 아니다. 공부해서 채워 나가면 된다. 아는데 실천을 하지 않는 것은 죄다! 정확히 맡다고 생각이 됩니다.

2. 손발이 어그라드는 개발

이미 개발된 내용을 발견을 하면 흔적을 지우는 단계입니다. 이미 동작이 되고 있는 내용이므로 리팩토링을 통해 혹 의도하지 않은 결과가  도출되지 않도록 하기 위해서는 충분한 테스트를 통해 개선을 해야 합니다. 첨부터 설계가 잘되어 있다면 문제가 없습니다. 하지만, 개발을 하다가 보면 충분한 설계 또는 실력 부족으로 충분하게 좋은 설계가 나오지 못하는 경우에는 문제의 소지가 있으며, 새로운 컨텐츠가 추가되는 경우 기존 개발된 소스를 수정해야 할 사항시 리팩토링을 하나 둘씩 적용해야 합니다. 첨부터 일을 크게 벌리면 시간 부족과 동시에 문제가 발생하였을 경우 신경써야 할 부분도 많아지고 그 만큼 시간을 소비하는 경우가 많습니다. 작은 일 단위로 분할을 한 후, 리팩토링  하는 것이 가장 좋은 방법이라 생각이 됩니다.

3. 설계에 충분한 시간을 할당

설계가 좋은 시스템은 개발시 복잡도를 줄이는 방법입니다. 경우의 수 경험에 따른 내용을 하나 둘씩 정리해 가는 단계입니다. 가장 좋은 방법으로는 Use Case 및 요구사항 분석표를 만들고 나올 수 있는 경우의 수와 확장성에 고려하여 시스템을 구축하여 인수인계시 좋은 인상을 남길 수 있으며, 개발시 난 개발을 막을 수 있습니다. 설계의 중요성을 강조하고 싶습니다. 설계의 문제점은 팀장 또는 직속상관에게 설계시 충분한 대화로 그 경험을 빌리는 경우가 가장 좋습니다. 그렇다고 무작정 빌리는 경우, 자신의 이해도  및 자신의 것으로 만들기에 문제가 될 수 있습니다.

4. 문제 발생시 대화를 하자.

설계시 또는 개발된 내용에 대해 생각했던 이외 문제가 발생하였을 경우(예외처리) 기타 등등 생각하지 못했던 문제가 발생하기 마련입니다. 기존 시스템 개발에 대해 이야기 하고 현재 봉착된 문제점을 이야기하여 리팩토링 하는 방법입니다. 가장 큰 문제는 대화  부족으로 인하여 커뮤니케이션이 안되서 발생하는 문제가 많습니다. 이것을 어떻게 풀어야 할지 고민하지 말고, 대화를 통해 조금더  좋은 시스템으로 갈 수 있도록 해야 합니다. 경험이 있는 개발자라면 자기당착에 빠져 질타하는 경우가 발생할 수 있는데, 이것은 팀웍을  깨는 가장 좋은 방법입니다. 문제점을 이야기 하고 수정 또는 개선사항에 대해 논의 한 후, 미래지향적인 방향으로 가야 할 부분입니다. 가장 힘든 부분중에 하나라 생각합니다. 개발자들 능력에 따른 설계의 차이 있기 마련입니다. 통큰 사람이 되었으면 합니다.

5. 리팩토링 정리

  ㅇ 리팩토링이 필요한 부분을 발견하면 조금씩 조금씩 수정해 나가자.
  ㅇ 대화를 통해 문제를 풀어나가자.
  ㅇ 설계에 따른 시스템의 복잡도를 줄이자.
  ㅇ 실력이 부족하면 주위의 사람들로 부터 도움을 통해 실력을 배양하자.
  ㅇ 모르는 것은 죄가 아니다. 아는데 실천하지 못하는 것이 죄다!!