실용주의 프로그래머 #02. 실용주의 접근법
TL;DR
- ETC! 바꾸기 쉬운 코드인지 상기하자.
- 지식의 중복을 없애자.
🗓️ TIL (Today I Learned)
2022.03.19
🔖 오늘 읽은 범위
2장. 실용주의 접근법
🌟 책에서 기억하고 싶은 내용을 써보세요.
Topic8 좋은 설계의 핵심
ETC!! Easier to Change!!
- 잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다. (p.39)
[ETC를 따르는 설계 원칙 예시]
- 결합도 낮추기 : 관심사를 분리함으로써 각각이 더 바꾸기 쉬워진다.
- 단일 책임 원칙 : 요구사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있다.
- 좋은 이름 짓기 : 좋은 이름 → 코드를 바꾸려면 일단 코드를 읽어야 하는데 좋은 이름을 쓰면 코드를 읽기가 쉬워진다. **
- 소프트웨어라는 틀에서 생각해 보면 ETC는 선택의 갈림길에서 도움을 주는 안내자다. (p.39)
- 스스로에게 물어보라. ‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’ (p.40)
[변경이 더 쉬워질지 알 수 없는 경우 시도해보자!]
- 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 ‘바꾸기 쉽게’라는 길을 선택한다.
- 교체 가능하게 작성하라는 말은 코드의 결합도를 낮추고 응집도를 높이라는 이야기일 뿐이다.
- 엔지니어링 일지에 현재 상황과 선택, 그리고 변경 사항에 대한 추측을 정리해 둬라. 그리고 소스 코드에 이에 대한 표시를 남겨 둬라. (p.40)
- 이런 경우를 여러분의 직관을 발전시키는 기회로 삼으라.
Topic9 DRY: 중복의 해악
🛠️ Tip 15 DRY: 반복하지 말라 (Don’t Repeat Yourself)
- 프로그래머는 늘 유지 보수 모드에 있다. (중략) 이유가 무엇이건, 유지 보수는 별개의 활동이 아니며 전체 개발 과정의 일상적인 부분이다. (p.42)
- 소프트웨어를 신뢰성 높게 개발하는 유일한 길, 개발을 이해하고 유지 보수하기 쉽게 만드는 유일한 길은 우리가
DRY라 부르는 원칙을 따르는 것이라 생각한다. - 하나를 바꾸면 나머지도 바꿔야 함을 기억해야 한다. (중략) 이것은 기억하느냐 마느냐의 문제가 아니다. 단지 언제 잊어버릴 것인가 하는 문제다. (p.43)
- DRY는 지식의 중복, 의도의 중복에 대한 것이다. (p.44)
- 코드의 어떤 측면 하나를 바꿔야 할 때 여러 곳을 바꾸고 있나?
- 그것도 여러 가지 다른 형태를?
- 코드를 바꾸고 문서도 바꾸는가?
- 데이터베이스 스키마와 스키마를 담고 있는 구조 등도?
[모든 코드 중복이 지식의 중복은 아니다]
def validate_age(value):
validate_type(value, :integer)
validate_min_integer(value, 1)
def validate_quantity(value):
validate_type(value, :integer)
validate_min_integer(value, 1)
- 코드는 동일하지만 두 함수가 표현하는 지식은 다르다. 우연히 규칙이 같은 것뿐이다.
[개발자 간의 중복]
- 개발자 간의 중복에 대처하려면 크게는 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다. (p.53)
- 일일 스크럼 스탠드업 미팅을 운영해 볼 수 있다. 슬랙 채널같이 공통의 문제를 다루기 위한 공간을 만들라.
- 다른 사람의 소스 코드와 문서를 반드시 읽어라.
- 다른 사람이 여러분의 코드를 들여다보고 건드린다고 해서 기분 나빠하지 말 일이다. (p.53)
- 사람들은 쉽지 않으면 하지 않을 것이다.
Topic10 직교성 (decoupling)
일종의 독립성이나, 결합도 줄이기를 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.(p.55)
[직교성의 장점]
- 우리가 설계하고 싶은 것은 자족적인 컴포넌트, 즉 단일하고 잘 정의된 목적을 가진 독립적인 컴포넌트다. **
장점1. 생산성 향상
- 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다.
- 재사용도 촉진된다.
장점2. 리스크 감소
- 감염된 코드가 격리되어 있다.
- 시스템이 잘 깨지지 않는다.
- 테스트를 더 많이 하게 된다.
- 특정 업체나 제품, 플랫폼에 덜 종속될 것이다.
[설계] 업무에 적용하기.
- 직교적 시스템을 설계하는 방법 :
계층 구조사용- 각 계층은 자기 바로 밑에 있는 계층이 제공하는 추상화만을 사용하기 때문.
- 직교적인지 확인하는 방법 : ‘특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?’ 물어보기 → 직교적인 시스템은 ‘하나’여야 한다.
Topic11 가역성
Topic12 예광탄
Topic13 프로토타입과 포스트잇
Topic14 도메인 언어
Topic15 추정
💭 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- ‘다른 사람이 여러분의 코드를 들여다보고 건드린다고 해서 기분 나빠하지 말 일이다’, 라는 구절에서 찔림이 왔다. 처음 개발자로 일하면서 동료와 협업했을때 이런 문제로 속앓이를 한 적이 있었다. 그때는 왜 이기적으로 말도 없이 코드를 고쳐버렸나 싶어 꿍해있었던 적도 있는데 후에 생각해보면 전체적으로는 코드 퀄리티가 개선되는 결과였다. 지금은 고치는 건 좋으나 당황하지 않도록 이야기만 해달라고 공유하니 서로 더 신뢰도 생기고 코드 퀄리티도 점진적으로 좋아지는 일석이조가 되었다. 개발 일을 시작하면서 스킬 뿐 아니라 사람으로서도 매일 조금씩 성장함을 느껴서 좋다.
🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- [Topic9 DRY:중복의 해악] 가능하다면 언제나 객체의 속성을 읽고 쓸 때 접근자 함수를 사용하라. 그러면 나중에 기능을 추가하기 더 쉬워질 것이다. (p.50)
- getter, setter를 쓰라는 뜻 같은데,, 이건 클린 코드에서 지양하라고 했던 것 아닌가..? 헷갈린다.ㅠㅠ
- 단일 접근 원칙
댓글남기기