더 나은 코드

템플릿에 콜백을 위한 객체를 전달할 때 람다식을 사용하시나요? Functional 인터페이스를 정의한 분리된 클래스 객체를 전달하시나요?

오늘 작성한 코드를 복기해 보았습니다.

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

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

어제 팀에서 작성된 코드 중에 이런 패턴의 코드가 있어서 Effective Java 책의 내용(아이템 7 다 쓴 객체 참조를 해제하라)을 살펴보았습니다.결론은 ‘다 쓴 객체 참조를 프로그래머가 항상 명시적으로 해제(null 처리)할 필요는 없다’ 입니다. 아래는 관련된

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

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

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

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

이 글을 읽어서 좋습니다.

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

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

좋은 프레임워크 덕에 간단히 Hello World 로 익힌 기능으로 제품 코드를 작성할 수도 있지만 그것으로 부족할 때가 많습니다.

단위테스트 책에서 비지니스 로직에서 의존 객체들과의 커뮤니케이션하는 코드를 완전히 분리해서 별도의 객체가 수행하도록 하고 비지니스로직을 담은 객체는 이렇게 하면 핵심 비지니스 로직에 대한 테스트 코드를 작성하고 유지보수하기 쉬워진다. 실행 성능도 좋아지며 중요한 비지니