Today I Learned - Day 56 [코드 가독성에 대하여]

인터넷을 뒤져보면 별의 별 방식으로 가독성을 무너뜨려놓은 개그용 코드를 볼 수 있다.

[형... 으로만 작성한 코드라거나... 세미콜론 등을 위에서 define 해 놓고 생략시킨 코드라거나...]

물론, 개그용 코드인 만큼 반응 자체가 격하지는 않지만, 전체적으로 '명치 한 대 강하게 때리고 싶다'는 의견이 주를 이루는 걸 볼 수 있다.

그리고 실제로도 저런 코드를 보게 된다면 보안용이 아닌 이상 명치 한 방으로는 끝나지 않을(...) 격한 환영을 받게될것이기도 하다.

 

그럼 반대로 생각해 보자.

'가독성이 좋은 코드란 무엇일까?'

오늘의 주제는 바로 이것이다.

---

일전에 스파게티 코드에 대해서 정리했던 적이 있다.

[TIL - Day 4 [스파게티 코드에 대해서] (URL: https://lsu0503.tistory.com/44)]

이런저런 말을 다 생략하고 해당 게시글의 핵심 만 정리하면 '스파게티 코드는 이해하기 힘든 코드다'라는 내용이었는데, 오늘의 주제도 이와 동일하다. 다만, 스파게티 코드에 대해서 다룰 때에는 컨벤션과 SOLID법칙에 해당하는, 간단한 내용 만 작성했었는데, 본 게시글에서는 그 쪽 보다는 구성에 대해서 서술할까 한다.

 

그럼, 살짝 살펴보도록 하자.

---

캐싱

컴퓨터에는 캐시 메모리라고 하는 장치가 있다.

CPU가 사용할 자료를 미리 담아둠으로써 CPU의 성능을 높이기 위한 장치로, 사실상 'CPU가 메모리에 접근하는 시간을 줄여서' 성능을 높이는 장치다.

캐싱 또한 이와 유사하다.

 

캐싱(Caching)은 '자주 사용하는 코드를 하나의 변수 내지는 매크로로 지정하여 줄이는 행위를 의미한다.

즉, 반복적으로 나오는 다소 길이가 긴 참조문을 변수로 저장해서 한 눈에 볼 수 있도록 구성하는 것.

이렇게 사용하면서 반복적으로 등장하는 코드는 작성 시간을 소소하게 줄일 수 있고, 그렇지 않아도 '이것은 그러한 것이다'하고 한 눈에 볼 수 있도록 만들 수 있다.

이외에도 클래스 여럿을 타고 들어가야 하는 변수를 캐싱해 놓을 경우에는 복잡한 상관관계도 정리할 수가 있다.

거기다가 소소하게 string값 같은 경우에는 오타 방지도 가능하다.

 

사실상 안 하는 것이 더 손해인 기술인데, 이를 안하는 이유가 뭐냐면 보통은 무심코 지나쳐서다.

작성하다 보면 일일히 타이핑하고 있던 경우가 대부분이라는 것.

문제는, 이 캐싱은 초반 부터 하는 게 효율이 매우 좋다는 점.

그러니, 캐싱에 유의하여 작성하는 습관을 기르는 것이 좋다.

 

그리고, 자주 안나오는 것이더라도 장황하다 싶으면 캐싱을 하자.

캐싱의 주요 목적은 자주 나오는 코드의 정리이기는 하지만, 궁극적인 목표는 '가독성'이라는 점에 유의해야 한다.

---

메소드

메소드는 '클래스의 가장 기초적인 둥작 단위로서의 함수'를 의미한다. 당연하지만 객체 지향의 가장 기초적인 내용이기도 하니, 모르는 사람은 없을 것이다.

그렇다면 과연, 이 메소드를 개발자는 매번 잘 지키고 있는 것일까.

숙련된 사람이라서 메소드를 나누는 습관이 길러져있다면 몰라도, 초심자는 아마 자주 어그러질 것이다.

 

그렇다면, '메소드를 지켜서 작성한다' 라는 것은 무엇일까.

이걸 정리하기 전에 '메소드'로 나눠서 작성하는 이유에 대해서 먼저 언급해야 할 것 같다.

함수를 메소드 단위로 나눠서 적는 이유는 각 동작을 독립적, 직관적, 범용적으로 표현하기 위해서다.

독립적으로 작성하여 다른 함수의 변화에 받는 영향을 최소화하고, 직관적으로 작성하여 가독성을 높이며, 범용적으로 작성하여 해당 동작이 필요하다면 그저 호출만 하면 되도록 만들기 위해서 사용하는 것이 '메소드'라는 개념이라는 것이다.

 

사실 이건 본인도 잘 지키지 못하고 있는 요소중 하나다.

동시에 못 보고 지나치기도 쉬운 요소 중 하나.

때문에 리팩토링을 할 때에 유의깊게 살펴봐야 하는 요소 중 하나이기도 하다.

---

모듈화

이 역시도 각 클래스를 최소 기능 단위로 나눠서 작성한다는 개념으로,

모듈화의 목적 역시도 각 기능을 독립적, 직관적, 범용적으로 표현하기 위함이다.

그 영향 역시 메소드와 동일하다. 즉, 각 기능을 독립적으로 작성하여 다른 클래스의 변화에 받는 영향을 최소화하고, 직관적으로 작성하여 가독성을 높여서 유지보수 편의성을 높이면서, 범용적으로 작성하여 해당 기능이 필요하다면 그저 갖다 끼워 넣기만 하면 되도록 작성하기 위해서 사용하는 개념이라는 것.

 

그리고 개발을 할 때에 가장 지키기 어려운 내용이기도 하다.

기능을 작성하다 보면 분명 계획을 세밀하게 세웠어도 못 보고 지나치거나 오류가 나거나 시간이 부족하거나 등등으로 정신없이 작성하다 보면 항상 어그러져 있는 요소이기 때문.

리팩토링을 하는 이유도 이러한 모듈화를 나중에라도 준수하도록 수정하기 위함이라고 봐도 될 것이다.

 

특히 이쪽은 가독성 이외에도 재사용성에도 매우 크게 관계되는 내용인지라, 작업하는 도중에 계속해서 신경을 써야한다.

---

여기에 추가로 주석이나 헤더 같은 부연 설명 요소를 사용하는 것도 좋다.

다만, 이 둘의 경우에는 오히려 이로 인해서 오히려 코드가 눈에 잘 안보이는 역효과가 일어날 수도 있기 때문에, 작성한 주석이 많거나 길다고 한다면, 코드에 '중단점'을 배치하는 것이 좋다.

 

가독성은 개인 제작에서 유지 보수는 물론, 협력 상황에서도 매우 중요한 요소다.

거기다가, 상술한 내용을 지키다 보면 독립성도 같이 챙길 수 있기도 하다.

그렇기 때문에라도, 오늘 내용은 유의깊게 생각 해 보는 것을 추천한다.