어른들은 누구나 처음엔 어린이였다

지훈진·2022년 2월 2일
2

BetterProgrammer

목록 보기
11/17

그러나 그것을 기억하는 어른은 별로 없다. (어린왕자에서 인용)

20장. 효과적인 버전 관리

디스크 상의 소스 코드는 손짓 한 번으로도 너무 쉽게 사라지는 디지털 연기와 다를 바 없다.

그래서 git이 필요하다. subversion이나 mercurial 같은 형상관리 툴은... 회사에서 쓰지 않는다면 굳이 익힐 필요도 없을 것 같다. 필요할 때 하면 된다. 버전 관리를 하지 않는 프로젝트 폴더가 있다면 당장 입력하자. git init
저장할 때는 '모든 것을 저장하라', '가능하면 적게 저장하라'는 모순적인 소제목이 이어서 나온다. 하나로 합쳐 말하면 필요한 것들만 모두 저장하라. 라고 말할 수 있을 것 같다.

저장소의 과거 기록을 검색하는 과정에서 큰 도움을 얻을 수 있다.

'change userservice', 'modify orderservice', 'refactoring'... 이런 식의 커밋 메시지를 많이 보았을 것이다. 이런 메시지들이 도움이 되던가? 아니었을 것이다. 커밋 메시지는 명확하고 간결하게, 코드를 작성할 때 처럼 신경써서 작성하여야 한다. 영어가 자신없다면 차라리 한글로 적는 것을 추천한다. (영어로 적어야한다는 규칙이 없다면...) 버그를 만들었더라도 명확하게 수정한 의도를 커밋에 남기면, 다른 개발자가 리뷰를 하다가 버그를 찾을 수도 있다.

개선하려면 변화해야 한다. 완벽하려면 자주 변화해야 한다.

윈스턴 처칠의 말이다. 자주 변화하기 위한, 이를 추적하기 위한 완벽한 도구는 버전관리 툴이다. 꼭 사용하자.

21장. 골키퍼 있다고 골 안 들어가랴

개발 과정에서 벌어지는 관계의 문제나 정치, 마찰에서 벗어날 수 없다.

이 챕터는 개발자가 가장 불안정한 관계를 맺게 되는 팀으로 QA를 뽑고 있다. 챕터의 제목이 왜 '골키퍼 있다고 골 안 들어가랴'인지는 잘 이해가 되지 않는다. 아무래도 영어권의 은유가 많다보니 그런 것 같다.

소프트웨어 개발을 선형적 절차로 바라보는 시각은 잘못된 것이다.

공학설계 시간에 배웠던 폭포수 모델은... 완벽하지 않기 때문에 불가능하다. 실수는 있을 수 밖에 없는데, 개발이 끝나 QA로 프로덕트가 전해지면 버그 천지일 것이다. 개발팀은 QA가 빨리 안한다고 난리, QA는 개발이 제대로 안되었다고 난리가 난다. 즉, 선형적인 절차에 대한 잘못된 시선부터 버려야 한다.

만약 4개의 팀이 컴파일러를 만든다면, 4패스 컴파일러가 만들어질 것이다.

소프트웨어의 구조와 그것을 개발하는 팀의 구조는 서로 유사해진다는 콘웨이 법칙이다. 이렇게 되지 않기 위해선 의사소통 건전해야한다고 책을 이야기하고 있다. 그리고 이것은 QA팀과의 커뮤니케이션에서도 마찬가지이다.

사무실을 뜨기 전에 빌드를 뱉어내고 싶은 유혹이 엄습한다.

'급할수록 돌아가라'는 뜬구름 잡는 속담이 있다. QA에게 테스트 버전을 배포할 때는 서두르지 않아야 한다. 우선 자신의 변경사항을 스스로 테스트한 뒤에, 기능 변경이나 추가로 인한 테스트 방법과 기대값을 설명해야한다. 그리고 정확하게 테스트 버전을 배포해야 한다. 테스트 버전을 배포한 뒤에 정상동작하는지 확인도 해야한다. 이를 자동화 스크립트로 만들면 더 좋다.

오류 보고서는 개인적 경멸의 표시가 아니다.

QA가 버그를 찾아주는 것을 개발자는 감사히 여겨야 한다. 고객이 발견하기 전에 먼저 발견해준 것이다. 버그가 발생했다면 정확하게 동작하도록 고치기만 하면 된다. QA가 바라는 것은 그것 뿐이다.

품질은 모두의 책임이다.

개발팀과 QA팀 모두 좋은 프로덕트를 만들기 위해 일한다. 팀끼리 건전한 관계를 유지해야 한다. 필요한 건 오직 사랑뿐이다. 무한도전~

profile
집사없는 개발 고양이

0개의 댓글