🌀가독성 좋은 코드, 언제쯤 가능할까 ;ㅅ;
변수명 짓기에 고민이 많았던 나는 읽기 좋은 코드가 좋은 코드다 라는 책을 추천받아 읽게 되었다. 팀원에게서 코드리뷰를 통한 피드백을 받았던 부분이 책에 고스란히 적혀있었고, 실제 내가 작성한 코드를 떠올리면서 고쳐야 할 부분을 계속 생각해볼 수 있던 시간이었다. 코드에 대한 시야가 약간은 넓어진 기분 !
기억에 남는 문장들을 적어보았다. 두고두고 기억해야 할 중요한 부분. 어쩌면 코드리뷰와 테스트코드를 잘할 수 있는 계기가 되지 않을까 싶다.
- 코드는 다른사람이 이해하는데 들이는 시간을 최소화하는 방식으로 작성되어야 한다. 일반적으로 분량이 적은 코드로 똑같은 문제를 해결할 수 있다면 좋다. 하지만 항상 분량이 적다고 해서 좋은 것은 아니다. 적은 분량으로 코드를 작성하는 것은 좋은 목표이지만, 이해를 위한 시간을 최소화하는게 더 좋은 목표이다.
- 이름에 정보를 담아라. 보편적인 이름 보다는 특별하고, 매우 구체적인 단어를 선택하여 무의미한 단어를 피해라.
- 좁은 범위에서 짧은 변수명은 괜찮다. 하지만 그렇지않다면, 이름에 의미를 분명하기 위한 정보를 만들기 위해 긴 변수명을 지어도 된다.
- 이름에서는 부정적인 용어를 피하는 것이 좋다.
get으로 시작하는 이름의 메소드는 가벼운 접근자로 단순히 내부 멤버를 반환한다고 생각한다. 그러므로 가벼운 연산을 수행하지 않는 메소드는 get보다는, 그 의미를 설명해줄 수 있는 문장을 적자.- 본인이 지은 이름을
"다른 사람들이 다른 의미로 해석할 수 있을까?"라는 질문을 던져보며 철저하게 확인해야 한다. - 좋은 소스코드는 "눈을 편하게" 해야한다. 미학적으로 보기 좋은 코드가 편하다.
- 주석의 목적은 코드를 읽는 사람이 코드를 작성한 만큼 코드를 잘 이해하는 것을 도와주는데 있다. 코드를 빠르게 유추할 수 있는 내용은 주석으로 달지 말아라.
- 나쁜 이름에 대해서는 주석을 달지 말고, 이름을 고칠 생각을 해라.
"좋은 코드 > 나쁜코드 + 좋은 주석"이다. - 주석에는 내가 이렇게 짠 이유나, 나만의 생각, 결함을 적어도 좋다. 사람들이 쉽게 빠질 것 같은 함정을 경고해라.
- 파일이나 클래스 수준에서는 큰 그림을 설명하고, 각 조각이 어떻게 맞추어지는지 설명해라.
- 단순한 케이스 보다는 코너케이스를 설명해주는 입/출력 예를 주석에 적어놓는 것이 좋다.
- 프로그래머는
if (10 ≤ legnth)보다는if (length ≥ 10)를,while (bytes_expected > bytes_received)보다는while (bytes_received < bytes_expected)를 더 읽기 쉽다고 생각하다. 왼쪽은 값이 더 유동적인"질문을 받는" 표현, 오른쪽은 더고정적인 값으로, 비교대상으로 사용되는 표현으로서 사용되고 있다는 것이다. 때문에bytes_received는 검사를 수행하고자 하는 대상으로, 루프가 반복될 때마다 값이유동적으로 변하고,bytes_expected는 더"안정적인" 값으로 비교에 사용된다.
- 조건문 블록의 순서
부정이 아닌 긍정을 다루어라.If(!debug) 가 아닌 if(debug)를 선호하자.- 간단한 것을 먼저 처리하자.
- 필요할 때, 함수 중간 부분에 코드가 반환되도록 작성하자. 이는 중첩을 피하고 코드를 더 깔끔하게 작성할 수 있다.
- 반복문, 조건문 사용 시
중첩을 최소화하자. 설명변수(요약변수)를 추가해 거대한 표현을 더 소화하기 쉬운 조각으로 나누어라.
- 드모르간의 법칙을 사용해보아라 (not을 분배하고, and/or 바꾸기)
"영리하게" 작성된 코드에 유의해라.나중에 다른 사람이 그 코드를 읽게된다면 혼란을 초래할 수 있다.- 중간결과를 저장하는 변수는 제거할 수 있는 가능성이 높다.
- 변수가 적용되는 범위를 최대한 좁게 만들어라.
- 변수는 항상 맨 위에 정의될 필요가 없다. 사용하기 바로 직전 위치로 옮기는 것이 좋다.
- 주어진 함수나 코드블록을 보고, 스스로에게 질문해보아라 "상위수준에서 본 이 코드의 목적은 무엇인가?" "이 함수는 만들어진 목적과 직접적으로
상관없는 하위 문제도 존재하는가?" - 일반적인 목적을 가진 코드를 많이 만들어라. 이는 프로젝트의 나머지 부분에서 완전히 분리되므로 좋다.
- 일반적인 목적의 코드를 프로젝트의 특정 코드에서 분리해라. 하지만 지나치게 추출하면, 가독성을 해칠 것이다.
- 한 번에 하나의 작업만 수행하게 코드를 구성해라.
- 다른 작업사이를 왔다갔다 하는 코드가 존재하는 경우,
디폴트 값을 먼저 설정한 후 조건에 따라 바텀업 방식으로 진행한다. - 코드베이스를 최대한 작고 가볍게 유지해라.
- 읽거나 유지보수하기 쉽게 테스트를 만들어라. 테스트코드는 읽기 쉬워야한다.
- Mock Data를 테스트코드에 주입할 때, 볼 필요없게 숨겨 더 중요한 내용을 눈에 잘 띄게 해라.
- 좋은 테스트 입력값을 선택해라. 가능하면 가장 간단한 입력으로 코드를 완전히 검사할 수 있어야 한다.
- 테스트를 가능하기 위해 실제 코드의 가독성을 희생시킨다? 실제 코드와 테스트 코드는 서로 윈-윈 상황이 되어야 한다. 테스트를 가능하기 위해 지저분한 코드를 넣어야 한다면, 무엇인가 잘못된 것이다.
테스트가 읽기 편하면 작성하기 쉬워지고, 따라서 사람들은 더 많은 테스트를 작성하게 된다.
android developer @bucketplace