[Week] 2주차 진도

[jin5335]

• 발표자를 제외한 인원은 느낀점, 질문사항을 코멘트로 남겨주세요.
• 발표자는 발표자료를 준비하시고 공유해주세요.

이번 주 발표자

• @jin5335

진도

• chapter 3 : 함수
• chapter 4 : 주석

발표자료

• 발표자료 링크는 여기에!

[ChoMk]

chapter 3 : 함수

좋은 함수란?

• 작게
• 하나의 함수에 하나의 일을 시키자..
• 서술적인 이름을 사용하자
• 함수의 인수는 적게 사용하자
• 플래그 인수는 사용 ㄴㄴ
• 많은 인수를 사용하려면 걍 묶어서 사용하자..
• 이름에서 유추가능하지 않은 행동은 시키지 말자
• 에러 타입을 반환 받기 보다는 예외처리로..
• 중복 ㄴㄴ

  기억에 남는 말

• 시스템을 구현할 프로그램이 아니라 풀어갈 이야기로 여기자.

  나의 생각

• 좋은 함수는 내용을 보지 않고 함수 선언부만 보고도 파악할 수 있는 함수가 아닐까?...
• 인수가 많아지면 선언부만 보고 함수를 해석하기 어려운 듯...

  질문

• pool.release(instance) 은 어떤가요?(전 별로 좋아 보이지 않아서... 질문을...)
  • A: acquire, release 반대라면 이해가능하지않을까요... 단독적으로 보긴 어렵...

chapter 4 : 주석

주석?!

• 저작권, TODO 말고는 필요할까?...
• 주석으로의 로직에 대한 설명은 코드가 진행됨에 있어서 관리가 힘들고 관리를 못하면 거짓말이 된다..
• 테스트용이나 불필요한 코드에 대한 주석처리는 그냥 지우자... 어차피 깃이라는 친구가 다 관리해주니..
• 예제(소수 예제)에서 나오는 공식들에 대하여 주석으로의 설명 보다는 함수명에 구글링할 시에 잘 찾을 수 있는 이름(공식 이름)으로 정하면 주석이 필요하지 않지 않을까?

나의 생각

• 주석이 할 수 있는 대부분이 IDE, GIT을 통하여 해결 가능하다고 생각한다.. 주석은 가독성만 나쁘게 만드는거 같은 생각이.. (로직에 대한 부연 설명은 PR에서 셀프 리뷰를 통하여 해결할 수 있다 생각함, 깃으로 트랙킹해서 과거 로직이나 부연 설명을 찾을 수 있다 생각함..)

경험

• 코드리뷰 중에...(생략)

[DaehunGwak]

요약

03. 함수

• 함수는 한 가지를 해야한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
• 소프트웨어는 글쓰기와 같음 -> 테스트를 통과하는 리팩토링의 반복
• 실천 전략
  • 작게
  • 한 가지만
  • 서술적으로
  • 인수는 적게
  • 부수효과는 X
  • 명령과 조회는 분리하면서
  • 오류 코드보단 예외를 사용하고
  • 반복하지 않으면서
• 대가 프로그래머는 시스템을 구현할 프로그램이 아니라 풀어갈 이야기로 여긴다

04. 주석

• 애초에 주석이 없는 방향으로
• 주석은 나쁜 코드를 보완하지 못한다
• 코드로 의도를 표현하라
• 함수나 변수, 클래스로 표현할 수 있다면 주석을 달지 마라

좋은 주석

• 법적인 주석
• 정보를 제공하는 주석
  • 흠 그런데 예시에선 이것도 함수나 클래스로 추상화해서 없애는 걸 권장
• 의도를 설명하는 주석
  • 예시가 이해안감... 어쨋든 저자의 의도를 명시하는건 좋음
• 의미를 명료하게 밝히는 주석
• 결과를 경고하는 주석
• TODO 주석
  • 지금 당장 할수 없는 앞으로 할일을 TODO 주석으로 남기면 좋음
• 중요성을 강조하는 주석
• 공개 API에서 Javadocs

내가 모르는것.. 나중에 봐야할 것..

• Abstract Factory Pattern
• SOLID
  • SRP (Single Responseibility Principle)
  • OCP (Open Closed Principle)
• AOP (Aspect Oriented Programming)
• COP (Component Oriented Programming)

Q

• Q: 추상팩토리로 개선한 함수에서 EmployeFactory 구현체를 Employee 상속 클래스마다 구현시키면 오버 엔지니어링일까?
  • ex. CommisionedEmployeeFactory -> CommissionedEmployee
  • A: 회사의 예로 생각해보면 어떨까? (삼성 회사의 직원 유형, 엘지 회사의 직원 유형이 다를 수 있기때문에 저렇게 구성된것일 것이다)

    
    public abstract class Employee {
    public abstract boolean isPayday();
    public abstract Money calculatePay();
    public abstract void deliverPay(Money pay);
    }

public interface EmployeeFactory { public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType; }

