..

20210721

회고는 나 자신을 위해 쓰는 글이며 대부분의 경우 나 자신 외 다른 독자를 별로 고려하지 않는다.

Fact

  1. Clojure/script 문법, 내장함수, 네임스페이스, 메크로 등에 대해 공부했다.
  2. 개인 프로젝트 Tresk의 축소판을 Clojurescript + Reagent로 작성해봤다.
  3. 개인 프로젝트 Tresk의 레이아웃과 설명 등을 미세하게 고쳤다.
  4. 리팩터링 책에서 돌 하나를 수집했다.
  5. 리팩터링 스터디가 끝났다. (4회)

Feeling

  1. 돌을 수집하는 것이 자연스럽기 보다는 약간의 의무감처럼 하는 것 같기는 한데, 습관 형성에는 필요하다고 본다. 내가 흥미와 에너지를 느끼는 돌만 수집하라는 원칙은 잘 지키고 있다.
  2. 아예 새로운 기술/언어를 익히는 것은 오랜만인데, ‘하면서 배우는 것’이 참 중요한 것 같다. 그리고 책이나 글, 영상도 예제 위주로 잘 되어있냐 아니냐에 따라 나의 학습에 큰 영향을 미친다. 나에게 적절한 난이도면서 필요한, 예제 위주의 글 하나가 정말 많은 시간을 아낀다. 특히 Clojure/script는 자료가 잘 없어서…
  3. 리팩터링 스터디에서 내가 작업한 2개의 리팩터링이 좋은 평가를 받아서 기분이 좋다. 그렇지만 한편으로는 좀 털려야(?) 배우는게 많은데 그런 면에서는 많이 아쉽다.
  4. 다음으로 스터디할 책이 ‘IT에 몸담은 이들을 위한 지적 생산 기술’ 인데 뭔가 이런 류의 책은 비슷비슷한 얘기를 하기도 하고 결과적으로 변화가 일어나는 경우가 적어서 꺼려지기도 했지만, 오히려 이런 책을 많은 사람들과 함께 스터디 해본적이 없기에 좋은 기회가 될 것 같다고 생각했다.
  5. 실무자들과 스터디를 하면서 배우는 점이 참 많고 감사하다. 매주 이렇게 해나간다면 몇년 후의 나에게 어떤 변화가 생길지 기대된다. 대학에서도 이런 형태의 스터디를 내가 조직하면 좋을텐데, 사실 여러모로 쉽지 않은 일이다.

Finding

  1. Reagent에 대해서는 웬만해서는 다 익혔다. 이 글이 글이 도움이 많이 된다.

  2. 메크로에 대해서도 많이 공부했다. 이 글, 이 글, 이 글이 좋다.

  3. Clojure 자체 문법 등은 여기를 자주 이용한다.

  4. 테스트가 있어야 리팩터링을 할 수 있고, 리팩터링을 잘해야 오버 엔지니어링을 안할 수 있다. 리팩터링을 못하면 ‘그거 나중가면 힘들 것 같은데, 지금 뭐 어떻게 해야하지 않을까’ 이렇게 된다. 그때 그때 필요한 작업만 하고, 나머지 작업은 더 많은 정보를 알고 있는 미래의 나에게 미루는 것이 좋다. 이것을 실행하면서 좋은 코드를 얻으려면 테스트와 리팩터링 실력이 필요하다.
  5. 무엇이 아니라 왜를 드러내야 한다. 이름 뿐 아니라 테스트 코드도 마찬가지다. addOne같은 함수 이름이 구현이 드러나는 예시다. 테스트 설명도 when audience is more than 20 이런 것보다 when audience exceeded limit 이런식이 낫다.
  6. 함수 매개변수 기본값을 요즘 안쓰다보니 까먹고 있었다.

     //1
     function example(param) {
         const param2 = param ? param : 0;
     }
    
     //2. 1보다 이게 낫다.
     function example(param) {
         const param2 = param ?? 0;
     }
    
     //3. 그런데 1, 2보다 이게 낫다.
     function example(param = 0) {
     }
    
  7. 데이터의 종류를 구별해야한다.

     class Receipt {
       constructor() {
         this.header = '';
     }
    
     writeHeader(invoice) {
       this.header = `청구내역 (고객명: ${invoice.customer})\n`;
     }
    

    예를 들어 위와 같은 코드에서 customer를 따로 저장한 뒤, getHeader 같은 다른 함수에서 header를 생성하기 위한 데이터를 가지고 있는 편이 낫다.

  8. orderDetails같은건 복수의 의미가 아니다. 세부사항 자체가 details다. 이런 경우 애매해지는데, 아예 다른 식으로 이름을 짓거나, a/an을 붙이는 방법이 있다.
  9. 이상한 코드는 테스트를 짜보면 더 잘 드러난다. ‘이거 테스트 안짜셨죠? 는 유효한 질문이었다.’
  10. 매개변수를 너무 자세하게 많이 넘기는 것은 좋지 않다. 더 큰 레벨에서 더 적은 수의 매개변수를 넘겨야 좋다. 테스트를 짜보면 더 잘 드러난다.
  11. 9, 10에 대해서는 이 PR을 참고하여 문제점을 찾아보면 이해가 잘 된다.

Future Action

  1. 내일은 이전에 Tresk에서 작성한 reducer로직을 Clojure/script를 이용해서(특히 메크로) 짜보는 것으로 하루를 시작할 것이다.
  2. 내일은 Tresk를 이용한 짧은 주기의 할일 관리 및 회고, 피드백을 시도할 것이다. 반드시!

Affirmation

참고 : 자기 다짐 의 올바른 사용

나는 더 좋은 코드를 짜기 위해 계속 노력하는 사람이다.

Feedback