2019-05-12 Daily Post


1. 클로저

자바스크립트의 클로저 개념을 4년만에 이해했다. 지금은 이해하고있지만 곧 다시 잊고 헷갈릴지도 모르겠다. 자바스크립트를 그냥 사용만 해보고 요즘 처음으로 공부해보고 있는데 알고있으면 도움이 많이 될 것 같다. 이것도 언젠가는 블로그에 정리해야겠다.

2. Angular JS

Angular JS? Angular? 버전 올라가면서 1과 2~가 부르는 명칭이 다르다했는데 기억이 안난다. 프론트엔드에 대해서 잘 모르고 실무에서는 프레임워크를 안써봐서 프론트엔드 프레임워크에 대해서는 잘 모르는데, 최근에 조금 보니 좋은것 같다. Angular JS는 별로 좋지않다고 들었던 것 같은데 악명(?)에 비해서는 프론트엔드 멍청이가 보기에는 꽤나 좋은 프레임워크인 것 같다.

3. Google Analytics

Google Analytics는 생각보다 많은 정보를 수집해서 가지고 있다. 브라우저 정보부터 사용자 행동패턴까지 수집한 정보를 가공해서 많은 부분에 활용할 수 있도록 한다. Google Analytics의 API에 대해서 보고 있는데, Google Analytics에서 웹 클라이언트로 제공해주는 사이트보다 훨씬 많은 것을 할 수 있는 것 같다. 필터링의 경우 사이트에서는 일부 제약이 있지만 API를 사용하면 제약이 많이 없어진다. 조회 성능때문에 제약을 걸어둔건가 싶기도 한데 좀 더 알아봐야겠다. 정리가 어느정도 되면 포스트 작성해야겠다.

4. 잡담

최근들어 평일에는 어렵지만 주말에는 가급적이면 운동을 하고있다. 이제 2주째인데 주말에만 하면 살이 안빠지려나 싶다. 평일에도 할 수 있으면 해야지 싶은데 퇴근하면 만사가 귀찮으니 하려나 싶다. 그래도 술은 많이 줄였으니 조금은 가능성이 있어보인다. 정 안되면 스트레칭정도라도 하려고 노력해봐야겠다.

블로그는 1일 단위로 작성하려했는데 점점 1주일 단위가 되고있다. 1일 단위로 쓰면 내용이 별로 없기도 하고 평일에는 만사가 귀찮아서 안하게되는 것 같다. 그래도 노력이라도 해봐야겠다. 일기라도 쓸까…​


2019-05-05 Daily Post


1. 계약에 의한 설계(Design by Contract)

얼마전 스프링캠프에서 계약에 의한 설계(Design by Contract)라는 말을 들었다. 처음 듣는 용어라서(지금 생각해보면 들었을것 같은데 기억나지 않으니 처음듣는 것이다) 조금 찾아봤는데, 선행조건과 후행조건, 그리고 불변식이 핵심적인 내용이다. 간단하게 요약하자면 어떤 메소드 M에 a라는 값이 입력값으로 들어갔을 때 이 메소드는 항상 b라는 값을 반환한다는 것을 보장한다는 것이다. 선행조건과 후행조건으로는 a의 값과 b의 값에 대한 조건이 될 수 있다.(예를 들면 null이 아니다 라던지..)

이 용어와 설계기법은 모르고 있었지만 설계를할 때 가능한 지키려하는 방법 중 하나라서 친숙한 설계방법이었다. 개인적인 생각으로 저런 방법으로 설계를 함으로써 메소드의 역할과 책임이 분명해진다고 생각한다. 역할과 책임이 분명해짐으로 디버깅이 편하고, 무엇보다 입력값에 대한 반환값이 보장되어 TC작성에 유리한 설계방법이다. 특정 기능에 대해 입력값과 반환값이 보장되므로 보장되는 값으로 메소드를 실행해서 반환값을 확인하면 되기 때문이다. 또한, 기능간의 호출관계를 정리하기 좋은 설계방법이라고 생각한다.

