TIL 2022.03.20

hun2__2·2022년 3월 21일
0

노개북

목록 보기
3/5

## Day2

오늘 TLI 3줄 요약

  • ETC + DRY원칙을 지켜라
  • 코드를 직교적으로 작성하라
  • 예광탄을 쏴라

TIL(Today I Learned) 날짜

2022.3.20

오늘 읽은 범위

2장

책에서 기억하고 싶은 내용을 써보세요.

  1. 어떤게 잘 설계되었다는 건 그 물건이 사용하는 사람에게 정응하여 맞춰진다는 것이다. (p39)
    1. ETC(Easier to Change)
      • 결합도를 줄여라
      • 단일 책임 원칙
      • 이름 짓기
  2. 스스로 자꾸 물어보라. '내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?' 파일을 저장할 때마다 물어보라. 테스트를 쓸 때도, 버그를 수정할 때도 물어보라.(p40)
  3. 교체 가능하게 작성하라는 말은 결합도를 낮추고 응집도를 높이라는 이야기일 뿐이다 (p40)
  4. DRY원칙(p42~)
    • 모든 지식은 시스템 내에서 단 한번만, 애매하지 않고, 권위 있게 표현되어야 한다.
      - DRY원칙은 복붙금지 뿐만아니라 지식의 중복, 의도의 중복도 포함이다.
    • 모든 코드 중복이 지식의 중복은 아니다.
      - 코드는 동일해도 서로 표현하는 지식이 다르다면 중복이 아니다.
    • 문서화 중복
      - 주석을 남발한다고 좋은게 아니다 함수의 이름으로 충분히 알려주고 부족한뿐만 채워라.
  5. 가능하면 언제나 객체의 속성을 읽고 쓸 때는 접근자(getter, setter)함수를 사용하라.
  6. 팀원 한 사람을 프로젝트 사서로 임명하라.(p53)
  7. 접근은 상호적이다. 다른 사람이 여러분의 코드를 들여다보고 건드린다고 해서 기분 나빠하지 말 일이다. (p53)
  8. 잘 설계된 시스템에서는 데이터베이스 코드가 사용자 인터페이스와 서로 직교할 것이다. (p55)
  9. 직교적인 시스쳄을 작성하면 두 가지 큰 장점이 있다. 바로 생산성 향상과 리스크 감소다.(P57)
    1. 생산성 향상
      • 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다.
      • 시스템이 더 느슨하게 결합되어 있을수록 재조합하고 개량하기 쉽다.
      • 직교적인 컴포넌트들을 결합함으로써 댠위노력당 더 많은 기능을 얻을 수 있다.
    2. 리스크 감소
      • 감염된 코드가 격리되어 있다.
      • 시스템이 잘 깨지지 않는다.
      • 테스트가 쉬어져서 더 많이 하게 되어 안정성이 올라간다
      • 특정 업체나 제품, 플레폼에 덜 종속될 것이다.
  10. 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라. (p61)
  11. 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생가하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.(p68)
  12. 시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라.(p73)
  13. 묵표물을 찾기 위해 예광탄을 쏴라(p73~)
    • 예광탄 코드는 한 번 쓰고 버리려고 만드는 것이 아니다. 앞으로도 계속 사용할 코드다. 예광탄 코드도 다른 제품 코드와 마찬가지로 오류 검사, 올바른구조, 문서화, 자체 검사를 갖추어야 한다.
    • 핵심은 필요한 모든 요소를 연결하여 'hello world'를 찍는 것이다.
    • 예광탄 코드는 프레임 워크를 만드는 것이고 나중에 그 위에 살을 덧붙인다.
    • 예광탄 코드 기법은 일이 어떻게 될지 100% 확신할 수 없는 상황에서 사용된다. 그러므로 처음 몇 번 시도 때 목표에 맞기 않더라도 놀랄 필요가 없다.
    • 예광탄 코드 기법는 애플리케이션이 전체적으로 어떻게 연결되는지 알려주고, 사용자에게 실제로 애플리케이션의 요소들이 어떻게 상호 작용하는지 보여주고, 개발자들에게는 코드를 붙일 아키텍처 골격을 제시해준다.
  14. 프로토 타입은 나중에 버리는 코드를 만든다. 예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격 중 일부가 된다.
  15. 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜로 프로토타입을 만들고 있는 게 맞는지 자문해 보라. 아마도 이런 경우에는 예광탄 방식의 개발이 더 적절할 것이다
  16. 동작하는 코드를 보여 줘라. 직접 사용해 볼 수 있게 하라. 그러면 그들에게 진짜로 필요한 것이 들어날 것이다. (p87)
  17. 사용하는 단위가 결과의 해석에 차이를 가져온다 (p95)
    • 6달과 130일은 같은 기간을 이야기 하지만 130일 이 더 정확도 높게 들린다.
    • 내가 전달하려는 정확도에 맞게 단위를 설정해서 대답하자.
  18. 어떤 종류의 추정을 하건 첫 단계는 상대방이 무엇을 묻고 있는지 이해하는 것이다.(p96)
    • 정화도 뿐만 아니라 도메인에 존재하는 조건에 대해서도 생각할 필요가 있다.
    • 조건이 명시적으로 드러나지 않는 경우 어떤 조건이 있을지 생각하는 습관을 길러야 한다.
  19. 계산한 추정치를 기록해 놓고, 나중에 이값이 실제 결과에 얼마나 가까웠는지를 평가해 보면 정말 좋다. (p99)
  20. 어떤 일에 걸리는 기간을 추정하기 위해 불확실성을 줄이는 2가지 방법 (P99~)
    • 초기 기능의 구현과 테스트를 마친 후, 이를 첫 번째 반복 주기의 끝으로 삼이라.
    • 이를 공식화하고 더 정확한 일정을 추정하는 것ㅇ르 가 반복 주기의 일부로 삼았을 때, 당신이 추정할 수 있는 가장 정확한 일정을 경영진에게 건넬 수 있을 것이다.
  21. 누군가 추정해 달라고 하면 뭐라고 대답해야 할까?(p102)
    • '나중에 연락드릴게요'

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

내가 하고 있던 작업이 프로토 타입이 아닌 예광탄 코드였었다. 둘의 차이점을 정확하게 알게되었고 내가 어떤 식을 예광탄 코드를 짜야하는지 가닥이 잡혔다ㅎㅎ
기본적으로 필요한 기능들위주로 연결시켜서 가장 간단하게 코드를 짜서 프레임워크를 만든다
그 다음 살을 붙여 코드를 풍성하게 만들자!

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

테스트 코드들이 이해가 잘 안된다,,, 처음 보는 언어들도 있고 툴들이 있어서 읽는데 어려움이 있었다.

오늘 읽은 다른사람의 TLI

profile
과정을 적는 곳

0개의 댓글