- 리팩토링 2판 중 내가 가장 많이 받는 질문 중 하나는 "관리자에게 리팩터링에 대해 어떻게 말해야 하나요?"이다. 관리자와 고객이 "리팩터링은 누적된 오류를 잡는 일이거나, 혹은 가치 있는 기능을 만들어내지 못하는 작업"이라고 오해하여 리팩터링이 금기어가 돼버린 조직도 있다. 리팩터링을 위한 일정을 몇 주씩 잡는 개발팀을 보면 오해는 더욱 커진다. 설상가상으로 실제로는 리팩터링이 아닌, 어설픈 재구성 작업을 하면서 코드베이스를 오히려 망가뜨리는 모습을 보면 또 불신이 증가한다. 관리자가 기술에 정통하고 설계 지구력 가설도 잘 이애하고 있다면, 리팩터링의 필요성을 쉽게 설득할 수 있다. 이런 관리자는 오히려 정기적인 리팩터링을 권장할 뿐만 아니라 팀이 리팩터링을 충분히 하고 있는지 살펴보기도 한다. 그..

리팩터링 저자는 거의 1시간 간격으로 리팩터링을 한다고 한다. 그러다보니 저자의 작업 흐름에 리팩터링을 녹이는 방법이 여러가지 였고 이번에는 그 흐름들을 설명한다. 3의 법칙 1. 처음에는 그냥 한다. 2. 비슷한 일을 2번째로 하게 되면 (중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다. 3. 비슷한 일을 3번째로 하게 되면 리팩터링 한다. 준비를 위한 리팩터링: 기능을 쉽게 추가하게 만들기 리팩터링하기 가장 좋은 시점은 코드베이스 기능을 새로 추가하기 직전이다. 이 시점에 현재 코드를 살펴보면서, 구조를 살짝 바꾸면 다른 작업을 하기가 훨씬 쉬워질만한 부분을 찾는다. 가령 내 요구사항을 거의 만족하지만 리터럴 값 몇개가 방해되는 함수가 있을 수 있다. 함수를 복제해서 해당 값만 수정해도 ..

YAGNI는 You aren't gonna need it 의 줄임말으로써, 프로그래머가 필요하다고 간주할 때까지 기능을 추가하지 않는 것이 좋다는 원칙이다. 실제로 필요할 때 무조건 구현하되, 그저 필요할 것이라고 예상할 때에는 절대로 구현하지 말라는 것이다. 프로그램을 작성하다보면, 현재는 사용하지 않지만 나중에 사용할 것 같은 또는 나중에 확장될 수 있을 것 같은 작업을 미리 해두는 경우가 가끔씩 있는 것 같다. 이전 개발을 할 때, 쌓였던 경험들로 인해 내 코드의 미래가 보여지기 시작하면서, "현재는 필요없지만, 나중을 위해서 이 기능을 추가해 놓으면 편하다." 라는 생각이 든다. 예를 들어서, 어떤 웹사이트를 만들고 있는데, 기능 요구사항에는 모달을 사용하는 것이 있다. 그런데 현재 내가 개발하는..

리팩터링은 소프트웨어의 모든 문제점을 해결하는 만병통치약을 아니지만, 코드를 건강한 상태로 유지하는 데 도와주는 약임은 분명하다. 1. 리팩터링하면 소프트웨어 설게가 좋아진다. : 리팩터링하지 않으면 소프트웨어의 내부 설계(아키텍쳐)가 썩기 쉽다. 아키텍처를 충분히 이해하지 못한 채 단기 목표만을 위해서 코드를 수정하다 보면, 기반 구조가 무너지게 된다. 코드 구조가 무너지기 시작하면, 악효과가 누적된다. 코드만으로 설계를 파악하기 어려워질수록 설계를 유지하기 어려워지고, 설계가 부패되는 속도는 더욱 빨라진다. 같은 일을 하더라도 설계가 나쁘면 코드가 길어지기 십상이다. 사실상 같은 일을 하는 코드가 여러 곳에 나타날 수 있기 때문이다. 그래서 중복코드 제거는 설계 개선 작업의 중요한 한 축을 차지한다...

리팩터링이란 - 리팩터링 2판 리팩터링은 겉으로 드러나는 코드의 기능은 바꾸지 않으면서, 내부 구조를 개선하는 방식으로 소프트웨어 시스템을 수정하는 과정이다. 버그가 생길 가능성을 최소로 줄이면서 코드를 정리하는 정제된 방법이다. 요컨대, 리팩터링한다는 것은 코드를 작성하고 난 뒤에 설계를 개선하는 것이다. "코딩 후 설계 개선"이라는 정말 이상한 말이다. 우리가 예전부터 따르던 소프트웨어 개발 방법은 설계부터 하고 코드를 작성하는 방식인데, 좋은 설계가 우선되어야 하고 코딩은 그 다음이다. 하지만 시간이 흐르면서, 코드는 수정되고 시스템의 무결성, 즉 설계에 맞춘 구조는 점차 뒤죽박죽이 되어간다. 공학에 가깝던 코딩 작업은 서서히 해킹에 가까워진다. 이 과정을 반대로 하는 것이 리팩터링이다. 리팩터링을..

나는 react로 프로그래밍을 할 때 styled-component (emotion)같은 CSS-in-JS 라이브러리를 사용하여 프로그래밍을 했다. 그 이유는 https://blog.logrocket.com/8-reasons-to-use-styled-components-cf3788f0bb4d/ 에 자세히 설명되어있고, 이 아티클을 인용하여 글을 작성한다. React에서 컴포넌트에 스타일링을 하는 방법은 다음과 같다. 1. 외부 CSS 파일에 CSS코드를 작성하여 className으로 속성을 전달하기 2. inline CSS를 react component 안에 넣기 3. CSS-in-JS 1. 외부 CSS 파일에 CSS코드를 작성하여 className으로 속성을 전달하기 => 대규모 어플리케이션 프로젝트의..

react로 개발을 하다보면, 상태관련 로직이 중복되는 경우를 발견할 수 있다. 이때에는 HOC이나 render props를 사용하여 중복되는 코드를 줄일 수 있는데, 커스텀 훅을 사용하면 위 방법을 사용하지 않고도 그것을 가능하게 해줍니다. 커스텀 훅을 사용함으로써 상태관련 로직을 재사용할 수 있으며, 각 state가 각각 완전히 독립적이게 할 수 있습니다.

공식문서 ko.reactjs.org/docs/hooks-intro.html#motivation "훅은 컴포넌트로부터의 상태 관련 로직을 추상화 할 수 있다." 훅이 있기 전까지는 class 컴포넌트를 사용했습니다. class는 그 자체가 새로운 인스턴스를 반환하고 그 인스턴스는 "this"를 저장하고 있기 때문에, 그 인스턴스 자체가 react에서 알고 있는 값이 되므로 react에서 제거하지 않는 이상, 페이지가 새로 렌더링 되더라도 해당 인스턴스를 기억하고 있기때문에, 상태관리를 자유롭게 할 수 있기 때문입니다. 반면에 함수 컴포넌트는 함수의 라이프 사이클 특성상, 생성 -> 갱신 -> 제거 과정을 거치고 return이 되면 메모리상에서 제거된다. 그렇기 떄문에 함수 컴포넌트는 자신의 동작이 끝나면 ..