[3주차] lean_Code_5-7장_최가희

[GaHee99]

5장 - 형식맞추기

1. '팀으로 일한다면 팀의 합의해 규칙을 정하고, 모두가 그 규칙을 따라야한다. 필요하다면 규칙을 자동으로 적용하는 도구를 활용한다',
   혹시 도구 활용해보신 분 계신가요?? 규칙 체크 도구 뿐만 아니라 , 팀 코드적으로 좋았던 툴이나 도구들 궁금해요!~

6장 - 객체와 자료구조

1. '인터페이스나 조회/설정(getter, setter)함수 만으로는 추상화가 이뤄지지 않는다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야한다. ' 혹시 좋았던 예시나 생각 있으셨을까요?

2. 아래 코드가 '디미터 법칙을 거론할 필요가 없다'라고 명시돼있는데, 혹시 이유를 알 수 있을까요?
   제가 이해한 바로는 아래 코드가 '자료구조' 이기 때문인 것 같은데 어떻게 생각하세요?
   final String outputDir = ctxt.options.scratchDir.absolutePath;

7장 오류 처리

3. 외부 API사용시, 외부 API Failure에 대한 에러코드들을 열거, 나열하는 것 보다, 외부 API감싸는 것을 더욱 추천하더라구요,
   저는 이 부분 읽고 큰 도움이 됐는데, 혹시 다른분들은 외부API 에러처리들을 평소에 어떻게 처리하셨었는지 궁금해요!

[find11570]

5-1. ESLint, Prettier 등을 사용했던 것 같아요! 함수 정의 시 함수를 쓰냐 화살표 함수를 쓰냐, for문을 쓰냐 아님 forEach/map을 쓰냐 등 코드 작성법이 다 다른데 이런 방식을 일관성 있는 방식으로 구현할 수 있도록 ESLint가 잡아주고요
Prettier 를 쓰면 줄 바꿈, 공백, 들여 쓰기 등 텍스트를 일관되게 작성할 수 있습니다 두개를 같이 써서 잡아줬던 것 같아요
6-1. 전 없었던 것 같아요. 그냥 숨기지 않고 공개했던 것 같은데... 같이 생각 공유하고 싶어요!
6-2. 가희님이 말씀하신대로 자료구조에 저장된 값을 직접 가져오는 형태이기 때문에 디미터 법칙을 위반하지 않은 것 같아요. 디미터 법칙은 객체 간의 메서드 호출을 제한하는 것이기 때문에 필드 접근에 대한 해당 코드로 변경하면 디미터 법칙을 거론할 필요가 없는거죠!

[lee-JunR]

Q. 6장

맞습니다.

final String outputDir = ctxt.options.scratchDir.absolutePath;

ctxt, options, scratchDir, absolutePath 가 모두 자료구조라면 구조를 노출해도 되니깐 괜찮다...라고 이해했습니다.
하지만 해당 코드가 객체로 설정되어있다면 마땅히 객체 내부의 구조를 숨겨야하므로 해당 중첩 구조는 좋지 않음...이라 정리했어요!

[chuseok]

5장. 1

intellij에서 tdd live template 사용해본 적이 있습니다!
그리고 도구는 아니지만 팀 규칙에 맞게 형식이 정의된 코드를 생성하는 코드를 만들어서 활용한 경험이 있습니다!(좋은 방법인지는 잘 모르겠지만 위에서 말씀드린 tdd live template 과 같은 느낌이네요)