하위 페이지
  • slipp.net에 소스 코드로 질문을 올리면서 느낀 점.
메타 데이터의 끝으로 건너뛰기
메타 데이터의 시작으로 이동

slipp.net을 오픈한지 4.5개월이 지나 간다. 참 빨리도 지나간다.

내가 처음 slipp.net을 기획할 때 만들고 싶은 커뮤니티는 개발자들이 소스 코드를 통해 더 많은 이야기를 나누고, 즐거워하고, 새로운 것을 배우는 공간으로 만들고 싶었다. 개발자들이 소스 코드로 이야기할 때 즐거움을 느낀다면 그 보다 더 좋은 것이 있겠는데. 아직까지 많은 개발자가 같이 하는 공간은 아니지만 4.5개월 동안 내가 소스 코드를 공유하면서 느낀 점을 이야기해보려 한다.

slipp.net의 최초 의도가 소스 코드를 통한 소통이었기 때문에 내가 먼저 이에 대한 시도를 했다. slipp.net은 지금까지 내가 개발하던 습관대로 개발을 진행했다. 하지만 개발을 하면서도 "이 방법이 맞을까?", "더 좋은 방법이 없을까?"라는 의문점을 가질 때가 많았다. 하지만 프로젝트를 진행할 때는 구현해야할 요구사항도 많았고, 팀 내에 이런 의문을 제기하는 것이 나의 치부를 드러낸다는 생각이 들어 쉽지 않았다. 그렇다고 온라인상에 내 소스 코드를 공유하고 의문점을 제시하는 것도 쉽지 않다. 하지만 커뮤니티의 활성화를 위해 일단 소스 코드를 하나씩 공개해 보기로 했다. 일차적으로 커뮤니티 활성화를 위해 소스 코드를 공개하면서 느낀 점을 공유해 본다.

다음 코드에 대한 테스트와 리팩토링을 어떻게 하면 좋을까? (http://www.slipp.net/questions/59)

slipp.net에 공개한 첫번째 소스 코드 공유였다. 얼마나 많은 개발자가 참여하고 의견을 남길까?라는 생각을 하면서 글을 적었다. 그런데 생각보다 많은 분들이 참여해 의견을 남겨 주었고, 나는 이 질문에 답변을 준 코드들을 참고해 소스 코드를 리팩토링했다. 이 때 리팩토링한 코드는 현재  slipp.net 소스 코드에 그대로 반영했다.

이 소스 코드를  공개를 통해 slipp.net 코드를 리팩토링한 것도 있지만 그 동안 잊고 지냈던 테스트 데이터를 Builder 패턴을 활용해 처리하는 부분을 다시금 떠올릴 수 있었다. clean code 책에서 이 부분을 찾아 다시 학습하고 이후의 단위 테스트는 이 방식을 활용해 테스트 데이터를 생성하도록 변경했다. 그 동안 테스트 데이터를 만들 때 뭔가 부족하다고 생각했는데 이 방식을 활용해 일정 부분 개선할 수 있었다.

slipp 태그 소스 코드에 대한 요구 사항 및 구현 방법은? (http://www.slipp.net/questions/70)

두번째 질문은 slipp.net의 핵심 코드로 구현되어 있는 태그 기능에 대한 질문이었다. slipp.net을 구현하면서 가장 많은 고민을 했고, 최종적으로 내린 결론은 유사한 형태의 데이터이지만 Tag, NewTag 두 개의 도메인으로 나누어 개발하는 것으로 결론을 내렸다. 태그 처리 부분에 대한 복잡도도 가장 높았다.

이 질문에 많은 질문, 답변, 해결책이 오고 갔다. 이 질문을 주고 받으면서 대략적인 pseudo 코드를 만들었다. 어떻게 개선해 나갈 것인지에 대한 대략적인 감을 얻을 수 있었다. 감을 얻을 후에 대대적인 리팩토링 작업을 진행했다. Tag와 NewTag를 하나로 합치는 작업을 하고, 태그 수를 증가시키거나, 감소시키는 부분에 대한 개선 작업을 하고, 전체적인 구조를 바꾸는 작업이었다. 시간 나는 틈틈이 일주일은 걸려서 리팩토링 작업을 진행했다. 최초 개발할 때보다 운영하면서 개선해 가는 작업이 더 힘들다는 것을 다시 한번 느낄 수 있게 되었다. 배포도 한번에 진행하지 않고, 두 번에 걸쳐 나누어 배포함으로써 내가 최종적으로 원하는 모습의 코드를 만들어 낼 수 있었다. 리팩토링과 관련한 모든 개선점은 slipp.net에서 의견을 준 개발자들을 통해 얻을 수 있었다. 그 동안 나 혼자만의 생각으로 가지고 있었다면 느끼지 못했을 부분이 많을 듯 하다.

guava를 활용해 Collection 데이터를 변환하는 방법 (http://www.slipp.net/questions/90)

다른 코드들도 있지만 세번째로 즐거웠던 경험은 위 글을 공유했을 때이다. 이 글은 slipp.net을 구현하면서 얻게 된 작은 tip을 공유하려는 글이었다. 이 글의 답변을 보면 알겠지만 내가 tip으로 제공한 작은 코드에 대한 다양한 다른 구현 방식을 제시하고 있다. 다양한 다른 방법 때문이 아니라 내가 지금까지 소홀히 생각하고 있었던 부분을 느낄 수 있었기 때문이다. 사실 이 코드는 정말 작은 코드이다. 하지만 이 코드에서조차 고민해야할 부분이 있다는 것을 느꼈다. 

Function<SocialUser, String> userToString = new Function<SocialUser, String>() {
    public String apply(SocialUser user) {
        return user.getUserId();
    }
};
 
Collection<String> userIds = Collections2.transform(searchedUsers, userToString);

위 소스 코드에서 "userToString이 어디에 위치하는 것이 좋은가?"라는 원론적인 질문이 등장한 것이었다. 답변을 보면 알겠지만 SocialUser에 static으로 가지는 것이 좋겠다는 의견이 있다. 나 또한 이 답변을 보니 그 방법이 좋겠다는 생각을 하게 되었다. 처음에는 아무 의도 없이 그냥 작은 tip을 공유하려고 쓴 글인데 내 자신이 더 많은 것을 배우고 느낄 수 있었다.

 

나는 더 많은 개발자가 소스 코드를 통해 소통하면서 즐거운 경험을 하기 바라면서 커뮤니티를 운영하고 있다. 하지만 커뮤니티를 운영하면서 가장 많은 것을 배우고 느끼는 것은 바로 내 자신이라는 생각을 다시 한번 하게 되었다. 소스 코드를 공개하고 tip을 공유하는 것이 다른 개발자를 위한 것이라 생각하겠지만 결과를 돌이켜 보면 내 자신에게 더 많은 도움이 되었던 경험을 계속해서 하게 된다. 내 자신의 성장을 바란다면 자신의 소스 코드를 꼭꼭 숨기기 보다는 좀 더 많은 사람들에게 공개하고 의견을 구한다면 점점 더 성장해 가는 자신의 모습을 보게 될 것이라 확신한다. 나 또한 아직까지 부족한 것이 많다고 느끼기 때문에 더 많은 소스 코드를 공개하고 더 많은 것을 느껴 나갈 계획이다.