# 2021/10/21

### 스터디 진행방식, 일정

- **범위**
- 1-2장씩
- 부담스럽지 않게
- **일정**
- 주 1회 (목요일 오후 9시 30분 ~ 11시)
- **진행 방식**
- 경험이나 생각 공유
- 2주에 한 번 정도 클린코드를 적용한 코드를 소개하거나 함께 고치는 방향도 있다
- 스터디 끝나고 스터디 시간에 이야기한 내용 함께 정리 (hackmd.io - github)

---

# 2021/10/28

### 1차 스터디

- 범위 : 1장

<img src="https://i.imgur.com/A3oiQIe.png" width=200/>

### 요구사항을 코드로 표현한다.
#### 경준님
- 감명이 깊었다. 그래서 저번주 작업할때 잠깐 생각이 나서 내가 잘하고 있나 돌아봤었다.
- 저는 입사한지 얼마 안 돼서 프로젝트에 있는 코드를 다 파악하지 못하고 있을 때가 많은데, 내가 이 말을 지키면서 코딩하면, 나중에 다른 사람이 시간을 허비하는 일이 없지 않을까? 자신이 될 수 있다.
- TODO 주석 외에는 저도 자바독 써요
-

#### 효건님
- 손권남님 : 히스토리를 위키에다 남기지말고 코드(주석)에다 남겨라.
- 자바독 주석 강조하심 /** ~ **/
- 코드로 표현하라는 말에서 코드에 주석이 포함되는 말인줄 알았는데

#### 예빈님
- 그래서 저는 요즘 커밋메시지를 자세히 적으려고 노력하고 있어요.
- 가게팀 암호문이었음. 코드에 주석이 있으면 반갑다. 코드에 남기는 것도 좋고 그게 힘들면 주석을 쓰는게 좋지 않을까..

<br/><br/>

### 여러 기능을 하는 메서드는 기능을 명확히 기술하는 메서드, 실제로 수행하는 여러개 메서드로 나눠라
#### 경준님
- 왜 우리는 좋은 코드를 사수하지 못하나?
- 일정을 길게 뽑으면 못해보인다 (잘해보이고 싶어서 그럴까?)
- 연장근무 하면서 실험삼아 리팩토링 해보곤 해요.

#### 효건님
- 주로 고민하던 부분인데, 명확하게 문장으로 나와서 고민이 해결되는 느낌이었다.(오늘 코드 짜면서도 해당하는 케이스가 있었다)
- 비슷한 동작을 하는데 분기를 해서 조금씩 차이가 있을 때
- 메소드 1개가 1개의 일을 하도록 해야 한다
- 명확히 기술하는 메서드 : 분기만 처리하는 메서드
- 실제로 수행하는 여러개 메서드 : 각각의 분기마다 필요한 기능을 수행하는 메서드
- 리팩토링 할거니까 주말에 연장근무 할게요! 라고 당당히 말할 수 있었으면 좋겠어요.
- 인정받는 스타개발자? 특정 기술을 잘한다. 클린코드를 잘해서 인정받을 수 있는 개발자가 될 수 있을까?

#### 예빈님
- 나중은 없다 (p4)
- 좋은 코드를 사수하는 일은 좋은 프로그래머의 책임이다 (p7)
- 캠프장은 처음 왔을 때보다 더 깨끗하게 하고 떠나라 (p19)

enum 이 조건 타입
A(Predicate, Function() -> ~),
B(,() -> ~),

if A -> 고구마
if B -> 감자

if (A) {
if (B)
}

return;
}

if (A면서 C면)

CService
ㄴ A, B
api ( 사용하는곳 주문팀 channel)
주문팀 request

가게도메인
Dto
enum
A (() -> AService)
B (() -> BService)

of().execute();

public () {

if (isA면서B인상황이면) {
이렇게_행동한다()
}

if (status == A && status != C) {
String a = "asd";
a.concat("asdasde");
}
}

<br/><br/>

---

# 2021/11/4

### 2차 스터디

- 범위 : 2,3장
- 베스트 3 뽑아오기

