티스토리 뷰
오늘 TIL 3줄 요약
- 응집도를 높이고, 결합도를 낮추자.
- 이벤트는 모든 곳에 있다.
- 상속도 일종의 결합이다.
TIL (Today I Learned)
2022.03.26
오늘 읽은 범위
5장. 구부러지거나 부러지거나 p181-p239
책에서 기억하고 싶은 내용을 써보세요.
결합도 줄이기
높은 결합도는 변경의 적
이다.결합도가 높으면 이리저리 연결되어 있어서 여러 가지를 동시에 바꿔야 하기 때문
이다.- 소프트웨어의 구조는
유연
해야 한다. 결합도가 낮은 코드가 바꾸기 쉽다
.- 결합은
두 개의 코드 조각이 무언가를 공유하면 언제나
일어날 수 있다.
=> 내가 개발할 때, 항상 의도적으로 생각하는것이 있다. 바로 응집도를 높이고, 결합도를 낮추자인데 아니나다를까 이 책에서도 언급하고 있다. 지금보다 더 신입일 때의 일인데, 내가 코드를 작성하고 수정하면 여기 저기서 사이드이펙트가 발생하는 일이 비일비재하였다. 또한 내 Service는 항상 높은 결합도를 갖고 있었다. 그 코드를 가지고 팀원들과 코드리뷰 시간을 가졌는데 결과는 당연히 좋지 않았다. 지금도 코드를 작성할때면 그 기억이 떠올라 우선 돌아가는 코드를 만들고 어떻게 결합도를 낮출지 고민한 뒤에 리팩토링을 하는 습관을 갖게 되었다.
데메테르 법칙
- 데메테르라는 프로젝트를 수행하는 도중 개발자들에게 보다
깨끗하고 결합도가 낮은 함수를 작성하는
방법을 알려주기 위해 만들었다. - 메서드 호출을 엮지 말라.
=> 개인적으로 메서드 이름은 추상적이여야 한다고 생각한다. 메서드 이름에 너무 많은 정보가 노출되면 속사정이 노출되는 것과 같다. 호출하는 쪽은 메서드의 구현을 신경쓸 필요가 없다. 피곤할 뿐이다. 그냥 묻지 말고 시키자!
어디에나 이벤트가 있다.
- 이벤트는
모든 곳에 있다
. - 이벤트가 어디서 발생하든 이벤트를 중심으로 공등려 만든 코드는
일직선으로 수행되는 코드보다 더 잘 반응하고 결합도가 더 낮다
.
=> 개인적으로 다른 모듈을 호출해서 로직을 처리해야 한다면, 인터페이스를 만들고 이를 구현하는 객체를 만들어 비동기로 이벤트를 호출하는 방식으로 결합도를 낮추는 방법을 즐겨 사용한다. 테스트 코드를 작성하긴 조금 귀찮지만, 확실히 이벤트를 사용하면 모듈간의 결합도를 낮출 수 있다. 이 글을 다른 개발자가 보게 된다면 한번 시도해보길 추천한다.
코드를 공유하기 위해 상속을 쓸 때의 문제
상속도 일종의 결합
이다.
=> 단순히 코드를 공유하기 위해(중복 코드가 싫어서) 상속을 사용하지 말자. A클래스(부모)와 B클래스(자식)가 서로 상속 관계일 때, 이 사실을 모르는 개발자가 A클래스의 메서드를 전혀 다른 내용으로 수정하였고, B클래스가 A클래스의 메서드를 사용하고 있었다면, 해당 기능은 당연히 기존대로 동작하지 않을 것이다. 이런 문제를 피하기 위해서라도 단지 코드를 공유하자는 이유로 상속을 쓰지 말자!
외부 설정으로 애플리케이션을 조정할 수 있게 하라.
- 정보를 일반 파일로 관리할 때는 널리 쓰이는 일반 텍스트 형식을 사용하는 추세다. 2021년 기준으로는
YAML
과JSON
이 가장 많이 쓰인다. - 설정 정보를 API 뒤로 숨겨라.
=> 나도 즐겨 사용하는 방법이다. 시스템 설정 정보를 application.yml 파일에 작성해놓으면 설정 정보를 토대로 프로젝트가 구동되고, @value 어노테이션을 이용하여 소스코드에서 해당 값을 불러서 사용하기도 한다. 또 profile을 이용하면 production, stage, local 등으로 구분해서 각기 다르게 값을 설정할 수도 있다. 상당히 편리한 기능이다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
오늘은 상당히 머리에 잘 들어오고, 공감이 되는 내용이 많았다. 특히 응집도를 높이고 결합도를 낮추기 위해 노력했던(지금도 노력중이다.) 기억이 쉬지 않고 내 머릿속에 떠올랐다. 나는 빠르게 기능을 찍어내고, 유지보수만 하는 개발자가 아니다(그런 개발을 하고 싶지도 않다). 세상에서 유일하게 변하지 않는 단 한가지는 "모든 것은 변한다."라는 사실이다. 진화하는 서비스에 맞게 유연한 설계와 코드를 작성하기 위한 방법은 무엇이 있을지 더 고민하고, 실천해야겠다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
Topic 30 변환 프로그래밍은 잘 이해가 되질 않았다.. 오늘은 이만 푹 쉬고 내일 다시 한 번 더 읽어봐야겠다!
'Book > 실용주의 프로그래머' 카테고리의 다른 글
[TIL 6] 실용주의 프로그래머 #6. 동시성 (0) | 2022.03.29 |
---|---|
Mission: 연습문제 풀이! (0) | 2022.03.27 |
[TIL 4] 실용주의 프로그래머 #4. 실용주의 편집증 (0) | 2022.03.24 |
[TIL 3] 실용주의 프로그래머 #3. 기본 도구 (0) | 2022.03.23 |
Mission: 나의 최애 북틸 (0) | 2022.03.22 |
- Total
- Today
- Yesterday
- 리팩토링
- 릿코드
- 코테
- 북클럽
- 파이썬
- 구현
- 정렬
- 노마드코더
- webflux
- leetcode
- 백준
- 자료구조
- 인프런
- 김영한
- Real MySQL
- mysql 8.0
- 데이터베이스
- Spring
- 스프링
- 스프링 부트
- kotlin
- MySQL
- 노마드
- Algorithm
- spring boot
- Refactoring
- 그리디
- 코틀린
- 문자열
- 알고리즘
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |