10장. 클래스

책에서 기억하고 싶은 내용

• 클래스 체계
  • 캡슐화 추상화 단계는 순차적으로 내려감. 변수 목록 다음에는 공개 함수가 나옴. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣음. 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 좋음. 같은 패키지 안에서 테스트 코드가 함수를 호출하거나 변수를 사용해야할때 protected로 선언하거나 패키지를 전체로 공개함. 캡슐화를 풀어주는 경정은 언제나 최후의 수단인걸 생각하기.
• 클래스는 작아야 한다!
  • 클래스 이름 클래스 이름이 모호하다면 클래스 책임이 크다는 것이다. (예를 들면 processor, manager, super 등) 클래스 설명은 만일("if"), 그리고("and"), -(하)며("or"), 하지만("but")을 사용하지 않고서 25단어 내외로 가능해야함.
  • 단일 책임 원칙 클래스나 모듈을 변경할 이유가 하나, 단하나뿐이어야 한다. SRP는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. 책임, 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워지고 더 좋은 추상화가 더 쉽게 떠오른다.
    • 응집도 클래스는 인스턴스 변수 수가 작아야함. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야함. 메서드가 변수를 더 많이 사용할 수록 메서드와 크래스는 응집도가 높아짐. => 응집도가 높아짐 : 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶임
• 변경하기 쉬운 클래스
  • 변경으로부터 격리 구체적인 클래스는 상세한 구현(코드)을 포함하며 추상 클래스는 개념만 포함함. 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠지지만 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리함. 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아짐. 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 변경으로부터 잘 격리되어 있다는 의미. 결합도를 낮추려면 DIP를 따르는 클래스가 나옴. => 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙.

오늘 읽은 소감

SRP를 소개하는 부분에서 우리는 대다수 '깨끗하고 체계적인 소프트웨어'보다 '돌아가는 소프트웨어'에 초점을 맞춘다는 부분에서 공감되었다. 하지만 저자는 돌아가는 것에서 멈추는 것이 아니라 '깨끗하고 체계적인 소프트웨어'를 생각해야한다고 말한다. 그런 소프트웨어를 만들기 위해서는 큰 클래스로 처리하는 것이 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다고 한다. 이를 설명할때 예를 드는 것이 서랍이었는데 아주 인상깊었다. 내 성격상 세세하게 나누어 정리하지 않고 한 공간에 여러 가지를 넣어버리는데 이런 성격이 코드상에도 반영되는 것 같았기 때문이다.

궁금한 내용 또는 잘 이해되지 않는 내용

SRP(Single Responsibility Principle) OCP(Open-Closed Principle) DIP(Dependency Inversion Principle)

8장. 경계

책에서 기억하고 싶은 내용

• 외부 코드 사용하기

  • 패키지 제공자는 적용성을 넓혀 제공하며 사용자 시스템 환경에 꼭 맞는 패키지가 아니기 때문에 시스템 경계에서 문제가 생길 수 있다.
    • 경계 인터페이스를 사용할 대는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.

• 경계 살피고 익히기

  • 외부 코드를 사용할때 테스트를 먼저 하자
    • 바로 코드에 외부 코드를 호출하지 말고 간단한 테스트 케이스를 작성해 외부 코드를 익히자 => 학습 테스트라고 부른다.

• log4j 익히기 로깅 기능을 대신 아파치의 log4j 패키지를 사용할때 테스트 코드를 작성해 익히자.

• 학습 테스트는 공짜 이상이다

  • 학습 테스트는 이해도를 높여주는 정확한 실험이다.
    • 학습 테스트를 통해 새버전이 나올때마다 자신의 코드와 호환되는지 테스트 하자.

• 깨끗한 경계

  • 통제하지 못하는 코드를 사용할 때는 너무 많은 투자를 하거나 향후 변경 비용이 지나치게 커지지 않도록 주의하자
    • 경계에 위치하는 코드는 깔끔히 분리하고 테스트 케이스도 작성한다.
    • 외부 코드에 휘둘리지 않도록 통제가 가능한 우리 코드에 의존하자!
    • 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자
    • 새로운 클래스로 경계를 감싸거나 아니면 ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자

      오늘 읽은 소감

      이번 챕터를 왜 노개북 스케쥴에서 빠졌는지 알 것 같다. 노마드북클럽은 입문부터 초보자 대상으로 챌린지를 진행하는데 이번 챕터는 외부 코드, 라이브러리 활용에 관련한 내용이 주로 진행되어서 활용을 하지 못하는 초보자가 읽기엔 이해안되는 부분이 많을 수 있을 거라는 생각이 들었다. 물론 나도 읽으면서 힘들었다. 자바를 안한지 3년정도 되었고 현재 하고 있는 업무도 javascript를 사용하기 때문에 어려웠다. 그래도 외부 코드를 호출하기 전에 먼저 간단한 테스트를 작성해 외부 코드를 익히는 학습 테스트를 진행 후 도입하라는 것과 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자는 부분을 배울 수 있어 유익했다. 항상 외부 패키지를 사용할때 주의하며 사용해야겠다!

9장. 단위 테스트

책에서 기억하고 싶은 내용

• TDD 법칙 세 가지

  • 첫번째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
    • 두번째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
    • 세번째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. => 주의 사항 : 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 함

• 깨끗한 테스트 코드 유지하기

  • 테스트 코드가 지저분할 수록 변경하기 어렵고 실패하는 테스트 코드를 통과시키기 어렵다.
    • 테스트 코드는 실제 코드 못지 않게 중요하며 사고와 설계와 주의가 필요하다.
    • 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
    • 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.
    • 테스트 커버리지가 높을 수록 별다른 우려 없이 아키텍처와 설계를 개선할수 있다.

