스터디/클린코드

Junit에서 테스트 데이터 클리닝 하기

들어가며 책 단위테스트에서 통합테스트를 할 경우 공유 의존성의 초기화에 대해 이야기를 하는 부분이 있다. 공유 의존성은 테스트 컨텍스트를 공유하는 여러 테스트를 같이 실행하면 말 그대로 공유하기 때문에 앞서 실행된 테스트가 뒤에 실행되는 테스트에 영향을 미친다는 것이다. 그렇기 때문에 이 의존성에 대한 초기화 작업이 필요하다. 그렇다면 공유 의존성의 초기화 작업은 언제하는게 좋을까? 이에 대한 대답도 책에서 답해주고 있다. 테스트를 수행하기 전에 초기화를 해주는 것이다. 필자는 예전부터 습관적으로 테스트가 끝나고 마지막에 테스트에 사용된 공유 데이터를 지우는 작업을 했다. 테스트를 수행하면서 필요한 셋업데이터를 만들고 테스트 대상을 검증하며 생긴 데이터가 있으니 이후에 생성된 데이터를 지워야 한다는 생각..

2023.02.28 게시됨

생각/회고

2023년 1월 회고

들어가며 회고를 쓸 때 마다 매번 똑같은 생각을 한다. 시간은 정말 정말 빠르다. 그래서 시간을 허투루 쓰지 않고 내 발전을 위해서 알차게 쓰기 위해 계획을 세우고 잘 이행하는게 정말 중요한 것 같다. 2022년 회고를 하면서 잘 지키지 못했던 계획이 있었고 2023년에 계획을 조금 수정해서 이어가보기로 했다. 한달에 한편의 기술 블로그 글 작성 한달 회고 작성 분기에 최소 1권의 기술 책 읽기 두달에 최소 1권의 경제 책 읽기 X원 모으기 목표 점검 한달에 한편의 기술 블로그 글 작성 기술 블로그 글 작성 하는건 항상 어렵다고 생각한다. 나만의 허들 같은게 있다. ‘이 정도는 글로 작성해 둘만 하겠다!’ 같은 허들. 보통의 경우 특정 기술에 대해 딥 다이브 한 뒤 그 내용을 정리해서 글을 작성해야 만족..

2023.02.05 게시됨

스터디/스프링

Spring Batch 멀티 스레드 프로세싱을 활용하며 겪은 문제 (1)

들어가며 보통의 팀들이 사용하듯 통계성, 일회성 작업을 배치로 많이 작성하여 해결하고 있다. 그런데 필자가 기본적인 배치의 구조를 잘못 이해하면서 문제가 발생했다. 스프링 배치의 멀티 스레드 프로세싱을 활용하며 겪은 문제 중 잡 스코프(job scope)를 가지는 빈(bean)을 사용할 경우 겪은 문제를 기록한다. 문제 회사 코드를 가져올 수 없으니 예제 코드를 작성하고 요구사항에서 문제가 발생한 부분에 집중하기 위해 불 필요한 부분은 생략하였다. 코드는 코틀린으로 작성했다. 요구 사항 다른 시스템에서 전달받은 이벤트 중 특정 이벤트의 값이 잘못되어 올바르지 않은 값이 저장되었다. 다른 시스템을 담당하는 팀에서 파일로 전달받은 값으로 특정 데이터들을 수정해야 한다. 작성한 코드 배치 코드 처리 속도를 올..

2023.01.30 게시됨

스터디/세미나 기록

백명석님의 지속가능한 SW 개발을 위한 코드리뷰

소프트 웨어 장인정신이란? 지식과 경험의 공유로 전문성을 갖춘 개발자를 육성 후배들에게 지식과 경험을 공유 코드리뷰 개발자가 지금부터 당장 행할 수 있는 공유 활동 배움을 주고 받으며 지속가능한 SW개발자가 될 수 있는 실천법 목적? 주목적은 품질문제 검수 학습 및 지식 전달 코드, 해결책 등 관련 지식 공유에 기여 대게 리뷰어들도 하드 스킬과 소프트 스킬도 얻게 된다. 다른 사람이 잘 하는 모습을 보고 동기부여가 잘 된다. 상호 책임감 증대 오너십 및 결속 증대 팀에서 일어나는 일 공유 설계 개선 제안 개발 문화 개선 코드리뷰가 어려운 이유 좋은 PR을 만들기 위해서 PR의 저자가 고생해서 설명을 적어주어야 한다. 만드는 사람이 고생해야 쓰는 사람이 편하다와 같은 논리 코드에 대한 비판을 자신에 대한 ..

2023.01.08 게시됨

생각/회고

2022년 회고

2022년 회고를 작성하며 2022년에는 1년차 개발자로서 회고를 작성했는데 이번 회고는 개발자 뿐 아니라 개인적인 내용도 담아 회고를 작성하고자 한다. 2022년 계획은 얼마나 달성했나? 2022년 내 목표는 아래와 같다. 현재 내가 속한 회사 역량레벨의 항목을 전부 만족하기 한달에 한편 이상의 기술 블로그 글 작성하기 한달에 한권 이상의 기술 서적을 읽기 한달 회고 작성하기 결론부터 말하자면 내가 속한 회사 역량레벨의 항목을 만족하는 것 외에는 전부 지키지 못했다. 정확히는 딱 세달 유지했다. 2월까지 잘 지켰지만 이후에는 잘 지켜내지 못했다. 3월에 내가 목표를 달성하지 못했다는걸 인지 했을 때 ‘회사 일이 너무 바쁘다’, ‘한달에 한번씩 지켜내기에 너무 힘든 목표다.’ 라고 생각했다. 지금 되돌아..

