개발자 99% 커뮤니티에서 수다 떨어요!
TIL (Today I Learned) 날짜
2022.03.21
오늘 읽은 범위
2장. 실용주의 접근법
책에서 기억하고 싶은 내용을 써보세요.
2장. 실용주의 접근법
이 챕터는 소프트웨어 개발의 모든 차원에 적용 가능한 요령이 있고, 보편적으로 적용된다고까지 할 수 있는 프로세스나 그 자체로 거의 당연하게 여겨지는 아이디어를 모아놓은 챕터이다.
Topic8~15까지 8까지 주제로 나누어 설명하는데 아래는 그 중 기억에 남는 6가지이다.
'Topic8 좋은 설계의 핵심'에서는 ETC(Easier to Change)를 따르는 것을 설명한다.
바꾸기 더 쉽게. 이게 전부다.
왜 결합도를 줄이면 좋은가? 관심사를 분리함으로써 각각이 더 바꾸기 쉬워지기 때문이다.
왜 단일 책임 원칙이 유용한가? 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다.
왜 이름 짓기가 중요한가? 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문이다.
'Topic9 DRY: 중복의 해악'에서는 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다고 말한다.
(DRY = Don't Repeat Yourself)
그리고 이 법칙은 코드에서 뿐만 아니라 코드 밖에서도 적용되어야 하며
단순히 코드의 중복을 중복이라고 보는 것이 아니라 지식의 중복을 중복으로 보기 때문에
코드는 같더라도 중복으로 보지 않을 수 있고 코드는 다르더라도 중복으로 볼 수도 있음을 말한다.
Topic10 직교성
컴퓨터 과학에서 직교성은 일종의 독립성이나, 결합도 줄이기decoupling를 의미한다.
하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.
이러한 직교성이 적용되면 컴포넌트들이 각기 격리되어 있으면 어느 하나를 바꿀 때 나머지 것들을 걱정하지 않아도 된다.
직교적인 시스템을 작성하면 생산성 향상과 리스크 감소라는 두 가지 큰 장점을 가지게 된다.
Topic11 가역성
환경의 변화로부터 프로젝트를 보호하는 몇 가지 기법들에 대해 말해준다.
최종결정이라는 것은 없다. 언제든지 요구사항은 바뀔 수 있다.
Topic12 예광탄은
뼈대를 먼저 만드는 것으로 이해했다.
예광탄을 미리 만들면 진행 상황에 대해 더 정확하게 감을 잡을 수 있고 통합작업을 수행할 기반이 생긴다.
Topic13 프로토타입과 포스트잇
프로토타입을 만드는 이유는 위험 요소를 분석하고 노출시킨 후, 이를 매우 저렴한 비용으로 바로잡을 기회를 얻기 위함이다.
위험을 수반하는 모든 것이 프로토타이핑의 대상이 될 수 있다.
시스템 골격의 일부가 되는 예광탄과 달리 프로토타입은 나중에 버리는 코드다.
프로토타이핑의 가치는 생산한 코드에 있는 것이 아니라 이를 통해 배우는 교훈에 있다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
클린코드를 먼저 읽어서 그런지 새로운 것도 알고 복습도 하는 느낌이다. 성격상 처음부터 제대로 하고 싶지만 프로그래밍을 할 수록 결코 생산적이지 못한 방법임을 체감한다. 프로그래밍에 성격을 맞춰가네...
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
DSL이 아직 잘 안와닿는다.