profile
Software Engineer + Product Manager
태그 목록
전체보기 (190)개발일기(32)Netty(16)테스트(16)토비의 스프링(12)trouble shooting(12)생각(10)How to work(10)Java(10)tcp(8)network programming(7)프로덕트 오너(7)회고(6)토비의스프링(6)우주지상국(6)agile(6)더 나은 설계(5)wireshark(5)2021(5)TDD(4)git(4)코드리뷰(4)github(4)프로젝트 매니저(3)Telnet(3)커리어(3)asynchronous(3)실시간(3)IntelliJ(3)Spring(3)windows(3)고민(3)multithreading(3)2022(3)인프콘(3)test(3)Software Engineering(3)네트워크 패킷분석(3)오브젝트(3)debug(3)C(2)collaboration(2)독서(2)networking(2)함께자라기(2)소프트웨어 개발자(2)(2)Thread(2)사용자(2)management(2)개방폐쇄원칙(2)http(2)clean architecture(2)컨퍼런스(2)Resource Leak(2)배포(2)실용주의 프로그래머(2)관계(2)Locale(2)TROUBLESHOOTING(2)클린 아키텍처(2)User Manual(2)리더(2)의존관계(2)더 나은 디자인(2)배움(2)습관(2)test case(2)ci(2)기획(2)jackson(2)(2)software engineer(1)Pair Programming(1)TCP Connection Persistence(1)균형(1)고객(1)Device Driver(1)실험(1)면접(1)동료주도개발(1)소수점(1)프로토타입(1)메모리가시성(1)Interrupt(1)요구사항(1)데이터(1)Q&A(1)util(1)Functional(1)사용자중심(1)ux(1)제품(1)가짜필요(1)사람(1)결합도(1)동료(1)조직(1)아주힘듬(1)network(1)디버깅(1)Messaging Server(1)모델링(1)분석(1)CI/CD(1)Manangement(1)switch(1)Nginx(1)커뮤니케이션(1)json(1)자유(1)환경(1)1553B(1)프로그래밍(1)redmine(1)cherry-pick(1)impact(1)우주(1)행복(1)String(1)인터뷰(1)Messaging System(1)복잡성(1)클린코드(1)Ideation(1)di(1)커밋(1)putty(1)리팩토링(1)JIRA(1)성과(1)화면중심(1)clean software(1)Native(1)SDLC(1)발표(1)마음 가짐(1)제안서(1)JNA(1)개발문화(1)notion(1)협업(1)개발자(1)사업(1)Software Enginerring(1)split()(1)멀티쓰레드(1)Messaging Service(1)의존(1)문제(1)mock(1)프로젝트(1)Product Design(1)유틸리티(1)Strategy Pattern(1)예측(1)aws(1)Feedback(1)변경(1)작업난이도(1)snmp4j(1)이슈관리(1)데이터 통신(1)핀란드(1)준비(1)장애회고(1)읽기모임(1)volatile(1)창업(1)아두이노(1)디자인 패턴(1)신뢰성(1)User Journey(1)코딩(1)lua script(1)테스트케이스(1)가치(1)alignment(1)heap memory(1)노이즈캔슬링(1)MVP(1)독서메모(1)일기(1)algorithm(1)마인드(1)메타포(1)템플릿(1)설계(1)authentication(1)cdd(1)부족함(1)협력(1)코드변경관리(1)세미나(1)변화(1)Persona(1)문서(1)자동화(1)캐시일관성(1)인증(1)SNMP(1)매니지먼트(1)비실시간(1)객체지향의사실과오해(1)커뮤니티(1)refactoring(1)StringUtils(1)Network Analyze(1)Pain Point(1)dll(1)추상화(1)figma(1)비정상종료(1)우선순위(1)캐시불일치(1)IoC(1)assembly(1)projects(1)집중(1)actions(1)SI 프로젝트(1)신뢰(1)trouble shoooting(1)백로그(1)Product Designer(1)S3(1)Pull Request(1)아쉬움(1)ObjectMapper(1)iteration(1)VxWorks(1)PacketSender(1)junit(1)주간보고(1)JConsole(1)불편(1)코드작성외에(1)Memory Leak(1)응집도(1)

개발일기 #38 : Marker Interface 아이디어

하루를 돌아보며 오늘 했던 몇 가지 설계 결정 사항들의 이유를 정리하는게 쉽지 않다. 뭔가 이거다 싶어서 방향을 잡고 나아갔는데 처음 생각과는 달리 새로운 상황을 계속 마주하며 어떻게 어떻게 나아간 느낌이 더 많이 든다. 그래도 하나씩 정리해 보자. 하나의 전송 메시지

