코드 가독성에 대해 (feat: KISS, Boy scout rule)

 

개요

코딩을할때 어떤 방법이 100% 옳다라는 정답은 없지만 코드의 가독성에 대해 생각하고 작성 한다면 추후에 같은 코드를 보면서 개발을할때 훨씬 수월하게 할 수 있다는 생각은 100% 맞는 말 같습니다.

 

이 포스팅은 사내 그룹스터디 할때 토픽이 되었던 주제인데, 좋은 글인거같아 정리삼아 포스팅을 하려고 합니다.

아래의 포스팅 전체의 내용을 다루는것보다, 사내 스터디를 할때 기억에 가장 남은것들만 우선 정리한 포스팅 입니다.

 

 

1. 코드의 가독성은 왜 높아야할까?

어떤 feautre을 개발한다고 칩시다.

저는 프론트엔드 개발자이니까 보통 기획과 디자인 그리고 백엔드 개발자에게 디자인 리뷰 , API interface등 리뷰를 받고 개발을 진행 한적이 많은데, 리뷰를 받고 feature 개발 하기까지의 2주라는 시간이 소요된다고 가정하에, 이 2주동안은 feature의 대한 이해, 왜 개발을 하는지? 어떤 기획의 의도가 있는지를 파악을 한 상태에서 개발을 할것입니다.

예를들어 변수명 및 함수명을 마감기한이란 압박때문에 5분 조차 고민 안하고 생각나는 대로 지었고, 어떻게 개발 완료를 해서 배포까지 완로 되었습니다.

하지만 한달 후 , 다른 feature 개발 후 전에 개발하던것에서 에러가 터지거가, 추각개발건이 있다고 가정하에 변수명과 함수명을 대충 지었다는 이유로 전체적인 로직을 한번 쭉 훑어봐야하는 불상사가 생길 수 있습니다.

또 다른 이슈는 제가 휴가를 가거나 Day off인날은 다른 개발자가 제 코드를 무슨 생각으로 짰는지 파악할때 변수명과 함수명을 잘 지었으면 코드 파악하는것이 훨씬 수월 했겠죠.

 

5분 생각해서 변수 명을 고민하거나 적절한 주석을 다는 것으로 다른 개발자(미래의 자기 자신도 포함)가 1시간 고민하는 일을 막을 수 있을지 모릅니다. 중요한 것은 단기적이고 개인적인 생산성이 아니라 상품의 라이프 사이클 기간에 걸친 팀 전체의 생산성입니다

 

코드의 가독성을 높게 코드를 작성하는 방법론은 매우 많지만 아래의 간단한 예제를 통해서 변수명이 왜 중요한지 파악해보겠습니다.

  function checkLegalDrinkingAge(age:number):boolean{
    if(age > 19){
      return true;
    }else {
      return false;
    }
  }

 

사실 위의 코드예시는 함수명과 age라는 파라미터를 보고 "19" 라고 되어있는 부분이 어떤 값인지 유추 할 수 있습니다.

하지만 19를 변수로 따로 관리 해서 예를들어 const LEGAL_DRINKING_AGE = 19 라는 constant 로 따로 관리하면 어떤 의도로 19를 작성했는지, 또는 19가 어떤 의미인지 더 잘 파악 할 수 있겠네요.

 

코드의 가독성을 중시해야 할지 결정하는 기준은 코드를 읽고 해석하는 데 드는 시간과 코드를 작성하는 데 드는 시간을 비교하는 것입니다.

 

 

 

2. 프로그래밍 원칙

견고하고 가독성 높은 코드를 작성하기 위해서는 프로그래밍 원칙에 따르는 것이 유용한 경우가 많습니다. 본 장에서는 코드의 가독성을 고려할 때 특별히 중요한 것뿐만 아니라, 혹시 과도하게 적용해도 부작용이 별로 없는 프로그래밍 원칙 5개가 참고 포스팅에 있지만 저는 2개정도만 정리하려고합니다.

 

2-1. The boy scout rule

