좋은 코드를 작성하기 전에 좋은 코드가 무엇인지 알고 넘어갈 필요가 있을 것 같다.
나는 클린코드
라는 책을 읽으며 좋은 코드를 작성하는 법을 배우고 있다. 해당 책에서는 소프트웨어 개발 분야의 몇몇 OG들의 코멘트를 인용하여 좋은 코드를 설명하고 있다. 이를 내 나름대로 요약하자면 좋은 코드란 아래와 같다.
- 명확하게 표현되어 읽기 쉬운 코드
- 테스트 코드가 잘 작성된 코드
- 고치기 쉬운 코드
이와 같은 요건을 만족하여 좋은 코드를 작성하기 위해서는 조금 더 세부적으로 공부하고 이해할 필요가 있다.
명확하게 코드를 작성해야겠다라고 생각만하고 코드를 작성한다고 명확한 코드가 나오는 것은 아니다. 예를 들어 메소드는 하나의 기능만을 수행한다던지, 변수명을 명확하게 작성한다던지 더 디테일한 기법을 적용하여 좋은 코드를 작성할 수 있을 것이다. 아마도 이 책을 계속 읽어 나가고 정리하다보면 이러한 것들을 이해하고 체득할 수 있을 것이라고 예상하고 기대한다.
좋은 코드는 '좋은' 코드이니깐! 과 같은 무책임한 이유 말고 정말 현실적인 이유는 무엇일까?
내가 생각하기에 가장 큰 부분은 유지보수성
이다. 소프트웨어 서비스는 소모품이 아니다. 한번 쓰고 버리는 것이 아니라 계속 쓸 것이고, 새로운 요건이 생기면 수정해서 사용할 것이다. 정말 서비스의 의도 자체가 쓸모 없어지지 않는 한 소프트웨어는 지속적이다.
법이 바뀌고 세상이 바뀐다. 그에 따라 비즈니스 요구사항도 역시 계속 변하기 마련이다. 내가 말하는 유지보수성은 기존 비즈니스 요구사항을 만족하며 새로운 요구사항에도 만족하는 코드를 작성하는 것이다.
그렇다면 변한 요구사항에 따라 소프트웨어의 특정 모듈을 수정해야하는 상황이라고 가정해보자. 나쁜 코드는 어떨까? 특정 모듈을 고치면 된다고 생각했는데 특정 모듈이 다른 모듈에서 의존성을 가진 모듈이다. 그럼 다른 모듈도 싹 다 고쳐야 한다. 하루 걸릴 일이라고 생각했는데 일주일이 걸리게 된다. 혹은 로직이 변함에 따라 버그가 초래되기도 한다.
따라서 애초에 좋은 코드를 작성해서 이러한 일들이 발생하지 않게끔 주의를 기울여야한다. 처음에는 돌아가는 길이라고 생각이 들지 모르겠지만 결국에 뒤돌아보면 지름길인 것이다.
좋은 코드를 작성하기 위해 기한, 공수 등의 조건에 전문가로써 적극적인 의견 전달이 필요하다. 즉 좋은 코드를 작성하는데에 더 많은 시간이 든다면, 관리자에게 적극적으로 어필하고 시간 투자가 되지 않았을 경우 어떤 사태를 초래할 수 있는지 말해야 한다는 것이다. 우리는 업무에서 전문가이자 프로이다. 나쁜 코드를 짜게 되는데에 변명할 것이 아니라 좋은 코드를 짜게끔 스스로 환경을 만들어 나가야한다.