logo

2020.01, Montly I Learning

<br>

2020년 새로 시작한 프로젝트(?)
하루는 너무 짧소, 한달로 갑시다.
복습과 회고와 반성의 코딩일기
내 머리에 잔디 심기

<br>

01.01

- vue

  • Vue JS 인프런 완강
    • Vue의 디자인 패턴 공부

<br>

01.02

- junit5

  • 더 자바, 테스트 코드를 짜는 법
    • Junit5 구조 및 기본 사용법
    • Junit5 태깅에 따른 테스트 그룹화
    • Junit5 조건에 맞는 테스트 분기
    • Junit5의 확장팩 정의 사용법
    • Mockito when() -> given()
    • Mockito verify() -> then()

- lecture. spring-security test

  • @WithMockUser
  • @WithUser
  • @WithAnonymousUser

<br>

01.03

- spring-batch Configurer

  • Spring Batch에 MetaData를 데이터베이스에 남기지 않으려 삽질을 했다
  • 관련 블로그 작성중

<br>

01.04

- 약속

<br>

01.05

- project. podo-dev

  • google-analytics 적용

- project. helloprice

<br>

01.06

- project. podo-dev

- lecture. spring-security

  • Spring Security Structure 공부
  • Security-contenxt-holder
  • Authentication Manager

- etc

@UtilityClass
public class BeanUtils {
    public static <T> T getBean(Class<T> type) {
        ApplicationContext applicationContext = ApplicationContextProvider.getContext();  
        return applicationContext.getBean(type);
    }
}
  • scroll-bar 커스텀 코드
::-webkit-scrollbar {
    width: 2em;
    height: 2em
}
::-webkit-scrollbar-button {
    background: #ccc
}
::-webkit-scrollbar-track-piece {
    background: #888
}
::-webkit-scrollbar-thumb {
    background: #eee
}

<br>

01.07

- book. 오브젝트

  • 객체의 자율성과 결합도와의 고민, 트레이드 오프
  • 개발자를 클래스 작성자, 클라이언트 프로그래머로 구분하는 내용이 인상깊었다.
  • 추상화 관련 트레이드 오프

- test code

  • RabbitMQ Mock으로 띄우기
implementation group: 'com.github.fridujo', name: 'rabbitmq-mock', version: '1.0.10'

@TestConfiguration
public class RabbitMQTestConfig {

    @Bean
    public ConnectionFactory connectionFactory() {
        return new CachingConnectionFactory(MockConnectionFactoryFactory.build());
    }
}
  • @TestConfiguration
    @TestConfiguration은 scan 되지 않는다.
    테스트 클래스에 inner static class로 정의되면 scan된다.
    그렇지 않다면 @Import를 사용해 테스트 코드에 주입한다.
@TestConfiguration
public class TestConfig {}

@Import(TestConfig.class)
class DeadlinkJobTest {}
  • @SprinbBootTest에 대한 고찰
    @SprinbBootTest는 여러 테스트에서 하나의 Context를 올린다.
    매번 올리지않음. (왜 매번 올린다 생각했지?)
    각 테스트 별로 초기화 할려면 사용하면 된다.
@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD)
  • propertis를 이용한 Bean 설정
@TestPropertySource(properties = {"job.name=" + DeadlinkJobConfig.DEADLINK_JOB_BEAN_NAME})

@ConditionalOnProperty(name = "job.name", havingValue = DeadlinkJobConfig.DEADLINK_JOB_BEAN_NAME)
  • 테스트코드에서 @AutoWired를 안쓰고 생성자에서 주입하기
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)

<br>

01.08

- 회사 행사

- book. 오브젝트

  • 상속에 관한 좀 더 구체화된 내용
  • 덕분에 객체지향사실과 오해에서 이해안됬던 부분이 이해됬다!

- project. podo-dev

  • tui-editor 커스텀 CSS를 정의했다.(리팩토링)
  • ehcache에 버그 이슈가 있어서 해결했다.

key에 모두 + 연산시, 숫자를 더한다.

@Cacheable(value = "getblogComment", key = "#blogId + #requestPaging.page") // key=1 + 1 // key = 2

수정

@Cacheable(value = "getblogComment", key = "#blogId + '#' + #requestPaging.page")

- study

  • StringCalcualtor 예제를 풀었는데, 생각보다 시간이 오래걸렷다.
  • 어떻게 해야 좀더 좋은 설계를 할까 고민중이다. 내일 리팩토링

- lecture. spring-security

- spring-boot

<br>

01.09

- 약속

- book. 오브젝트

  • 역할, 협력, 책임과 관련된 내용
  • 객체지향의 사실과 오해에 좀 더 구체화된 내용.

- study

  • StringCalcualtor 마무리

