실용주의 프로그래머 2장 실용주의 접근법

항목 8. 좋은 설계의 핵심

• ETC(Easier to change), 하지만 적당히와 적절히!
• 엔지니어링 일지가 가장 좋은 툴이 블로그나 노션인데, 한동안 잘 안적고 있어서 적어야겠다고 생각.

항목 9. DRY: 중복의 해악

• 중복의 해악으로 주석과 코드가 그 지식이 중복된다는 것을 책을 보고 깨달음.
• 주석은 목적과 용도를 넣기!, 원리는 코드로 이해하기 쉽게 하자!
  • 단, 무조건은 아님.
• 다행인가 지금까지 우연히 규칙이 같았던 적은 없음.
• 요새 잘 못하고 있는것.
  • 다른 사람의 코드와 문서를 읽는것 : 지금 사전설계에서 다른 분들꺼 PR에 어떤것들이 반영된건지 아직 못본것. 꼭 보자
    • 봤는가?

항목 10. 직교성

• 결합도를 낮추고, 응집도를 높이는 것에 연결된 단어. 이런 특성을 가지면 직교적이다 할수 있다.
• 좌표평면에서 동쪽으로 움직여도 y축 데이터가 변하지 안흔것도 일종의 직교성
• 변화를 국소화해서 개발 테스트 시간 단축의 장점
• 사전 설계의 경우? : 이것을 모듈화나, 클래스화에 녹여낼 수 있다고 생각.
• 다른 팀원이 툴킷이나 라이브러리 도입할때 다른데 영향은 없을까? 이런 고민 필요
  • ex) 갑자기 spring boot 3.5 -> 4로 업글?
• 버그 수정마다 태그 붙이기. ex) 지라 번호? 또는 이슈 번호로
  • 경향을 분석한 리포트
  • 각각의 수정이 수정된 파일 개수가 적다면? 또는 수정한 모듈의 개수가 적다면? 결합도 낮고, 응집도 좋다라고 평할수 있을듯
• 연습 문제 1 관련. 진짜 이럴까? 이걸 난 잘 모르겠다.

항목 11. 가역성-

• 가역성(可逆性, reversibility)은 어떤 과정이 진행된 후, 시스템과 주변이 초기 상태로 완전히 되돌아올 수 있는지의 여부를 나타내는 개념이다. 가능할 경우를 가역 과정(reversible process), 불가능한 경우를 비가역 과정(irreversible process)이라고 한다.

• 결정이 돌에 새겨지는 것이라 가정하고, 발생할지도 모를 우연한 사건들에 대해 준비하지 않는 데에서 실수가 나온다.
• 결정이 돌에 새겨진 것이 아니라 해변가의 모래위에 쓰인 글씨라 생각해 보자. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

최종 결정이란 없다.

항목 12. 예광탄

• 요구 사항으로 부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무엇인가를 찾아야한다.

• 예광탄은 한번 쓰고 버리는 코드를 만드는것이 아니다. 75p

• 모든 기능이 들어있지 않을 뿐 / 시스템을 구성하는 요소를 모두 연결해 놓은 후 목표물에 얼마나 근접했는지 확인할 수 있으며. 조정도 가능하다

• 변경 요청과 기능 추가 요청은 언제나 게속 들어오기 마련이다. 76p

• 예광탄 장점 : 1. 사용자가 뭔가 작동하는지 일찍 볼 수 있다. 2. 개발자가 들어가서 일할 수 있는 구조를 얻는다. 3. 통합 작업을 수행할 기반이 생긴다. 4.보여줄 것이 생긴다. 5.진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

• 예광탄 vs 프로토타입 : 예광탄은 기능은 없지만, 완결된 코드이며, 골격이다. 프로토타입은 예광탄을 발사전에 수행하는 정찰이나 정보 수집과 같다. 프로토타입은 쓰고 바로 버림.

• 솔직히 예광탄을 정말 잘써야된다고 생각한다.

  • 코드까지는 한번 봐야할 설계나 작업이 있고, 그 작업에 이것을 하지 않으면 리스크가 상당히 크다.(불가능한데 우린는 무언가 하고 있지 않은가? 시간은 꽤 오래걸릴작업인데 시간 산정을 짧게 한건 아닐지)

항목 13. 프로토타입과 포스트잇

• 절대적인 건 없고, 때로는 코드 대신 포스트잇이든 그림을 그려도 괜찮!

항목 14. 도메인 언어

• 문제를 도메인에 가깝게 프로그래밍 하라
  • 메서드, 클래스, 변수에 도메인 용어를 넣는것도 방법 일듯
• 동작하는 코드에 대해서 디자인빼고 파바박 보여지는 예광탄이 필요하고, 그것을 토대로 사업부랑 소통하자.
• 외부 dsl(ex) html, sql) vs 내부 dsl(ex) gradle)

내부 DSL의 핵심 개념

Groovy의 문법은 그대로 사용 가능 - 변수 선언, 반복문, 조건문, 함수 등 Groovy의 모든 기능을 사용할 수 있습니다.

빌드 도메인에 특화된 API와 구조 추가 - Gradle이 제공하는 특별한 함수들과 컨벤션이 있습니다:

// Groovy 문법 그대로 사용
def myVersion = "1.0.0"
def list = [1, 2, 3]

// 하지만 Gradle이 제공하는 특별한 DSL 구조
plugins {  // Gradle이 제공하는 빌드 전용 블록
    id 'java'
}

dependencies {  // Gradle이 제공하는 의존성 관리 전용 블록
    implementation "org.springframework:spring-core:${myVersion}"
}

tasks.register('myTask') {  // Gradle의 Task API
    doLast {
        println "This is Groovy code in Gradle DSL"
    }
}

즉, Groovy라는 언어 위에 빌드 자동화 도메인에 특화된 API와 구조를 얹은 것이 Gradle DSL입니다. 이것이 내부 DSL의 정의 그 자체

항목 15. 추정

• 질문자가 매우 높은 정확도의 답을 요구하는가, 아니면 단순히 큰 그림만을 요구하는가? 기간을 추정할 때 다음과 같은 단위를 사용하기를 추천한다.

  • 1~15일 : 일
  • 3~8주 : 주
  • 8~30주 : 달
  • 30주 이상 : 추정치를 말하기 전에 다시 한번 생각해 보라.
• 추정 단계
  • 모델을 만들어라
  • 모델을 컴포넌트로 나누어라
  • 실행계획을 세울것.(이건 내생각)
  • 각 매개변수에 값주기

• 추정치 기록과 분석

  • 여러분이 계산한 추정치를 기록해 놓고, 이 값이 실제 결과에 얼마나 가까운지를 평가해 보는 것은 좋은 생각이다.
  • 여러분은 추정치가 꽤 좋다는 것을 자주 발견할 것이고, 점차로 이를 기대하게 될 것이다.
  • 추정치가 잘못되었더라도 움츠리거나 도망가지 마라. 왜 여러분의 추측과 실제 값이 달라졌는지 원인을 찾아야 한다.
• 추정치의 조정
  • 프로젝트 진행상황에 맞춰서 점증적으로 조정.
• 나라면 “나중에 전화드릴께요” 라 말할 것이다.

Action Plan

• 나는 추정에 대단히 관심이 많다.
• 특히 내 업무에 대한 추정과 추정이 틀린 이유를 분석하고 싶긴하다.
• 그래야 좀더 시간을 쏟아볼지, 말지를 결정할 수 있는것 같다.
• 해볼것 : 한가지 업무에 대해서 스스로 데드라인과 추정치 만들고, 기록하고, 다르다면 원인 분석하는 글쓰기 하기.