함수형 프로그래밍에서 함수가 되기 위한 조건 중 하나(맞나…​?)에도 이와 같은 조건이 필요했던 것으로 기억하여 무슨차이가 있나 생각해봤다. 고민하다 지인에게 질문을 했는데 지인피셜로 함수형 프로그래밍에서 이 개념을 포함하는 것이라 한다. 좀 더 자세한 내용은 독립 포스트로 작성해봐야겠다.

2. Google Analytics

Google Analytics는 페이지 로딩 시 ga('send', 'pageview')로 페이지 조회 정보를 전송한다. 지금까지 페이지 조회에 대한 정보만 수집해서 분석하는 기능만 있는 줄 알았는데 생각보다 할 수 있는 기능이 많은 것 같다. 페이지 조회 외에도 이벤트 발생 시에도 ga 함수를 호출해서 이벤트 전환 정보를 기록할 수도 있다. 또한, GA에서 제공하는 Dimension 값을 지정하거나 Custom Dimension 값을 지정해서 특정 사용자의 정보를 지정해서 특정 사용자의 행동 패턴도 파악할 수 있다. 아직 알아볼 기능이 많지만 이것도 공부를 좀 더 한 후 독립 포스트로 작성해야겠다.

3. 블로그 카테고리 정리

블로그 카테고리가 많아서 정리를 했다. 일단 이대로 글을 계속 써보다가 개편해야될거같으면 다시 해야겠다.

4. 디자인패턴

디자인패턴을 자주 검색해서 찾아본다. 검색하는 횟수가 좀 많아졌는데 그냥 블로그에 정리해놔야겠다.

5. DDD

최범균님이 쓴 DDD START! 를 읽기 시작했다. 내용이 생각보다 심오한거같다. 앞부분만 조금 읽고 전반적으로 어떤내용을 다루는지 한 번 훑어본 다음에 책을 덮었다. 오늘은 정신이 좀 산만해서 집중이 잘 될때 제대로 읽어야겠다.

6. 잡담

블로그에 정리한다고 한 내용은 언제 정리를 할지 모르겠다. 매번 한다하고 안한다.

날이 엄청 풀리다 못해 더워졌다. 어린이날이다. 일요일이지만 대체휴일로 내일도 쉰다. 쉬면뭐하나 공부하고 운동해서 살이나 빼야지 ㅠㅠ

이전회사에서 퇴사한지 1년 조금 넘게 지났다. 아직도 이전회사에서 사용하는 특정 모듈의 에이전트정보가 나한테 문자로 온다. 처음에는 웃겼는데 이거 정보 빼달라고 연락해야되나..


2019-04-30 Daily Post


1. Google Analytics

구글 어낼리틱스에서 유용하고 사용할만한 몇가지 기능을 알게되었다. 사용법도 조금씩 익혀가고 있다. 아직은 블로그에 달아놓기만 하고 제대로 활용하고있지 못한데 사용법을 조금씩 익히면서 유의미한 데이터를 볼 수 있는 방법을 조금씩 찾아봐야겠다.

2. 현금영수증 용도변경

어제 홈택스에 용도변경신청을 했는데 오늘 답변이 왔다. 접수가 완료됐고, 변경되는데 1주일정도 걸린다고 한다. 생각보다 오래 걸리기는 하지만 되는게 어디야 기다려야지.

3. Fiddler

아직 사용법이 익숙하진 않지만 fiddler를 통해 웹 요청을 확인한다. 주로 브라우저 개발자툴을 이용하기는 하지만 화면전환이 일어나는 곳에서는 피들러를 사용하고 있다. 피들러에서 프록시 설정을 하고, 모바일 기기에서 wifi 설정에서 프록시 설정을 하면 피들러를 사용하는 pc를 프록시할 수 있다. http 뿐만 아니라 https도 약간의 설정과 신뢰과정을 거치면 요청을 중간에 가로챌 수 있다. 모바일 앱에서 요청을 보내고 그 요청을 피들러가 있는 프록시 서버에서 가로채서 요청/반환 값을 변조할 수 있다. 신뢰 과정을 거쳐야하기 때문에 해킹을 하는데 사용하기는 어렵지만 장난치기 좋을것 같다.

