<div id="readability-page-1" class="page"><div>Image by <a href="https://www.freepik.com/free-photo/still-life-illustrating-ethics-concept_26407526.htm#query=philosophy&amp;from_query=%EC%B2%A0%ED%95%99&amp;position=1&amp;from_view=search&amp;track=sph">Freepik</a> 
<img src="https://velog.velcdn.com/images/joosing/post/ecc36892-76b3-47a7-8142-adac80a52916/image.png">
<blockquote>
성공하는 코드 서비스들은 사용자가 복잡해 하는 기술적인 영역을 대신 구현하고, 그것을 구현한 자신은 서비스 뒤에 숨기며, 사용자가 자신의 비지니스 로직 구현에 집중하고, 비지니스 로직만 코드에 드러날 수 있게 함을 목표한다는 공통된 철학을 가지고 있는 것 같습니다.
</blockquote>
몇 일 전에 <a href="https://velog.io/@joosing/focus-on-business-logic-in-asynchronous-test-code">'비지니스 로직에 집중하는, 비동기 테스트 코드 만들기 (Awaitility)'</a> 라는 글을 쓰고 집으로 걸어가는 밤길에 생각이 났습니다.
<h2 id="서비스-받은-경험">서비스 받은 경험</h2>
비동기 시스템을 테스트 하는 코드를 작성하며 테스트하려는 비지니스 로직과 비동기적인 처리를 위한 기술적인 코드가 뒤섞여 있어 불편했습니다. 
<pre><code>@Test
void inventory_reflects_requested_value() {
 // 1. When - 상태 변경 명령 전송
 store.requestAsync(new ChangeInventory(100));

 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 long startMillis = System.currentTimeMillis();
 while (System.currentTimeMillis() - startMillis &lt; 2000) {
 if (store.getInventory() == 100) { // condition 
 // success
 return;
 }
 }

 // 3. (실패 시) 실패 판정에 사용된 값 출력
 log.info("status : {}", store.getInventory());
 fail();
}</code></pre>
여러 시도를 하던 중에 알게 된 <a href="https://github.com/awaitility/awaitility">Awaitility</a> 라는 서비스의 도움으로 코드를 간결하게 만들 수 있었습니다. Awaitility 서비스는 제가 직접 작성하던 비동기 처리를 위한 기술적인 코드를 대신 작성해 주었고(더 멋지게), 복잡했던 기술적인 코드를 자신 뒤에 숨겨주었습니다. 그리고 사용자가 비지니스 로직을 테스트하는 코드에 집중하고, 비지니스 로직과 관련된 코드만 궁극적으로 드러나게 해주었습니다. 
<pre><code>@Test
void inventory_reflects_requested_value_awaitility() {
 // 1. When - 상태 변경 명령 전송
 store.requestAsync(new ChangeInventory(100));

 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 with().conditionEvaluationListener(condition -&gt; log.info("status on failure : {}", store.getInventory())) // 테스트 조건 확인 시, 상태 값을 출력합니다
 .await() // 기다립니다
 .atMost(500, MILLISECONDS) // 500 msec 동안
 .pollInterval(ofMillis(100)) // 100 msec 간격으로
 .until(() -&gt; store.getInventory() == 100); // 다음 조건을 통과할 때까지
}</code></pre>
<h2 id="스프링의-철학">스프링의 철학</h2>
문득 토비의 스프링 책에서 배웠던 스프링의 <a href="https://velog.io/@joosing/%ED%86%A0%EB%B9%84%EC%9D%98-%EC%8A%A4%ED%94%84%EB%A7%81%EC%9D%84-%EC%9D%BD%EA%B3%A0">감동적인 철학</a>이 떠올랐습니다. 스프링은 엔터프라이즈 환경에서 기술적인 복잡함과 비지니스의 복잡함을 분리하려 했고, 기술적인 복잡함은 자신이 구현하고, 스스로는 프레임워크 뒤에 숨겼으며, 사용자가 비지니스 로직 구현에 집중하고 비지니스 로직과 관련된 코드만 드러나게 노력했다는게 설명의 요지였습니다. 오늘 만난 Awaitility 그리고 Spring 뿐만 아니라 Netty, JUnit 같은 많은 좋은 프레임워크들이 이와 같은 공통된 철학을 가졌다는 생각이 걸어가는 길에 떠오릅니다. 
<h2 id="나도-나아갈-길">나도 나아갈 길</h2>
사용자가 어려움을 겪고 있는 복잡한 기술 영역을 서비스하고, 기술의 존재는 숨기며, 사용자가 각자의 비지니스를 잘할 수 있게 돕는, 그래서 사용자의 영역이 드러나게 하는 서비스를 만들면 Spring처럼 Awaitility처럼 유익한 서비스가 될 수 있겠다는 생각이 듭니다. 내가 할 수 있는 일은 어떤 것이 있을지 생각해 봅니다.</div></div>

