전체 글81 3. 함수 작게 만들어라 중첩 구조가 생길만큼 함수가 커져서는 안된다는 뜻이다. 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 당연한 말이지만, 그래야 함수는 읽고 이해하기 쉬워진다. 한 가지만 해라 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 함수 당 추상화 수준은 하나로 함수가 확실히 한 가지 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다. 특정 표현이 근본 개념인지, 아니면 세부사항인지 구분하기 어려운 탓이다. 그리고 구분하기 어려워지면 세부사항에 세부사항을 더 붙이는 복잡한 함수가 된다. 위에서 아래로 내려가기 규칙 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 .. 2022. 7. 13. 2. 의미 있는 이름 의도를 분명히 밝혀라 로직이 간단한 것보단, 이름이 간단 명료한 것이 좋다. 그릇된 정보를 피하라 유사한 개념은 유사한 표기법을 사용한다. 일관성이 떨어지는 표기법은 그릇된 정보이다. 개발자는 대부분 (객체에 달린 상세한 주석이나 제공하는 다른 목록을 보고 선택하기 보다는 이름만 보고 객체를 선택하는 경우가 대다수이다.) 의미있게 구분하라 customerInfo 와 customer / accountData 와 account 는 구분이 가지 않는다. 읽는 사람이 차이를 알도록 이름을 지어라. 발음하기 쉬운 이름을 사용하라 genymdhms (generate date, year, month, day, hour, minute, second) 라는 단어의 조합은 발음하기도 어렵고, 토론하기도 어렵다. 검색하기 .. 2022. 7. 13. 1. 깨끗한 코드 코드가 존재하리라 어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능 하기에 코드가 사라질 가망은 없다. 궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심 나쁜코드 나쁜 코드에 발목이 잡혀 고생한 기억은 많다. 실제로 고행이라는 이름도 있다. 어째서 나쁜 코드를 짰는가? -> 당장 급해서, 서두르느라 자신이 짠 쓰레기 코드를 쳐다보며 나중에 고쳐야겠다고 생각한다. But, 나중은 오지 않는다. (르블랑의 법칙) 나쁜 코드로 치르는 대가 나쁜 코드는 개발 속도를 크게 떨어뜨린다. -> 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생기기 때문 -> 결국 생산성이 0에 수렴 -> 재설계를 시작 -> 기존의 것을 100% 수용하지 않으면 관리층에서는 대체하려고 하지 않을 것이고, 오.. 2022. 7. 13. 이전 1 ··· 11 12 13 14 다음