4. Grails

망할 grails는 아무리 봐도 줏대가 없다. 프레임워크에서 사용하는 변수인데도 언제는 콜렉션 객체였다가 언제는 문자열 객체가 된다. 계층파괴는 둘째치고 이건 진짜 좀 너무하는거 아닌가? 마음에 드는건 기본 테스트 Framework로 Spock을 사용한다는거 하나뿐이다.

5. etc

봄이여서 그런지 벌이 많이 나오고있다. 무섭다. 내일은 근로자의날이라 쉰다 너무 좋다 ^^

끄읕!


2019-04-29 Daily Post


얼마나 자주, 오래 할 지는 모르겠지만 오늘부터는 가급적 그 날 알게된 것이나 겪은 일을 블로그에 기록하려 한다. 개발과 관련된 내용일 수도 있고, 전혀 관련없는 내용일 수도 있다. 그냥 글쓰기 연습겸 일기장처럼, 낙서장처럼 끄적일 것이다.

1. 현금영수증 용도변경

현금영수증을 개인소득공제에서 지출증빙으로 용도변경 할 일이 생겼다. 판매 사이트나 판매단체에서는 딱히 이렇다할 방법이 없는것 같다. 지인으로부터 국세청에서 용도변경이 가능하다는 정보를 얻었다. 국세청에 문의해본 결과 인터넷으로 용도변경 신청시 필요한 서류는 신분증 사본(주민등록증, 운전면허증, 여권)과 건 별 내역서 혹은 현금영수증 사본(날짜, 승인번호 9자리, 금액이 모두 기재되어 있어야 함, 홈택스에서 다운 가능)이 필요하다는 답변을 받았다. 또한, 소비자 발급수단관리에 지출증빙 귀속 사업장이 입력되어있어야 한다고 한다. 그래서 필요한 서류를 준비해서 국세청에 용도변경 신청을 했다.

2. Browser Request Content Type

브라우저에서 웹 서버로 요청을 보내면 무조건 Request Header에 Content Type이 포함된다고 생각하고 있었다. 그런데 오늘 보니 그게 아니였다. 그냥 GET 요청이면 Request Header에 Content Type이 포함되지 않는다. 이게 특정 브라우저에서만 그런지 모든 브라우저에서 동일한 것인지 까지는 확인해보지 않았지만 처음 알게된 사실이다.

3. apache poi

엑셀과 관련된 기능을 처리하기 위해 많이 사용하는 라이브러리다. 이 apache poi가 특정 버전에서 특정 버전으로(minor) 올라가면서 어떤 기능의 기본 값(default value)이 바뀐다는 것을 얼마전에 알게 되었다. 오늘 버전을 올리면서 기본 값 뿐만 아니라 이 라이브러리를 사용하여 템플릿(?)처럼 기능을 제공하는 다른 라이브러리에서도 버전호환성이 맞지 않아 문제가 발생한다는 것을 알게되었다.

4. Grails Filter

Grails의 Filter에서 uri로 필터를 지정할 수 있다는 것을 알고 있었다. uri에 **를 사용해서 하위 경로를 포함시켜 필터를 적용할 수 있다. 그런데 서로 다른 패턴으로 동일한 필터를 적용시킬 수 있을 줄 알았는데 적용이 안된다. controller로 조건을 걸 때는 'example*|sample*' 처럼 여러 패턴을 하나의 필터에 적용할 수 있는데 uri는 안된다. uri도 여러 패턴을 적용할 수 있게 해줬으면 좋겠다는 생각을 한다.

