- 리팩터링 2판 중 리팩터링하면 프로그램 성능이 느려질까봐 걱정하는 사람이 많다. 나는 실제로 소프트웨어를 이해하기 쉽게 만들기 위해서 속도가 느려지는 방향으로 수정하는 경우가 많다. 직관적인 설계 vs 성능 은 중요한 주제이다. 내가 성능을 무시하는 이유는 설계의 순수성을 우선시하거나 조만간 더 빠른 하드웨어가 나오리라 믿기 때문이 아니다. 예전에도 너무 느린 소프트웨어는 고객이 수용해주지 않았고 빠른 하드웨어가 등장하더라도 성능 기준이 낮아지는 경우는 드물었다. 리팩터링하면 소프트웨어가 느려질 수도 있는 건 사실이다. 하지만 그와 동시에 성능을 튜닝하기는 더 쉬워진다. 하드 리얼타임 시스템을 제외한 소프트웨어를 빠르게 만드는 비결은, 먼저 튜닝하기 쉽게 만들고 나서 원하는 속도가 나게끔 튜닝하는 것..

2020.01.02~2020.02.29 까지 동계인턴한 경험을 1학기가 지난 지금 다시 써본다. ETRI는 대학생들이 실무경험을 할 수 있게 방학시즌마다 단기 인턴을 고용한다. 경기, 부산, 대전, 대구 등의 도시에서 다양한 업무에서 1~7씩 뽑는다. 그리고 업무별 담당자도 다르고 나처럼 서류합격 후 바로 인턴에 합격되는 경우도 있고 전화면접으로 전공지식과 자기소개에 대한 질문을 하는 경우도 있다고 한다. (나는 서류합격후 바로 인턴으로 발탁되었다.) 경기,부산,대구는 뽑는 부서도 적고 인원도 적다. 그러나 대전은 뽑는 부서도 많고 뽑은 인원도 총합해서 많은 편이었다. (부서별로는 1~5명) 그래서 대전으로 지역을 정하고, 어느 부서에 지원을 할지 많은 고민을 했다. 합격률을 높이기 위해 많인 뽑는 부서..

- 리팩터링 2판 중 리팩터링은 소프트웨어 아키텍처를 바라보는 관점을 완전히 바꿔놓았다. 내가 프로그래밍을 시작한지 얼마 되지 않은 시절에는 코딩을 시작하기 전에 소프트웨어 설계와 아키텍처를 어느정도, 심지어 거의 완료해야한다고 배웠다. 일단 코드로 작성된 뒤로는 아키텍처를 바꿀 수 없었고, 부주의로 인해 부패할 일만 남았다고 여기곤 했다. 리팩터링은 이런 관점을 크게 바꿔놓았다. 그래서 나는 수년 동안 운영되던 소프트웨어라도 아키텍쳐를 대폭 변경할 수 있었다. 이 책의 부제처럼 리팩터링으로 기존 코드의 설계를 개선할 수 있다. 하지만 앞에서 말했듯이 레거시 코드는 변경하기 어려울 때가 많다. 특히, 탄탄한 테스트가 뒷받침해주지 못하면 더더욱 어렵다. 리팩터링이 아키텍처에 미치는 실질적인 효과는 요구사항..

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

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

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

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

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