이 글을 읽고 댓글을 읽기 전까지 이렇게 하는 게 맞나 싶었다.
이 글에 나오는 코드 짧게 쓰기, 글자 하나만 사용하기 등 여러 목차의 내용을 읽다보면 그럴싸 하지만…. 협업적인 측면에서 봤을 때 이게 옳은 방향성인가? 라는 생각을 했기 때문이다.
다행히 많은 댓글에는 이렇게 하면 안된다고 나와 있었고, 해당 글의 마지막에도 “편법을 많이 사용하면 유지 보수하기가 힘들어져서 당신을 해고할 수 없게 됩니다.” 라고 나와 있었다. 즉, 이렇게 하면 안된다는 의미 ^^
list
→ lst
.userAgent
→ ua
.browser
→ brsr
.그래도, 모든 내용이 무의미 했던 것은 아니다. 인상 깊었던 것 중 하나는 위와 같이, “약어 사용하기” 였다. 회사에서 프로그래밍을 하는데, 다른 인원이 개발을 참고하다 보면 어떤 인원은 변수명에 약어를 즐겨 사용하고, 또다른 인원은 Full name을 즐겨 사용한다. 여기서 나는 개인적으로 Full name을 즐겨 사용한다.
약어를 즐겨 쓰는 분들에게 물어보니 대부분 코드 길이에 초점이 맞추어져 있거나, 자신만의 편의성(?) 때문에 약어로 Naming을 한다고 말해주었다.
반면 나는, Naming을 약어로 할 경우 협의성이나 내가 나중에 유지보수를 하려고 해당 파일을 봤을 때 해당 약어를 유추하지 못 할 가능성을 대비하기 위해 Full Naming을 사용한다. 뭐, 결국에는 해당 팀이 어떻게 변수명을 Naming 할 것이냐 결정되는 게 Best 이기는 하겠지만, 나는 Full Naming이 좋다.
해당 글의 마지막에 나온 “편법을 많이 사용하면 유지 보수하기가 힘들어져서 당신을 해고할 수 없게 됩니다.” 는 웃픈 말이기는 하지만, 글쎄 유지 보수가 하기 힘들면 나도 힘든 거자나 ㅋㅋㅋㅋㅋ…..
아무튼, IT 글을 읽고 재밌게 봤던 것은 오랜만이었던 것 같다. 다른 목차들도 다 의미는 있는 바이지만, 글쎄… 이건 고수로 가는 것이 아니라 내가 날 더 힘들게 하는 방식인 것 같다.