본문 바로가기

Book/Clean Code

 (11)
[클린 코드] Assignment #15: 마지막 독후감 🖊️ 책을 읽은 후기 나쁜 코드를 작성하면 생산성이 크게 떨어지며, 프로그래머라면 좋은 코드를 작성하는 의무를 책임져야 한다. 이 책은 처음부터 엄청 공감되는 내용으로 시작됐다. 프로젝트를 진행하면서 코드를 깨끗이 써야한다는 의무는 항상 알고 있었지만, 그 방법을 잘 몰라 막막해져서 내 코드만 하염없이 바란 본 일들이 잦았다. 그러나 이 책을 읽고 나서는 배운 내용을 실제로 적용하면서 내 코드가 조금이라도 깨끗해지는 게 보여서 뿌듯했다. 챌린지를 진행하면서 후반부에 읽었던 테스트 코드 부분은 아직 완벽히 이해하지 못해 실제로 적용 해보지는 못했지만, 앞으로 공부하면서 꼭 실천해보고 싶다는 생각이 들었다. 책에서는 Java를 기준으로 예제를 제공해 내용을 이해하기에는 무리는 없지만, 최근에는 Dart언어를..
[클린 코드] Assignment #12: TIL - 10장. 클래스 📢 DAY 17 ~ 18 🏷️ 오늘 읽은 범위: 10장. 클래스 🖊️ 짧은 내용 요약 🧩 기본 클래스 구조 클래스는 기본적으로 캡슐화를 하고, 깨끗하게 작성한 클래스 내부의 구조는 다음과 같다. 정적 공개 상수 정적 비공개 변수 비공개 인스턴스 공개 합수 비공개 함수 🌟 깨끗한 클래스를 만드는 규칙 작게 만든다. 클래스가 하나의 책임만 가지면, 작은 것으로 판단한다. 클래스의 이름은 해당 클래스의 책임을 기술하기 때문에, 클래스가 하나의 책임만 지고 있는지를 판단하려면 클래스의 이름을 살펴본다. 클래스 명에 모호한 단어나 if, and, or, but과 같은 단어를 사용하지 않고 25자 이내로 작성했는지 확인한다. 클래스의 응집력을 적절히 유지한다. 클래스의 응집력을 유지하려면, 클래스의 인스턴스 변수 ..
[클린 코드] Assignment #11: TIL - 9장. 단위 테스트 + 나의 최애 북틸 📢 DAY 14 ~ 15 🏷️ 오늘 읽은 범위: 9장. 단위 테스트 🖊️ 짧은 내용 요약 🧹 테스트 코드도 깔끔하게 유지해야 하는 이유 요즘은 TDD와 같은 테스트 주도 개발 프로세스를 따라 개발을 진행하면서 많은 테스트 코드를 작성하게 된다. 이때, 테스트 코드를 깔끔하게 작성하지 않으면 테스트 코드가 복잡하고 지저분해지면서, 실제 코드보다 짜는데 시간도 오래 걸리고, 변경도 어려워진다. 그러면 실제 코드를 테스트하기 어려워지기 때문에 실제 코드에서 결함이 발생할 가능성이 높고, 이게 걱정되어 실제 코드를 유연하게 변경하기 어려워진다. 그렇기 때문에 테스트 코드는 실제 코드 못지 않게 깨끗하게 짜야 한다. 💡 깨끗한 테스트 코드의 장점은? 테스트 케이스가 있으면 안정성을 제공해 실제 코드의 변경이 쉬워..
[클린 코드] Assignment #10: TIL - 7장. 오류처리 + 공부법을 서로 공유해요 📢 DAY 12 ~ 13 🏷️ 오늘 읽은 범위: 7장. 오류처리 🖊️ 짧은 내용 요약 프로그램의 안정성을 위해 오류 처리는 필수적이지만, 자칫 잘못하면 오류 처리로 인해 더러운 코드가 만들어질 수 있다. 오류 처리를 프로그램 논리와 분리하면 코드의 유지보수성도 높아지고, 프로그램의 로직을 이해하기가 훨씬 쉬워지면서 깨끗한 코드를 작성할 수 있다. 😊 깨끗한 코드를 만드는 오류 처리 방법! try-catch문과 같은 예외를 사용해 오류 처리하기 try-catch 구조를 사용해 예외처리를 하면, 코드도 깔끔해지고 필수적인 구현 기능의 범위를 잘 구분해 만들게 된다. 이 때, 테스트 케이스를 먼저 작성한 후, 테스트를 통과하도록 코드를 작성하면 try-catch 내부에 필수적인 기능을 구현하기 더욱 쉬워진다...
[클린 코드] Assignment #08: TIL - 6장. 객체와 자료구조 📢 DAY 10 🏷️ 오늘 읽은 범위: 6장. 객체와 자료구조 🖊️ 짧은 내용 요약 추상화하자 클래스 안에 선언하는 변수는 외부에서 직접적으로 접근하지 못하도록 숨기는 게 좋다. 하지만 그렇다고 마냥 get, set 함수를 넣는다고 변수가 숨겨지는 것은 아니다. 이런 변수와 같은 자료를 숨기려면 추상화를 통해 사용자가 자료를 구체적으로 몰라도 자료를 조작할 수 있게 해야 한다. 그래서 메소드를 만들 때도 자료의 사용을 직접적으로 알 수 없는 추상적인 표현을 사용하거나 추상 인터페이스를 사용해 객체를 구현한다. 객체 자료를 추상화로 숨긴 채 자료를 다루는 함수만 공개한 형태 자료 구조 자료를 그대로 공개하면서 별다른 함수는 없는 구조(ex. DTO) 상황에 맞게 사용하자 객체 지향적인 코드와 절차 지향적인..
[클린 코드] Assignment #07: TIL - 5장. 형식 맞추기 📢 DAY 9 🏷️ 오늘 읽은 범위: 5장. 형식 맞추기 🖊️ 짧은 내용 요약 프로그래머는 형식에 맞춰 깔끔하게 코드를 짜야 한다. 코드의 형식은 코드의 유지보수와 확장성에 영향을 미치기 때문이다. 📜 깔끔한 코드 형식을 지키기 위한 몇 가지 규칙 👉 세로 코드의 적절한 세로 길이를 지키자 소스 코드는 한 파일 안에서 200줄 이내로 작성한다. 신문기사처럼 위에서 아래로 술술 읽히게 작성하자 각 내용은 짧게 구성하고 순서대로 작성한다. 코드 파일 첫 부분에는 고차원 개념과 알고리즘을 설명하고, 점점 세세하게 묘사한다. 종속 함수의 경우 호출하는 함수를 호출되는 함수보다 먼저 배치한다. 빈 행을 잘 사용하자 코드의 묶음은 빈 행으로 구분한다. 밀집한 코드는 가까이 두자 밀접한 코드는 한 개념을 이해하는 데..
[클린 코드] Assignment #05: TIL - 4장. 주석 + 나의 최애 북틸 📢 DAY 6~7 🏷️ 오늘 읽은 범위: 4장. 주석 🖊️ 짧은 내용 요약 주석은 꼭 필요한 상황이 아니라면 쓰지 않는 게 제일 좋다. 왜냐하면 주석은 좋은 주석보다 나쁜 주석이 더 많기 때문이다. 다음의 나쁜 주석의 특징 및 유형이다. 작성한 사람만 아는 주석(추가 설명을 요하는 주석) 코드와 중복된 내용이 있는 주석(의무적으로 달린 주석) 오해의 여지가 있는 내용이 담긴 주석 가독성을 방해하는 주석(닫는 괄호에 적힌 주석) 기타 쓸데없는 주석(이력, 분풀이 주석, 실수, 작성한 사람, 주석 코드, 다른 위치에 있는 코드를 설명, 너무 많은 정보) 나쁜 주석이 생기는 이유는 크게 3가지다. 주석은 유지보수하기 어렵다. 그래서 시간이 지나면 주석이 쓸데없는 정보로 변한다. 프로그래머가 정확한 의도로 주석..
[클린 코드] Assignment #04: TIL - 3장. 함수 📢 DAY 4~5 🏷️ 오늘 읽은 범위: 3장. 함수 🖊️ 짧은 내용 요약 함수는 작게 만드는 게 좋다. 블록에 들어가는 줄은 함수를 호출하는 코드로 작성해 최대한 1~2 줄로 작성한다. 함수는 무조건 한 가지 일만 하도록 만든다. 한 가지 일은 한다는 뜻은 추상화 수준이 하나인 단계만 수행한다는 뜻이다. 쉽게 설명하면 함수 내부의 코드를 다른 함수로 계속 쪼개서 쪼개지 못할 때까지 나누는 거다. 대신 함수 내부의 코드는 추상화 수준이 동일하게 만든다. 추상화 수준을 동일하게 만드는 것은 어렵지만 구현할 기능을 단계별로 작성해본 뒤 단계가 내려갈수록 추상화 수준을 한 단계씩 낮추면 추상화 수준을 일관되게 만들 수 있다. 함수의 이름은 길어도 괜찮으니 서술적인 이름이 좋다. 이름은 최대한 일관성 있게 짓는..

티스토리툴바