Work
입사 후 처음으로 사내 Java CMS 플랫폼을 활용한 프로젝트 전 과정을 참여했다. 입사 초반에 작은 수정사항이 있어서 CMS를 다뤄보았는데 그때와 비교해서 코드 이해도가 많이 나아진 모습을 확인할 수 있었다. 하지만 새 기능을 올리는 것은 어렵지 않았으나 원래 있던 소스에 수정사항이 생겼을 경우 아직 헤매는 부분이 많았고, 내가 모르는 CMS 기능들이 많아서 코드를 세밀하게 뜯어보아야겠다고 생각이 들었다. ( * 코드를 뜯어보면서 어떤 식으로 정리를 해나가는 게 좋을까? ) CMS를 공부하고 정리한 내용을 바탕으로 문서화해서 남겨둬야겠다. 큰 프로젝트의 전체를 코드만으로 파악하는 것은 꽤 힘든 일이었다. 내가 그랬고, 이후 신입 개발자가 비슷한 상황에 처했을 경우 꽤 도움이 될 것 같다.
특히나 프로젝트를 참여하면서 문서에 중요함에 대해서 배우게 되었다. 초반에 업무 문서에 대한 경험이 없어 중요하게 생각하지 않고 빠르게 확인하고 넘어가 코드에 더 집중하거나 전달사항을 문서화하지 않고 메신저로 직접 전달하는 방식이었는데 문서를 통해 요구사항을 정확히 이해하는 것이 실제 코드 작성 시간을 단축시켜 주며, 더 나은 사용자 경험을 가질 수 있도록 고민할 수 있는 지름길이었고, 작업 과정에서 발생하는 공유 사항을 문서화했을 때 공유 대상과 서로 정확하고 빠른 소통이 가능하다는 점을 직접 경험했다. 한 가지 사례로 코드 작성 중 git 충돌이슈로 많은 양의 코드를 전달해야 했는데 메신저로 전달하기에는 힘들다고 판단하여 워드로 정리해 전달하니 2차적인 메시지 없이 많은 양의 내용을 정확하게 전달할 수 있었다.
Tech
Repository 추상화
매번 Service에서만 추상화를 하다보니 Repository에서 추상화를 한다는 생각을 하지 못했었다. Repository도 Service와 같은 이유로 Dependency Injection을 위해 추상화를 걸어주는 것이라고 했다. Repository도 추상화를 걸어주기는 했지만 머리로는 잘 이해가 되지 않았다. Service는 매번 추상화하다 보니 이게 맞나 보다 하고 사용했었는데 Repositroy에 추상화를 거는 것은 낯설게 느껴졌던 것이었다. 더군다나 내가 구현한 Repositroy는 인터페이스와 구현 클래스가 1:1 관계뿐이어서 더더욱 추상화의 필요성을 느끼지 못했다. 호기심에 찾아본 결과 생각 정리에 도움 되는 게시글을 발견했다.
OKKY - Service와 DAO에서 인터페이스를 쓰는 이유가 궁금합니다.
해당 게시글과 댓글을 읽어보니 결국 이것도 개발방법론 중 하나일 뿐이라는 생각이 들었다. 팀 프로젝트 같은 경우 절대 혼자 하는 것이 아니기 때문에 결국 팀원과 함께 의견을 맞춰가는 것이라고 생각했다. ( * 물론 왜 사용하는지에 대한 이유를 설명할 수 있어야 한다고 생각한다.)