Programmer!/Good Program

좋은 코드를 만들기 위한 방법

petitCoding 2023. 2. 27. 12:52

1. 코드 리뷰

가장 기본적이면서도 정확한 방법이라 할수 있다. 내 코드 또는 상대방의 코드를 컴퓨터의 도움 없이 눈으로 읽으며 잘못된 부분을 찾아내는 방법이다. 로직을 한눈에 살펴보기 어렵다면 다음 사항들을 위주로 진행하면 도움이 된다.

 

  • 오타가 있는가?
  • 적절하지 못한 변수/함수 타입을 사용했는가?
  • 사용하지 않(아도 되)는 코드가 있는가?
  • 함수명이나 변수명이 상황에 맞지 않는가?
  • 코드에 중복된 부분이 존재하는가?
  • 코딩 표준을 준수하였는가? 

 

신기하게도 코드리뷰를 하면 할수록 코드를 읽는 힘이 길러져서 나중에는 눈으로 발견하기 어려운 버그들도 찾아내는 경험을 할 수 있다.

코드 리뷰는 보통 git 에서 Pull Request를 생성하면 리뷰어들이 코드를 리뷰한 뒤 문제가 있는 부분에 커맨트를 달고, 그것을 개발자가 수정하는 방법으로 진행한다. 아주 기본적이면서도 중요한 부분이기 때문에 절대 이 부분을 소홀히 하지 말 것.

 

2. 테스트 기반 개발 (TDD)

사람의 눈으로 코드를 살피는 것은 아무래도 한계가 있기 때문에 TDD를 도입하는 것도 방법이 될 수 있겠다. TDD에 대해서는 부정적인 견해를 가진 사람도 꽤 많은데 그 이유는 테스트 환경을 구축하고 함수를 구현할 때마다 테스트 코드 또한 작성, 유지보수하는데 드는 시간과 노력을 무시할 수 없기 때문이다.

그럼에도 불구하고 나는 테스트 코드를 작성하는것을 매우 추천한다. 그 이유는 다음과 같다.

 

  • 테스트 코드를 작성하면서 내가 만든 함수의 input / output 을 한번 더 고민하고 더 효율적인 코드를 만들 수 있다.
  • 다른 사람들이 내 코드를 이해하기 편하다 - 테스트 코드를 통해 이 함수가 어떤 역할을 하는지 알 수 있기 때문이다.
  • 코드를 리팩토링할 때 수월하다  - side effect를 미연에 방지할 수 있고 내가 올바르게 코드를 리팩토링했는지에 대한 검증 또한 이루어지기 때문이다. 사실 이것이 TDD를 하는 가장 큰 이유이기도 하다.

 

너무 과한 TDD는 오히려 독이 될 수 있다. 물론 엣지 케이스를 잡아 내는게 중요할 수는 있지만 발생하지도 않을 엣지 케이스까지 모두 커버하기에는 유지보수에 상당히 많은 시간과 에너지가 소요된다. 적당한 커버리지를 유지하면서 코드를 관리하는 것을 권장한다. 

 

3. 코딩 표준 지키기

이것 역시 아주 기본적인 사항이다. 요새는 esLint, prettier등을 사용해 IDE에서 자동으로 코딩 표준에 따라 코드를 작성할 수 있기 때문에  사실 사람의 머리로 크게 신경 쓸 것은 없다. 단, 개발 환경을 잘 셋팅해 놓는 것이 무엇보다 중요하다.

 

4. 코드는 항상 간결하고 쉽게

혼자 개발을 하는 경우라 해도 코드는 간결하고 쉬워야 한다. 사실 이게 가장 어렵다. 부득이하게 복잡한 로직이 들어가서 기억을 못 할것 같다면 꼭 주석을 달아 놓도록 한다. 사실 코딩하는 순간에는 나는 무엇이든 기억할수 있을것 같다는 자신감이 들지만 단 하루? 아니 한시간만 지나도 이걸 왜 짰는지 기억이 안나는 경우가 100%이다. 

함수의 길이가 10줄을 넘어가면 복잡해지므로 최대한 간결하게 줄이거나 나누는 등 리팩토링을 하는것도 매우 중요하다. 코드는 어린아이도 이해할 정도로 쉬워야 하며, 코드 한 줄 한 줄에는 그 코드가 왜 존재하는지 납득할 수 있는 이유가 반드시 있어야 한다.

쓸 데 없이 길게 늘여쓰거나 직관성이 없는 코드는 그야말로 쓰레기이다.

 

반응형

'Programmer! > Good Program' 카테고리의 다른 글

Design Pattern  (0) 2012.08.28
S/W 계층 구조  (0) 2012.04.12
S/W Process  (0) 2012.04.12
Critical System  (0) 2012.04.12
소프트웨어 공학 - 프로젝트 관리  (0) 2012.04.12