바닥부터 천천히

스터디/코드리뷰

테스트 코드에는 일련의 로직을 넣지 말자

들어가며테스트 코드의 미덕은 무엇일까~프로덕션 코드의 안정성을 비롯해 여러가지 장점이 있겠지만프로덕션 코드가 어떻게 동작하는지 설명하는 문서로써의 역할도 톡톡히 한다고 볼 수 있다. 다시말해 누군가가 읽어야 하는 대상이라는 말이다.누군가가 읽어야 한다면 읽는데 부담이 없어야 하니 이해를 방해하는 요소는 적으면 적을수록 좋다.그런데 테스트 코드를 작성하다보면 유혹에 넘어가 이해를 방해하는 요소를 작성하는 경우가 생기곤 한다. 물론 코드를 작성하는 당시 '나'는 해당 코드를 잘 이해할수 있을지 모르지만한달이 지나고 두달이 지난뒤 그 코드를 다시 읽는 '나'는 이전의 '나'와 거의 다른사람이다.결국 내가 작성한 코드도 쉽게 이해하지 못 할 수 있다. 여기서 이해를 방해하는 요소는 테스트 코드에 일련의 로직을 ..

스터디/코드리뷰

하드코딩한 매직넘버는 상수로써 표현하자

들어가며코드리뷰 사항 중 꽤 개선하기 쉬운 부분이다.그런데 생각보다 잘 지켜지지 않는 부분인것 같기도 하다. 프로그래밍에서 상수(static final)로 선언하지 않은 숫자를 매직 넘버, 문자열을 매직 리터럴이라 한다.이를 정적(static)이고 변경 불가능(final)한 상수로 선언하여 사용하자. 간혹 단순히 값을 옮겨적는것이 상수로 표현한다고 착각하는 경우도 있는 것 같다.해피케이스와 배드케이스로 나누어 살펴보도록 하자 문제상황예전에 대학생때 다른 블로그에 써둔 주제가 동일해서 그대로 가져왔다. AS-ISpublic class Noise { private final double decibel; public Noise(double decibel) { validate(decibe..

스터디/코드리뷰

테스트도 단일책임원칙을 지키자

들어가며테스트 코드를 작성하는게 익숙치 않은 리뷰이들을 보면 간혹 테스트에서 여러가지를 한번에 테스트하는 모습을 보곤한다.여러가지라 표현한 이유는 그 케이스가 하나의 양상을 띄는게 아니라서 그렇다. 동일한 케이스에 대한 반복을 하는 경우도 있고해피케이스와 엣지케이스를 섞기도 하며컨텍스트를 유지하며 일련의 흐름을 작성하기도 한다. SRP(Single Responsibility Principle: 단일책임원칙)에 대해 한번쯤 들어봤으리라 생각한다.어떠한 객체에게 하나의 책임만 있어야 한다고 하는데 사실은 단일 (변경)책임 원칙이다.위키피디아를 보면 다음과 같이 적혀있다.The single-responsibility principle (SRP) is a computer programming principle ..

스터디/코드리뷰

생성자 내부에서 너무 많은 일을 하지 말자

들어가며나도 예전에 생성자 내부에서 이리저리 지지고 볶다보니 문제를 겪은 적이 많다.단적인 예로 외부 통신하는 RestTemplate을 wrapping하는 클래스를 만들었었는데생성자 내부에서 RestTemplate을 만들다 보니 테스트하기가 너무 힘든 구조가 됐었다. 이때 피부로 느끼고 깨달음을 얻었던 부분이 멤버변수를 생성하기 위한 로직을 생성자 내부에서 만들지 말자는 것이다.생성자에서 뭔가 멤버변수를 생성하는 로직이 너무 많으면 이를 제어하고 테스트하기 너무 힘들어진다.멤버변수 생성에 대한 로직이 필요하다면 별도의 Factory를 두는것이 더 적절하다고 본다. 그리고 부가적인 이점이 있는게 리팩터링 내성이 올라간다.리팩터링 내성이라 함은 작성해둔 테스트 코드가 운영코드의 리팩터링이 발생했음에도 컴파일..

스터디/코드리뷰

Exception을 테스트 할 때 거짓 음성을 주의하자

거짓 음성여기서 언급한 거짓 음성이 무엇인지 먼저 짚고 넘어가자~거짓 음성이란 실제로는 실패해야 하는 테스트가 통과하는 경우를 의미한다.다시말해 기능이 고장났는데 테스트가 통과하는 케이스를 의미한다. 보통 테스트의 정확도를 이야기할 때 거짓 음성과 거짓 양성에 대해 이야기를 한다.대게 거짓 양성에 대해 더 중요하게 다루곤 하지만 코드리뷰를 하며 거짓 음성을 발생시키는 케이스를 많이 본 것 같다. 조금 더 정확히 짚고 넘어가면 기능이 실패한다기 보다 기능에 대해 테스트가 정확히 검증해주지 못하는 케이스라고 봐야할 것 같다. 예제 코드 1그래서 Exception을 테스트하는 것과 어떤 관련이 있는가 싶을텐데코드로 살펴보도록 하자~public class MyCollection { private stati..

스터디/코드리뷰

코드 리뷰 요청에 정성을 담아보자

습관의 중요성나도 잘 못하기는 하는데 그래도 아무것도 안적는 사람들이 생각보다 많아서 적는다.말 그대로 코드리뷰 요청을 보내는데 코드리뷰 본문에 아무것도 적지 않는 사람들이 종종 있다. 이렇게 본문이 텅~ 비어버린 코드리뷰를 보면 어떤 생각이 들까?진짜 어렵다.뭘 해줘야 하는지 길을 찾기가 너무 어렵다.이렇게 되면 코드 컨벤션에 대해서만 주구장창 잡기도 한다. 내가 지금 재직중인 회사에는 아래와 같은 말이 있다.코드리뷰도 정~~~~말 똑같다고 느낀다.코드리뷰를 요청한, 만든사람이 본문에 내용을 잘 담아주면 코드 리뷰어가 방향성을 잡고 리뷰를 해주기 참~ 좋다. 나중에 취업하고 본격적으로 일할 때도 굉장히 중요한 요소이다.내가 PR을 생성해서 코드리뷰를 요청했는데 본문이 텅 비어있으면팀원들은 뭘 리뷰해줘..

스터디/코드리뷰

코드리뷰 카테고리 신설의 이유

5년차 개발자로 살아오면서 제법(?) 많이 코드리뷰를 해본 것 같다. 대학생때 친구들과 스터디하면서 해보기도 했고취준생일때 같이 교육받는 동기들과도 해보고취업 이후에는 팀 내에서 팀원간 코드리뷰도 해보고이외 활동으로 카카오 테크 캠퍼스 리뷰어, 우아한 테크코스 리뷰어, 넥스트 스탭 코드 리뷰어로도 여러번 활동했다. 물론 시니어 개발자분들에 비하면 그 실력이 부끄러운 수준이지만 깔깔.. 아니 그래서 코드리뷰 카테고리를 신설한 이유가 무엇인가! 포부를 밝히기 전에 히스토리를 설명해보면 이번 우아한 테크코스 7기 리뷰어 신청을 했다가 떨어졌다.. 조금 웃긴게 와이프와 함께 신청했는데 나만 떨어졌다 ㅋㅋ내가 같이 하자고 꼬드겼는데 내가 떨어지는 어처구니 없는 상황이 벌어질줄이야! 지금도 내 앞에 앉아서 열심히 ..

스터디/Kotlin

RSA 키를 만들고 보관하고 사용하기

개요RSA를 사용해서 클라이언트에게서 전달받은 값의 무결성을 검증하곤 한다.엄청 예전에 만들었던 기능인데 그냥 머릿속에만 두면 언젠가 내가 어떻게 했었는지 잊지 않을까? 싶어서 끄적여본다~ RSA는 공개키 암호화 방식이기에 공개키는 클라이언트에게 전달되어야 한다.전달은.. 알아서 잘 했다고 하고 (타팀분에게 DM으로 전달했던것 같음~)비밀키는 아무도 볼 수 없도록 잘 가렸다고 가정하자~ 구현그럼 이제 공개키와 비밀키를 생성해야하지 않을까?키페어를 생성하는데 이때 사용한 구현체는 KeyPairGenerator이다.java.security.KeyPairGeneratorval keyPairGenerator = KeyPairGenerator.getInstance("RSA")keyPairGenerator.init..

스터디/Kotlin

코틀린 초간단 sha-256 만들기

fun String.sha256(): String { return MessageDigest.getInstance("SHA-256") .digest(this.toByteArray()) .joinToString { "%02x".format(it) } } 끗!

스터디/이펙티브코틀린

아이템 30 - 요소의 가시성을 최소화화라

WHY? 작은 인터페이스는 배우기 쉽고 유지하기 쉽다. 기능이 많은 클래스보다 기능이 적은 클래스를 이해하는 것이 쉽고 유지보수하기 쉽다. 보이는 요소 자체가 적으면 유지보수하고 테스트할 것이 적다. 변경을 가할 때는 기존의 것을 숨기는 것보다 새로운 것을 노출하는 것이 쉽다. 기존 요소는 이미 사용하고 있는 부분에 많은 영향을 미치고 있을 수 있기 때문이다. 가시성과 관련된 제한을 변경하는 것은 더 어렵다. 따라서 변경할 경우 대체제를 제공해야한다. 클래스의 상태를 나타내는 프로퍼티를 외부에서 변경할 수 있다면 클래스는 특정 조건을 만족해야하는 자신의 상태를 보장할 수 없다. 클래스의 값(var)의 setter의 가시성만 private하게 제한 하도록 하는 것이 좋다. 가시성이 제한 될수록 클래스의 변..