1주차: 1장 리팩터링: 첫 번째 예시 ~ 2장 리팩터링 원칙

[choisohyun]

인상깊었던 책의 내용과 인상깊었던 이유
현업 등 코드에 반영할 수 있는 방법과 생각
관련 아티클이나 이해를 돕는 자료를 첨부
새롭게 알게된 점이나 이해가 어려웠던 점

[jiyoung-bak]

[1주차] REVIEW

• 익스트림 프로그래밍에 대하여 알게 되었다.
  • https://martinfowler.com/bliki/ExtremeProgramming.html
  • https://ko.wikipedia.org/wiki/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D
• 다향성을 활용한 재구성에서 객체지향을 사용하는게 낯설었다.
• 두가지 모자를 번갈아가면서 쓸 예정이다. 리팩터링 모자를 쓰면 새로운 기능 추가 없이 리팩터링만! 기능추가모자쓸 때엔 리팩터링말고 새로운 기능 추가에 집중을!!

[BEMELON]

p88

리팩터링 시간을 일정에 따로 잡아두지 않고, 대부분의 리팩터링을 다른 일을 하는 중에 처리한다

if문 작성하는 것에 시간을 따로 할당하지 않는 것처럼 리팩터링을 한다는 것에 놀라움(?)
궁금증) 따로 분리 안하고 하나의 브랜치에서 하게 되면 코드 리뷰 난이도가 너무 올라가는 건 아닌지..

p100

향후 변경에 유연하게 대처할 수 있는 유연성 메커니즘을 소프트웨어에 심어두는 것이다. ... 앞으로 어느 부분에 유연성이 필요하고 어떻게 해야 그 변화에 가장 잘 대응할 수 있을지 추측하지 않고, 그저 현재까지 파악한 요구사항만을 해결하는 소프트웨어를 구축한다. 단, 이 요구를 멋지게 해결하도록 설계한다. 진행하면서 사용자의 요구사항을 더 잘 이해하게 되면 아키텍처도 그에 맞게 리팩터링해서 바꾼다

설계 과정에서 항상 이러한 유연성에 대한 타협을 어디까지 할 것인가에 대한 고민이 있었고, 시간을 잡아먹는 요소 중 하나였는데 리팩토링을 기계적으로 할 수 있다면 설계에서의 시간을 많이 아낄 수 있겠다 라는 생각

[suojae]

인상깊었던 점

1. 리팩토링의 시작은 테스트 코드 작성부터
2. 이해하기 쉬운 코드 작성과 성능 퍼포먼스가 좋은 코드 사이의 트레이드 오프 관계가 있다. 이때 팁은 전체적인 코드는 읽기좋은 코드를 작성하되 성능적으로 중요한 부분은 좁은 부분만 최적화하는 것이다. 왜냐하면 성능 관련 코드는 아주 좁은 범위내에 있기 때문
3. 팀원들이 서로의 코드를 수정할 수 있는 권한을 주어야한다.
4. 리팩토링하는 시점 -> 새로운 기능 추가전, 버그수정, 코드이해해야할 때, 반복적인 작업을 3번째 하고 있을 때

[hamo-o]

TDD란?
자가 테스트 코드 (스스로 성공/실패 판단) + 리팩터링

---

리팩터링 하다가 성능이 나빠지면 어떻게 해야 할까?

1. 성능에 신경쓰지 않고 일단 리팩터링에 집중
2. 성능 최적화 시점이 되면 프로파일러로 프로그램 분석, 자원을 잡아먹는 지점 알아내기
3. 그 부분 개선하기

---

무언가 수정하려 할 때는 먼저 수정하기 쉽게 정돈하고 그런 다음 쉽게 수정하자. _켄트 벡

항상 버그가 발생하면 그 원인을 찾아 수정하기 바빴는데, 리팩터링을 우선시 하는게 문제를 빨리 해결할 수 있는 방법이 될 수 있음을 배웠다.

---

JS/TS를 위한 리팩터링 자동화 툴이 있을까?

eslint가 그 역할을 일부 해왔다고 생각한다. 검색해보면 여러 툴이 나오기는 하는데, 쓸만할지 궁금하다.

---

getter는 지양해야 하는가?

리팩터링 관련된 사항은 아니지만 ...
책에서는 getter를 사용하면 메서드명을 이용해서 데이터에 접근할 수 있다며 애용하고 있다. 그런데 객체지향에서는 getter와 setter의 사용을 지양해야 한다고 알려져 있다. 자바스크립트 클래스에서 getter와 setter를 사용하는 것은 좋은 습관일까?

[LastCow9000]

리팩터링을 하면 새 기능 개발의 속도가 저하된다?

• 아니다. 기존 코드를 읽기 쉽고 수정하기 쉽게 되기 때문에 오히려 빨라진다.

리팩터링을 언제 해야 할까?

• 비슷한 일을 세 번째 하게 되면 한다(삼진 리팩터링)

관리자에게 뭐라고 말해야 할까?

• 기술을 잘 모르는 관리자에게는 "리팩터링한다고 말하지 말라" 는 조언을 얻었다.

[choisohyun]

• 리팩터링 후에 항상 테스트하는 습관을 들여라. 많이 반성하게 된다. 잘 동작하는지 확인을 편하게 하기 위해서라도 테스트 케이스를 작성하고 시작해 봐야겠다. 작은 범위부터 하면 테스트 케이스도 많지 않을 것이다.
• 쪼개기 단계가 이렇게까지 많았나 싶을 정도로 쪼개면 리팩터링을 했을 때 위험성이 적어지는 것 같다. 롤백도 쉽게 될 것 같고..
• 두 개의 모자 리팩터링 작업 쪼개기와 비슷한 맥락이다. 기능 추가와 리팩터링을 구분하고 쪼개야 작업이 다르다는 것을 인지할 수 있다. 작업할 때 단계별로 커밋하는 습관을 다시 잡아보자..
• 프로 개발자의 역할은 효과적인 소프트웨어를 최대한 빨리 만드는 것이다. 빠르게 구현하는 방법은 리팩터링이다. 리팩터링의 본질은 코드 베이스를 예쁘게 꾸미는 것이 아니라 경제적인 이유로 하는 것이다. 리팩터링은 개발 기간을 단축하고자 하는 것이다.
  • 리팩터링에 대한 관점을 새롭게 가지게 되었다. '빠르게' 안정적으로 만들 수 있는 코드를 만들자