DAY 2
- 오늘 읽은 범위 : 2장
책에서 기억하고 싶은 내용을 써보세요.
바꾸기 쉽게, ETC (Easier to Change)
- 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
- 왜 결합도를 줄이면 좋은가? 관심사를 분리함으로써 각각이 더 바꾸기 쉬워지기 때문이다.
- 왜 이름 짓기가 중요한가? 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문이다.
- 왜 단일 책임 원칙이 유용한가? 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다.
반복하지 말라, DRY (Don't Repeat Yourself)
- 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.
- 두 군데 이상에 표현된다면, 하나를 바꾸면 나머지도 바꿔야 함을 기억해라.
모든 코드 중복이 지식의 중복은 아니다
온라인 와인 주문 프로그램에서 사용자의 연령과 주문 수량을 기록하고 검증하는 기능이 필요하다가 해 보자.
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)- 위의 두 함수는 내용이 동일하지만, DRY 원칙 위반이 아니다.
- 코드는 동일하지만, 두 함수가 표현하는 지식은 다르다. 우연히 규칙이 같은 것 뿐이고, 중복이 아니다.
개발자 간의 중복
개발자 간의 중복에 대처하려면 크게는 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다.
- 스크럼 스탠드업 미팅 운영을 해라 / 슬랙 채널같이 공통의 문제를 다루기 위한 공간을 만들어라
- 팀원 한 사람을 프로젝트 사서로 임명하라.
- 코드리뷰를 통해서든 다른 사람의 소스 코드와 문서를 반드시 읽어라.
- 다른 사람의 것을 기웃거리는 게 아니고, 거기서 배우는 것이다. 접근은 상호적이다. 다른 사람이 여러분의 코드를 들여보다 건드린다고 해서 기분 나빠하지 말아라.
재사용하기 쉽게 만들어라.
여러분은 뭔가를 직접 만드는 것보다 기존의 것을 찾아내고 재사용하기 쉬운 환경을 조성해야 한다. 사람들은 쉽지 않으면 하지 않을 것이다. 그리고 재 사용에 실패한다면 지식 중복의 위험을 감수해야 한다.
직교성
- 관련 없는 것들 간에 서로 영향이 없도록 하라.
- DRY 원칙으로 무장하고 직교성 원칙을 충실히 적용한다면 개발하고 있는 시스템이 더 유연하고 이해하기 쉬워질 것 이다. 디버깅, 테스트, 유지 보수 또한 쉬워질 것
가역성
- 당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다.
- 최종 결정이란 없다.
프로젝트 일정 추정하기
- 코끼리 먹기
- 요구 사항 확인하기
- 위험을 분석하고 위험도가 높은 부분을 우선하기
- 설계, 구현, 통합
- 사용자와 함께 검증하기
- 코드와 함께 일정도 반복하며 조정하라.
- 이 방법은 경영진에게 별로 인기가 없다. 경영진은 보통 프로젝트가 시작되 기도 전에 하나의 정확한 숫자를 원하기 때문이다. 여러분은 팀, 팀의 생산성 그리고 환경이 일정을 결정한다는 사실을 경영진에게 이해시켜야 한다. 이 를 공식화하고 더 정확한 일정을 추정하는 것을 각 반복 주기의 일부로 삼았 을 때, 여러분이 추정할 수 있는 가장 정확한 일정을 경영진에게 건넬 수 있 을 것이다.
- 누군가 추정해 달라고 하면 뭐라고 대답해야 할까?
- “나중에 연락드릴게요.” 라 말해야 한다.
잠시 손을 멈추고 시간을 내어 이번 항목에서 설명한 단계를 밟아 나간다
면 대부분의 경우 더 좋은 추정치를 얻을 수 있을 것이다. 커피 머신 앞에서 허투루 말한 추정치는 커피와 마찬가지로 여러분에게 해를 끼칠 것이다.
- “나중에 연락드릴게요.” 라 말해야 한다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
코드 작성 시, 항상 ETC와 DRY 원칙을 상기시켜며 작성을 해야겠다.
개발자 간의 중복 파트에서 "팀원 한 사람을 프로젝트 사서로 임명하라."라는 문장이 마음에 와닿았다. 이전의 회사에서 프로젝트를 작업할 때, 사수 없이 주니어 프론트엔드 개발자 3명이서 작업을 진행 했었는 데, 사수가 없다보니 ETC 와 DRY 원칙이 하나도 지켜지지 않았다.
만일, 부득이하게 사수가 없는 경우에는 팀원 간의 코드 리뷰 등 서로 간의 잦은 협의를 하는 것이 원활한 프로젝트를 이끌어 갈 수 있을 것이라는 생각이 든다.
2장 끝날 무렵 즈음에, 프로젝트 일정 추정하기라는 주제를 가진 글이 나왔다.
이전의 회사에서 프로젝트를 애자일 방식으로 진행을 했어서 기획자분이 항상 일정에 민감해하셨었다. 그러다보니 작업물을 넘겨받을 때 항상 일정이 얼마나 걸릴 것 같냐는 질문을 하셨다.
그럴때 , 나는 그 순간을 얼른 모면하고 싶기도 했었고 내가 일정을 말하는 순간 그 일정을 지켜야겠다는 강압감과 부담감이 생겨 항상 머릿속이 새하얘졌었던 기억이 난다.
앞으로 일정을 물어본다면, 코끼리 먹기의 세부사항들을 꼼꼼히 따져가며 일정을 도출하여 신중하게 결과를 말해야겠다.
