목표 좋은 소프트웨어 설계 목표는 필요한 시스템을 만들고 유지보수하는데 최소한의 비용과 인력이 투입되는 것이다. 만약 새로운 기능이 추가되는데 점점 더 많은 인력 또는 비용과 시간이 필요하다면 무언가 잘못되고 있는 것이다. 사례 연구 엉망진창이 되어 가는 신호 시스템을 급하게 만드는 것 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않을 경우 무엇이 잘못되었나? 현대의 개발자도 이와 비슷한 경주를 하며, 토끼와 유사한 과신을 드러낸다. 물론 개발자가 잠을 자는 것은 아니다. 오히려 정반대다. 현대의 대다수 개발자는 뼈 빠지게 일한다. 하지만 그들의 뇌는 잠에 취해 있다. 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고 있는 바로 그 뇌가 잠자고 있다. 시장에 출시하는 것이 먼저니까 ..
전체 글
조금 늦은 2022년 회고를 써보려고 한다. 써야지 써야지 생각은 했지만 계속 실천으로 옮기지 못했는데, 역시 나는 적당히 바빠야 시간을 더 내는 사람인 것 같다. 상반기 2022년 상반기는 2021년과 비슷하게 보냈다. 회사에서 내 포지션은 프론트엔드였고, 여전히 AngularJS를 사용한 유지보수를 진행했다. 그래도 회사에서 SaaS 전환을 시도하게 되면서 내게 스프링 부트 + 리액트 조합을 사용한 회원가입 / 로그인 프로토타입을 만들어보라고 해서 알지 못하던 스프링과 자바를 공부할 수 있어서 좋았다. ID와 PW를 사용한 로그인 외에 구글/네이버/카카오 로그인을 붙이면서 OAuth의 동작 원리들을 이해할 수 있었다. 이 작업을 하면서 외부 API를 사용하는데 자신감이 많이 붙었다. 하반기 1 상반기..
아직 10월이지만 연말인 것 같이 느껴지는 이유는 22텀이 끝나서인 것 같다. 22텀을 돌아보면서 받은 은혜를 기억하고 다음 텀을 준비하면서 어떤 마음으로 준비하면 좋을지 생각해보려고 한다. 순에서 1월에 순원들을 처음 만나게 됐다. 온라인이지만 기도 제목을 받으며 내가 너무 부족함을 느꼈다. 나의 기도 제목은 '이직하고 싶어요', '건강하게 해주세요' 이런 것들일 때가 많았는데, '반복되는 선택으로 예수님을 증거할 수 있기를 원해요'라는 기도 제목을 받으면서 내가 우리 순원들에게 챙겨줄 수 있는게 있을까? '내 믿음의 부족함이 우리 순원들에게 보여지면 어떡하지?', '다른 순장님들처럼 나는 재밌고 에너지 넘치지 않는데, 순모임의 시간이 재미도 없고 은혜도 없으면 어떡하지?'라는 고민이 생겼다. 그래도 ..
아웃리치? 우리 교회에서는 해외 또는 국내로 약 일주일 정도 선교 봉사를 떠나는 것을 아웃리치라고 부르는 것 같다(내 생각). 나는 7월 말 - 8월 초에 화개에 있는 교회로 4박 5일간 아웃리치를 다녀오게 되었다. 어떻게 가게 되었는지? 그냥 다들 가는 거니까 가야겠다고 생각했다. 올해는 특히 순장이라는 역할을 맡게 되었는데, 나도 하지 않으면서 다른 사람들에게 가라고 말하지 못하는 성격 때문에 순원들에게 아웃리치에 가자고 말하기 위해서 가야했다. 솔직히 가고 싶은 마음도 있었던 것 같다. 왜 이렇게 많은 사람들이 아웃리치를 기다려왔는지 궁금했고 나도 예수님을 깊게 만나는 경험을 하고 싶었다. 문제는 7월에 우리 회사가 굉장히 바쁠 예정이라는 것이었다. 7월말까지 제품 출시라는 목표는 정해져 있었고, ..
왜 크런치 모드...? 기존 우리 회사 제품을 SaaS로 전환하기 위해 7월 3주간 크런치 모드에 들어가게 되었다. 최대한 빠르게 우리 제품을 AWS에 올리는 것이 목표였고, AWS는 물론이고 클라우드 환경, 그리고 기존 프론트엔드 개발자에서 백엔드 개발자로 전환되면서 아는 것이 하나도 없는 뇌까지 제로 베이스에서 시작하는 프로젝트였다. 7월 말까지 제품 출시라는 목표가 있었고 7월 초부터 조금씩 기획이 완성되었기 때문에 일정이 굉장히 빠듯했다. 백엔드 개발 백엔드로 넘어오면서 개인적으로 좋았던 점은 테스트 코드 작성이 쉬움 더 깔끔하게 코드 작성이 가능 테스트 코드 작성이 쉬운 것과 깔끔한 코드 작성이 쉬운 것은 굉장히 개인적인 의견이고, 아직 백엔드에 대해 자세히 모르기 때문일 수도 있는데, 프론트엔..
Chapter06 기본적인 리팩터링 함수 추출하기 함수 추출하기는 코드 조각을 찾아 무슨 일을 하는지 파악한 다음 독립된 함수로 추출하고 목적에 맞는 이름을 붙이는 리팩터링이다. 독립된 함수로 묶는 기준은 여러가지가 있을 수 있는데 '목적과 구현을 분리'하는 방식이 가장 합리적인 기준이 될 수 있다. 코드를 보고 무슨 일을 하는지 파악하는 데 한참이 걸린다면 그 부분을 함수로 추출한 뒤 '무슨 일'에 걸맞는 이름을 붙이자. 이렇게 해두면 나중에 코드를 다시 읽을 때 함수의 목적을 더 쉽게 알 수 있고, 본문 코드에 대해서 신경쓰지 않아도 된다. 절차 함수를 새로 만들고 목적을 잘 드러내는 이름을 붙인다.('어떻게'가 아닌 '무엇을' 하는지가 드러나도록) 대상 코드가 매우 간단하더라도 함수로 뽑아서 목적이..
Chapter05 리팩터링 카탈로그 보는 법 리팩터링 설명 형식 이름 이름은 리팩터링 용어를 구축하는 데 중요하다. 책 전반에서 해당 리팩터링을 이 이름으로 지칭한다. 같은 기법을 다르게 부르는 경우도 있기 때문에 그중 흔한 이름도 함께 소개한다. 개요 리팩터링의 핵심 개념을 간략히 표현(개념도 + 코드 예시) 절차 리팩터링하는 과정을 단계별로 제시 예시 해당 리팩터링 기법을 실제로 적용하는 간단한 예와 그 효과를 보여줌 리팩터링을 안전하게 수행하려면 단계를 최대한 잘게 나누고 각 단계마다 테스트해야 한다. 상황이 난해할수록 단계를 잘게 나누자.
Chapter04 테스트 구축하기 리팩터링을 제대로 하려면 불가피하게 저지르는 실수를 잡아주는 견고한 테스트 스위트가 필요하다. 리팩터링을 하지 않더라도 좋은 테스트를 작성하는 일은 개발 효율을 높여준다. 자가 테스트 코드의 가치 모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자. 자가 테스트를 만들면 테스트가 컴파일만큼 쉬워진다. 컴파일할 때마다 테스트를 함께 실행하면 디버깅 시간을 크게 줄여줘서 생산성이 상승한다. 자가 테스트 코드 자체뿐 아니라 테스트를 자주 수행하는 습관도 버그를 찾는 강력한 도구가 된다. 테스트 스위트는 강력한 버그 검출 도구로, 버그를 찾는데 걸리는 시간을 대폭 줄여준다. 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다. 기능을 추가해야 할 때..
Chapter3 코드에서 나는 악취 기이한 이름 코드는 단순하고 명료하게 작성해야 한다. 코드를 명료하게 표현하는데 가장 중요한 요소 하나는 바로 '이름'이다. 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경 써서 이름을 지어야 한다. 함수 선언 바꾸기 변수 이름 바꾸기 필드 이름 바꾸기 세가지 작업을 통해 기이한 이름을 명료한 이름으로 바꾸어보자. 이름만 잘 지어도 나중에 문맥을 파악하느라 헤매는 시간을 크게 절약할 수 있다. 마땅한 이름이 떠오르지 않는다면 설계에 더 근본적인 문제가 숨어 있을 가능성이 높다. 그래서 혼란스러운 이름을 잘 정리하다 보면 코드가 훨씬 간결해질 때가 많다. 중복 코드 똑같은 코드 구조가 ..
Chapter 2 리팩터링 원칙 리팩터링: [명사] 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법 리팩터링: [동사] 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다. 특정한 방식에 따라 코드를 정리하는 것만이 리팩터링이다. 리팩터링은 결국 동작을 보존하는 작은 단계들을 거쳐 코드를 수정하고, 이러한 단계들을순차적으로 연결하여 큰 변화를 만들어내는 일이다. 개별 리팩터링은 아주 작을 수도 있고, 작은 단계 여러 개가 합쳐진 모습일 수도 있다. 따라서 리팩터링하는 동안에는 코드가 항상 정상 작동하기 때문에 전체 작업이 끝나지 않았더라도 언제든 멈출 수 있다. 누군가 "리팩터링하다가 코드가 깨져..