<br>

01.10

- book. 오브젝트

  • 캡슐화 이야기, 캡슐화는 결국 응집도와 결합도를 높인다.
  • 변경관점에서의 응집도와 결합도에 관련된 얘기
  • 이책에서 말하는 책임이 단일 책임 원칙의 책임과 다른 것인지 의문이었는데, 명확히 명시된 부분을 읽어서 좋았다.
  • 데이터 중심의 설계의 문제점

- lecture. spring-security

  • lecture. spring-security 구조
  • AccessDecideManger 구조
  • AccessDecideManger Config

- study

  • 스터디 팀원 코드리뷰
  • 코드리뷰 받은 내용 수정
  • 또 상수화를 안시켰다.
  • double에 대한 고찰 (정확하지않다..!)
        final String x = "20.3";
        final String y = "10.7";
        final double dx = 20.3;
        final double dy = 10.7;
        
        System.out.println(Double.parseDouble(x) - Double.parseDouble(y)); // bad! 9.600000000000001
        System.out.println(dx - dy); // bad! 9.600000000000001
        System.out.println(new BigDecimal(x).doubleValue() - new BigDecimal(y).doubleValue()); // bad! 9.600000000000001
        System.out.println(new BigDecimal(dx).subtract(new BigDecimal(dy))); // too bad!! 9.600000000000001421085471520200371742248535156250

        System.out.println(new BigDecimal(x).subtract(new BigDecimal(y))); // goooood! 9.6

<br>

01.11

- 약속

- study

  • 코드 리뷰 반영
    • {} 블록을 이용한 클래스 초기화
    • 일급컬렉션 적용. 컬렉션을 캡슐화하자.
    • 자료구조명 사용 금지 (bad : parseMap)
  • Assert에 대한 공부 https://offbyone.tistory.com/294

<br>

01.12

- project. podo-dev

  • 유저 정보 관련 이슈 수정 후 재배포
  • secruity session less 하게 변경
  • 테스트코드 작성

Request Mocking

final MockHttpServletRequest request = new MockHttpServletRequest();
RequestContextHolder.setRequestAttributes(new ServletRequestAttributes(request));

then() 사용법 ( eq. verify() )

//then
then(attachImageStorageUploader).should(times(1)).writeFileOfAttachImagesToStorage(any());
then(attachFileStorageUploader).should(times(1)).writeFileOfAttachFilesToStorage(any());

<br>

01.13

- book. 오브젝트

  • 캡슐화 이야기 연장
  • 메소드 네임 또는 파라미터를 통해 구현체의 정보가 노출된다면 그것 또한 캡슐화를 위반한다는 내용이 인상 깊었다
  • 캡슐화 재정의 : 변동되는 것을 모두 감추는 것
  • 책임주도설계에 대한 서론
  • 책임 주도 설계는 곧 캡슐화로 이어진다.
  • 송신자는 수신자에대한 어떠한 가정도 할 수 없게 된다.
  • 이 메세지를 누구에게 전송해야지 부터 시작하자.

- blog

  • 객제지향의 사실과 오해를 읽고, 01 리팩토링 후 배포

- study

  • 코드리뷰 후 리팩토링, 코드 재리뷰

- lecture. spring-security

  • AccessDecisionManager를 누가 호출하고, 로직에 대해서 공부
  • 전체적인 security 아키텍처 정리가 마무리 됬다
  • ignoring()

- CI

  • 회사에서, CI 환경을 구성 중인데
  • CI를 통해서 Docker 이미지를 배포하는 환경을 테스트하고 있다.

<br>

01.14

- 약속

- book. 오브젝트

  • 객체지향 설계를 어떻게해야하는지 예시를 볼 수 있었다.
  • 객체지향 사실과 오해와 나온 내용인데
  • 실제 코드로 과정을 볼 수 있어서 좋았다.

- project. coinchatbot

  • 서버를 재시작했는데 터져 버렸다.
  • 몇 시간을 헤맸는데,
  • 사용자가 없는 몇몇 코인에 대한 텔레그램봇을 직전에 삭제 했는데..(기억이..)
  • 서버를 재부팅 하니, token 만료되어 커넥션이 되지않아 문제가 발생했다.
  • 집에와, 설정해주고 정상구동 확인 후 마무리

- lecture. spring-security

  • ignoring()에 대한 추가적인 공부
  • ignoring()은 SecuritychainFilter를 안타지만
  • permitAll()을 SecuritychainFilter를 탄다.
  • 따라서 적절하게 나누어서 처리.

<br>

01.15

