본문 바로가기

Programing

(391)
[Java] 배열 in 자바 자바에서는 배열이 객체이다. 이것은 자바 언어 명세에 적혀있다. JLS 4.3.1 An object is a class instance or an array. 오브젝트는 클래스의 인스턴스이거나 배열이다. C/C++ 의 배열 즉 C/C++의 배열과 달리 자바의 배열은 객체라는 큰 차이가 생긴다. C언어에서는 sizeof 라는 명령으로 자료구조의 크기를 구할 수 있다. #include int main(int argc, const char * argv[]) { int num = 1; int arr[2] = { 1, 2 }; printf("%lu\n", sizeof(num)); printf("%lu\n", sizeof(arr)); return 0; } C언어의 데이터 타입의 크기는 플랫폼(시스템)에 따라 다를 ..
[test] 404 테스트 404 테스트라는 이름은 그냥 내가 지은 이름이다. 지금 다니는 회사는 PO라고 부르는 기획자도 어느정도 개발 지식을 요구하는 경우가 있다. 데이터 분석을 직접하는 경우가 있어서 SQL 같은 쿼리 언어에 대해 알고 있어야 스스로 일이 가능하다. 또한 swagger 를 통한 API 사용도 하는 경우가 있어서 HTTP에 대한 배경 지식이 필요하다. 그래서 내가 생각해 낸 테스트이다. 물론 이것이 모든 경우에 대해 커버 가능하지는 않지만 해보면 이 사람이 어느정도의 능력을 가지고 있는가 간접적으로 확인해 볼 수 있다. 필요한 것 원가 웹상에 글을 쓰거나 삭제가 가능한 플랫폼을 준비한다. 나의 경우 티스토리 블로그를 이용하는데 이용 가능한 방법은 여러 플랫폼이 있을 것이다. 또한 커뮤니케이션을 위한 도구가 필요..
[책] 프로그래머의 장점과 단점 프로그래머의 장점은 A라고 말하면 A를 해준다. 프로그래머의 단점은 A라고 말하면 A만 해준다. 최근에는 이런 이야기도 있었다. [개발자의 머리구조] 어느 아내가 프로그래머 남편에게 「쇼핑하러 갈 때, 우유 하나 사와. 아, 계란 있으면 6개 사와」 남편은 잠시 후, 우유를 6개 사왔다. 아내는 물었다. 「왜 우유를 6개나 사왔어!」 남편「계란이 있길래 6개 사왔지…」
[Spock Framework] Mock vs Stub Spock Framework Reference Documentation 을 보면 다른 종류의 Mock Objects로 Stub을 소개하고 있다. 레퍼런스에서는 mock 은 stubbing과 mocking을 둘 다 할 수 있고 ,stub은 단지 stubbing 만 할 수 있다고 나와 있다. 가장 큰 차이는 stub은 몇 번 호출되었는지를 물어볼 수 없는 차이가 있다. 하지만 이것으로는 Mock() 와 Stub()을 언제 써야할 지 명확하지 않다. 우연히 처음에는 Stub()을 사용하다가 카운팅 여부를 확인해야 해서 이후에 Mock()으로 바꾸는 작업이 있었는데 이 side-effect로 다른 테스트 케이스가 깨지는 경험을 하게 되어 차이를 이제야 이해할 수 있었다. 예를 들어 아래와 같이 CancelSer..
[스프링] 생성자가 private 일때 스프링은 객체는 어떻게 만들까? 어제 지니님의 요청한 코드리뷰를 하다 아래와 같은 코드를 발견했다. (이름은 적절히 각색하였습니다.) import lombok.AccessLevel; import lombok.Getter; import lombok.NoArgsConstructor; import lombok.Setter; @Getter @Setter @NoArgsConstructor(access = AccessLevel.PRIVATE) class ReceiptProperties { private String receiptUrl; } 내가 하려는 이야기는 lombok을 썼다는 것이 아니고 왜 private 생성자로 결정 했을까가 포인트이다. 위의 코드를 일반 자바코드로 풀어쓰면 아래와 같다. class ReceiptProperties { p..
[Spring] FieldError의 계층구조 스프링 Controller에서 파라미터 에러가 나면 BindingResult 로 바인딩 결과를 받아 올 수 있다. @RestController @RequestMapping(value = "/some") public class SomeController { @PostMapping(value = "/thing") public ResponseDto ready(@RequestBody @Valid Params params, BindingResult bindingResult) { if (bindingResult.hasErrors()) { // ... } 만약에 결과를 받지 않을 경우 @Valid에서 실패한 것은 MethodArgumentNotValidException 예외가 던져진다. 이 예외 안에는 위의 Cont..
[JPA] H2 테스트 코드에서 createdAt 필드가 없던 이유 코드리뷰에서 save 를 반복하며 직접 iteration을 도는 것보다 saveAll 을 호출하는 것이 성능상 더 좋을 것 같다는 comment가 달렸다. 정말로 그럴지 테스트 해보기 위해 테스트코드를 짰다. 사실 테스트라기 보다는 리스트로 데이터를 saveAll을 수행시 어떻게 동작하는지 디버깅을 해보려는 것이었다. @DataJpaTest @ActiveProfiles("test") class RequestRepositoryFunctionalSpec extends Specification { @Autowired RequestRepository sut def "saveAll 로 처리하면 성능상 이점이 있을것이다 by yh"() { given: List entities = [ getDummyEntityWit..
[Java] Effective Java의 Dogma 어제 코드리뷰를 받다가 아래와 같은 댓글을 보았다. from보다는 of가 더 적절할 것 같네요. from: 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드 of: 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드 이펙티브 자바의 첫 아이템 '생성자 대신 정적 팩토리 메서드를 고려해보자'가 적용된 부분에 대한 리뷰이다. 리뷰하신 분은 책의 내용을 comment에 같이 적어두었다. 이펙티브 자바에 나오는 것 같아서 찾아보니 아래와 같이 맞았다. 한글판은 12~13쪽이다. 평소에 Junior 개발자들이 이펙티브 자바를 스터디를 할 때 참관하면서 교조주의(敎條主義)에 빠지는 것을 자주 경계했었다. 교조주의란 무언가에 대한 굳은 믿음과 그러한 가치관을 뜻하는 의미로 도그마(..