#### 경준님
- 검색하기 쉬운 이름(p. 28) 3위
- 추상화 단계 (p. 45)
- 내려가기 규칙 (p. 46)

#### 효건님
- p40 추상화 단계
- p50 함수 인수 - 테스트 관점 (인수를 모아서 추상화하는 건 테스트에 큰 차이가 있을까?)
- p51 많이 쓰는 형식 (이벤트.. 내가 생각하는 그런 이벤트가 아니네)

#### 예빈님
- p32 기발한 이름을 피해라
- 욕설 enum값 YOKSUL
- p28 검색하기 쉬운 이름을 사용해라

<br/>

### 1. 검색하기 쉬운 이름을 사용해라
- 주문팀 컨벤션 중 하나가 해당된다
- "/v1/shop/{shopNumber}"
- RequestMapping 쓰지 않기

- 가게팀은 이상해
- admin
- AdminShopRepository
- internal
- ShopInternalRepository
log.info("[class이름][메서드이름] 어쩌구저쩌구")
spring:
jpa:

- @JsonProperty("region3Code")
- 가급적 피하자
- 몽고db 쓰면서 누구는 template, 누구는 querydsl...
- 하나로 통합하고 있음

- 가게팀 ApiRes
- 의미 없는 것 같다
- fail() - auth만 씀
- timestamp - 의미있을 수도 (API 쓰는 팀에서)

- yml 검색이 어렵다.
- http://mageddo.com/tools/yaml-converter

결론
- 컨벤션을 정할 때 검색하기 쉽게 정하자
- 어떻게 컨벤션을 유지할 것인가

<br/>

### 2. 함수 인수 - 테스트 관점 (인수를 모아서 추상화하는 건 테스트에 큰 차이가 있을까?)

책에서는 인수 3개이상? 복잡하다

// 인자가 3개인 함수 (인자 간 조합이 다양함 -> 테스트하기 어려움) 를
foo(String a, List<String> b, boolean c) { }
// 아래처럼 쪼갤 수 있다 -> 각 메소드를 테스트할 수 있음
foo1(String a) { }
foo2(List<String> b) { }
foo3(boolean c) { }

    
FooParameter fooParameter
foo4(fooParameter) {
    
}

Point a;
int x, int y;


prefix가 같으면 VO 냄새가 난다


class User {
private String userName;
private String userPhone;
private String userAddr;
private String userAge;   
}

class Bar {
    private String a;
    private String b;
    
    public boolean isEmpty() {
        return a == null && b == null
    }
}

foo (Bar bar, boolean c, int d, boolean e) {
    
    void validate() {
        if (c && d < 5) {
            throw new Illegal();
        }
    }
}

### 3. 추상화 단계 (p. 45), 내려가기 규칙 (p. 46)

추상화 단계?

경준님 정리해주세요

<br/><br/>

---

# 2021/11/18

### 3차 스터디

- 범위 : 4,5,6,7장
- 베스트 3 뽑아오기

<img src="https://i.imgur.com/K2lvA1d.png" width=150/>

#### 효건님
- 있으나 마나한 주석(주석에 무감각해짐), 다른 코드의 내용까지 달아버리면 수정 누락
- 자료/객체 비대칭 (자료 추상화)
- 세로 위치 (특히 종속함수)

#### 경준님
- 자료구조 / 객체지향
- Unchecked Exception
- v잡종구조

#### 예빈님
- p90 공개하지 않을 코드라면 javadocs는 쓸모가 없다.
- 가게팀 코드는 ???????권남님의 영향으로 거의 항상 javadocs 쓰고 있음
- 주석이 너무 없어도 문제이지 않을까?
- baemin-review 쪽의 형태소분석기 코드
- p107 함수 순서
- public public private private private VS
- public private public private private

