3장. 함수 에 대한 의견 교환




이 글은 로버트C. 마틴이 지은 클린코드를 읽고 각 챕터에 대한 의견 교환 및 토론을 한 내용 입니다.

댓글로 의견 교환 및 토론은 환영합니다.




오늘은 함께 스터디하는 4명 중 2명이 일과 건강 문제로 스터디에 빠져서 나를 포함해 2명이서 스터디를 진행하였다.




: 

  • 더러운 함수는 이해가 안간다.
  • 함수를 작게 만들라는게 마음에 든다.
  • 함수를 한가지 일만 해야한다고 하는게 뇌리에 박힌다.
  • Switch 문을 사용할때 클린코드 규칙이 깨진다고 하는게 가장 중요한 이야기인것 같고 Switch 뿐만 아니라 if 문을 여러번 사용할때도 같다고 생각된다.
  • 나머지는 와닿지 않는다.
    • ) 함수인수 갯수, boolean 타입을 넘기는것 ..
  • 아직 경험이 별로 없어서 와닿지 않고 enum 크게 와닿진 않는다.




나: 

  • enum 오류 코드를 사용하는 것이 의존성 자석이고 그렇게 쓰지말라고 한 것 같은 경우는 기존의 exception 클래스를 상속받아서 새롭게 해당 예외만 생성하고 사용하면 된다는 말 같다.
  • Enum 사용할때 타입 같은 것을 정의하고 값을 DB에 저장하면 좋다고 생각한다.
    • string 이라는게 에러가 생길수 있는 구석이 많음, 예를 넘겨주거나 받을때 String 이면 kakaopay 인데 kakpay 같이 될수 있는데 이를 방지할수 있다.
  • 함수 챕터에서 로버트C. 마틴이 함수인수의 갯수에 대해 이야기한 것이 중요하다고 생각되는 이유는 함수 인수가 많으면 설계와 정의를 못한거라고 생각한다.
  • 알고리즘 문제를 풀더라도 객체지향적으로 설계하고 정의하면 함수 인수가 많아질 일은 없다고 생각한다.
    • 예를 들어 이진수 변환 문제가 나오면 나는 하나의 이진수 클래스로 만들어 이진수를 저장하는 것을 멤버변수로 만들고 변환하는 과정을 매서드로 만들 것이다.
  • 챕터에서 가장 중요한 말은우리가 함수를 만드는 이유는 개념을 다음 추상화 수준에서 여러단계로 나눠 수행하기 위해서가 아니던가인듯하다.
    • 말에 객체지향의 목표가 있다고 생각든다.
    • 예를 들어 함수에서 다음 함수로 넘어가거나 쪼갤때 단순히 줄을 나눠서 쪼개거나 그냥 인수를 그대로 넘기면 절차지향과 다름없다.
    • 함수를 쪼갤 , 혹은 구현 혹은 리팩토링할 함수를 추상화하고 함수에서 호출하는 다음 함수의 레벨(깊이, 레이어) 나눠줘야 한다고 생각한다.
  • 이는 단순히 함수뿐만 아니라 다른곳에도 적용된다고 생각한다.
    • 예를 들면 DDD 에서 도메인 레이어에서 인프라 레이어로 넘어가는데 이때에도 적용되는 말이라고 생각한다. 
    • 그래서 인프라 레이어에서의 변경이 일어나도 도메인 레이어에는 영향이 없도록 인프라 레이어를 사용, 호출하는 도메인 레이어에서는 인프라 레이어를 추상화(인터페이스화) 하는 것이 중요하다고 생각한다.

3.17. Parallel Execution

By default, JUnit Jupiter tests are run sequentially in a single thread. Running tests in parallel, e.g. to speed up execution, is available as an opt-in feature since version 5.3. To enable parallel execution, simply set thejunit.jupiter.execution.parallel.enabled configuration parameter to true, e.g. in junit-platform.properties(see Configuration Parameters for other options).

Once enabled, the JUnit Jupiter engine will execute tests on all levels of the test tree fully in parallel according to the provided configuration while observing the declarative synchronization mechanisms. Please note that the Capturing Standard Output/Error feature needs to enabled separately.

Parallel test execution is currently an experimental feature. You’re invited to give it a try and provide feedback to the JUnit team so they can improve and eventually promote this feature. 


3.17. Parallel Execution


기본적으로 JUnit Jupiter 테스트는 단일 스레드에서 순차적으로 실행됩니다. 테스트를 병렬로 실행할 때 실행 속도를 높이기 위해 5.3 버전부터 opt-in 기능을 사용할 수 있습니다. 병렬 실행을 사용하려면 junit-platform.properties 에 있는 junit.jupiter.execution.parallel.enabled configuration 매개 변수를 true로 설정하면됩니다. (다른 옵션에 대해서는 Configuration Parameters 참조)

JUnit Jupiter 엔진이 활성화되면 선언 된 동기화 메커니즘을 관찰하면서 제공된 구성에 따라 테스트 트리의 모든 수준에서 완전히 병렬로 테스트를 실행합니다. 표준 출력 / 오류 캡처 기능은 별도로 활성화해야합니다.






'스터디 > JUnit' 카테고리의 다른 글

[JUnit 5] 3.15. Test Templates  (0) 2018.12.19

3.15. Test Templates

@TestTemplate method is not a regular test case but rather a template for test cases. As such, it is designed to be invoked multiple times depending on the number of invocation contexts returned by the registered providers. Thus, it must be used in conjunction with a registered TestTemplateInvocationContextProvider extension. Each invocation of a test template method behaves like the execution of a regular @Test method with full support for the same lifecycle callbacks and extensions. Please refer to Providing Invocation Contexts for Test Templates for usage examples.



3.15. 테스트 템플릿츠

@TestTemplate 매서드는 정기적인, 규칙적인 테스트 케이스가 아니고 정확히 말하자면 테스트 케이스들을 위한 템플릿 입니다. 그 때문에, 그것은 등록 프로 바이더가 돌려주는 호출 문맥의 수에 응해, 여러번 호출하도록 설계되고 있습니다. 따라서 그것은 반드시 등록TestTemplateInvocationContextProvider 의 확장과 함께 사용해야 합니다. 테스트 템플릿 메소드를 호출 할 때마다 동일한 라이프 사이클 콜백 및 확장을 완벽하게 지원하는 일반 @Test 메소드를 실행하는 것처럼 동작합니다. 사용 예제는 Providing Invocation Contexts for Test Templates 을 참조하십시오.


























'스터디 > JUnit' 카테고리의 다른 글

[JUnit5] 3.17. Parallel Execution  (0) 2018.12.26

+ Recent posts