좋은 코드스타일, 좋은 아키텍처에 대해 얘기하는 수많은 글귀들이 있다. 대부분 다 동의하는 내용일 것이다. 지역범수의 범위를 최소화해라.. 함수의 의도를 명확히 해라... 테스트 케이스를 작성해라... 등등 일반적이고 원론적인 이야기들.
나는 자바 개발자라서 그런지 몰라도, 항상 직접적인 의존관계를 최소한으로 줄일려고 노력하는 편이다. 내가 봤던 대부분의 책은 객체지향을 기초로 써져있는 책들이다 보니, 추상화시키는 습관에 대해서 많이 강조를 하는 편이기 때문이다. 복잡하고 방대한 프로그래밍의 세상을 단순하고 직관적으로 바라보면서 의존관계가 변경이 되어도 클라이언트의 입장에서는 변동이 없도록, 물론 그렇다고 꼭 추상화가 좋은 것만은 아니라는 걸 알고있다. 지나친 추상화는 도리어 코드의 실제 의도를 저 밑바닥으로 감추고, 당췌 코드가 뭘 의도하는 건지 파악하기 힘들게 한다. 자바같은 OOP진영에서는 모든걸 추상화 하려고 시도한다. JPA 같은 경우도, 구체적인 쿼리를 코드상에서 드러나지 않게 밑바닥으로 감추지 않나. 이 부분을 싫어하는 개발자들도 분명 있을 것이다. 특정 기술이나 구현에 종속되는 걸 벗어나는 위주로 계속 발전을 하다보면, 결국 나중에는 개발을 하는 게 아니라, 그냥 툴 사용을 배우는 수준으로 변하지 않을까 걱정하는 글들도 봤다.
언제나 선이 중요한 셈이다. 내가 생각하는 적정선..
별거 아닌 주니어 개발자지만, 나는 개인적으로 좋은 코드를 3가지 영역으로 구분한다.
- 가독성
- 생산성
- 효율성
아무리 개발실력이 뛰어나다고 하더라도, 누구나 직관적으로 알아보고 이해할 수 있는 코드를 작성하지 않으면, 그 개발자는 실력이 없다고 생각한다. 결국 개발은 혼자 하는 일이 아니므로, 다른 팀원이 유지보수할 수 있게끔 만들어줘야 할 필요가 있다. 코드가 좀 길어줘도 상관이 없다. 각 클래스, 함수마다 의도와 역할이 분명히 명시되고, 조립할 수 있게 모듈별로 쪼개도록 노력해야 한다. 본인이 아무리 실력에 자신이 있다고 하더라도, 이 부분을 신경 안 쓰면, 결국 시간이 지나고 다시 자기의 코드를 본다면 파악하기 힘들 것이다. 좋은 개발자는 네이밍컨벤션에서부터 그 흔적을 나타낸다. 가끔 네이밍컨벤션을 대수롭지 않게 생각하고, 자기 마음대로 짜진 코드를 보게 되는데, 볼때마다 참 곤혹스럽다. 네이밍컨벤션은 단순히 가독성만을 위한 게 아니다. 네이밍을 어떤 자기만의 규칙으로 일관적으로 짜게 되면, 이 공통된 특징을 이용해, 코드를 굉장히 유용하게 확장할 수 있다. 실제로 변수나 클래스에 대한 일정한 네이밍 규칙을 가지고, 기능을 구현하는 라이브러리, 프레임워크가 상당히 많다. 코드의 가독성이 확보된다면 주석 같은 경우도 불필요해진다. 이런 말하면 욕먹겠지만, 나는 주석을 굉장히 싫어한다. 주석보다는 테스트케이스를 훨씬 좋아한다. SI 개발자로 일하면서 주석에 뒷통수 데인적이 몇번 있다보니, (뭐 시나리오는 예상된다. 누군가 작업해놓은 코드를 후임자가 이어받았는데 수정해놓고 주석은 그대로 놨뒀겠지..) 주석을 신뢰하기보다, 무언가 독립적인 모듈로 짜져있어서 개별테스트하기 쉬운 코드조각을 훨씬 선호한다.
생산성이란, 객체지향적인 관점에서 코드를 유지보수하기 쉽고 확장가능하기 편하도록 만들어주는 걸 총칭하는 걸로 나는 여긴다. 이건 나만의 정의이다. 다른 사람들은 생각이 다르겠지.. 아무튼 보통 디자인 패턴에서 이런 경우를 찾아볼 수 있는 것 같은데, 아무래도 이거에 익숙하지 않으면 가독성이 떨어지는 부분도 분명 있단 말이지..
효율성은 프로그램 입장에서의 효율성을 이야기한다. 보통 알고리즘에서 많이 찾아볼 수 있는 것 같은데, (물론 알고리즘을 더 넓은 추상적인 의미로 생각할 수 도 있고, 꼭 알고리즘이 효율성이라는 것도 아니지만..) 암튼 메모리 최적화, 시간복잡도 같은, 성능을 끌어올리는 관점이라고 나는 생각한다.
가독성이 좋다고 해서, 생산성과 효율성이 좋다고 보장할 수 없다. 그 반대도 마찬가지이다.
세마리 토끼를 다 잡는 게 제일 베스트이겠지만, 현실적으로 세 마리의 토끼를 다 잡는 것은 매우 힘들다.
이 세 마리 토끼는 서로 어떤 부분에서는 반비례 관계?를 가지게 되어서, 생산성을 너무 좋게 하려고 하다가 효율성을 포기할 수 밖에 없는 상황이 올 수도 있고..반대도 마찬가지.. 물론 이 세가지 다 안 좋은 코드도 존재하고, 이 세가지 항목을 모두 높은 수준으로 충족하는 코드도 있겠지만, 대부분은 그 사이 어디선가 타협점을 보게 된다.
나는 웹 같은 추상화된 프로그래밍 분야에서는 가독성이 그 무엇보다 우선시되어야 될 필요가 있다고 생각한다. 최적화는 그 다음의 일이다. 결국 돌고 돌아 선이 중요한 셈이다. 내가 생각하는 적정선.. 이 적정선은 결국 짬으로 해결을 할 수 밖에 없다고 생각한다. 언제나 상황은 케이스바이케이스니까, 어떤 전략을 선택할지는 경험밖에 답이 없는 것 같다..
개인적인 똥글이었다..