약 13시간 전
·
0개의 댓글
·
post-thumbnail

IntelliJ 디버그 모드 실행 시 로딩 시간 지연 문제 개선

intellij에서 스프링 부트 기반의 애플리케이션을 개발하고 있다. 종종 디버그 모드로 실행하고 브레이크 포인트를 걸어 코드를 확인해 보기도 하는데 디버그 모드로 실행하면 초기 애플리케이션 로딩시 아주 오랜시간이 걸린다. 디버그 모드라 다 그런줄 알고 있었는데, 오늘

약 13시간 전
·
0개의 댓글
·

개발일기 #37 : 부딪히는 말들

오늘 마주한 몇몇 말들이 마음에 불편함이 된다. 합의하여 정한 일정 중 하루를 예정에 없던 용도로 사용하겠다고 통보하면서 데드라인은 그대로 유지하겠다는 말을 듣는다. 무례하게 느껴진다. 하루를 다른 용도로 사용하면 데드라인도 하루 미루는게 당연하다고 말해주었다.예외적인

3일 전
·
0개의 댓글
·

토비의 스프링 | 3장 템플릿 (모임 중 든 생각, 기억에 남는 말말말)

‘객체란 무엇인가?’라는 질문을 받고 순간적으로 상태와 행위를 가진 프로그래밍의 단위 정도가 생각납니다. 조금 있다 문득 객체 중에는 상태가 없이(사용자가 멤버 변수를 정의하지는 않아도 사실 객체가 되기 위해 JVM이 관리하는 상태는 있을 테지만) 행위만 가지는 객체도

4일 전
·
0개의 댓글
·

콜백을 위해 항상 람다식을 전달하는게 좋나요?

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

4일 전
·
0개의 댓글
·

개발일기 #36 : 변경되지 않는다면

프로젝트가 끝날 때까지 메시지가 추가되지 않을 것 같다면 if-else 체인으로 그냥 처리해도 될 것 같다. 좋은 디자인 패턴을 먼저 적용하려고 하기 보다 테스트를 통과하는 코드를 빠르게 작성하고 코드를 점진적으로 개선해 나가는게 더 도움이 된다. 어제 읽기모임을 통해

4일 전
·
0개의 댓글
·

토비의 스프링 | 변하는 것과 변하지 않는 것을 분리하는 과정

토비의 스프링 3장(템플릿)에서 거대하고 복잡한 하나의 메서드에서 변하는 것과 변하지 않는 것을 분리하며 객체지향의 핵심 원칙(개방폐쇄원칙)을 점진적으로 구현해 나가는 과정을 보여줍니다. 중복을 제거하고 재활성을 높였으며 변경에는 닫혀 있고 확장에는 열려있는 이 코드를

5일 전
·
0개의 댓글
·

토비의 스프링 | 3장 템플릿 (독서메모)

토비의 스프링을 읽고 핵심적인 내용을 정리합니다.개방 폐쇄 원칙 (OCP, Open-Closed Principle)이란 자유로운 확장에는 열려있고 변경에는 굳게 닫혀 있다는 객체지향 설계의 핵심 원칙이다. 이 원칙은 코드에서 어떤 부분은 변경을 통해 그 기능이 다양해

5일 전
·
0개의 댓글
·

토비의 스프링 | 3장 템플릿 (생각나눔)

토비의 스프링을 읽고 인상적이었던 부분과 느낀점을 정리합니다.매 장을 읽을 때 마다 새롭고 좋습니다. 3장이 변하지 않는 것과 변하는 것을 분리하는 개념이 나오는데 책에는 스프링이 버전업 되어도 변하지 않는 가치가 풍성하게 담겨있다는 생각이 듭니다. 3장에서 하나의 메

5일 전
·
0개의 댓글
·

개발일기 #35 : 다양한 선택지와 이유들

처음으로 배운 프로그래밍 언어는 대학 1학년 때 C 언어였다. 그리고 다음해 Java를 배우는데 과제를 엄청 내주셨다. C 수업에서 구구단 출력하기 같은게 과제였다면 Java 수업에서는 도서관 대출 프로그램 같은게 과제로 나왔다. 그때 나는 프로그래밍을 그만하고 싶을

6일 전
·
0개의 댓글
·

개발일기 #34 : 서비스 코드 안에 테스트 코드

외부 시스템으로 전송하는 메시지는 값을 조회하는 쿼리(Query)와 값을 변경하는 명령(Command)으로 구분된다. 쿼리와 명령 메시지를 처리하는 모듈의 단위 테스트를 위해서는 외부 시스템을 모의하는 프로그램을 내장(Embedded)하고 테스트를 진행한다. 명령 전송