• 깨끗한 테스트 코드

  • 깨끗한 테스트 코드를 만들기 위한 것은 가독성이 필요하다.
    • 가독성을 높이기 위해서 필요한 것은 명료성, 단순성, 풍부한 표현력(최소한의 표현으로 많은 것을 나타냄)이 필요하다.
    • 코드를 간결하고 표현력이 풍부한 코드로 리팩터링 해야한다.
    • 이중 표준 : 테스트 환경은 자원이 제한적일 가능성이 낮기 때문에 실제 코드에서는 사용을 피하는 것도 테스트 코드에서는 사용할 수 있다.(코드의 깨끗함과는 철저히 무관)

• 테스트 당 assert 하나

  • JUnit으로 테스트 코드를 짤 때는 함수마다 assert 문을 단 하나만 사용하자. => assert 문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.
    • 테스트 함수마다 한 개념만 테스트하자.
  • 개념 당 assert문 수를 최소로 줄여라.

• F.I.R.S.T

  • Fast(빠르게) : 테스틑 빨라야 한다.
    • Independent(독립적으로) : 각 테스트는 서로 의존하면 안된다.
    • Repeatable(반복가능하게) : 테스트는 어떤 환경에서도 반복 가능해야 한다.
    • Self-Validating(자가검증하는) : 테스트는 부울(bool)값으로 결과를 내야한다. 실패 아니면 성공으로만 나야지 판단이 주관적이 되면 지루한 수작업 평가가 필요하게 된다.
    • Timely(적시에) : 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

• 결론
  • 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화한다.
    • 테스트 코드는 지속적으로 꺠끗하고 표현력을 높여 간결하게 정리하여 관리하자.
    • 테스트 API를 구현해 도메인 특화 언어(DSL)를 만들자.

      오늘 읽은 소감

      테스트 코드의 중요성을 알았지만 알면서도 작성하지 않고 프로젝트 기한에 맞추기에 급급해 제대로된 테스트 코드를 작성하지 않고 통합 테스트를 통해 오류를 찾고 수정해왔다. 이번 챕터를 통해 테스트 코드의 중요성을 다시금 깨닫고 실제 코드를 구현하기 전에 단위 테스트를 구현하라는 규칙을 배울 수 있게 되어 좋았다. 이직을 준비할때 면접 봤던 회사에서 간단한 API 구현 과제를 받은 적이 있는데 구현 조건 중 테스트 코드를 작성하라는 것이 있었다. 나는 코드를 구현하고 테스트 코드를 작성했는데 단위 테스트를 하려고 보니 작성하기 너무 어려웠고 결국 통합 테스트밖에 못하고 제출했던 기억이 있다. 결국 면접에서 왜 단위 테스트는 안했냐는 질문을 받았고 물론 그것때문에 떨어진 것은 아니지만 아쉬움이 많이 남았었다. 지금 생각해보니 단위 테스트를 적시에 작성하지 않아서 구현이 더 어려웠던 것 같다. 이번에 알았으니 앞으로 적시에 작성하여 단위 테스트를 작성하는 습관을 길러야겠다.

궁금한 내용 또는 잘 이해되지 않는 내용

BUILD-OPERATE-CHECK 패턴 given-when-then TEMPLATE METHOD 패턴

7장. 오류 처리

책에서 기억하고 싶은 내용

• 오류 코드보다 예외를 사용하라 오류가 발생하면 예외를 던지자 => 논리가 있는 호출자 코드가 오류처리 코드와 뒤섞이는 복잡한 상황을 만들지 않기 위함

• Try-Catch-Finally 문부터 작성하라

  • 예외가 발생할 코드를 짤 때는 try-catch-finally문으로 시작하자 => catch블록은 프로그램 상태를 일관성 있게 유지시키는 역할함
  • 단위 테스트 시 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하자 => try블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워짐

• 미확인 예외를 사용하라

  • 모든 예외를 다 확인하여 예외 처리하는 것에는 비용이 든다.
  • 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 모두 고쳐야한다. (확인된 예외를 던졌을 때 catch블록이 세단계 위에 있다면 그 사이 메서드가 해당 예외를 정의해야한다.)
  • 캡슐화가 깨질 우려도 있기 때문에 확인된 예외를 사용할때 주의하자.

• 예외에 의미를 제공하라 -예외를 던질 때 전후 상황으르 충분히 덧붙인다. => 오류 메시지에 정보를 담아(실패한 연산 이름과 실패 유형 언급) 예외와 함께 던진다.

  • 로깅 기능을 사용한다면 오류를 기록하도록 충분한 정보를 넘겨줘야한다.

• 호출자를 고려해 예외 클래스를 정의하라

  • 오류를 잡아내는 방법으로 사용할 수 있도록 오류를 분류하자.
    • 외부 api를 사용할 때는 감싸기 기법을 이용하자. => 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다.
      • 예외 클래스는 하나만 있어도 충분하다.
    • 한 예외만 잡아내고 다른 예외는 무시해도 된다면 여러 예외 클래스를 사용해도 된다.