public class EmployeeFactoryImpl implements EmployeeFactory { public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType { switch (r.type) { // 이때 각 new 클래스 들은 위의 Employee abstract class를 상속받은 구현 클래스 case COMMISSIONED: return new CommissionedEmployee(r); case HOURLY: return new HourlyEmployee(r); case SALARIED: return new SalariedEmployee(r); default: throw new InvalidEmployeeType(r.type); } } }

[KimYealynn]

Chapter03. 함수

한 함수내 추상화 수준을 맞춰라, 그리고 그 다음 함수에서는 추상화 수준을 한단계 낮춰라(내려가기)

확실히 이 규칙을 지킬 수 있다면 코드읽기가 엄청 쉬워질 듯 하다, 근데 내 코드에 적용은 못하겠음.........

• 추상화 수준이란?

추상화란 구체적인 것을 감추고 보고 싶어하는 전체적인 특성을 드러내는 것이다. 함수는 그 함수의 이름보다 하나더 낮은 수준에서 내부의 코드를 채워주고 있다는 것을 알 수 있다. 다시 그 내부의 코드를 더 깊이 들어가면, 그것 역시도 다른 개념을 추상화시키고 있는 것이며, 계속해서 가장 구체적인 내용이 나올 때까지는 한 수준씩만 더 구체적으로 변화됨을 유추할 수 있을 것이다.

[추상화 수준이 높음] [추상화 수준이 낮음]
getHtml() > String pagePathName = PathParser.render(pagePath) > .append("\n")

동사와 키워드

• write(name) → writeFiled(name) : name이 filed라고 명시
• assertEquals(expected, actual) → assertExpectedEqualsActual(expected, actual) : 함수명에 키워드를 추가하여 인수 순서를 기억할 필요가 없다.

Chapter04. 주석

주석은 실패를 만회하기 위해 적는 것...주석을 달아야겠다! NO → 코드를 고치자

과격한 표현 같은데 확실히 코드를 잘 바꾸면 주석이 필요 없어지는 경우가 많은 듯 주석을 달기전에 더 생각해봐야겠다.

과도한 주석은 읽는이로 하여금 모든 주석을 무시하도록 유도한다.

나는 모든 주석 잘 안 읽는 편이라 문제,,,,,지만 이 말이 백퍼 이해가 간다. 그치만 일하다 보면 어쩔 수 없이(내 코드 표현력의 한계 때문 만이 아니라도..) 필요한 경우가 생기는 것 같은데 최대한 간결하게 쓰도록 해야겠다.

Q

1. 부수효과를 일으키지마라! 에서 checkPasswordAndInitializeSession 은 함수가 한가지만 한다는 규칙을 위반한다는데, 이럴일이 은근 많은 것 같아서... 여러개 해도 된다는 건가.... ?
   • A: wrap을 해야하는 단어를 생각해야하는건데, 저 워딩보단 다른 좋은 하나의 짧은단어가 있지않을까.. 제가 어휘력이 부족해서.....

[minSW]

[Chapter 3] 함수

📖 기억에 남는 부분

요약 정리

한 가지만 수행하고 이를 잘 나타낼 수 있는 서술적인 이름의 중복되지 않는 최대한 작은 함수를 만들어라 단, 처음부터 탁 짜지는 건 불가능하다. 글 짓기를 하듯 다듬고 고치고 정리하라 (+단위 테스트 케이스)

• Switch 문은 본질적으로 N가지를 처리
  • 다형성(polymorphism) 을 이용하여 저차원 클래스에 숨기고 반복하지 않도록.
• 함수인수 : 무항 >단항 > 이항 >>>> 삼항 >>>>>>>>(안돼 사용할 수 없어 돌아가)>>>>>>>> 다항
• 부수 효과를 일으키지 마라
  • 일반적으로 출력인수는 피하고, 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경할 것
  • 순수함수(pure function)?

느낀점

• "플래그 인수는 추하다" & "try/catch 블록은 원래 추하다"
  • 추한 코드의 집합체... 오늘도 반성합니다... 🥺

따로 찾아본 부분

• SRP (Single Responsibility Principle, 단일책임 원칙)
  • 클래스가 변경될 이유는 단 한가지여야
• OCP (Open Closed Principle, 개방-폐쇄 법칙)
  • 기존 코드를 변경하지 않으면서 기능을 추가 할수있도록 설계해야 (=>확장성?)
• 출력 인수
  • 함수가 작업한 결과를 돌려받기 위해서 사용된다 (<-> 입력 인수 : 함수에게 작업거리를 주기 위해 전달)

[Chapter 4] 주석

📖 기억에 남는 부분 & 느낀점

주절거리는 주석 / 같은 이야기를 중복하는 주석 (있으나 마나 한 주석)

• 이해가 안되어 다른 코드를 뒤져봐야하는 코드는 무의미
  • => 그런 주석은 바이트만 낭비할 뿐이다
• 나 혼자만의 이해를 위한 주석을 남기지말자

주석으로 처리한 코드

• 주석으로 처리해놓은 코드는 그냥 삭제해라
  • "잃어버릴 염려가 없다" => 소스코드관리 시스템의 히스토리를 절대적으로 신뢰할 수 있는가?
• => 🤔 TODO 형태 주석과 동반된다면?

전역 정보

• 코드를 달아야한다면 근처에 있는 코드만 기술하라
  • 시스템 어디엔가 있는 다른 값을 함께 기술한다면, 해당 값이 변한다고 주석 내용이 변하리라는 보장 X

🤔 질문

• "함수 당 추상화 수준이 하나" 라는 의미 => @KimYealynn 코멘트 참고하면 될 듯!
• if 문을 의미있는 이름의 함수로 뽑아내는 것에 대한 의견
  • 물론 ide로 찾아갈 수 있지만.. 실제 코드들에서는 이렇게 사용하는 경우가 많지 않았던 것 같음
• 같은 이야기를 중복하는 주석
  • 한국어 <-> 영어의 갭으로는 용인될 수?

[jin5335]

끝!!!!