- 팀의 모든 사람에게 쉽게 이해되는 코드가 있다면, 그거시 바로
클린코드
입니다.
- 클린 코드는 Author 외에도 읽고 개선할 수 있어야합니다. 그것을 바탕으로 모든게 쉬워집니다.
- 읽기 쉽고
- 수정하기 쉽고
- 확장도 쉽고
- 유지보수도 쉽고
- 팀의 규칙이 있고, 그 규칙을 지키세요!
- 바보같이 단순하게 유지하세요. 단순한 것이 항상 더 좋은겁니다. 복잡성을 줄이세요!
- 보이스카우트 규칙 -> Non-clean code를 발견했다면 수정하세요. (Leave the campground cleaner than you found it.)
- 항상 근본 문제를 찾으세요. 원인을 찾아내세요.
- 세팅값들 같은 경우는 코드의 최상단에서 받게해야합니다 (Keep Configurable Data At High Levels)
- 상속 / interface 를 if/else 나 switch/case 보다 선호해야합니당
- 멀티쓰레드 코드는 분리하세요!
- 과도한 Configuration 가능성을 만들지 마세요. (쓰지도 않는 옵션 만들어놓는 이야기인듯)
- 의존성주입(DI)를 사용하세요!
- 디미터법칙을 따르세요. 단일책임원칙에 가까움
- 일관적이게 작성하세요. 모두 유사하다면, 다른 이가 알아먹기 쉬울거에요
- 번수명도 이해를 돕는 도구입니다. 자세히 ... !
- Condition을 한번더 변수로 지정하던지, 다른 매소드로 빼던지 해서 캡슐화 합니다. 그런 컨디션은 찾기힘드니까 최대한 한곳에서 처리하세요 (변수면 매소드 상단에, 메소드면, 특정이름 그룹으로 하던지 한 클래스에 모으던지 등)
- 원시타입보다는 전용 클래스를 만드는게 더 좋아요 Value objects like a pro.
- 논리적 종속성을 피하세요. 예를들어,
밥먹는 시간 알리미
라는 클래스가 있다면,밥먹는시간
이 알리미 클래스에 들어있다면, 꽤나 골치아픕니다.회사시간규칙
이라던지밥관련변수
라던지회사규약
같은 것들로 나눈다음알리미
클래스에서 참조하면 어떨가요? - (일부로 실수를 유도하는게 아니라면) 부정적인 조건문은 피하세요
- 명확하고, 해당 변수를 잘 설명할수 있는 이름이 좋습니당
- 변수들이 구별하기 쉬워야해요!
- 소통을 위해 발음하기 쉬워야합니다!
- IDE등에서 검색하기 쉬워야합니다!
원주율
이나단위변환상수
등 매직넘버가 필요하다면 상수로 바꾸세요! 3.14 이렇게 써놓지 말기!Avoid encodings. Don't append prefixes or type information. 이거는 모-던 개발자들에게는 옛날이야기...
- 작아야함. 더, 더, 더!
- 한가지만 해야함
- 이름은 최대한 이해하기 쉽게, 설명이 충분히 되게 (이름만보고도 어떻게 구현했는지 알아야 베스트일듯)
- 인자가 적을수록 좋데요
- 사이드이팩트가 없어야합니다. (예를들어서 find 함수에서 이메일이 전송된다던지 ...?)
- flag 성 인자를 사용하지 마세요. 그럴꺼면, 여러 메소드로 빼서 상위에서 if else 로 하던지 다형성으로 해결하던지 ...
- 코드로 설명할수 있다면 베스트입니다
- 중복된 내용적지 마세요
- 쓸데없는 이야기 쓰지마세요 (
이거 쫌 어려움
이런거) - 주석은 코드 위에 다세요. 함수 끝나거나 블록 끝나는데 달지마세요 (Don't use closing brace comments.)
- 코드를 주석처리하지마세요. 그냥 지우세요 git이 있잖아요!
- 의도한 바가 특별히 있다면, 주석 사용할 수 있어요
- 코드에 대한 설명이 필요하다면, 주석 사용할 수 있어요
- 해당 코드가 발생할수 있는 결과 / 에러에 대해서 사용할 수 있어요
- 개념적으로 계층화 합니다 ex) ui / biz logic / external call(api) 등
- 관련된 내용들은 한눈에 볼수 있게 최대한 가깝게 붙여놓읍시다.
- 예륻들어 변수를 맨위에서 선언하고... 그거를 맨 아래서 쓴다면 너무나 햇갈리겠죠?
- 클린코드를 위한 종속함수는 private 으로 유지하세요
- 비슷한 함수들은 비슷한곳에 모여있어야합니당
- 기능을 아랫쪽 방향으로 합니다. 이게 뭔말이냐면, 종속함수들 예를들어
밥먹다
:밥주문
,결제
,먹기
라면class {public 밥먹다, private 밥주문, private 결제, private 먹기}
같은 순서로 코드가 짜여있다면, 이해하기 더 쉬운 코드일 것입니다. 왜냐면 논리적 흐름을 따라가는대로 코드가 있으니 ... - 최대한 작은 라인을 갖게하세요. (길면 보기 힘들어서 그런가 ... ?!)
수평정렬을 사용하지마세요.(저희는 해당사항 없음)(저희는 대부분 린트로 해결 ...)스페이스
를 사용하여 서로의 연관도를 밀접한지 아닌지 설정합니다.들여쓰기 규칙을 지키세요(저희는 대부분 린트로 해결 ...)
- 내부 구조를 숨기세요
- list, map 등 데이터 구조를 적극 활용하세요
- data면 데이터지, 데이터도 되고 비즈니스로직도 하는
엄청난
친구를 만들지마세요. - 역시나 작아야합니다
- 역시나 단일책임원칙을 지킵니다
- 인스턴스 variable의 수는 적으면 적을수록 좋습니다.
- Base Class는 상속되는 친구들에 대해서
당연히
아무것도 몰라야합니다. - 다양한 함수를 선언하는게, 인자받고 여러가지 기능하는 것보다 좋습니다 ... !
- static method 보다는 그냥 method 가 좋습니다. (왠만하면 객체에서 isDone 이런거 쓰라는듯)
- 하나의 테스트에서는 한가지만 검증합니다.
- 읽기 쉬워야합니다
- 빨라야합니다
- 독립적이어야합니다.
- 여러번 실행해도 동일한 결과가 나와야합니다.
- 쉬운 로직 변경을 위해 여러군데를 연속적으로 변경해야하는 경우는 안되요.
- 한 군데 변경하면, 여러군데에서 에러날 가능성이 있거나 에러가 나면 안되요.
- 다른 곳에서 복붙한다음, 조금 수정한다는 가정아래에서 사용하기 힘들 정도의 코드는 안되요.
- 불필요하게 복잡하면 안되요.
- 불필요하게 중복되면 안되요. (사용자 체크로직 등이 함수로 안빠져있고 여기저기 퍼져있는경우등?)
- 코드 이해하기 어려우면 안되요.