publicA a asd(T t) {
a
  map()  this::toRequest(List<a)
return    a.stream
toList();
 doOnNext(err -> logOnError(log.err("asdasd ", err ))   
    
}

// 예측할 수 있는 코드가 좋은 코드이고, 그래서 경준님은 함수형(java 8 - stream)을 좋아한다~
new A
add
Collectors.toMap() toList()
바퀴 재구현 하지마 있는 라이브러리 써라

== null != null (권남매직)


if 

Objects.isNull()
Objects.nonNull()

도넛이란 🍩
??대 철학과 천재
ts
우함마

유삼님의 습관
list에 Optional.ofNullable(list) stream ???????????????

<br/><br/>

---

# 2021/11/25

### 4차 스터디

- 범위 : 8,9장

#### 효건
- FIRST
- 빠른게 ????????????? 요약해주세요효건님
- 학습 테스트
- 테스트 당 assert 하나 - 배보다 배꼽이 더 커지기

#### 예빈
- 외부 코드 사용하기 (p144)
- 라이브러리 입장에서 숨기고 싶은 클래스
- 테스트는 어느 환경에서도 실행될 수 있어야 한다. (p168)
- feign같은 외부 환경 테스트

#### 경준
- 문제는 실제 코드가 진화하면 테스트 코드도 변해야 한다는 데 있다.
- DSL
- 깨끗한 테스트 코드, 가독성 가독성 가독성

- Spring Context

@F'I
interface ApplicationPublisher
    void publish(Event e);



class Service {
    private final ApplicationPublisher ap
    private final Repository repo
        
        public void save(A a) {
        repo.save(a);
        ap.pulish(aIsCreated())
    }
}

class ServiceTest {
    private Service service = new Service(it -> it++, mockRepo());
    
    
    sevice.save(Aa)
        verify()
        
    EventLister.handle(a);

a
}


request {shopNo}
controller = new Controller(new Facade(new Service(new Repository()))).doSomething()
    
    response=controller.asdasd(); {shopAddress}


when(repo.getAddress).thenReturn("송파구 어쩌고");


assertThat(response).isEqualTo("송파구 어쩌고");


assertThat(a).isTrue();

통합테스트, 우테코 시절 까지 -> 객체 하나만 하면 단위, 통합은 여러개 섞인거
통합테스트 (환경이 뜬다) -> 스프링쓰는거, 단위테스트는 자바만 쓰는거

Repository Redis Em
Aws Local

<br/><br/>

---

# 2021/12/09

### 5차 스터디

- 범위 : 10, 11, 12장

#### 예빈
- 클래스는 작아야 한다.
- 이미 커다란 클래스
- 결론: QA를 안타는 리팩토링부터 하자. ex.메소드 분리
- 결론: 깨진 유리창? 새로 만드는게 빠르다
- 템플릿 메소드 패턴

#### 효건
- 단일 책임 원칙
- 책임이 하나여야 한다.
- 변경할 이유가 하나여야 한다.
- ㄹㅇ?
- ㄹㅇ?
- 설정 논리는 일반 실행 논리와 분리해야 모듈성 높아진다.
- 순수 자바 AOP 프레임워크
-

#### 경준
- 강조하는 차원에서 한 번 더 말하겠다.
- ㄹㅇ?
- 시스템 제작과 시스템 사용을 분리하라
- DSL
- https://www.infoq.com/presentations/domain-specific-languages/

<br/><br/>

---

# 2021/12/16

### 6차 스터디

- 범위 : 13, 14장

#### 예빈
- 동시성
- jiggle
- 짠적이 없다
- 주문팀) DB 관련 동시성은 패턴화 되어있어요. (SimpleLockRunner)
- 점진적인 개선
- 나쁜 팀 역학은 복구하면 된다. 하지만 나쁜 코드는 썩어 문드러진다.

#### 경준
- 동시성 고민 언제 해봤나. (Web App 개발자)
- ConcurrentHashMap
- 동시성 테스트
- 분할만 잘해도 크게 개선된다
- 어떻게 분할하는게 옳은가..
- 코드 중심이냐 vs 개념 중심이냐
- 효율성이냐 vs 강한 규칙
- 최대한 깔끔하게 정리하자
- 어떻게? (몰기 vs 나누기)

#### 효건
- 동시성 필요한 이유
- 결합을 없애는 전략
- Mashaller
- interface 의 적합한 예시가 아닌가
- Exception
- Exception에도 적절한 역할을 부여하자

<br/><br/>

---

# 2021/12/16

### 7차 스터디

- 범위 : 15, 16장