- book. 오브젝트

  • 책임 주도 설계, 실제 코드를 반영하는 과정 마무리
  • 도메인 모델은 가이드라인 뿐만 아니라, 구현하면서 발 맞추어 바꾼다.
  • 클래스가 하나의 책임을 가지고있는지 파악 하는 팁
  • 응집도가 높은 클래스는 생성시, 모든 인스턴스르 함께 초기화 한다.
  • 메소드들이 인스턴스 변수를 어떻게 사용하나 파악해보자.
  • 책임 주도 설계는 어렵다, 어떤객체에 어떤 책임을 부여하는지는 어렵다.
  • 어려움을 극복 할 수 있는 방법,
  • 데이터 중심으로 처음에 짜보자.
  • 메서드를 쪼개고, 그 메서드에 필요한 데이터를 가지고있는 클래스에게 책임을 전하라
  • 리팩토링하다보면, 더 좋은 결과를 볼 수도 있다.

- lecture. spring-security

  • lecture. spring-security의 15가지 필터에 대한 내용
  • WebAsyncManagerIntergrationFilter
  • SecurityContextPersistenceFilter
  • HeaderWriterFilter
  • CsrfFilter

- study

  • 자동차경주 예제를 풀었다.
  • 내일은 팀원들과 코드리뷰

- CI

  • docker 무중단 배포에 대해 리서치 중이다.
  • docker swarm을 발견해서, 테스트 결정.

<br>

01.16

- book. 오브젝트

  • 좋은 인터페이스를 만드는 원칙을 공부
  • 디미터 법칙
  • 묻지 말고 시켜라
  • 의도를 드러내는 인터페이스
  • 명령 쿼리 분리 원칙
  • 초보자는 원칙에 얽매인다. 원칙을 유연하게 사용하라
  • 결합도와 응집도의 충돌할 때도,
  • 트레이드 오프 발생. 적절하게 선택해라.

- study

  • 자동차경주 게임
  • 생각해보니 실수한 부분이 너무많다.
  • 셀프 수정을 진행했다.
  • 코드리뷰하기, 코드리뷰 받기

- CI

  • docker-swarm를 NAS에 구성중인데,
  • 왠지는 모르겠지만 registry에서 이미지를 못찾는다.. 도대체왜?
  • 하루종일 헤맸는데, 해결책을 못 찾았다.

- lecture. spring-security

  • 필터 까보기
  • LogoutFilter
  • UsernamePasswordAuthenticationFilter
  • DefaultLoginPageGeneratingFilter

<br>

01.17

- book. 오브젝트

  • 기능분해 방식의 문제점에 대한 이해
  • 모듈에 대한 정의
  • 기능분해를 모듈로 분해함으로써 장점

- study

  • 자동차경주 게임
  • 부족한 점이 많았던 코드
  • 일급컬렉션에 얽매였다.
  • validate(), 인자를 활용하는 시점에서 사용하자.
  • constants를 하나의 인터페이스에 정의하는게 옳을까?

- CI

  • NAS에 docker swarm을 구축하려는데
  • NAS전용 OS는 리눅스를 커스텀해서 무언가 되질않는다.
  • 커맨드에 에러가 계속발생한다.
  • 내일은 도커 컨테이너에 우분투를 올려서 도커 - 우분투컨테이너 - 도커로, 도커를 감싸서 진행해볼까 한다.

<br>

01.18

- study

  • 자동차경주 게임
  • 코드리뷰를 반영했다.
  • 일급컬렉션을 적용했다.
  • GUI /비즈니스로직 분리
  • IntStream#range(), IntStream#rangeClosed() 차이
  • validate()에 대한 고찰, 활용하는 곳에서 validate() 하자

- CI

  • docker swarm 뻘짓..
  • NAS의 자체 OS에 한계점으로
  • NAS docker에 우분투를 올리고, 그위에 도커를 올려서 진행해보려했다.
  • 다만, 컨테이너 기반의 우분투라 그런지,
  • 우분투 내부 도커에서 스토리지 관련 에러를 보여주며, 이미지 풀링이 안된다.
  • 에러 : 이미지를 저장할 저장공간이 지정되있지 않아!
  • 웹에 블로깅을 따라하다, fdisk 명령에, 실수로 하드를 날려버렸다..
  • 아이고 멘탈아...

<br>

01.19

- 휴식 (회복중)

<br>

01.20

- 약속

- book. 오브젝트

  • 추상데이터 타입과, 절차 추상데이터 타입 차이점에 대한 공부
  • 타입이 확장된다면 절차 추상 데이터 타입이 옳지만,
  • 오퍼레이션이 확장 된다면 추상 데이터타입이 옳다.
  • 이펙티브자바에서 해당 내용이 있었는데, 더 명확하게 알 수 있었다.

<br>

01.21

- 약속

- book. 오브젝트

  • 의존성 주입에 관한 내용
  • 학부때 내용을 복습하는 느낌!
  • 정인상교수님 감사합니다..