Joo's Work

JooSing

Image by Freepik 
성공하는 코드 서비스들은 사용자가 복잡해 하는 기술적인 영역을 대신 구현하고, 그것을 구현한 자신은 서비스 뒤에 숨기며, 사용자가 자신의 비지니스 로직 구현에 집중하고, 비지니스 로직만 코드에 드러날 수 있게 함을 목표한다는 공통된 철학을 가지고 있는 것 같습니다.
몇 일 전에 '비지니스 로직에 집중하는, 비동기 테스트 코드 만들기 (Awaitility)' 라는 글을 쓰고 집으로 걸어가는 밤길에 생각이 났습니다.
서비스 받은 경험
비동기 시스템을 테스트 하는 코드를 작성하며 테스트하려는 비지니스 로직과 비동기적인 처리를 위한 기술적인 코드가 뒤섞여 있어 불편했습니다. 
@Test
void inventory_reflects_requested_value() {
 // 1. When - 상태 변경 명령 전송
 store.requestAsync(new ChangeInventory(100));
 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 long startMillis = System.currentTimeMillis();
 while (System.currentTimeMillis() - startMillis < 2000) {
 if (store.getInventory() == 100) { // condition 
 // success
 return;
 }
 }
 // 3. (실패 시) 실패 판정에 사용된 값 출력
 log.info("status : {}", store.getInventory());
 fail();
}
여러 시도를 하던 중에 알게 된 Awaitility 라는 서비스의 도움으로 코드를 간결하게 만들 수 있었습니다. Awaitility 서비스는 제가 직접 작성하던 비동기 처리를 위한 기술적인 코드를 대신 작성해 주었고(더 멋지게), 복잡했던 기술적인 코드를 자신 뒤에 숨겨주었습니다. 그리고 사용자가 비지니스 로직을 테스트하는 코드에 집중하고, 비지니스 로직과 관련된 코드만 궁극적으로 드러나게 해주었습니다. 
@Test
void inventory_reflects_requested_value_awaitility() {
 // 1. When - 상태 변경 명령 전송
 store.requestAsync(new ChangeInventory(100));
 // 2. Then - 일정 시간 동안 상태 변경 여부 확인
 with().conditionEvaluationListener(condition -> log.info("status on failure : {}", store.getInventory())) // 테스트 조건 확인 시, 상태 값을 출력합니다
 .await() // 기다립니다
 .atMost(500, MILLISECONDS) // 500 msec 동안
 .pollInterval(ofMillis(100)) // 100 msec 간격으로
 .until(() -> store.getInventory() == 100); // 다음 조건을 통과할 때까지
}
스프링의 철학
문득 토비의 스프링 책에서 배웠던 스프링의 감동적인 철학이 떠올랐습니다. 스프링은 엔터프라이즈 환경에서 기술적인 복잡함과 비지니스의 복잡함을 분리하려 했고, 기술적인 복잡함은 자신이 구현하고, 스스로는 프레임워크 뒤에 숨겼으며, 사용자가 비지니스 로직 구현에 집중하고 비지니스 로직과 관련된 코드만 드러나게 노력했다는게 설명의 요지였습니다. 오늘 만난 Awaitility 그리고 Spring 뿐만 아니라 Netty, JUnit 같은 많은 좋은 프레임워크들이 이와 같은 공통된 철학을 가졌다는 생각이 걸어가는 길에 떠오릅니다. 
나도 나아갈 길
사용자가 어려움을 겪고 있는 복잡한 기술 영역을 서비스하고, 기술의 존재는 숨기며, 사용자가 각자의 비지니스를 잘할 수 있게 돕는, 그래서 사용자의 영역이 드러나게 하는 서비스를 만들면 Spring처럼 Awaitility처럼 유익한 서비스가 될 수 있겠다는 생각이 듭니다. 내가 할 수 있는 일은 어떤 것이 있을지 생각해 봅니다.

성공하는 코드 서비스들의 숨겨진 철학 (대신하고, 숨기고, 드러나게)

댓글