2023.01.01 게시됨

스터디/이펙티브코틀린

아이템 15 - 리시버를 명시적으로 참조하라

무언가를 더 자세하게 설명하기 위해서, 명시적으로 긴 코드를 사용할 때가 있듯이 리시버도 명시적으로 적어주는 것이 좋다. 단지, 짧게 적을 수 있다는 이유만으로 리시버를 제거하지 말자. 여러 개의 리시버가 있는 상황에는 명시적으로 적어주는 것이 좋다. 여러 개의 리시버 특히 스코프 내부에 둘 이상의 리시버가 있는 경우, 리시버를 명시적으러 적어주도록 하자. 이를 지켜주면 코드를 오해하고 작성하거나, 의도하지 않은 방향으로 코드가 동작하는걸 미연에 방지할 수 있다. AS-IS class Node(val name: String) { fun makeChild(childName: String) = create("$name.$childName") .apply { print("Create $name") } fun ..

2022.03.25 게시됨

스터디/이펙티브코틀린

아이템 14 - 변수 타입이 명확하지 않은 경우 확실하게 지정하라

앞장에서도 계속해서 언급해왔듯이 프로그래밍은 쓰기보다 읽기가 중요하다. 따라서 가독성을 위해 코드를 설계할 때 읽는 사람에게 중요한 정보를 숨겨서는 안된다. 코드를 읽으면서 숨겨진 변수 타입을 확인하기 위해 함수 내부로 일일히 들어가서 확인해야 한다면 당연히 가독성은 떨어질 수 밖에 없다. 사람이 작업을 위해 잠깐 동안 기억할 수 있는 기억력의 총량은 그리 크지않다. 다시 말해 한정된 사람의 메모리 자원을 쓸데없이 낭비하는 것은 좋지 않다. 물론 매번 변수타입을 명확하게 하라는 것은 아니지만 적절히 가독성을 위해서 변수타입을 명확하게 지정해 주도록 하자. 그러면 타입 안정성까지 덤으로 얻어 갈 수 있다. (아이템 4 - inferred 타입으로 리턴하지 말라)

2022.03.25 게시됨

스터디/이펙티브코틀린

아이템 13 - Unit? 을 리턴하지 말라

The type with only one value: the Unit object. This type corresponds to the void type in Java. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-unit/ Unit은 공식문서에서 볼 수 있듯 한가지 값을 가질 수 있는 타입을 나타내는 객체이다. Java에서 void 와 비슷한 타입으로 볼 수 있다. (자바의 void 는 값을 가지지 않지만..) Unit? 는 Unit 이나 null 값을 가질 수 있다. 그래서 이를 이상하게 사용하면 마치 Boolean 처럼 사용할 수 있다. 그렇게 사용하지마라 ~처럼 사용한다는 것 자체가 의도를 벗어난 행위를 하는것이다. 예측하기 어려운 오류를 만들 수..

2022.03.25 게시됨

스터디/이펙티브코틀린

아이템 12 - 연산자 오버로드를 할 때는 의미에 맞게 사용하라

연산자 오버로딩은 그 이름의 의미에 맞게 사용하자. 큰 힘에는 큰 책임이 따른다. 코틀린에서 ! 연산자는 boolean의 반대를 나타내는 not 연산을 의미한다. 이런 연산자를 팩토리얼을 표현하기 위해 아래와 같이 표현한다면 다음과 같다. 10 * !6 그리고 위 코드를 not으로 읽어보면 아래와 같이 된다. 10 *6.not() 오버로딩을 이런식으로 활용하면 혼란스럽고 오해의 소지가 있다. 코틀린의 모든 연산자는 별칭이다. 즉, 본래의 이름이 있기 때문에 그 의미를 벗어나도록 오버로딩하면 안된다. 분명하지 않은 경우 그런데 오버로딩을 한 연산자가 이름의 뜻을 제대로 의미하는지(관례를 충족하는지) 확신이 들지 않을 때가 있다. 아래의 경우 * 는 함수를 여러번 실행시키는 의미로 사용되었다. 3 * pri..

2022.03.25 게시됨

스터디/이펙티브코틀린

아이템 11 - 가독성을 목표로 설계하라

프로그래밍은 쓰기보다 읽기가 중요하다 고로 항상 가독성을 생각하면서 코드를 작성해야 한다. 그렇지 않으면 오류를 찾기위해 코드를 작성할 때보다 오랜 시간 코드를 읽는 자신을 발견할 수 있다. 개발자가 코드를 작성하는 데는 1분 걸리지만, 이를 읽는 데는 10분이 걸린다. by 로버트 마틴 인식 부하 감소 가독성이란 코드를 읽고 얼마나 빠르게 이해할 수 있는지를 의미한다. 경험과 인식에 대한 과학으로 만들어진 어느 정도의 규칙이 있다. fun readGood(person: Person?, view: View) { if (person != null && person.isAdult) { view.showPersion(person) } else { view.showError() } } fun readBad(pe..

2022.03.25 게시됨