- study

  • 자동차경주 게임
  • 자동차경주 게임 step02 진행

- lecture. spring-security

  • 필터 까보기
  • BasicAuthenticationFilter
  • RequestCacheAwareFilter
  • SecurityContextHolderAwareRequestFilter
  • AnonymousAuthenticationFilter
  • SessionManagementFilter

<br>

01.22

- book. 오브젝트

  • 의존성역전에 대한이해, 추상화된 것에 의존하라
  • 왜 역전? // 기존의 절차방식이랑 의존성 방향이 반대됨.
  • 패키지를 문맥에서 재사용할부분/재사용할 필요없는 부분으로 의존성역전 패키지를 나눔
  • 유연성의 다른 이름은 복잡성
  • 유연성은 좋은 것만이 아니다.

- study

  • 자동차경주 게임
  • 자동차경주 게임 step02 코드리뷰
  • Optional#get() 조심하자.

- spring-cloud-gateway

  • spring-cloud-gateway를 테스트 삼아 해보고 있다.
  • gateway, auth-server, api-server 세 서버를 두고 로컬에서 테스트해보고 있다.

- lecture. spring-security

  • 필터 까보기
  • ExceptionTranslationFilter
  • FilterSecurityInterceptor
  • RememberMeAuthenticationFilter

<br>

01.23

- book. 오브젝트

  • 상속의 문제점
  • 불필요한 인터페이스를 상속받음
  • 메소드 오버라이딩 문제
  • 부모클래스와 자식클래스 동시 수정 문제

<br>

01.24 ~ 01.29

- 여행

<br>

01.30

- book. 오브젝트

  • 복습
  • 상속에 관한 피해를 최소화 하는 법
  • 추상화를 사용해라
  • 단, 부모클래스에서 추상메소드를 아래로 내리기가 아니라
  • 자식클래스에서 중복코드를 위로 올리기 전략을 사용해라.
  • 위로 올리기 전략을 실수해 추상화를 빼먹더라도 한 눈에 금방 알 수 있다.
  • 부모클래스에 인스턴스가 추가된다면 ?
  • 자식클래스에 인스턴스 초기화 전략을 변경해야한다.
  • 하지만, 인스턴스 초기화 전략 < 비즈니스 전략 이기 때문에,
  • 인스턴스 전략의 결합도를 포기한다.
  • 따라서, 상속은 어떻게든 결합도를 가지게된다.
  • 상속은 확신이 있을때 사용하라.
  • 상속보다는 합성을 이용하는것이 좋다.

- nhn-forward

  • HTTP API에 대한 고민 / NHN 이경환 개발자님
    • 리소스 위상의 위치에 대한 고민
    • 이것이 sub-resource 인가? 속성인가?
    • CRUD가 아닐때는 동사구를 사용
    • POST 일때, 201 응답, Location Header를 주는게 좋다.
    • PUT vs PATCH
    • GET file
      • 메타데이터, 파일다운로드 어떻게 구분하지
      • Accept Header를 사용해보자.
    • 캐쉬에 대한 고민
      • 목록 형식에 응답에 링크를 응답했을때, 클라이언트가 링크를 쭉 호출한다면, n+1, 캐쉬에대해 고민해야됨
      • 공용정보와 개인정보 함께 응답하는 상황 -> 캐쉬에대해 고민해보자.
    • REST api, 여러 리소스가 한번에 들어오는경우
      • for문을 사용할 것인가
      • 메소드를 rest하게 정의 할것인가 /../tasks/addTags
    • flag성 이름 규칙을 정하자 is_, can_, has_
    • queryParameter도 이름을 정확하게 쓰면 좋다.

- lecture. spring-security

  • 강의내용 복습

- study

  • 코드리뷰 반영, 재코드 리뷰

<br>

01.31

- book. 오브젝트

  • 상속보다 합성이 좋은 이유
  • 상속을 합성으로 바꾸는 법 : 상속관계를 제거하고, 부모 클래스의 인스턴스를 자식클래스의 인스턴스 변수로 선언하자.
  • 상속은 클래스의 추가적인 기능으로 인해 폭팔적인 조합을 만들 수 있다. 클래스 폭팔..!
  • 최상위 클래스에서 추상메소드를 정의한다면?
  • 합성은 이를 해결 할 수 있다.
  • 학부때 배운 [데코레이터패턴](https://www.project. podo-dev.com/blogs/118) 이 나왔다!
  • 합성이 상속보다 좋은 이유 : 상속은 구현을 재사용하지만, 합성은 인터페이스를 재사용한다.

- lecture. spring-security

CommentCount 0
이전 댓글 보기
등록
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
TOP