-
비슷한 기능을 하는 객체 2개가 있는데, 지금 나온 기획안으로는 똑같지만 추후에 바뀔 것이 예상이 된다.
- 중복되는 코드가 있더라도 각각 만든다
- “의도적인 중복” 이라고도 부르는 technique
- 중복되는 코드를 없애고 추상화시켜서 묶는다
어느 게 더 적절할까요?
-
먼저 상속을 해봐도 좋고, 다형성으로 해 봐도 좋고, 어떻게 해 봐도 좋고, 적절한 걸 만들어서 쓰자.
-
굳이 처음부터 미래의 상황을 고려하여 고도화를 고려하는 건 오버 아키텍처링일 수도 있다.
-
처음에는... 중복되는 코드를 없애고 추상화시켜서 묶는다? 라고 생각
- 기능추가가 된다? 라는 시점은 서비스가 그렇게 성숙하지 않았다 라는 이야기
- 여기서 “중복되는 코드를 없애고 추상화시켜서 묶는다” 로 열심히 처리를 했는데, 또 여기서 바꿔야 된다면?
- 작은 규모의 회사에서 빠르게 개발을 하다 보니 이런 경험이 매우 빈번
- 그래서 필요한 만큼만, 미래의 내가 고통받지 않을 만큼만 (어차피 그 똥은 내가 치워야 하기 때문에)
- No silver bullet: 처음에 개쩌는 클린 아키텍처 + DDD 이렇게 다해놔도 기획에서 엎어지면 의미없다...
- 차라리 바뀌었을 때 side effect 를 검증하거나, 기획적으로 아귀가 안 맞는 변경 / 수정사항이 왔을 때 빠르게 쳐 낼수있는 test code 를 잘 짜는것이 도움이 되었다...
-
결론: TDD + 리팩터링 무지성 129301회독 하자
-
Unit test
- 런던파 vs 고전파 가 현재 대립중 (런던파는 2018년, 고전파는 ~2010년)
- 런던파
- Movie 를 test 할 때 Reserve 를 mock 으로 만든다
- 반대로 Reserve 를 test 할 때 reserve 도 mock 으로 만든다
- 고전파
- 아니다, mock 은 network / database transaction 을 하는 것 정도만 mock 을 하고 나머지는 실제로 사용한다.
-
객체지향의 사실과 오해: 객체지향은 현실세계를 모사하는 것, 그리고 은유하는 것이다. 현실세계를 ‘묘사' 하는 건 아니다.
-
작은 규모의 기업에서 정부에게 ‘비대면 바우처' 라는 걸 받는데 이게 K-소프트웨어 (K-SaaS) 를 공짜로 이용할 수 있는 AWS credit
- 여기에 카카오워크가 들어가 있을 확률이 매우높다