7일 전
·
0개의 댓글
·

개발일기 #33 : Client First

TDD(Test Driven Development)를 사용하면 실패하는 테스트 코드를 먼저 작성하고 테스트를 성공하는데 필요한 코드에 집중함으로 꼭 필요한 코드만 만들게 되는 효과를 볼 수 있다. 비슷하게 우리가 어떤 부분적인 스펙을 구현하기 위해 서로 의존관계를 가지

2022년 9월 22일
·
0개의 댓글
·

개발일기 #32 : 추상화 계층

기존에 WEB에서 API 서버를 거쳐 외부 시스템까지 전달되는 경로에 모두 외부 시스템에서 정의한 메시지 ID와 의존적인 메시지 구조를 사용했다. 이유는 변환과정이 필요 없어서 간단했기 때문이다. 그러나 외부 시스템 통신 인터페이스에 변화가 생기면 WEB까지 수정되어야

2022년 9월 21일
·
0개의 댓글
·

개발일기 #31 : 실험과 과정이기에 의미 있는 코드리뷰

출퇴근 길에 토비의 봄티비 유투브 채널 박재성님 편을 듣고 있다. 박재성님은 기존에 강의만 하는 방식에 문제의식을 느끼고 과제를 하고 코드리뷰를 매일 해주는 방식의 교육을 만드셨다고 한다. 3년전 영상이라 아직 하시나 해서 찾아보니 Next Step이라는 사이트가 아직

2022년 9월 21일
·
0개의 댓글
·
post-thumbnail

소프트웨어의 복잡성과 모델링

지금까지 하나의 채널로 하나의 외부 시스템을 제어하는 구조만 만나왔는데 새로운 시스템은 두 개의 채널로 하나의 시스템을 제어하는 특별한 구조를 가지고 있다. 별거 아닌거 같은데 오늘 채널의 메시지 처리 파이프라인을 구성하며 어려움을 겪는다. 간단한 외부 환경 변화 하나

2022년 9월 21일
·
0개의 댓글
·

개발일기 #30 : 아는 만큼 보인다

토비의 스프링 3장 템플릿을 읽기 시작했습니다. 시작하자 마자 너무 명쾌한 설명을 만납니다.개방 폐쇄 원칙 (OCP, Open-Closed Principle)이란 자유로운 확장에는 열려있고 변경에는 굳게 닫혀 있다는 객체지향 설계의 핵심 원칙이다. 이 원칙은 코드에서

2022년 9월 20일
·
0개의 댓글
·

MockBean이 뭐야?

최근에 백엔드 개발자들과 테스트에 대한 이야기를 나누다보면 Mocking에 대해 어떻게 생각하는지, 또는 Mock을 써도 되냐 안되냐 같은 질문을 종종 접합니다. 사실 Mock이 무엇을 의미하는지 몰라서 사전을 찾아보니 ‘가짜의’, ‘모의의’ 이런 뜻이네요. 그러고 보

2022년 9월 20일
·
0개의 댓글
·

개발일기 #29 : 내부 모듈 테스트는 디버거도 괜찮다

지난주 TDD로 기능 하나를 개발하면서 약간의 어려움을 겪었다. 대게 기능 내부를 블랙박스로 두고 외부 인터페이스만 테스트하는 테스트 코드를 먼저 작성했었는데 기능을 구성하는 내부 모듈들이 생각보다 많고 크기가 커서 테스트를 돌리지 못하고 코드를 작성하는 시간이 점점

2022년 9월 19일
·
0개의 댓글
·

토비의 스프링 | 2장 테스트 (모임 중 든 생각, 기억에 남는 말말말)

토비의 스프링 책 2장은 왜 테스트 코드를 작성해야하는지 설명하는데 좋은 레퍼런스가 되는 것 같습니다.테스트코드가 때때로 문서화가 되기도 해서 좋습니다.JUnit 테스트 메서드는 default 접근제어자면 충분합니다.의존하는게 많아지면 테스트가 어려워집니다. 테스트가

2022년 9월 18일
·
0개의 댓글
·

토비의 스프링 | 2장 테스트 (핵심 요약)

테스트 코드를 만들어야 스프링이 지원하는 가치를 누릴 수 있다. 테스트 코드가 없었다면 지금의 스프링 자신도 없었을 것이다.테스트 코드는 개발자의 행복과 관련이 있다. 테스트 코드는 내가 만든 코드를 확신할 수 있게 하고, 마음에 안정감을 준다. 테스트 코드는 변화(코

2022년 9월 18일
·
0개의 댓글
·