본문 바로가기

TIL

 (56)
2022/01/28 TIL The RED : TDD 테스트 주도 설계? 테스트 주도 설계라는 말을 사용하려면 TDD를 하게 되면 좋은 설계가 되어야 하는데 그렇지 않다. 단위 테스트는 책임 분산을 유도하지 않는다. 낮은 응집에 대한 피드백을 주지 않는다. 의도 노출을 요구하지 않는다. 설계 관점에서는 TDD에서 힌트는 얻을 수 있지만 해결책은 아니라는 생각이 들었다. 양질의 경험과 함께 DDD, MSA를 학습하면 좋은 설계를 만들 수 있지 않을까 라는 생각을 했다. 테스트 주도 개발의 한계 은탄환은 없다. 브레드 브룩스의 논문에 다오는 내용으로 소프트웨어 프로젝트에 은총알이란 없다는 뜻이다. TDD 역시 좋은 개발 방법론이지만 모든 것을 해결해 주지는 않는다. 테스트가 힘든 경우 예측하기 어려운 코드(랜덤값, 동시성 문제 등등) ..
2022/01/27 TIL The RED : TDD private 메소드는 테스트해야 하는가? 결론적으로 이규원 님의 의견은 No이다. private 메소드 자체가 외부에 공개되지 않아야 하는 코드인데 테스트하게 되면 내부 구현이 노출된다. 내용 결합이 발생해 운영코드와 테스트 코드가 강하게 결합되어 한쪽이 변경되면 다른 한쪽에 많은 영향을 끼치게 된다. private 메소드 테스트는 처음 TDD를 학습할 때부터 궁금한 영역이었는데 강의를 보기 전부터 테스트를 안 하는 것이 좋다고 생각했었다. private을 테스트하기 위해 protected public으로 바꾸거나 reflection을 활용하는 방법이 있을 것 같았는데 결과적으로 private 함수는 테스트하는 대상의 관심사가 아니라는 생각이 들었었다. 이번 챕터에서는 캡슐화와..
2022/01/26 TIL 클린 코드 15장 : JUnit 들여다보기 접두어 f는 중복되는 정보다. 그러므로 접두어 f를 모두 제거하자. 해당 클래스에서 종종 동일한 단어가 변수에 들어가는 경우가 생기는데 이런 부분은 클래스 이름 좀 더 명확히 하고 중복되는 단어를 줄이는 것이 좋다. 부정문은 긍정문보다 이해하기 약간 더 어렵다. 공감 가는 부분이었다. 가능하다면 비교 구문에서는 긍정문을 사용하는 게 좋다. 클린 코드 16장 : SerialDate 리팩터링 비판이 있어야만 발전도 가능하다. 의사들도 한다. 조종사들도 한다. 법률가들도 한다. 우리 프로그래머들도 방법을 배워야 한다. SerialDate라는 라이브러리의 코드를 수정하기 전에 나온 내용이다. 실력 있는 개발자들은 코드를 공개하고 이에 대한 비판을 두려워하기보단 성장의 ..
2022/01/25 TIL 클린 코드 14장 : 점진적인 개선 프로그래밍은 과학보다 공예에 가깝다. 지저분한 코드를 짠 뒤에 정리해야 한다는 의미이다. 퇴근 후 학습을 하고 나면 실무에서 바로 적용하고 싶은 욕구가 많이 생기게 된다. 하지만 막상 적용해보면 상황에 알맞지 않아 오히려 더 어려움을 겪은 경험이 있다. 이는 내가 생각한 코드에 상황을 맞추려고 했었기 때문이다. 처음에는 동작하는 최소한의 코드를 만들고 점진적으로 깨끗한 코드를 만들어야 한다. 인수 유형은 다양하지만 모두가 유사한 메서드를 제공한다면 클래스 하나로 분리하는 것을 고려하면 좋다. 클래스 분리의 시기를 하나 더 알게 되었다. The RED : TDD DOC(Depended On Component) : 실제 의존하고 있는 요소 SUT(System Under T..
2022/01/24 TIL 클린 코드 13장 : 동시성 동시성이 어려운 이유? public class X { private int lastIdUsed; public int getNextId(){ return ++lastIdUsed; } } 위의 코드에서 모든 경로를 고려하려면 JIT 컴파일러가 바이트 코드를 처리하는 방식과 자바 메모리 모델이 원자로 간주하는 최소 단위를 알아야 한다. 간단하게 바이트 코드만 고려해도 경로는 약 12,870 개에 달한다. 어떤 레벨에서 경우의 수가 많은지 몰랐었는데 이번기회에 동시성의 경우의 수가 발생하는 부분을 알게 되었다. 스레드 코드 테스트하기 다중 스레드를 고려하지 않는 순차 코드부터 만들기 보조 코드를 넣어 강제로 실패를 일으키게 한다 자동화하기 TDD는 아는것에서 모르는 것으로 이동하며 ..
2022/01/23 TIL The RED : TDD Object-Oriendted의 핵심은? 캡슐화, 상속, 추상화, 다형성이 정말 핵심인지 고민해봐야 한다. 많은 프로그래밍 패러다임은 대부분 추상화를 지원한다. Alan Kay는 아래와 같은 말을 했다.OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. 이 문장은 다형성이라는 단어로 표현될 수 있지 않을까?라는 고민을 해보면 좋다. 다형성은 late-binding이 지원되어야 한다. 개인적인 의견 TDD강의지만 객체지향에 대한 얘기가 많이 나오다 보니 떠오른 생각이 있었다. 객체지향, TDD와 같은..
2022/01/22 TIL GoF의 디자인 패턴 3장 : 추상 팩토리 추상 팩토리란?추상 팩토리란? 서로 연관성이 있거나 독립적인 여러 객체의 군을 생성하는 디자인 패턴 장점 : 동일한 제품군에서는 쉽게 대체할 수 있다. 제품 사이의 일관성을 유지할 수 있다. 단점 : 제품군이 다르다면 추상 팩토리로 해결하기 힘들다. 추상 팩토리를 사용하면 AbstractFactory, ConccreteFactory, AbstractProduct, ConcreteProduct를 통해 생성하게 되면 제품별로 일관성을 유지하며 차이점을 만들 수 있는 점이 인상적이었습니다. Spring Runner 특정 환경과 기술에 종속적이지 않다는 것은 엔터프라이즈 기술(스프링이 제공하는 기술)을 사용하지 않는다는 게 아니라 POJO가 세부 기술에 직접 노출되지 ..
2022/01/21 TIL Spring Runner 모듈화란? 전체적은 구조를 표현하기 위해 관련된 클래스의 집합을 하나의 논리적인 단위로 묶는 구성 요소 (Java에서는 Package) 공식문서에서 Package를 나누는 기준에 대해 알게 되어 좋았다. 수직적 관심사 요구사항을 효과적으로 해결하는 것이 최우선 목표 수평적 관심사 재사용성이 최우선 목표이다. 두 개의 관심사가 섞이면 안 된다. 관심사의 분류에 따라 최우선 목표가 다르다는 것을 알게 되었습니다.
2022/01/20 TIL Spring RequestDto, ResponseDto RequestDto (RequestBody) GET의 경우 getter, setter, 기본 생성자가 필요하다. POST의 경우 getter, 기본 생성자만 필요하다. GET의 경우 WebDataBinder를 사용하는데, Java Bean방식을 사용해서 setter가 필요하다. POST의 경우 Jackson2HttpMessageConverter의 ObjectMapper를 사용하고 이는 setter가 필요하지 않다. ResponseDto (ResponseBody) getter만 존재하면 된다. 참고 : https://jojoldu.tistory.com/407 SpringRunner 부수효과 : 함수가 결과값 이외에 다른 상태를 변경시킬 때 부수효과가 ..
2022/01/19 TIL GoF의 디자인패턴 2장 가교패턴 서로 독립적으로 확장되지만 함께 동작해야 하는 개념들을 별도의 클래스 계층으로 분리하는 것이 목적이다. 논리적 개념(추상 클래스)과 물리적 개념(구현 클래스)으로 설명을 한다. 추상 팩토리 패턴의 적용이 힘들 떄 사용하는 것이 좋은 것 같다. 인터페이스나 추상클래스의 필요성에대해 알게되었습니다.

티스토리툴바