• 정상 흐름을 정의하라

  • 비지니스 논리와 오류처리가 분리된 코드가 간결한 알고리즘으로 보인다.

    • 외부 api를 감싸 독자적인 예외를 던지고, 코드 위에 처리기를 정의해 중단된 계산을 처리하는 코드가 적합하지 않은 상황도 있으니 상황을 판단하여 예외적인 상황을 캡슐화해서 처리한다던지 잘 판단해서 예외를 사용해야한다. ex) 특수 사례 패턴 : 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식

      // before
      try {
      MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
      m_total += expenses.getTotal();
      } catch(MealExpensesNotFound e){
      m_total += getMealPerDiem();
      }
      

    // after public class PerDiemMealExpenses implements MealExpenses{ public int getTotal(){

     // 기본값으로 일일 기본 식비를 반환한다.

    } } ```

• null을 반환하지 마라

  • null을 반환하는 코드는 일거리만 늘리고 하나라도 빼먹으면 애플리케이션이 통제 불능에 빠질지도 모르니 안좋다.
    • 메서드에서 null을 반호나하고싶다면 예외를 던지거나 특수 사례 객체를 반환하자 => 사용하려는 외부 api가 null을 반환한다면 감싸기 메서드를 구현해 예외를 던지거나 특수 사레 객체를 반환하는 방식

• null을 전달하지 마라

  • null을 넘기지 못하도록 금지하는 정책을 만들자!

    오늘 읽은 소감

    매 챕터마다 현재 진행하고 있는 프로젝트 api 구현할때 도움이 되고 있다. 이번 챕터도 아주 중요한 부분을 정리해주어 좋았다. 특히 null을 반환하고 전달하는 부분에서 저자가 최대한 사용하지 않는게 좋다고 하는 부분에서 깊은 공감과 감명을 받았다. java에선 null이 중요하지만 javascript에서는 null뿐만 아니라 undefined가 있어 처리를 이중으로 해야한다. 아주 골치 아프다. 대부분 완벽하게 처리하지 못하고 테스트를 거치면서 아! 처리하는 걸 깜박했다 하고 다시 코드 수정하고는 했다. 최대한 반환하지 않는것이 좋으니 joi를 사용한다던지 유효성 검증을 도와주는 모듈을 사용하여 처리를 대신해야겠다고 생각했다.

6장. 객체와 자료 구조

책에서 기억하고 싶은 내용

• 자료 추상화

  • 변수를 private으로 선언하고 각 값마다 조회(get)함수와 설정(set)함수를 제공하지 않기
  • 자료는 추상적인 개념으로 표현하기

• 자료/객체 비대칭

  • 절차적인 코드 기존 자료 구조를 변경하지 않으면서 새함수 추가 쉬움 새로운 자료 구조 추가하기 어려움 새로운 함수가 필요할때 적합
  • 객체 지향 코드 기존 함수를 변경하지 않으면서 새 클라스 추가하기 쉬움 새로운 함수를 추가하기 어려움 새로운 자료 타입이 필요할때 적합

• 디미터 법칙 휴리스틱 : 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙 객체는 조회 함수로 내부 구조를 공개하면 안됨

  • 기차 충돌 여러 객차가 한 줄로 이어진 기차처럼 보이는 것 => 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안됨 예시)

    final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

    변경 후)

    Options opts = ctxt.getOptions();
    File scratchDir = opts.getScratchDir();
    final String outputDir = scratchDir.getAbsolutePath();

    디미터 법칙 적용 후)

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

  • 잡종 구조 객체, 절반은 자료 구조인 것 중요한 기능을 수행하는 함수도 있고, 공개 변수나 공개 조회/설정 함수도 있는 것 => 공개 조회/설정 함수는 비공개 변수를 그대로 노출됨 잡종 구조는 되도록 피할것!
  • 구조체 감추기 내부 구조 드러내지말기 모듈에서 해당 함수는 자신이 몰라야하는 객체 탐색하지 않기 변경 전)

  String outFile = outputDir + "/" + className.replace('.', '/') + ".class";
  FileOutputStream fout = new FileOutputStream(outFile);
  BufferedOutputStream bos = new BufferedOutputStream(fout);

  변경 후)

  BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);

• 자료 전달 객체 DTO(자료 전달 객체) : 공개 변수만 있고 함수가 없는 클래스 데이터베이스에 저장된 가공되지 않은 정보를 애플리케이션 코드에서 사용할 객체로 변환하는 일련의 단계에서 가장 처음으로 사용하는 구조체 예) 빈(bean) 구조

  • 활성 레코드 DTO의 특수한 형태 공개 변수가 있거나 비공개 변수에 조회/설정 함수가 있는 자료 구조지만, 대개 save나 find와 같은 탐색 함수 제공 데이터베이스 테이블이나 다른 소스에서 자료를 직접 변환한 결과 활성 레코드는 자료구조로 취급하기 비지니스 규칙을 담으면서 내부 자료를 숨기는 객체는 따로 생성 (내부 자료란 활성 레코드의 인스턴스)

    오늘 읽은 소감

    나는 javascript를 주로 사용하다보니 클래스, 인터페이스 등을 사용 안한지 오래되었다. 이번 챕터를 읽으면서 예제를 더 주의깊게 보고 이해했어야 했다. 지난날 java를 사용하며 spring 프로젝트를 진행했을때 나는 잡종코드를 마구마구 작성했었다는 것을 알게되었다. 역시 클리코드는 교과서 같다. javascript에서도 클래스를 사용하니 이번 챕터에서 배운 디미터 법칙을 적용하여 구현해봐야겠다.

궁금한 내용 또는 잘 이해되지 않는 내용

디미터 법칙 - 휴리스틱

5장. 형식 맞추기

책에서 기억하고 싶은 내용

• 형식을 맞추는 목적 코드 형식은 의사소통의 일환으로 처음 잡아놓은 구현 스타일과 가독성 수ㄴ은 유지보수 용이성과 확장성에 영향을 미친다.

1. 적절한 행 길이를 유지하라 JUnit, Time and Money 등 유명한 프로젝트들은 500줄이 넘지 않고 200줄 정도인 파일로 커다란 시스템을 구축 할 수 있다는 것을 보여준다.

   • 신문 기사처럼 작성하라 이름은 간단하면서도 설명이 가능하게 짓기 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명하기 아래로 내려갈 수록 의도를 세세하게 묘사하기 마지막 가장 저차원 함수와 세부 내역 작성하기
   • 개념은 빈 행으로 분리하라 패키지 선언부, import 문, 각 함수 사이에 빈행 넣기 빈행의 의미 : 새로운 개념을 시작한다는 시각적 단서
   • 세로 밀집도 서로 밀접한 코드행은 세로로 가까이 놓기 예) 두 인스턴스 변수 중간에 줄바꿈 -> 두 인스턴스 변수 붙히기
   • 수직 거리 서로 밀접한 개념은 세로로 가까이 두기, 한 파일에 두기 (단, 두 개념이 서로 다른 파일에 속한다면 규칙 X)
     • 변수선언 : 변수는 사용하는 위치에 최대한 가까이 선언
     • 인스턴스 변수 : 인스턴스 변수는 클래스 맨 처음에 선언
     • 종속 함수 : 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치하기, 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치(자연스레 코드가 읽히도록)
     • 개념 유사성 : 친화도가 높을수록 코드를 가까이 배치하기 예) 한 함수가 다른 함수를 호출해 생기는 직접적인 종송성, 변수와 그 변수를 사용하는 함수, 비슷한 동작을 수행하는 함수, 명명법이 똑같거나 기본 기능이 유사한 함수
     • 세로 순서 : 호출되는 함수를 호출하는 함수보다 나중에 배치(소스 코드 모듈 고->저차원)

2. 가로 형식 맞추기 짧은 행은 행이 바람직하며 100~120자가 적당

   • 가로 공백과 밀집도 공백을 사용하여 밀접한 개념과 느슨한 개념 표현 예) 할당 연산자를 강조하려고 앞뒤에 공백을 주어 두가지 요소가 나뉜다는 것을 표현 함수 이름과 이어지는 괄호 사이에는 공백을 넣지 않음 함수와 인자는 밀접하기 때문 수식에서 항과 항 사이에 공백을 넣어 곱셉과 덧셈, 뺄셈의 우선순위를 표현(도구 사용시 수식은 적용이 안되고 공백이 제거됨)
   • 가로 정렬 불필요하게 아래와 같이 정렬하지 않기

     private Socket            socket;
     private InputStream     input;

     클래스명이 길어진다면 선언부와 할당부를 나누기

     public FitNesseExpediter(Soket s, FinNesseContext context) throws Exception
     {
     return true;
     }

   • 들여쓰기 범위로 이뤄진 계층을 표현하기 위해 우리는 코드를 들여쓰기함 들여쓰기의 정도는 계층에서 코드가 자리잡은 수준에 비례
   • 가짜범위 빈 while 문이나 for문 최대한 사용하지 않기 아래 예제처럼 새행에 ;를 사용하지 않기

     while ( dis.read(buf, 0, readBufferSize) != -1)
     ;

   • 팀 규칙 팀은 한 가지 규칙에 합의해야 함. 모든 팀원은 그 규칙을 따라야 함. 스타일은 일관적이고 매끄러워야함. 목표! 일관적인 스타일의 소프트웨어 구현하기 예시) 어디에 괄호를 넣을지, 들여쓰기는 몇자로 할지, 클래스와 변수와 메서드 이름은 어떻게 지을지 등 결정

3. 밥 아저씨의 형식 규칙 책 P.114~P.116 참고

오늘 읽은 소감

이번 챕터에서는 신문 기사처럼 작성하라는 부분이 인상깊었다. 아주 좋은 기사처럼 읽고 싶은 마음이 들게끔 구조적으로 코드를 작성하라는 것이다. 내 코드라고 하더라도 중구난방 정돈되지 않은 코드 구조로 짜서 유지보수할 때 힘겨웠던 것 같다. 세로 길이와 가로 길이에 대한 유명한 프로젝트를 기반으로 하여 조사한 그래프도 인상깊었다. 유명한 프로젝트가 무조건 세로 길이가 짧고 가로 길이가 정해져 있는 것은 아니지만 대부분 세로 길이가 짧고(제공 시스템에 비해) 가로 길이가 2~60자인 행이 많다는 것이 신기했다. 현재 진행 중인 프로젝트에서 팀원과 협의하지 않고 각자 맡은 서비스를 구현 중인데 지금이라도 이번 챕터에서 배운 내용을 공유하고 리팩토링하면서 개발을 진행해야겠다.

4장. 주석

책에서 기억하고 싶은 내용

주석은 나쁜 코드를 보완하지 못한다.

• 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다.
• 모듈을 짜고 보니 짜임새가 엉망이고 알아먹기 어렵다.
• 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다.

  코드로 의도를 표현하라

• 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다.

  좋은 주석

• 법적인 주석

    회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣으라고 명시하는 것

• 정보를 제공하는 주석

        기본적인 정보를 주석으로 제공하는 것(함수 이름에 정보를 담는 편이 좋고 주석이 필요없어진다.)

• 의도를 설명하는 주석

            가령 함수의 마지막 코드 return 값이 왜 1인지 설명하는 것

• 의미를 명료하게 밝히는 주석

                인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 의미를 명료하게 밝히는 주석이 유용하다. 
                그릇된 주석을 달아놓을 위험이 높기 때문에 주석이 올바른지 검증하기도 쉽지 않고 이때문에 의미를 명료히 밝히는 주석이 필요한 이유인 동시에 주석이 위험한 이유라서 항상 더 나은 방법이 없는지 고민하고 정확히 달도록 각별히 주의해야한다.

• 결과를 경고하는 주석

                다른 프로그래머에게 결과를 경고할 목적으로 주석을 사용한다.
                가령 프로그램 효율을 높이기 위해 정적 초기화 함수를 사용하려던 열성적인 프로그래머가 주석 덕분에 실수를 면할 수도 있다.

• TODO 주석

                앞으로 할일을 남겨두는 것
                프로그래머가 필요하다 여기지만 당장 구현하기 어려운 업무를 기술한다.(떡칠 금지)
                예시) 더 이상 필요 없는 기능을 삭제하라는 알림, 누군가에게 문제를 봐달라는 요청, 더 좋은 이름을 떠올려달라는 부탁, 앞으로 발생할 이벤트에 맞춰 코드를 고치라는 주의 등

• 중요성을 강조하는 주석

                자칫 대수롭지 않다고 여겨질 뭔가의 중요성을 강조하기 위해서라도 주석을 사용한다.

• 공식 API에서 Javadocs

                공개 API를 구현한다면 휼륭한 Javadocs를 작성한다.
                예시) 표준 자바 라이브러리

  나쁜 주석

• 대다수 주석이 나쁘다. 예시) 허술한 코드를 지탱, 엉성한 코드 변명, 미숙한 결정 합리화 등
• 주절거리는 주석

    의무감으로 혹은 프로세스에서 하라고 하니까 마지못해 주석을 다는 행위는 시간낭비다.

• 같은 이야기를 중복하는 주석

    코드의 내용을 그대로 중복한 주석

• 오해할 여지가 있는 주석 의도는 좋지만 구체적으로 주석을 달지 않아 오해할 만한 주석
• 의무적으로 다는 주석 모든 함수에 Javadocs를 달거나 모든 변수에 주석을 달아야 한다는 규칙은 어리석기 그지없다. 코드만 헷갈리게 만들고 거짓말할 가능성이 높으며 잘못된 정보를 제공할 여지를 만든다.
• 이력을 기록하는 주석 모듈 편집 시, 모듈 첫머리에 날짜와 주석을 추가한다.(일종의 로그) 옛날은 소스 코드 관리 시스템이 없었기 때문에 유용했지만 지금은 불필요하다.
• 있으나 마나 한 주석 너무 당연한 사실을 언급하며 새로운 정보를 주지 못하는 주석
• 무서운 잡음 목적이 불분명하고 오류가 있는 주석 함수나 변수로 표현할 수 있다면 주석을 달지마라!
• 위치를 표시한 주석 소스파일의 특정 위치를 표시하려는 주석 가독성만 낮아진다. 반드시 필요하고 아주 드물게 사용 가능하다.
• 닫는 괄호에 다는 주석 닫는 괄호에 특수한 주석을 달아놓는다. 중첩이 심하고 장황한 함수라면 의미가 있을 지도 모르지만 (책에서 선호하는) 작고 캡슐화된 함수에는 잡음이다. 닫는 괄호에 주석달지 말고 함수를 줄이려 시도하자!
• 공로를 돌리거나 저자를 표시하는 주석 누가 추가함 하는 주석. 소스 코드 관리 시스템이 하니까 쓰지말자.
• 주석으로 처리한 코드 현재 안쓰는 코드를 주석으로 처리하는데 질나쁜 와인병 바닥에 앙금이 쌓이듯 쓸모 없는 코드가 점차 쌓여간다. 이것도 소스 코드 관리 시스템으로 기억하자.
• HTML 주석 소스 코드에서 HTML 주석은 혐오 그자체다. 읽기가 쉽지 않기 때문이다.
• 전역 정보 주석을 달아야 한다면 근처에 있는 코드만 기술하라. 코드 일부에 주석을 달면서 시스템 전반적인 정보를 기술하지 마라. 예시) 기본값(config 파일의 데이터값)을 기술하는 짓
• 너무 많은 정보

    흥미로운 역사나 관련없는 정보를 장황하게 늘어놓지 마라.
    예시) base64의 설명

• 모호한 관계

   주석과 주석이 설명하는 코드는 관계가 명백해야 한다.
   부족한 설명은 필요없는 주석이다.

• 함수 헤더

    짧은 함수는 긴 설명이 필요없다.
    이름을 잘붙히자!

• 비공개 코드에서 Javadocs

    공개 API가 아니면 쓰지마라.

오늘 읽은 소감

챕터의 초반에 주석에 대한 저자의 강력한 의견과 그의 말을 뒷받침하는 근거들을 읽으며 고개를 끄덕이다가도 이직 후 인수인계 해줄 개발자가 없을때 나 혼자서 프로젝트를 파악하던 경험이 생각나며 그래도 주석이 필요한 상황도 있지 않나 생각했다. 가령 javascript 코드에서 java를 연결하여 호출하는 부분이 있었는데 어떤 역할을 하는지 의도를 적어준 주석이 나에게 해당 부분의 코드를 파악하는데 많은 도움이 되었다. 저자가 전달하려는 의도는 이해가 갔지만 어느 정도 주석은 필요하다고 생각한다. 저자가 우려한 잘못된 정보의 주석이나 주저리 적은 주석이라던가 하는 것은 문제가 될 수 있겠지만 이를 유의해서 작성한다면 코드를 파악하는데 시간이 줄어들지 않을까 싶다. 후반 예시에서 저자도 설명이 필요한 부분에 주석을 달았다. 그래서 결론은 저자가 말하는 것처럼 개발자라면 이해가 바로 될 정도로 좋은 코드를 작성하도록 노력하고 추가로 의도를 명확히 밝힌 좋은 주석을 작성하는 것이다.(아니면 나쁜 주석의 예를 잘 기억하고 안하던가) 오늘도 클린코드 덕분에 한걸음 더 좋은 개발자가 될 수 있는 규칙을 알게되어 기쁘다. 현재 진행하는 프로젝트에도 적용하여 좋은 주석, 함수 작성하는 습관을 길러야겠다.

3장.함수

책에서 기억하고 싶은 내용

1. 작게 만들어라
   • 함수를 만드는 첫번째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다.
   • 블록과 들여쓰기 다시말해, if문/else문/while문 등에 들어가는 블록은 한 줄이어야 한다는 의미다. ... 이말은 중첩 구조가 생길만큼 함수가 커져서는 안 된다는 뜻이다. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 당연한 말이지만, 그래야 함수는 읽고 이해하기 쉬워진다.
2. 한 가지만 해라!
   • 함수는 한 가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
   • 지정된 함수 이름 아래서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한가지 작업만 한다.
   • 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러작업을 하는 셈이다.
3. 함수 당 추상화 수준은 하나로!
   • 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야한다.
   • 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 즉, 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다. => 내려가기 규칙
   • 위에서 아래로 TO문단을 ㅇ릭어내려 가듯이 코드를 구현하면 추상화 수준을 일관되게 유지하기 쉬워진다.
4. Switch문
   • 각 switch 문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법 => 다형성을 이용한다.
5. 서술적인 이름을 사용하라!
   • 이름이 길어도 괜찮다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.
   • 함수 이름을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다. 그런 다음, 여러 단어를 사용해 함수 기능을 잘 표현하는 이름을 선택한다.
   • 이름을 붙일 때는 일관성이 있어야한다. 모듈 내에서 함수 이름은 같은 문구,명사,동사를 사용한다.
6. 함수 인수
   • 인수가 3개 넘어가면 인수마다 유효한 값으로 모든 조합을 구성해 테스트하기가 상당히 부담스러워진다.
   • 최선은 입력 인수가 없는 경우이며, 차선은 입력 인수가 1개뿐인 경우다.
   • 많이 쓰는 단항 형식

     함수에 인수 1개를 넘기는 이유로 가장 흔한 경우

     1) 인수에 질문을 던지는 경우 : boolean fileExists("MyFile") 2) 인수를 무너가로 변환해 결과를 반환하는 경우 : InputStream fileOpen("MyFile") 3) 이벤트 함수
     • 플래그 인수 : 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다. 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이다.
     • 이항 함수 : 좌표 객체 만들때 유용하고 최대한 단항 함수로 바꾸도록 해야한다.
     • 삼항 함수 : 인수가 3개라 이해가 힘들다.
     • 인수 객체 : 인수가 2-3개 필요하다면 일부를 독자적인 클래스 변수로 선언할 수도 있다.
     • 인수 목록 : 때로는 인수 개수가 가변적인 함수도 필요하다.
     • 동사와 키워드 : 함수의 의도나 인수의 순서와 의도를 제대로 표현하려면 좋은 함수 이름이 필수다. 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야한다. ex) write(name) => writeField(name) assertEqualse => assertExpectedEqualsActual(expected, actual)
7. 부수 효과를 일으키지 마라!
   • 함수에서 한가지만 해야지 클래스 변수를 수정한다거나 함수로 넘어온 인수나 시스템 전역 변수를 수정하는 추가적인 작업은 안좋다. => 시간적인 결합, 순서 종속성 초래
   • 출력 인수 : 최대한 피해라. 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택한다.
8. 명령과 조회를 분리하라!
   • 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야한다. 둘 다 하면 혼란을 초래한다. 명령과 조회를 분리하여 함수를 구성해라.
9. 오류 코드보다 예외를 사용하라!
   • 오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다.
   • Try/Catch 블록 뽑아내기
     • try/catch 블록을 별도 함수로 뽑아내는 편이 좋다.
     • 정상 동작과 오류 처리 동작ㅇ르 분리하면 코드를 이해하고 수정하기 쉬워진다.
       • 오류 처리도 한 가지 작업이다.
       • 오류를 처리하는 함수는 오류만 처리해야 마땅하다.
   • Error.java 의존성 자석 : 오류 코드 대신 예외를 사용하면 새 예외는 Exception 클래스에서 파생된다. 따라서 재컴파일/재배치 없이도 새 예외 클래스를 추가 할 수 있다.
10. 반복하지 마라!
    • 중복은 문제다. 코드 길이 증가 및 오류 발생 확률도 높아진다.
    • 구조적 프로그래밍, AOP, COP 모두 어떤면에서 중복 제거 전략이다.
11. 구조적 프로그래밍
    • 데이크스트 : 모든 함수와 함수 내 모든 블록에 입구와 출구가 하나만 존재해야한다. -> 함수는 return 문이 하나여야 한다.(함수가 클때만 유용)
12. 함수를 어떻게 짜죠?
    • 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다.
    • 코드가 길어질 수도 있고 그안에서 쪼개기도하고 테스트도 하고 한다. 규칙을 넣기도 하면서 만들어진다. -> 한번에 탁나오는 코드는 없다.
13. 결론
    • 프로그래밍의 기술은 언제나 언어 설계의 기술이다.
    • 대가 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다. 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어간다.
    • 시스템에서 발생하는 모든 동작을 설명하는 함수 계층이 언어에 속한다.

      오늘 읽은 소감

      이번 챕터를 통해서 가독성도 좋고 효율적으로 함수를 만드는 방법을 익힐 수 있어 좋았다. 개발하다 보면 함수가 길어지고 테스트를 진행할 때도 오류가 발생하면 찾기 바빴는데 그 원인이 함수를 최대한 쪼개고 하나의 역할씩만 하게 해서 사용하지 않아서 그런 것임을 알게되었다. 이번 챕터를 읽으면서 저자가 강력하게 하지말라고 하는 부분들을 내가 하고 있어서 뜨끔했고 어서 지금 진행중인 프로젝트의 코드를 수정해야겠다고 생각했다. 결론에서 저자가** 대가 프로그래머는 시스템을 풀어갈 이야기로 생각한다**고 했다. 나는 시스템을 구현할 프로그램으로 바라보았기 때문에 언어를 활용하지 못하고 그지같이 짰던 것 같아서 반성했다. 이번에 함수를 어떻게 짜면 좋은지 규칙들을 알게되었으니 잘 지켜나가면서 시스템이라는 하나의 이야기를 잘 풀어나가는 프로그래머가 되야겠다.

오늘 읽은 범위

2장. 의미있는 이름

책에서 기억하고 싶은 내용

• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.(p.22)

• 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.(p.25)

• 게다가 사람들은 접두어(또는 접미어)를 무시하고 이름을 해독하는 방식을 재빨리 익힌다. 코드를 읽을수록 접두어는 관심 밖으로 밀려난다. 결국은 접두어는 옛날에 작성한 구닥다리 코드라는 징표가 되버린다.(p.30-31)

• 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.(p.31-32)

오늘 읽은 소감

최근 회사에서 진행중이던 프로젝트에서 제일 힘들었던 부분이 파일명, 함수명, 변수명 지을 때였다. 최대한 협업할 때 다른 개발자가 알아보기 쉽도록 이름을 지으려 노력했는데 클린코드에서 소개한 규칙들을 읽으니 수정해야할 이름들이 떠올랐다. 내일 당장 적용시켜봐야겠다고 생각했다.

추천사 ~ 1장. 깨끗한 코드

책에서 기억하고 싶은 내용

• 우리 개발자에게는 체크아웃해 코드를 꺼낼 때보다 체크인해서 코드를 넣을 때 더 깨끗한 상태로 만들어야 할 의무가 있다.(p.xx)
• 꼭 맞게 닫히지 않는 문이나 비뚤어진 바닥 타일이나 지저분한 책상 등 아주 사소한 것들이 전체의 매력을 깎아먹기 때문이다. 깨끗한 코드가 중요한 이유는 바로 여기에 있다.(p.xxii)
• 코드에 정직하고, 코드의 상태에 관하여 동료들에게 정직하고, 무엇보다도, 자기 코드에 대해서 자신에게 정직하라는 뜻이다.(p.xxviii)
• 깨끗한 코드를 작성하는 방법은 배우기 어렵다. ... 고생을 해야한다.(p.xxxii)
• 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.(p.7)
• '코드 감각'이 있는 프로그래머는 나쁜 모듈을 보면 좋은 모듈로 개선할 방안을 떠올린다.(p.8)
• 나쁜 코드는 나쁜코드를 '유혹'한다.(p.9)
• 언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다!(p.15)

오늘 읽은 소감

"Later equals Never."

읽는 내내 저자에게 팩폭을 맞고 현타가 오기를 반복했다. 프로젝트 기한이 짧다는 핑계를 대며 돌아가기만 하면 그만이지 생각하고 나쁜코드를 계속 찍어냈던 과거의 내 모습이 파노라마처럼 지나갔다. 아니 현재도 그러는 것 같다. 애써 그동안 알면서도 핑계대며 넘어갔고 그래서 년차가 쌓여가지만 자신있게 시니어다라고 할만큼의 실력이 되지 못하고 주니어로 남아있는 것 같다. 시간이 지날 수록 년차만 쌓이고 실력은 주니어인 개발자로 남을 순 없다. 저자는 이 책을 그저 "기분 좋은 책"으로 머물지 말고 손으로 몸으로 마음으로 익히면서 연구하며 고생해야 자신의 지식으로 만들 수 있다고 당부한다. 진정으로 성장하기로 마음 먹었으니 전문가가 되기 위해 열심히 책을 독파할 생각이다. 나중은 결코 오지 않으니까..

궁금한 내용 또는 잘 이해되지 않는 내용

르블랑의 법칙 https://yiming.dev/clipping/2019/03/21/le-blanc's-law-a-k-a-later-equals-never/

Prologue

첫번째 면접 후 나는 퇴사했다. 그리고 사정이 생겨 계획과 다르게 재취업을 빠르게 추진하게 되었다. 잡코리아로 포지션 제안 온 회사 중 괜찮아 보이는 회사들 면접을 연달아 잡았다. 첫번째 면접의 쓰라린 아픔을 잊은채..두번째 회사 면접을 보러 갔다. 처음 제안 받은 포지션은 프론트 엔드였는데 메일로 일정을 잡고 보니 풀스택으로 변경되어 있었다. 당황스러웠지만 이또한 좋은 경험이 되겠거니 하고 준비했다. 가벼운 마음으로 면접장으로 갔는데 막상 가니 매우 떨렸다. 그 떨림을 숨기고 자기소개를 시작했는데 후반으로 가더니 양과 아웃사이더가 되어 대답했다. 유리 멘탈인 나는 정신이 나가기 시작했다. 그리고 다음 질문에도 정리가 안된채 대답해서 면접관이 정리해주었다. 급하게 준비하니 이런 문제가 생기는 것 같다. 이번 회사는 기술적인 질문은 거의(?) 없는 수준이었다. 그래도 면접 복기를 해보려 한다.

이력서 및 인성 질문

1. 자기소개
2. 개발파트는 어떻게 시작하게 되었는지
3. 이력서에는 백엔드 개발자라고 적혀있던데 풀스택 개발을 할 수 있는지
4. 전직장을 퇴사한 이유
5. 전직장에서 여러 프로젝트를 개발해보면서 회사에 기여한 부분이 있거나 자랑하고 싶은 부분 소개
6. 전직장에서 런칭한 서비스의 개발 기간이 얼마나 되는지
7. 본인의 기술 익히는 속도는 어느 정도인지
8. nodejs의 단점 설명
9. 리액트를 이용하여 개발을 진행한다 할때 개발 소요 시간이 얼마나 될 것 같은지
10. 본인이 디자인적인 감각이 있다고 생각하는지
11. cms 갤러리 같은 시스템을 구현할 수 있는지
12. 개발자와 협업해서 개발해본 경험이 있는지
13. 팀원과 커뮤니케이션하면서 원활하지 못했던 부분이나 아쉬웠던 경험이 있는지 있다면 어떤 식으로 해결했는지
14. 야근 관련해서 어떻게 생각하는지
15. 수직적인 지시에 대한 부담이 없는지

Review

앞서 말했듯이 자기소개할때 많이 떨면서 대답했는데 질문이 뒤로 갈수록 딱 이력서에 있는 부분과 인성 관련한 질문이라서 어렵지 않았고 모든 대답에 내 경험을 근거로 대답했다. 질문들을 받으며 지금 당장 업무에 쓸 실무자가 필요하다는 것을 많이 느꼈고 전직장의 분위기와 비슷할 것 같은 느낌을 받았다.ㅎㅎ 웃으며 끝난 면접에서 예상치 못한 면접비를 받으니 더 기분이 좋았다. 이번 면접에서 느낀 건 긴장해도 준비한 말을 끝까지 다하면 면접관들이 알아준다는 것이었다. 다음에 볼 면접은 화상 면접이다. 구글 Meet으로 면접을 진행하는데 기술적인 질문을 많이 받을 것 같은 느낌이 든다.
떨지말고 준비한 것 그대로 보여주고 오자! 화이팅!

Prologue

약 4년만에 개발자 면접을 보았다. 서류가 통과되고 이미 그곳에 취업된 것 마냥 상상의 나래를 펼쳤다.(INFP특) 과제 전형을 받고 살짝 당황했지만 열심히 코드를 작성했고 과제 전형까지 통과했다. 난 회사 근처 자취방 시세를 알아보며 김칫국을 다발로 마시고 있었다. 하지만..면접을 보고 처참히 무너졌다. 나는 기본기가 매우 부족한 생계형 개발자임을 알게되었다. 정말 가고 싶었던 회사였는데 떨어지게 되어 매우 아쉬웠다. 이 아쉬움을 간직한 채..그날 받았던 질문을 복기해보려 한다.

이력서 및 포트폴리오 질문

1. 자기소개
2. 전직장 어떻게 입사하게 되었는지
3. 회사 지원 동기 3-1. 회사의 장점이 많이 떨어지는 것 같은데 어떻게 생각하는지(꼬리질문)
4. 하나의 기술을 깊게 하기에 어려운 환경 속에서 설계/클린코드/구조같은 것들은 어떻게 학습하는지 4-1. 최근에 읽은 기술 아티클이 있거나 혹은 가장 기억에 남은 어떤 매체들의 내용 중 기억나는게 있으면 소개(꼬리질문)

과제 전형 질문

1. route, dto, controller, service, dao 이 5가지에 대해서 간략하게 설명 1-1. 왜 controller와 service로 나누었는지 설명과 역할 설명 1-2. dao의 역할
2. let과 const에 대한 설명
3. 비동기 로직에서 async/await 주로 작성을 했던데 promise를 직접 만들어 쓴 경험이 있는지
4. const가 객체일때 항목에 있는 값이 변경이 되는지 변수일때는 변경이 안되는지
5. call by value와 call by reference에 대한 설명
6. 통합테스트만 하고 단위 테스트를 안한 이유

추천받은 아티클과 책

1. 견고한 node.js 만들기
2. 리팩토링2

공부해야하는 부분

1. es6 문법 활용
2. 함수형 프로그래밍
3. Nodejs에서의 의존성 주입
4. 단위테스트
5. orm / mysql2
6. TypeScript
7. React

Review

이력서와 포폴에 대한 질문보다 제출한 과제물에 대한 질문이 많았고 꼬리 질문이 많았다. 과제물을 보면서 질문을 받다보니 위에 적지 못한 질문이 많다. 나는 과제물에 대한 질문을 생각해보지 않아서 많이 당황했다. 그리고 왜 이렇게 코드를 짰는지에 대한 질문을 받을때면 머리가 새하얗게 되버려서 아..음..어..같은 말을 많이 했고 자신감이 쭉쭉 떨어진 상태로 말했다. 나는 과제의 요구사항을 적용시키기에만 급급했고 어떻게 하면 더 좋은 코드가 될 것이고 그렇게 짠 코드가 왜 좋은지를 고민하지 않았다. 여튼 많은 반성을 하게 되었고 내가 작성한 코드에 대한 피드백을 많이 들어서 좋은 시간이었다. 코드리뷰하는 회사라 다른 것 같다.
아쉬움이 많이 남고 더 그 회사에 가고 싶다는 마음이 들게 만드는 면접이었다. 조언 받은 부분 잊지 않고 분발해서 다시 도전하고 싶다.

면접관 앞에 서면 나는 양과 아웃사이더가 된다. 이를 극복하려 찾아본 여러 유튜브 영상에서 얻은 Tip들을 정리했다. 간략하게 적어둔거라 연결된 링크로 영상을 보며 자세히 들어보는 걸 추천한다.

• • -

1. 테디쌤

• ★준비를 철저히 해서 자신감을 갖자!★
• 집을 나서는 순간부터 텐션업! 인사를 잘하자!
• 대기실에서도 웃는 모습, 친절!
• 면접 전 화장실에서 신나는 노래 듣기! -> 텐션 높이기
• 면접관을 내 친한 친구라고 생각하기!

2. 내일부터 출근

• '떨어지면 어쩌지'라는 불안한 마음을 갖지 말기! 합격해야만 해!! -> 강박 생김 -> 불안 -> 뇌정지 -> 실수연발
• 긴장은 당연한것이다 차분히 받아들이기
• 내가 보는 면접은 누군가가 간절히 바라던 자리였다고 생각하기
• 서류 면접에 통과했으니 면접을 볼 수 있는 것이니 자신감을 갖기
• 떨어졌다면 긴장때문이 아니라 지식/기술/태도 또는 서로 안맞아서 떨어지는 것

3. 캐시하우

• 양유형 숨쉴때 아래 근육을 이용해서 호흡 펌핑하기

   - 호흡 펌핑 방법
       1) 코로 숨을 깊게 들이마시기
       2) 입으로 강하게 내뱉는다 (강하게 독침을 쏘듯이)

  3) 전체적으로 힘을 조절하지 못하겠다면 말머리부분에서 강하게 소리를 내주기

   ex) 제가!(호흡독침)지금 말씀드릴 부분은~ / 여기를! 보시면~

• 동공지진형

  • 한곳에 시선을 머물게 연습하기 1) 사람과 사람사이를 보기 2) 발표 공간의 중앙을 바라보기 3) 상대방의 콧등을 보자
  • 다수의 상황이라면 왼쪽->오른쪽->중앙 순으로 3초씩 머무르기

• 화이트아웃형(아무것도 안들리고 아무것도 생각안날때) 준비가 되어 있어야하고 발표 상황에 익숙해지자

  • 상황에 익숙해지는 방법 1) 전화통화를 많이 해보기 2) 문의 전화, 상담 전화, 배달전화, 지나가는 사람에게 물어보기, 사람 많은 곳에서 알바해보기 3) 손가락으로 8자 모양을 만들고(기억력을 증진시켜준다고 함) "나는 할수있다" 외치기

• 아웃사이더형 글을 천천히 읽고 말을 천천히 하는 연습하기

** 준비 부족은 절대 안됨, 대사 많이 연습하기**

여러 영상에서 공통적으로 말하는 것은 준비를 철저히 많이 해야한다는 것이었다. 스스로가 준비가 덜 되었다는 것을 알기에 이를 들킬까봐 더 떨었나보다. 면접 준비와 연습 그게 먼저다. 아직 늦지 않았어..!