5. asciidoc

블로그를 asciidoc으로 쓰고 travisCI를 통해 빌드를 해서 github page로 관리를 하는데, 이 글을 쓰면서 특수문자 치환방지를 위해서 역슬래시(\)를 쓰면 된다는 것을 알게됐다. 근데 적용하고 보니 역슬래시도 같이나온다. 다시 알아봐야겠다. 그런데 역슬래시를 쓰고싶은데 역슬래시 치환방지는 어떻게 하는거지? 그냥 쓰면 되나? 일단 그냥 써봐야지

6. etc

스프링캠프 참석 이후 자극을 받게 되었고, 이제 다시 공부를 조금씩 시작하려고 한다. 아예 안한 것은 아니지만 했다고 볼 수도 없었다. 책을 폈는데 눈에 들어오지 않는다. 오랫만에 하는거니깐 처음부터 무리하지 말아야겠다.

이 글쓰기도 정말 얼마나 오래할 지 모르겠다. 매일은 아니더라도 가끔 한번씩은 써야지 라고 생각하고 있는데 첫날부터 이런 생각을 하는 것을 보면 정말 오래 못쓰겠지 싶다. 블로그도 쓰는 김에 카테고리 정리도 조만간 해야겠다.

끄읕!


SpringCamp 2019 참석 후기


1. Intro

SpringCamp는 2016년, 2017년 그리고 그 이후 2년만에 참석하는 것이다. 총 세 번 참석을 했는데, 지난번에 참석했을 때 모두 기억이 좋게 남아있어서 또 참석하게 되었다. 사실 작년에도 참석을 하고있었지만…​ 티켓 판매사이트에서 티켓 판매 오픈을 이상하게 하는 바람에 멍떄리다가 티켓팅에 실패했다. 올해는 2번으로 나눠서 티켓판매를 했는데, 첫 날 작년처럼 멍때리다 실패하고, 두 번째 날 겨우 티켓팅에 성공했다.

올해는 주로 코틀린과 모니터링에 대한 세션이 많았고, 개발 경험에 대해서 공유하는 세션들도 있었다. 코틀린은 아니지만 DSL을 사용하고 있는 입장에서 DSL을 명세를 작성하거나 스크립트를 작성하는 것이 아닌 비즈니스 애플리케이션을 구현하는데 사용한다는 것에 대해 회의적인 생각을 가지고 있어서 코틀린에는 큰 관심이 없기 떄문에 코틀린과 관련된 세션은 듣지 않고 다른 세션 위주로 참석을 했다. 참석한 세션의 내용 대부분이 만족스러웠고, 내가 가진 경험이나 생각과 비교를 하면서 들을 수 있어서 만족스러웠다. 또한, 스프링의 기능이나 모듈등에 대해서 새로 알게된 것들이 있어서 좋았다.

참석한 세션은 아래와 같고, 하루가 지났다고 기억이 자세히나지 않는 부분이 많지만 기억나는 내용 및 요약한 내용을 정리한다.

  • 실전에 써먹는 스프링 부트 (김지헌님)

  • Monitoring With Actuator (서경원님)

  • 자바에서 null을 안전히 다루는 방법 (박성철님)

  • 무엇을 테스트할 것인가? 어떻게 테스트할 것인가? (권용근님)

  • 당신도 할 수 있는 레거시 프로젝트 개선 이야기 (이경일님)

2. 실전에 써먹는 스프링 부트 (김지헌님)

업무에서 스프링 부트를 사용하고 있지는 않지만 개인적으로 공부를 조금씩이나마 하고 있고, 좀 더 알고 싶어서 세션에 참석했다.

