개발자에게 좋은 코드란?

함수를 선언식으로 만들어 오다가, 어떨때는 표현식으로 된 함수를 복사해서 가져와서 치다보면서 "아 지금 좋은 코드를 쓰고 있지는 않다"는 생각을 하면서도 이미 혼용된 함수 선언 방식을 프로젝트 내에서 전부 바꿀 수 없기 때문에 그냥 사용하곤 했다. 그렇게 코드를 치다가 내가 지금 치고있는 코드가 좋은 코드일까? 라는 생각을 했었다.

요즘 협업프로젝트중 1개를 리팩터 하며 지내고 있는데, 문뜩 좋은 코드란 무엇일까? 라는 의문을 품었고, 오늘 블로그에 정리할 것이다.

 

일단 내가 지금 생각하는 좋은 코드란? 이렇다.

-일관성 있는 코드

-변수명만 읽어도 그 의미를 어느정도 짐작하기 좋은 코드(함수이름이나, 변수)

-함수가 2번이상 사용되어야 하는경우 재사용되도록 밖으로 나와 있는 코드

-함수 설계시 입력값만 사용하도록 되어있는 코드

-함수는 한가지 일만 하도록 설계되어 의존성이 낮은코드

-복잡한 코드의 경우 주석이 꼼꼼하게 들어간 함수

 

지금 당장 생각나는 것들은 위와 같다. 물론 다 지켜지고 있지는 않다. 아무튼 내 생각은 이런데 실제 좋은코드라고 여겨지고 있거나 대세를 알고 싶었다. 그래서 조금 찾아보고 좋은 코드라고 여겨지고 있는 특성은 무엇이 있는지 공부해보았다.

 

찾아보니 결론은, "해답정도는 있으나 정답은 없다"인것 같다. 사람의 성격에 따라, 처한 환경에따라, 산업의 특성에 따라 등등 다 다른 관점이 있고 그 각각의 관점에서의 좋은 코드는 달라지기 때문이다. 그래서 코드를 말할때 '좋은' 이라는 말은 코드를 수식하기에 무리가 있다는 것을 알았다. 그래서 '좋은코드'란 말 대신 지금 당장 떠오르는 말은 '지향해야할 코드'라는 말로 정리를 해보았다.

 

내가 생각하는 지향해야할 코드

1.일관성 있는 코드

-함수를 만들때 선언식이나 표현식 중 한가지로만 통일해서 써야한다.

-변수명 또한 camel, snake, pascal방식 중 1가지로 통일해야한다.

-특수한 경우가 아니라면 리액트를 사용할때도 함수형, 클래스형 중 한가지 로만 사용한다.

 

2.변수명만 읽어도 그 의미를 어느정도 짐작하기 좋은 코드(함수이름이나, 변수)

-변수명 짓기 권장 법칙도 중요하지만 의미를 쉽게 알려줄 수 있으면 좋은 것 같다.

 

3.함수가 2번이상 사용되어야 하는경우 재사용되도록 밖으로 나와 있는 코드

-관리 및 효율이 좋아진다.

 

4.함수 설계시 입력값만 사용하도록 되어있는 코드

-입력값만 다루면 버그를 최소화 할 수 있을 것이라 생각한다.

 

5.함수는 한가지 일만 하도록 설계되어 의존성이 낮은코드

-가능하다면(물론 실력이..) 함수를 여러개 만들게 되더라도 한가지일만을 하게 만들어 심플하게 만드는게 버그를 최소화 할 수 있다고 생각된다.

 

6.복잡한 코드의 경우 주석이 꼼꼼하게 들어간 함수

-기능을 구현하다보면 어쩔수 없이 복잡한 코드가 생길 수 밖에 없는데, 그럴때는 나중에 다시 코드를 봐야하거나, 협업의 경우 팀원이 볼때를 대비해서 주석으로 설명을 달아둔다면 가독성을 올릴 수 있을 것이다.

-사실은 주석이 없는코드가 더 좋다. 주석 없이도 이해가 되는 코드가 최고이지만, 그렇게 될 수 없을 때 선택하는 최후의 수단이 주석이라고 생각.

 

7.표현적 가독성이 좋은 코드

-눈에 잘 들어오고 읽기 편한 코드

 

8.기능적 가독성이 좋은 코드

-함수, 변수들의 동작, 역할, 관계를 쉽게 파악할 수 있게 하는 코드

-남이 봤을때 이해가 잘되어, 따로 설명하는데 시간을 쓰지 않아도 되는 코드

 

9.유지보수가 용이한 코드

-유지보수가 용이한 코드는 추후 관리시간을 줄여주고, 장기적으로 봤을때 버그 감소, 유지비용 감소 등 여러 장점이 있다.

 

10.프로토타이핑 코드(급변하는 비즈니스 요구사항을 만족 시킬 수 있는 코드)

날림코드라는 말이 이해를 도울것이라 생각한다. 상황에 따라 빠르게 기능을 완성시켜야할 때가 있다. 통상적인 좋은코드의 모든 조건을 충족시키지만 비즈니스 요구사항을 만족시키지 않는 코드는 좋은 코드라고 할 수 없다고 생각한다. 실제로 파이널 프로젝트때 한번도 사용해본적없는 kakao map api를 사용하여 사용자 위치에 따른 마커정보를 불러와야하는 상황이 있었고 실제로 부담감을 느꼈다. 프로젝트의 핵심 기능이었기에 구현하지 못한다면 새로운 프로젝트를 하기 위해 한주 동안 했던 SR을 갈아엎고 새로 SR을 해야하는데, SR을 1주하고, 기능구현테스트를 1주하고, 다시 새로운 SR을 1주하게되면 4주 프로젝트에서 개발기간은 1주밖에 되지 않는데, 그러면 프로젝트는 기간내에 할 수 없을 뿐더러 망했다고 보면되겠다. 그래서 이 때 오로지 기능구현만을 빨리 할 수 있도록 코드를 쳤던 기억이 있다. 다행히 기능 구현이 가능하다는 것을 테스트해보고 프로젝트를 유지할 수 있었다. 주어진 시간이 짧거나, 요구사항이 자주 바뀌는 환경에 있다면 어쩔 수 없이 이런 프로토타이핑 코드가 가독성떨어지고 중복함수들이 섞여들어가도 좋은 코드라고 말할 수 있을 것 같다.