1. “Hello World”로 간단히 빠르게 사용법 익히기 2. 서비스를 만들며 만나는 문제를 깊이 있는 학습 가이드 삼기 3. 테스트 코드로 분명하게 이해하기

변하지 않는 것과 변하는 것 그리고 함께 변하는 것과 따로 변하는 것을 구분한 좋은 표본

특정 하드웨어 시스템을 제어하기 위해 Netty 기반 메시징 서버를 개발중입니다. 시험 중 특정 조건이 되면 타겟 시스템에서 일부 메시지를 처리하지 못하는 문제가 발생했는데요. 문제를 해결하기 위해 메시징 서버의 구조를 개선한 사례를 소개합니다.문제가 발생한 서버 시스

이 글을 읽어서 좋습니다.

개발자가 코드를 작성하는 기본적인 이유는 어떤 기능을 구현한 제품을 만들기 위해서입니다. 그런데 종종 우리는 좋은 코드를 만들어야 한다는 말을 듣습니다. 기능을 똑같이 구현하는데 좋은 코드를 만들어야 하는 이유는 무엇일까요? 그리고 좋은 코드는 어떻게 만드는 걸까요?

성공하는 코드 서비스들은 사용자가 복잡해 하는 기술적인 영역을 대신 구현하고, 그것을 구현한 자신은 서비스 뒤에 숨기며, 사용자가 자신의 비지니스 로직 구현에 집중하고, 비지니스 로직만 코드에 드러날 수 있게 함을 목표한다는 공통된 철학을 가지고 있는 것 같습니다.

동기와 비동기의 개념 / 코드 구현(Java) 상의 차이 / 성능 차이 측정 / 장단점 / 그리고 왜 사용하고 어떤 분야에 적합한지 개인적으로 정리해 보았습니다.

서비스 추상화와 목(Mockito) 프레임워크 활용

좋은 기회였던 것 같습니다. 특정 도메인에서 다양한 외부 API 서버와 통신하는 컴포넌트를 연이어 개발할 수 있었습니다. 1년 동안 7개 정도의 통신 컴포넌트를 개발했네요. 통신 프로토콜은 모두 달랐지만 처리하는 구조는 유사했기 때문에 점진적으로 통신 컴포넌트를 개선해

동료와 주석을 달아야 하는지, 달지 말아야 하는지 대화를 하다가 생각난 것들을 정리해봅니다. 예를 들면 이런 주석이 있습니다. frequency 라는 변수명에 주파수라는 주석을 달아놓았습니다. 영어를 그냥 한글로 해석한 것인데 javadoc으로 문서 생성을 할 때에만

내가 작성한 코드를 다른 사람에게 설명하기 위해 다시 들여다 보고 있다. 꽤 유익한 경험이다. 나는 주석을 잘 달지 않는 편인데 가능하면 코드를 읽고 의미가 드러나도록 노력하기 위해서 그리고 코드에 드러난 의미를 다시 주석으로 다는 중복을 피하기 위함이다. 그런데 내

JMS Listener로 메시지를 던지는데 메시지가 Listener로 전달되지 않았다. 이것 저것 확인해 보다가 Listener 메서드 파라미터 타입이 Super 클래스의 Sub 타입 A로 되어 있었다. 기존에 A 타입만 처리하던 것에서 B 타입까지 처리하도록 확장하면

애노테이션은 정의하기에 따라서 타입, 필드, 메서드, 파라미터, 생성자, 로컬 변수의 한 군데 이상 적용 가능하다.애노테이션이 부여된 클래스의 패키지, 클래스 이름, 접근 제한자, 상속한 클래스나 구현 인테페이스가 무엇인지 알 수 있다.애노테이션 같은 메타정보를 활용하

토비의 스프링 ‘7장 스프링의 핵심 기술의 응용’을 읽고 정리합니다. 6장까지 개선해왔던 UserDao에서 SQL 쿼리문을 분리하여 손쉽게 유지보수하고 확장가능한 구조를 만들어가는 과정에 집중합니다.반복적인 JDBC 작업 흐름은 템플릿을 이용해 DAO에서 완벽하게 제거

dev 프로파일일 때만 서비스 프로세스 내에 로드되어 테스트를 돕는 하드웨어 API 서버 시뮬레이터 N개가 있다.시뮬레이터는 스프링 빈으로 등록되어 있고 생성자에서 TCP 서버 모듈 생성과 초기화를 한다.dev 프로파일로 서비스를 실행할 때 종종 TCP 서버 포트가 이

새로운 외부 API 서버와 연동하는 모듈 개발을 시작했다. 이 프로젝트의 마지막 개발이 될 것 같다. 기존에 개발했던 모듈의 인터페이스 문서와 비교해 보니 구조가 동일하고 메시지의 종류나 일부 값들이 조금씩 다르다. 그래서 먼저 기존 모듈을 재활용이 용이한 구조로 개선

신규 안테나의 제약사항 때문에 미션을 수행할 수 없는 구간이 생기는 문제가 있었다. 하드웨어 엔지니어로부터 미션이 안되는 구간을 감안하고 운영하겠다는 이해할 수 없는 대답을 듣고 마음이 어려웠던 기억이 난다. 그 날 회고를 하면서 나 스스로 문제를 해결하겠다는 마인드를

생성자에 동일한 타입의 두 개 이상의 파라미터를 입력받아야 한다면 사용자 코드에 첫 번째 파라미터와 두 번째 파라미터 의미가 명시적으로 드러나지 않는다. 만약 두 파라미터의 순서를 실수로 잘못 전달해도 아무런 컴파일 오류가 나지 않고 실제 로직 상의 오류가 런타임에 발

스스로 더 즐겁게 기록하자. 기능 구현 중 직접적으로 관련 없는 클래스, 메서드, 변수 이름 리팩토링이 흔하게 일어난다. 그래서 현재 집중하고 있는 수정사항과 관련이 없는 많은 파일이 함께 바뀌면서 하나의 커밋에 여러가지 수정사항이 섞이는 현상이 자주 일어났다. 이렇게

계속해서 코드 작성과 테스트에 집중하고 있다. '데이터를 가져오지 말고 작업을 요청하라'는 원리가 계속 작동한다. 허용하는 범위를 초과하는 값을 메시지에 실어 보내면 채널 파이프라인의 전송 메시지 검증 핸들러에서 오류가 캐치되고 실제 타겟으로 메시지가 전송되지 않음을