✨ Clean Code 9장: 단위 테스트 📌 TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. TDD는 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구하고 있다. 이렇게 하다 보면 많은 테스트 케이스가 나오게 된다. 하지만 실제 코드와 맞먹을 정도로 테스트 코드는 방대해지며 이에 대한 관리 문제를 유발하기도 한다. 📌 테스트 코드는 깔끔하게 유지하자. 테스트 케이스의 중요성 개발자들은 코드의 유연성, 유지보수성, 재사용성에 대한 중요성을 알고 있다. 해당 단원에서는 이러한 중요성에 대한 버팀목이 단위 테스트라고 소개한다. 이유는 테스트 케이스가 있으면 변경에 두렵지.. ✨ Clean Code 7장: 오류 처리 🗣 서론 오류 처리는 프로그램에 반드시 필요한 요소 중 하나이다. 잘못된 가능성은 늘 존재한다. 우리는 이러한 잘못된 점을 잡을 책임이 있다. 깨끗한 코드와 오류 처리는 확실하게 연관성이 있다. 여기저기 흩어진 오류 처리 코드로 실제 코드가 하는 일을 파악하기 어려울 때가 있기 때문이다. 따라서 우리는 깔끔하게 오류를 처리하는 기법과 고려 사항들을 인지하고 있어야 한다. 📌 오류 코드보다 예외를 사용하라 오류 플래그나 호출자에게 오류 코드를 반환하여 오류를 처리하는 방법은 논리와 오류 처리 코드가 뒤섞여 깔끔하지 못하다. 오류가 발생하면 오류를 던지는 편이 훨씬 좋다. 그러면 호출자 코드가 더 깔끔해진다. 📌 Try-Catch-Finally 문부터 작성하라 try 블록은 트랜잭션과 비슷하다. try에서 .. ✨ Clean Code 6장: 객체와 자료구조 📌 자료 추상화 아래 두 코드는 2차원 점을 표현했다. 두 번째 코드는 인터페이스로 자료 구조를 명백하게 표현한다. 첫 번째 코드는 변수를 private로 선언하더라도 값마다 get/set 함수를 제공한다면 구현을 외부로 노출시키는 것은 마찬가지다. 따라서 추상 인터페이스를 제공하여 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미를 가지는 클래스를 나타낼 수 있다. 즉 개발자는 객체의 자료를 표현할 가장 좋은 방법을 신중하게 고민해야 한다. 생각 없이 get/set 함수를 추가하면 안 된다. public class Point { public double x; public double y; } public interface Point { double getX(); double getY.. ✨ Clean Code 5장: 형식 맞추기 📌 형식을 맞추는 목적 코드 형식은 의사소통의 일환으로 중요한 부분 중에 하나이다. 오늘 작성한 코드는 변경될 가능성이 높다. 따라서 오늘 작성한 코드의 가독성은 앞으로 많은 영향을 미칠 수 있다. 즉 유지보수와 확장성에 영향을 미칠 수 있어 코드 형식에 대해 깊게 고민할 필요가 있다. 코드 형식을 생각하지 않고 마구잡이로 개발하다 보면 내가 지금 제대로 하고 있는지 의심만 가득 생길 수 있다. 📌 적절한 행 길이 유지하기 소스 코드 길이가 길수록 이해하기 힘들다. 아무래도 짧은 코드가 이해하기 쉽다. 대다수 신문 기사는 짧은 것을 볼 수 있다. 날짜, 이름, 사실 등 뒤죽박죽 섞은 기사를 읽는다면 금방 읽다가 포기할 것이다. 코드는 신문 기사와 같다. 간단하고 짧게 이루어져야 한다. 대부분의 코드는 왼.. ✨ Clean Code 3장: 함수 🗣 서론 함수가 읽기 쉽고 이해하기 쉬우려면 어떻게 해야 할까?, 의도를 분명히 표현하려면?, 처음 읽는 사람이 프로그램 내부를 직관적으로 파악하기 위해선? 이와 같은 질문에 답변하기 위해 몇 가지 방법을 소개하고자 한다. 📌 작게 만들어라 함수를 만드는 규칙은 첫째도 작게, 둘째도 작아야 한다. 켄트 백의 코드를 보면 모든 함수가 2~4줄 정도라고 한다. 그렇다면 작게 만들어야 하는 이유는 무엇일까? 이에 대한 근거를 명확히 제시하기는 어렵다. 함수가 크면 그 만큼 많은 일을 하고 있는 것이 아닐까? 블록과 들여쓰기 중첩 구조가 생길만큼 함수는 커지면 안된다. 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다고 책에서 소개한다. 하지만 극단적으로 1단을 유지하는 연습을 하는 것이 좋겠다. 📌 한 가지만 .. ✨ Clean Code 2장: 의미 있는 이름 📌 의미를 분명히 밝혀라 좋은 이름을 지으려면 시간이 걸리지만, 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 변수, 함수, 클래스 이름은 존재 이유, 수행 기능, 사용 방법에 대해 답할 수 있어야 한다. 주석이 필요하다면 의도를 분명히 드러내지 못했다는 의미이다. 의도가 드러난다면 코드 이해와 변경이 용이해진다. 📌 그릇된 정보를 피하라 코드의 의미를 흐릴 수 있기 때문에 그릇된 단서를 남겨서는 안 된다. ex) accountList -> List는 프로그래머에게 특수한 의미이다. 유사한 개념은 유사한 표기법을 사용한다. (일관성이 떨어지는 표기법은 그릇된 정보) 📌 의미 있게 구분하라 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 불용어는 중복이다. (변수.. ✨ Clean Code 1장: 깨끗한 코드 😡 나쁜 코드로 인한 문제점 출시에 바빠 코드를 짜다보면, 기능을 추가할수록 코드는 엉망이 되어간다. 결국엔 감당하지 못하는 수준에 이른다. 나쁜 코드는 개발 속도를 크게 떨어뜨린다. (프로젝트 초기에는 번개처럼 나가다가 결국 굼벵이처럼 기어간다) 팀 생산성은 떨어진다. 르블랑의 법칙 - 나중은 결코 오지 않는다. 즉, 나중에 손보겠다고 생각한 코드는 결코 오지 않는다는 의미이다. 👨🏻💻 프로그래머들의 책임 좋은 코드를 사수하는 일은 프로그래머의 책임이다. 관리자가 일정과 요구사항을 강력하게 밀어붙이는 것도 그들의 책임이기 때문이다. 가장 좋은 방법은 언제나 코드를 깨끗하게 유지하는 습관을 가져야 한다. 🛀🏻 깨끗한 코드란? 그림을 그리는 행위와 비슷하다. (빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와.. 이전 1 다음