2.1. 스프링부트

  • Netflix도 자바와 관련된 시스템은 모두 스프링 부트로 전환했다.

  • Spring Boot - Spring Cloud - Spring Cloud Data Flow(https://spring.io 에 있는 세가지인데 무엇을 설명했는지 기억이 안난다…​ㅠㅠ)

  • 개발자가 손쉽게 부트앱을 만들 수 있다고 스프링에서 홍보중이다.

Spring BootSpring Framework를 기반으로한 개발 플랫폼으로 Spring Boot Starter, Spring Framework, Build Tool(Gradle, Maven)으로 구성되어 있다.

2.2. Gradle

GradleKotlin DSLGroovy DSL이 있다.

Kotlin DSL의 장점
  • 빠른 문서보기

  • 코드 자동완성

  • 에러 강조표시

  • 코드 리팩토링

Spring Boot Gradle Plugin
  • 의존성 관리

  • 실행가능한 아카이브 패키징

  • 애플리케이션 배포

  • 애플리케이션 실행

  • Actuator 지원

2.3. BOM(Bill of Material)

  • BOM으로 인해 버전을 명시적으로 작성하지않아도 된다.(호환 버전을 자동으로 import)

  • spring-boot-dependencies 모듈이 의존성 관리를 한다.

  • enforce platform으로 다른 BOM 파일 가져올 수 있다.

2.4. Code

@Profile 어노테이션으로 프로파일에 따라 다른 빈 설정 및 주입을 할 수 있다.

스프링 부트 자동구성(AutoConfiguration)
  • @Configuration

  • @Conditional~~

애플리케이션 속성을 실행시점에 외부에서 변경한다.
  • 실행 시점에 실행 파라미터(?)로 주입

  • @ConfigurationProperties

  • 무슨 json 을 만들어냄

ConfigurationProperties Example
@Component
@ConfigurationProperties(prefix = "example.tt")
public class ExampleProperties {
  String name;
  String key;
}

2.5. 후기

스프링 부트를 공부용으로 하는 작은 토이 프로젝트에서는 사용하고있다. 하지만 공부를 하는 것과 실무를 하는 것에는 차이가 있기 떄문에 공부를 하면서 알지 못한 처음보는 기능들을 알게되어서 좋았다.

3. Monitoring With Actuator (서경원님)

두번째 세션은 부종민님의 websocket 세션과 고민을 많이 하다가 밝히기 어려운 이유로 서경원님의 세션에 참석했다.

3.1. Why & How Monitoring

  • 장애 예방, 원인 파악, 조치

  • 변경에 대한 상태 확인

  • 성능 개선

  • 장기적인 서비스 상태 분석

  • 지표가 필요하다

모니터링을 하는데 지표를 어디서 어떻게 획득할 것인가?

3.2. NHN 모니터링 시스템

  • 서버 인프라 지표 수집

  • 애플리케이션 지표 수집

  • 모니터링 차트 제공

  • 지표 감시 및 알림

3.3. Spring Boot Actuator

  • Spring Boot 애플리케이션 모니터링

  • 제어 도구 제공 - endpoints

  • 애플리케이션 지표 제공 - metrics

  • dependency 추가하면 AutoConfiguration에 의해서 자동으로 등록한다.

  • 여러 종류의 endpoints 를 제공한다.

  • 사용할 endpoints를 설정을 통해서 제어 가능 및 외부 노출 설정이 가능하다.

  • enabled-by-default=false로 해서 기본 사용 옵션을 끌 수 있다.

  • spring-security로 endpoint 권한 설정 가능하다.

3.4. Metrics Endpoint

jvm, jdbc, web, library 등 여러가지 metrics 제공한다.

Boot1에서 계층형이었지만 2에서 Dimension구조로 변경(Tag를 붙입)

Dimension구조 장점
  • 이해하기 쉬움

  • 여러 관점에서 지표 분석 가능

  • 유연함 손쉬운 Tag 추가/삭제

RED Method - 반드시 측정해야하는 metrics
  • Request Rate

  • Request Errors

  • Request Duration

Hystrix - Circuit Breaker 장애 내성 / 지연 내성

3.5. Micrometer

설정밥법
  • dependency 추가 - AutoConfiguration

  • prometheus endpoint 추가

3.6. 후기

컨디션이 좋지 않아 많이 졸으면서 들었는데 Actuator라는 모듈을 통해서 모니터링을 할 수 있고, 지표를 볼 수 있다는 새로운 사실을 알게되어 좋았다. 여러 서버를 돌린다면 actuator를 통해서 서버에서 지표를 제공하고, 그 지표를 수집하는 저장소와 가시화할 수 있는 방법이 추가로 필요할 텐데 이에 맞춰서 인프라를 구축한다면 좋겠다는 생각을 했다. 다만, 전사적인 인프라를 구축하는데 사용하는데는 약간 무리가 있지 않을까 라는 생각을 하게 되었는데, 다른 한 편으로는 잘 알지는 못하지만 전사적으로 사용하는데 무리가 없으니 사용하고 있겠지 라고 생각했다. 또한, actuator에서 가시화하는 일부 환경(?)에 맞춰서 효율적으로 데이터를 전달해준다는 정보는 정말 좋은 팁이였던 것 같다.

4. 자바에서 null을 안전히 다루는 방법 (박성철님)

자바개발자라면 모두 궁금해할 만한 주제였다고 생각한다. 개발을 하는 과정에서 null체크를 한다고 했지만 발생하는 NullPointerException. 자바개발자가 가장 흔히 볼 수 있는 Exception이고, 고민을 많이 하는 부분이라고 생각한다. 많은 개발자들에게 고통을 주는 null을 안전하게 다루는 방법이라 하여 흥미가 생겨 이 세션을 듣게 되었다.

4.1. null에 대해서

JVM 언어 전쟁
  • 2000년대 중반 동적 티이핑/스크립팅 언어가 유행

  • 2010년 전후 함수형 프로그래밍

  • 2010년대 중반 null 안정성(실론, 코들린)

null 참조
  • 레코드 핸들링: 객체지향의 시초가 된 논문

  • 특별한 값이 없음을 나타내려고 null을 도입했고 이 값을 사용하려고 할 때 오류를 내도록 설계

  • 두 참조값이 null 일 때 두 참조는 동일하다고 판단

자바의 null 참조
  • 의미가 모호함

  • 초기화되지 않음, 정의되지 않음, 값이 없음, null 값

  • 모든 참조의 기본 상태(값?)

  • 모든 참조는 null 가능

4.2. null을 안전하게 다루는 방법

자바 기본 장치
  • 단정문(assertion)

    • 공개 메서드에서 사용하지 않아야 함

    • 소비자이면서 생산자일 때 만 사용

    • enableassertions 또는 -ea 옵션으로 활성화

  • java.util.Objects

    • null을 핸들링할 수 있는 메소드들이 추가

  • java.util.Optional

    • 변수와 반환값에 null을 사용하지 말라

    • Optional에 값이 있다가 확신하지 않는 한 get을 사용하지 말라

    • isPresent나 get은 가능한 사용하지 말라

    • 필드 매개변수등으로는 사용하지 말라

      • 직렬화 불가

    • 반환값은 사용해도 된다

null 잘 쓰는 법
  • API에 최대한 쓰지 말아라

    • null로 지나치게 유연한 메서드를 만들지 말고 명시적인 메서드를 만들어라

    • null을 반환하지 말라

    • 반환 값이 꼭 있어야 한다면 null을 반환하지 말고 예외를 던져라

    • 빈 반환값은 Null 객체

  • 사전조건과 사후조건을 확인하라: 계약에 의한 설계

    • Design by Contract

    • (개인적으로 좀 더 공부가 필요할 것 같음)

  • null의 범위를 지역(클래스 메서드)화

4.3. 후기

발표자 분께서 null을 다루는 몇가지 방법에 대해서 공유를 해주셨고, 주의할 점에 대해서 공유를 해주셨는데 누군가 알려주지 않았지만 느낌적인 느낌으로 발표내용처럼 하고있던 부분들이 있어서 숙제검사를 받은 느낌이라 좋았고, 주의해야될 부분들이 정말 꿀팁이였던 것 같다.

5. 무엇을 테스트할 것인가? 어떻게 테스트할 것인가? (권용근님)

평소에 테스트에 대해서 많은 관심을 가지고 있기 때문에 꼭 듣고싶었던 세션이다. 세션을 들어가기 전부터 기대를 많이 했고 내용이 궁금했다. 결론적으로는 이번 SpringCamp에서 가장 만족한 세션이었다.

5.1. 테스트로부터 얻을 수 있는것

안정감과 자신감이 생긴다

5.2. 무엇을 테스트할 것인가?

  • 비즈니스 요구사항 정리

  • 구현 vs 설계

  • 구현은 언젠가 변할 수 있고 테스트는 구현에서 무엇을 하는지 알 수 없고 알 필요도 없다

테스트 불가능한 것
  • 외부 요청

  • 외부 저장소

5.3. 어떻게 테스트할 것인가?

  • 테스트할 수 없는 것을 바운더리 레이어까지 올려서 피해를 최소화한다

  • 제어할 수 없는 영역을 파라미터로 받을 수 있는지 검토한다

  • 비즈니스 요구사항 및 설계가 변경될 수 있다

Java, Spring Framework
  • 테스트를 할 때 Spring Context가 굳이 필요하지 않다

  • 테스트를 할 때 비즈니스 프레임워크에 의존하지 말라

Test Double
  • 무엇을 Test Double로 처리?

  • 테스트가 구현을 알아야 함? ⇒ 알 필요 없다

  • 제어할 수 없는 영역을 Test Double로 처리

Embedded
  • 스프링에 내장된 시스템을 최대한 활용(ex. H2)

5.4. Tip & Rule

  • 테스트는 상호 독립적이어야 한다.(데이터간 의존성이 있어서는 안된다)

  • 테스트안에 의도가 드러날 수 있도록 해라

  • 테스트코드도 리팩토링 대상이다

5.5. 후기

앞서 언급했지만 평소에 테스트에 대해서 많은 관심을 가지고 있어서 가장 기대를 했고 주의깊게 들은 세션이다. 전체적으로 나와 비슷한 생각의 내용으로 발표를 하셔서 방향을 잘 잡아가고 있구나 라고 검사를 받은 느낌이 들어서 기분이 좋았다. 다만 Test Double 대상을 선git 정하는 부분에 대해서는 생각이 다른 부분이 있었다. 몇몇 이유때문에 테스트에서는 구현에서 어떤 행위를 하는지 알 수 있고 알아야 한다고 생각한다. 잘 못된 생각을 하고있을 수도 있지만 결론적으로 생각이 바뀌진 않았다. 생각이 바뀌진 않았지만 다른 사람의 생각을 듣고 고민을 하고 다시 생각해볼 수 있는 계기가 되어 좋았다.

6. 당신도 할 수 있는 레거시 프로젝트 개선 이야기 (이경일님)

누구나 경험해본, 경험하고 있는, 경험할 예정인 레거시 프로젝트를 개선한 경험을 공유하는 세션이여서 매우 흥미로운 주제이고 궁금해서 세션을 들었다.

6.1. 레거시 코드란?

  • 막막한 코드?

  • 복잡한 코드?

  • 남(주로 퇴사자)이 짠 코드?

  • 테스트코드로 커버되지 않으며 유지보수가 되고있지 않은 코드

  • 방치되고있는 코드

  • 오랜 시간 안정적으로 돌아가는 코드

6.2. 레거시 코드를 외면하는 이유?

  • 다른사람이 짠 코드는 수정하기 싫다

  • 신규프로젝트가 재미있다

  • 조직에서 인정받기 어렵다(ex. 평가가 좋지 않다…​)

6.3. 레거시 코드 개선

  • DDD? MSA?

    • 하면 좋긴 하다…​

내편으로 만들기
  • 왜 이렇게만들었어 지만 잘 동작은 하고 있음…​

  • 로직 파악하기

  • 직접 돌려보면서 파악하는 것이 중요

  • 테스트 케이스를 봐야함

    • 하지만 테스트케이스가 없을수도 있다

급한불부터 끄기
  • 코드 리팩토링

  • 리팩토링 대상 우선순위 정하기

  • 불필요하거나 수정하기 어려운(? 유지보수하기 어려운?) 것은 과감하게 삭제

한걸음씩 가기
  • 코드 패키지 분리

  • 분리가 용이하도록 설계 변경

  • 코드를 분리할 수 있는 부분은 분리

  • 개선을 하면서 코드 단위가 커지면 또 분리

아픈 곳 고치기
  • 리소스 사용량이 많은 부분은 추출

  • 로컬 캐시를 사용할 수 있는 부분은 로컬캐시를 사용

  • Memory Leak이 있는지 검토(?)

  • Matcher_AppendReplacement ⇒ 메모리 효율이 좋음

  • OOM Killer가 죽일 떄가 있는데 이런 경우 로그를 확인해서 왜 죽였는지 파악

  • v.v2.2 이상이 아니면 쓰지 않는것이…​(안정화가 안됐을 가능성이 높다)

조금 더 다듬기
  • RAM Drive를 사용할 수 있는가?

  • Spring Cloud Config

    • 설정을 Cloud로 관리해서 배포 없이 설정 변경

    • basedir/tmp/ 밑에 들어가서 삭제될 수 있기 때문에 basedir 수정하는것이 좋음

  • GC 튜닝 포인트 확인

6.4. 후기

이경일님의 세션은 레거시 코드를 개선해나간 과정에서 경험한 내용을 공유해주셨다. 세션을 들으면서 레거시 코드를 개선할 때 살펴봐야할 부분들과 주의할 부분 그리고 개선하는 순서 및 개선방법에 대해 생각을 해보게 되었고, 이후에 레거시를 개선한다면 많은 도움이 될 것 같다.

7. 후기

전체적으로 참석한 세션이 모두 만족스러웠지만 특히 권용근님의 "무엇을 테스트할 것인가? 어떻게 테스트할 것인가?"와 이경일님의 "당신도 할 수 있는 레거시 프로젝트 개선 이야기" 세션이 정말 재미있었다. 이 중에도 권용근님의 세션이 정말 좋았는데, 앞서 작성한 후기 내용처럼 내가 생각하는 부분과 유사해서 '방향을 잘 잡아가고 있구나' 라고 생각을 할 수 있었고, 발표 내용중에 내가 생각하는 부분과 다른 부분에서는 '저렇게 할 수도 있구나, 저렇게 해서 얻는 이점이 뭐지?'라고 비교 및 고민을 해볼 수 있게되어 좋았다.

멀티리전 가용성을 위한 글로벌 캐싱 - Hidden micro services (정윤진님, 김필중님), Local Cache와 Invalidation Message Propagation 전략을 활용하여 API 성능 튜닝하기 (김민규님) 이 두 세션도 듣고 싶었지만 컨디션이 좋지 않아 일찍 귀가를 해서 듣지 못해 조금 아쉬운 부분이 남았다.

최근에 조금 많이 안일해져서 이전처럼 공부를 많이 하고 있지 않았는데, 이번에 SpringCamp에 참석해서 나에게 다시 자극을 줄 수 있는 계기기 되었고 이로 인해 정말 참석을 잘 했다 라는 생각을 한다. 이번 행사에서 아쉬운 부분이 조금은 있었지만 SpringCamp는 참석할 때 마다 매우 만족하고 있고, 다음 SpringCamp도 벌써 기대가 된다.


Pagination