테스트 구축하기 드디어 나왔다. 테스트코드... 근데 이 책은 테스트에 관련된 책이 아니라서 상세하게 설명하지는 않았다. 그래서 좀 아쉽기도 하지만 테스트로 주제가 빠져버리면 책 한권으로도 부족하기 때문에 어쩔 수 없다고 생각한다. 예시 테스트 코드도 나쁘지는 않지만 좀 부족하다. 게다가 프론트엔드에서 테스트는 또 다른 얘기다. 자가 테스트코드의 가치 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다. 테스트를 작성하다 보면 원하는 기능을 추가하기 위해 무엇이 필요한지 고민하게 된다. 구현보다 인터페이스에 집중하게 된다는 장점도 있다. 게다가 코딩이 완료되는 시점을 정ㄹ확하게 판단할 수 있다. 테스트를 모두 통과한 시점이 바로 코드를 완성한 시점이다. 켄트 벡은 테스트부터 작성하는 습관을 ..
코드에서 나는 악취 이번에도 세부적인 내용은 적지 않겠다. 그 중에서도 중요하다고 생각한 몇가지만 적어보겠다. 그리고 가장 중요한 것은 코드를 작성할 때 생각을 하면서 짜는 것이다. 생각없이 코드를 적으면 악취를 풍긴다. 최대한 냄새를 풍기지 않게 주의하면서 코딩을 하자. 기이한 이름 코드를 명료하게 표현하는데 표현하는데 가장 중요한 요소 하나는 바로 이름이다. 마땅한 이름이 떠오르지 않는다면 설게에 더 근본적인 문제가 숨어 있을 가능성이 높다. (너무 많은 역할을 하고 있지는 않은지 생각해보자) 네이밍은 엄청나게 중요하다. 진짜로 엄청엄청. 변수명을 보고 유추하기 어렵다면 그건 잘못된 네이밍이다. 설계가 잘못되었는지 두 가지 이상의 역할을 하고 있는지 이런것들을 생각하는 것도 중요하지만 그것과는 별개로..
리팩터링 원칙 리팩터링 리팩터링 하는데 정의가 무엇일까? 정의는 다음과 같다. 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다. 여기서 겉보기 동작은 그대로 유지한 채. 라는게 중요하다. 성능을 개선하고 기능을 추가하는 거은 리팩터링이 아니다. 우리는 커밋을 할때도 기능 추가와 리팩터링 두 개의 모자를 구분해서 바꿔써야한다. 대부분의 회사에서 하는일은 유지보수다. 그리고 기능추가를 하려고 하는데 코드가 지저분할 경우가 있을 것이다. 그럴때는 먼저 리팩터링을 하자. 대단한 리팩터링을 얘기하는 것이 아니다. 함수가 좀 크다면 함수를 나누고 변수명이 모호하다면 변수명을 바꾸고 이런 기본적인 것들이라도 먼저 적용하면 훨씬 깔끔해진다. 이 이후에 코드를 보면..
배경 리팩터링2라는 책을 예전부터 알고 있었다. 개발바닥의 이동욱님을 통해서 알게되었고 꼭 스터디를 열어서 공부해야겠다고 생각했다. (클린코드, 함께 자라기, 객체지향의 사실과 오해, 오브젝트 등도 기회가 있다면 하고싶다.) 친구랑 우연히 얘기하다가 둘다 이 책으로 스터디를 하고 싶어한다는 것을 알게 되었고 스터디를 시작하게 되었다. 그리고 회사에서도 이 얘기를 하자 같이 하고 싶다고 한 두분이 있었고 회사 동료분의 친구까지 합쳐서 5명이 스터디를 하게 되었다. 이 책을 읽는 이유 사실 할 공부도 책도 너무 많다. 그 많은 책중에서 리팩터링이라는 책을 선택했다. 그 이유는 모두가 리팩터링이라는 것이 꼭 필요하다고 생각하기 때문이다. 특히 회사를 다니면 엄청 공감하게 된다. 작은 프로젝트에서는 그냥 하면 ..