좋은 코드란?
-
읽기 쉬운 코드
-
유지보수성을 가진 코드
-
코드를 처음 보는 사람도 쉽게 따라가며 읽을 수 있을 것
-
내 의식의 흐름을 기억하지 않아도 언제든 원하는 기능을 다시 찾아갈 수 있을 것
-
5년 뒤에 내가 다시 보더라도 금세 이해할 수 있을 것
-
새로운 기능을 추가하더라도 크게 구조변경이 없을 것
좋은 코드를 짜기 위해 아래 규칙들을 잘 지켜주면 좋다.
좋은 코드를 짜기 위한 규칙들
1. 변수명과 함수명을 짓는 방법
리소스 id로 content description을 가져오기 위해 getContentDescriptionByResId()라는 함수명이 쓰고 싶다.
함수의 기능에 대한 모든 정보를 담으려면 저 네이밍이 가장 마음에 드는게 너무 길어서 고민
결론은 서술적인 네이밍을 사용하는 것이 이상적.
간결하지만 의도를 다 표현하지 못하는 이름보다는 의도를 표현하는 긴 이름이 훨씬 좋다.
네이밍의 기준
-
발음하기 쉬운 - 읽기 힘든 변수명 쓰지 말 것
-
검색하기 쉬운 - 코드 찾는 사람이 ide에서 기능에 따라 검색하기 쉬울 것
-
의도가 드러나는 - 변수명/함수명을 보고 어떤 기능을 하는지, 어떤 목적을 갖는지 알 수 있을 것
2. 보이스카우트 규칙
‘캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라’
코드를 수정할 때 기존에 있던 코드를 조금이라도 더 깔끔하게 만들어 놓자는 의미
정리되지 않은 코드에도 새로운 기능을 추가할 수 있다.
이때 단순한 기능을 추가하더라도 기존에 있던 코드를 조금씩이라도 개선하는 습관이 필요하다.
3. 위에서 아래로 코드 읽기 : 내려가기 규칙
코드의 서술 순서는 가독성에 있어 상당히 중요하다.
어떤 클래스를 이해하기 위해 맨 위의 변수를 읽고 맨아래에 있는 함수를 이해하고 중간 메소드들을 한참동안 뒤적거려야 한다면, 뭔가 서술 순서가 잘못되었을 확률이 높다.
코드는 신문기사를 읽듯이 위에서 아래로 읽어 내려가며 이해할 수 있어야 한다.
기능은 위에서부터 아래 순서로 읽어내릴 수 있게 서술되어야하며 비슷한 기능은 서로 가까운 행에 배치하면 읽는 사람이 이해하기 쉽다.
4. 한번에 한가지 일만
저하나의 메소드는 한가지일을 수행해햐 한다.
여기에서 한가지 일이란 기능 단위에서 한가지의 일을 말한다.
5. 주석은 나쁜 코드를 보완하지 못한다
주석을 남용하지 말아라, 가급적이면 사용하지 말아라.
주석은 꼭 필요한 경우에 꼭 필요한 위치에만 사용해야한다.
6. 팀규칙
팀에서 정한 규칙에 따라 코드를 작성하는게 좋다
7. 모든 테스트가 돌아가게 하라 (TDD)
주로 통과할 테스트들을 미리 작성해둔 후,
코드가 조금 개선될 때마다 항상 이 테스트가 모두 돌아가는 상태를 유지해야한다.
참고
아래 블로그를 보고 작성한 글이다.
https://holika.tistory.com/59