The Boy Scout Rule 이 원칙은 "코드를 변경할 때마다 더 깔끔하게 만들어라"라는 생각을 기반으로 합니다. 보이스카우트 운동의 창시자 Robert Baden-Powell의 격언에서 영감을 받아 Robert C. Martin이 소프트웨어 개발에 적용한 원칙입니다.

 

 구체적인 예시로, 코드를 수정하는 과정에서 변수명을 더 명확하게 변경하거나, 필요한 주석을 추가하고, 불필요한 코드를 제거하는 것이 포함됩니다. 이 원칙의 핵심은 코드를 만질 때마다 전반적인 코드베이스의 질을 향상시키려는 노력입니다. 예를 들어, 복잡한 switch 문에 새로운 케이스를 추가하는 대신, 전략 패턴(strategy pattern)을 사용하여 리팩터링하는 것이 이 원칙을 따르는 좋은 예시가 될 수 있습니다.

 

2-2. KISS (Keep It Simple Stupid)

이 원칙은 "항상 간단하게 유지해라"는 의미로, 복잡성을 최소화하고 단순성을 유지하는 것을 강조합니다.

 

원래는 군사 장비의 설계 원칙으로 사용되었으나, 소프트웨어 개발에도 적용됩니다. KISS 원칙은 특히 기능과 구현 방식을 단순하게 유지하는 것을 지향합니다. 복잡하고 고도로 추상화된 코드보다는 이해하기 쉽고, 유지 관리가 용이한 코드를 선호합니다. 이 원칙의 핵심은 목적과 수단의 구분입니다. 프로그래밍 기법과 패러다임, 설계 방법은 코드의 가독성과 견고함을 향상시키기 위한 수단이어야 하며, 그 자체가 목적이 되어서는 안 됩니다. 예를 들어, 리액티브 프로그래밍이나 다른 고급 기법을 단지 그것이 "아름답다"거나 "일관성이 있다"는 이유로 사용하는 것은 KISS 원칙에 어긋납니다.

 

이 두 원칙은 모두 코드의 가독성과 유지 보수성을 높이는 데 중점을 두고 있으며, 좋은 소프트웨어 개발 관행의 일부로 널리 인정받고 있습니다.

 

KISS의 간단한 예로 자바스크립트 삼항연산자로 예를 들겠습니다.

const age = name === 'john' ? 20 : name === 'tom' ? 19 : name === 'zed' ? 30 : null;

 

이러한 삼항 연산자가 있다고 가정해보면, 이 정도 deps의 조건이면 그냥 if else문을 적나라하게 쓰는게 훨씬 가독성이 좋습니다..

Simple Stupid 처럼요. 

 

다른 개발자가 저 코드를 파악하려면 예를들어 10분 걸릴것을, 간단한 if else문으로 작성하면 3분도 안되는 시간에 파악 할테니까요.

아래 처럼 말이죠.

if (name === 'john') {
    return 20;
} else if (name === 'tom') {
    return 19;
} else if (name === 'zed') {
    return 30;
} else {
	return null;
}

 

 

저는 2년차때쯤엔 코딩테스트를 보다가 구현사항을 10줄이 넘게 코드 작성을 했었는데, 다른 분은 2줄이면 구현을 해버리는것을 본 뒤로

2줄로 구현하는게 가독성이 좋고, 간결해서 구현사항에 더 유리할 줄 알았었습니다. 하지만 지금은 그게 좋지만은 아닌것 같습니다.

특히 코딩테스트는 개인이보는거지만 실무에선 협업, 즉 다른 사람들과 항상 함께 같이 일을 하니까요.

 

사내 컨벤션이 있다면 컨벤션에 최대한 따라주면서, 컨벤션이 잘못된거같거나,개선사항이 있으면 좋을것 같은것들은 항상 팀원들과 얘기하면서 코드 가독성을 개선하면서 개발을 해야 할것 같습니다.

 

KISS reference

https://medium.com/@ksekwamote/keep-it-simple-stupid-how-it-applies-in-javascript-113b1c4e77a8

https://www.linkedin.com/pulse/best-practices-writing-javascript-code-dry-kiss-yagni-emmanuel/

 

 

참고한 포스팅: https://engineering.linecorp.com/ko/blog/code-readability-vol1