소프트웨어 장인

우아한 테크코스 프리코스에 탈락하였는데, 메일 피드백으로 추천해 준 책들 중 첫번째, 소프트웨어 장인이다.

배운 것들을 어떻게 활용해서 개발하고, 협업 방법, 개발문화라는 것에 대해 처음으로 제대로 고민할 수 있었다.

덕분에 조금 흔들리고 있었던 가치관을 다시 한번 확립할 수 있었다.

 

무엇보다 이 책을 읽고 왜 TDD를 해야하는 것인지 납득할 수 있었다. 이전까지는 "그냥 좋아서 쓰나보다~" 했는데, 가치관을 배우고, 장인정신을 탐구하여 이전의 마인드셋을 버리고 그 필요를 확인할 수 있어서 너무 좋았다. TDD와 jest를 공부해야겠다는 다짐을 했다.

 

아래는 책 내용 중 중요하다고 생각한 부분들을 정리한 것이다.

 

애자일

빠르고, 짧은 피드백 루프

애자일은 프로젝트 시작 첫주부터 동작하는 소프트웨어를 만듦

 

팀 문화

칼같이 나뉜 역할 없이 우선순위를 매긴 작업 백로그를 이용하고, 팀차원에서 우선순위에 따라 다음에 할 일과 누가 어떻게 어떤 일정으로 수행할 것인지를 정함

 

프로페셔널

코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져아할 최소한의 요건

이외의 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력, 보다 외향적인 성격등이 필요해짐

애자일 매니페스토

💡 우리는 스스로 소프트웨어를 개발하고, 다른사람들이 개발하는 것을 도와주며 더 나은 소프트웨어 개발 방법들을 찾고있다. 이 과정에서 우리는 다음과 같은 가치를 중요하게 생각한다.

절차와 도구보다는 개성과 화합을
방대한 문서작업보다는 동작하는 소프트웨어를
계약 조건에 대한 협상보다는 고객과의 협력을
계획을 따르는 것을 넘어서 변화에 대처하는 것을
더 가치있게 여긴다.

좌측의 사항도 가치가 있음을 인정하지만, 우리는 우측의 사항에 더 높은 가치를 둔다는 것이다.

애자일 매니페스토 원칙

1. 가치있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.
2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다.
3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달 주기를 짧게 한다.
4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.
5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 지원을 제공하고, 프로젝트가 완료될때까지 믿고 맡긴다.
6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 마주보고 대화하는 것이다.
7. 프로젝트의 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어이다.
8. 애자일 프로세스들은 지속가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다.
9. 기술적인 탁월함과 좋은 설계에 대한 지속적인 관심은 기민함을 높인다.
10. 단순함, 즉 하지 말아야 할 일을 최대한 하지 않아야 한다.
11. 최선의 아키텍쳐, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.
12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다.

소프트웨어 장인정신

소프트웨어 장인정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다.

소프트웨어 장인정신은 시켜야만 일하는 역량 미달의 노동자가 아니라 소프트웨어 프로페셔널의 수준을 높여 프로의 모습으로 일하는 소프트웨어 개발자를 지향한다.

소프트웨어 장인정신 매니페스토

💡 소프트웨엉 장인을 열망하는 우리는, 스스로의 기술을 연마하고, 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높인다. 이러한 일을 하는 과정에서 우리는 다음과 같은 가치를 추구한다.

동작하는 소프트웨어뿐만 아니라, **정교하고 솜씨있게 만들어진 작품을,**
변화에 대응하는 것뿐만 아니라, **계속해서 가치를 더하는 것을,**
개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,
고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를,

이 왼쪽의 항목들을 추구하는 과정에서, 오른쪽 항목들이 꼭 필요함을 의미한다.

동작하는 소프트에어 뿐만 아니라, 정교하고 솜씨있게 만들어진 작품을

레거시 프로젝트를 상대할 때 가장 큰 문제는 두려움

수정이 어떤 변화를, 오류를 가져올 지 모르기 때문에 두려움

새로운 기능을 추가 및 수정하는 일이 처음 어플리케이션을 개발할 떄와 비슷한 수준의 개발 공수로 완료될 수 있어야 하며, 코드 베이스 자체도 최대한 작아야 함

변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을

신규기능을 추가하고, 버그 수정을 뜻하는 것 + 코드를 정리하고, 구조를 개선하며 확장성을 높이고 테스트 가능하게 하고, 쉽게 유지보수 할 수 있게 하는 것

보이스카웃 규칙을 명심할 것

캠핑장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라

개별적으로 협력하는 것 뿐만 아니라 프로페셔널 커뮤니티를 조성하는 것

소프트웨어 장인정신의 중심에는 멘토링과 공유

소프트웨어 장인의 임무는 자기발전이나, 그보다 더 큰 임무는 다음 세대의 장인을 준비시킬 책임

1. 블로그에 글 업로드
2. 오픈소스 프로젝트에 기여
3. 작성 코드 공개
4. 지역 커뮤니티 참여
5. 페어프로그래밍

고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를

소프트웨어 장인은 공장 노동자가 아니다.

적극적으로 프로젝트의 성공에 기여해야함.(요구사항 질문, 비즈니스 이해, 개선사항 제시)

고객, 고용주와 생산적인 동반자 관계를 맺어야 함

코드와 관련된 일이 아니면 나의 일이 아니라고 생각하는 개발자는 소프트웨어 장인이라 할 수 없음

소프트웨어 장인의 태도

끊임없는 성장, 발전

자신의 커리어는 자신의 것이므로, 프로페셔널로 대우받기 원한다면 프로처럼 행동해야함→ 스스로를 발전시키기 위해 시간과 돈을 투자할 것

자기계발을 위한 학습법

1. 독서, 많은 독서
   1. 특정 기술에 대한 서적 : 특정 기술을 심도있게 다룬 것(nodeJS, Typescript, Java 등)
   2. 특정 개념에 대한 서적: 특정 개념, 기초를 쌓을 수 있는 책(TDD, 도메인기반 개발, 객체지향 설계, 함수형 프로그래밍)
   3. 행동 양식에 대한 서적 : 효율적으로 팀에서 일할 수 있게 하거나, 일반적인 상황에서 더 나은 프로페셔널이 될 수 있도록 조언(애자인 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발, 심리학, 철학, 경영관련 도서)
   4. 혁명적 서적, 고전 : 일하는 방식, 개인의 가치관을 바꾸는 책 (실용주의 프로그래머, 디자인패턴, 테스트주도개발, 익스트림 프로그래밍, 클린코더, 소프트웨어 장인정신, 리펙토링)
2. 블로그블로그를 배움과 자기계발에 대한 기록의 장으로 둘 것
3. 항상 최신정보를 습득할 수 있으나, 잘못된 정보가 있을 수도 있음
4. 기술웹사이트
5. 팔로우할 리더찾기또한 어떤 개념의 역사와 배경을 이해하는 것이 이해를 도울 수 있음 → 소셜미디어를 활용하는 것이 효과적(트위터, 텔레그램)
6. 해당 기술의 가장 좋은 자료들은 대체 누가 만들어 내고 있는가?를 알아야 함
7. 끊임없는 훈련훈련시에는 작성가능한 최선의 코드를 만드는데에 집중해야함카타같은 코딩 카타를 반복하더라도 매번 다른 테크닉, 다른 언어, 다른 기술, 다른 접근방법을 사용해야 효과를 최대화 할 수 있다.
8. CodeKata
9. 간단한 게임, 간단한 로직(틱텍토 게임, 볼링 점수 계산 등)을 배운 기술과 접근 방법으로 구현하기
10. 시간은 걱정말고 변수, 메서드, 클래스의 이름을 가장 이해하기 쉽고 의미를 포괄할 수 있게 최선을 다해 네이밍한다.
11. 실행관례와 새로운 기술을 배우는 것은 자동차 운전 훈련과 같음

펫 프로젝트

취미생활과 같은 나만의 소프트웨어 프로젝트를 진행해볼 것

기술스택을 먼저 결정하고, 해결한 문제를 찾기

펫프로젝트는 매우 안정되고 안전한 환경에서 시험하고 발견하고 학습하고 즐길 수 있는 기회를 만듦

기술스택 결정 → 프로젝트 주제 선정 → 기능 상세화, 백로그 작성 → 우선순위 작성 → 테스트, 배포, 버전컨트롤 등

오픈소스

오픈소스 프로젝트에 기여하는 것도 좋은 훈련 방법

오픈소스 프로젝트는 대부분 특정 목적에만 집중하여 범위가 제한적임

오픈소스 프로젝트에 참여하면 훌륭한 개발자들이 어떻게 일하는지 체험할 수 있음

페어프로그래밍

페어프로그래밍은 팀의 정신적 에너지를 높이고, 개발자끼리 서로 친밀해질 수 있음

또한, 새로운 내용을 빨리 배울 수 있으며, 자신의 역량을 제대로 파악하는 기회가 될 수 있음

1. 사회활동현재 처한 상황과 관련해 새로운 사실들을 계속 익히도록 스스로를 계속 노출시킬 수 있음
2. 모르는 것을 알기 위한 활동
3. 지역 사용자 그룹이나 기술 커뮤니티에 참여하는 것은 무언가를 배우고 아이디어를 나누기에 더할 나위 없이 좋은 방법
4. 일과 삶의 균형시간만들기확보한 시간을 집 근처 카페에서 생산적으로 활용하기뽀모도로 기법
   1. 어떤 일을 할지 정한다.
   2. 뽀모도로(타이머)를 25분 맞춘다.
   3. 타이머가 끝날때까지 그 일을 한다.
   4. 짧게 쉰다.(5분)
   5. 매 4회의 뽀모도로마다 길게 쉰다.(15~30분)뽀모도로시에는 절대 방해받아서는 안됨. 방해받는다면 뽀모도로를 완전히 중단하고, 새로운 뽀모도로를 처음부터 다시 시작해야함
   6. 뽀모도로를 할때는 할 일에만 집중하고 나머지는 머리속에서 완전히 날려버려야함
5. 집중:뽀모도로 기법
6. SNS활동, 유튜브 시청 등 아무 의미 없이 보내는 시간을 줄이기
7. 계발만 있는 것은 아니므로, 최소의 시간, 최대의 효율로 학습해야함

영웅, 선의, 프로페셔널리즘

‘아니오’, ‘안돼요’라고 말하는 방법 배우기

인정과 명예를 쫓아 불가능한 프로젝트를 억지로 시도하는, 영웅이 되려하지 마라

불가능한 일에 최선을 다하겠습니다, 가능합니다와 같은 말로 단언하지 않기.

불가능한 일을 억지로 하려하면 개발자는 휴일도 없이 갈려나가지만, 프로그램은 코드가 난잡하고 버그가 가득하며, 고객은 화를 내게 됨

⇒ 모든 책임은 개발팀이 지게 되는 최악의 경우로 이어지게 됨

일정안에 모두 완료하는 것이 불가능한 상황이라는 것을 분명히 알면서도 상사에게 “노력해보겠다”는 말을 어떻게 할 수가 있나?
노력해본다는 것의 의미가 무엇인가?
열심히만 하면 갑자기 불가능하던 일이 가능해지고 전부 완료할 수 있다는 것인가?
아니면 개인 생활과 가족을 모두 희생하고 야근과 휴일 근무를 밥먹듯이 하겠다는 뜻인가?
그런 뜻이라면 오래 일한다고 달라지는 것이 있나?
그렇지 않다면 평소 일을 대충하고 있다는 고백임과 동시에 거짓말을 하고 있는 것이 된다.

실망시키지 않기 위해 말하는 “네”는 거짓말이다. 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이다.

프로답게 행동하기

빡빡한 일정을 다루는 가장 좋은 방법은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것

대안제시하기

그냥 “아니오”라고 말하는 것은 프로다운 태도가 아니다.

반드시 대안이 따라와야 한다.

없다해도 대안을 찾아내기 위한 브레인스토밍은 해보아야 한다.

대안 없는 No는 상황에 도움이 되지 못한다.

동작하는 소프트웨어

정원돌보기

프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 더 가깝다.

코드는 유기물에 가깝다. 지속적 관리가 없으면 썩는다.

정기적으로 살피지 않으면 변화가 있을 때마다 상태가 나빠지게된다.

장인은 전체 어플리케이션을 몇분만에 테스트 할 수 있는 자동화 테스트를 구축하고 활용할 줄 안다.

장인은 좋은 디자인 원칙과 테크닉을 전체 어플리케이션 생애에 걸쳐 적용하여 좋은 코드를 작성한다.

코드의 품질이 프로젝트의 성공을 보증하지 못하지만, 실패의 핵심요인은 될 수 있다.

시간에 대한 잘못된 인식

테스트, 리팩토링

이 두 가지를 곧바로 하지않으면, 기술적 부채가 쌓이고, 그것은 대부분 청산되지 않는다.

개발자들은 의도적으로 나쁜 코드를 작성하지 않는다. 테스트 코드를 작성하지 않는 것은 이후 QA를 진행시키게 하고, 여기서 필요한 시간은 테스트 코드를 작성하는 시간과 비용은 배가 된다.

단위테스트 작성

단위테스트 작성에 정규 업무시간을 따로 할당하지 마라.

1. 단위테스트는 코드 작성에 이미 녹아있는 것이지, 별도의 작업이 아님
2. 테스트 하지 않았다면 코드 작성을 완료한 것이 아니다.
3. 공식적인 작업 일정표에 작업을 올리는 것은 제품 오너가 삭제할 수 있는 권리를 준다는 것과 같다.
4. 단위테스트를 별개의 작업으로 일정표에 올리면 대부분 기능 구현자체와 맞먹는 규모로 시간표를 차지하게됨 → 낭비로 인식할 수 있음
5. 테스트 코드를 작성하지 않는 것은 이기적인 행위이다.소프트웨어 프로젝트는 팀워크이다. 특정 개발자에게 쉽고 당연한 것이 팀내 다른 개발자에게는 어렵고 당연하지 않은 것일 수 있다. 개인의 이기적 행동으로 팀에 피해를 끼치지 마라.
6. 시간이 없어 테스트 코드를 작성하지 않는 것은 자신의 작업 시간만 생각하고 전체 프로젝트에 관계된 다른 사람들의 시스템 테스트, 디버깅 시간을 생각하지 않는 행위이다.

레거시코드

레거시코드를 리팩토링 하는 것은 직소퍼즐을 푸는 것과 비슷하다.

몇몇 조각을 맞추는데 성공하면 전체 그림의 일부분을 그릴 수 있다. 도전적 자세로 문제를 해결하라

회사와 개발자들은 정기적으로 도끼날을 가는 시간이 낭비가 아니라는 사실을 이해해아한다.

기술적 실행관례

XP실행 관례뜰은 소프트웨어의 품질, 즉 일을 올바르게 수행하는 관점에서 피드백 루프를 단축시킬 수 있는 여러 방법들을 제공함

실행관례를 도입한다고 해서 프로젝트의 성공을 보증하지는 않음

부분적 실행관례는 없다.

부분적인 것은 도움이 되지 않는다. 실행관례를 꾸준히 실행하지 않고 부분적으로 하다가 안한다면 그것이 효과가 있는지 알 수 없다. 어떤 실행관례들이 정말 효과가 있는지 없는 지를 알기위해서는 그에대한 명확한 전략을 정의해야함

팀을 설득하기

실행 관례가 효율적이라면 팀 구성원들이 모두 그 가치를 납득해야함

어떤 가치를 중시한다고 말하는 것과 행동으로 보여주는 것은 다름

실행관례의 도입자체를 관리자나 팀 구성원들에게 설득하려 하지말고 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중해야함 → 빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 자동화되고 빠른 릴리즈

자동화된 테스트

자동화된 테스트가 있으면 코드를 수정한지 몇 분 만에 안심하고 상용릴리즈에 반영할 수 있음

QA검증을 피할 수 있음

QA검증은 수동으로 수행되기 때문에 규모가 커질수록 시간과 비용이 많이 들게 됨

테스트 코드가 있으면 이 부분을 해결할 수 있게 됨

즉, 자동화된 테스트는 실제 측정 가능한 비즈니스적 가치를 가져올 수 있음

테스트먼저

테스트코드를 먼저 작성하는 것에서 오는 장점들

1. 아이디어 생각
2. 피드백 루프 규모 축소
3. 과잉설계, 오버엔지니어링 방지
4. 모듈, 클래스, 함수를 구체적으로 정의하도록 강제할 수 있음

테스트 주도 개발의 가치

TDD는 테스트 먼저의 진화된 버전

TDD는 테스트 단위가 얼마나 작아야 하는지 강제하지 않음

1. 테스트가 코딩방향을 주도하면 복잡한 코드를 작성하는 것이 어려워짐
   1. 테스트로 규정된 부분만 작성하기 때문(요구사항만 만족시키면 됨)
   2. 설계가 커지는 것을 방지함
2. 정규적 설계리뷰 미팅보다 훨씬 빠르고 객관적
3. 살아 움직이는 문서역할을 함
4. 통합이라는 관점에서 테스트 실패시 모두에게 메일이 가므로 빠른 문제 해결도 가능함

길고 긴 여정

커리어와 동기에 대하여

결단과 집중

어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다.

어디로 가고싶은지 커리어 방향을 확신할 수 없다면, 모든 문들을 열어보기 시작해야함

기회가 나타날 수 잇는 상황들을 만들어 내야할 필요가 있음. 기회는 절대 스스로 찾아오지 않음

기회를 만들기 위한 활동

1. 새로운 기술을 배우고, 지식을 확장함
2. 지역 커뮤니티에 출석하거나 행사에 참여
3. 다른 개발자, 비즈니스 맨과 교류하기
4. 새롭게 배운 것, 지금 하고 있는 것들을 블로깅하기
5. 오픈소스 프로젝트에 참여함
6. 프로젝트를 만들고 공유함
7. 콘퍼런스에 참석함
8. 콘퍼런스에 연사로 나섬

투자로서의 일터

업무에 대한 기여를 생각하지 않고 개인적 이유로 이력서에 채워넣을 기술들과 방법론들만 쫓지는 말 것. 이는 매우 비윤리적인 행위임

어떤 이유에서든 직장을 떠날 떄 남는 것은 오로지 지식과 경험뿐이다. 항상 배우고 더 나은 소프트웨어 장인이 되는 것에 집중한다면, 돈만 쫓을 때보다 더 좋은 직장을 구할 수 있을 것이다.

자율성, 통달, 목적의식

돈은 충족되어야 할 기본 조건이며, 지식 노동자를 움직이는 것은 자율성, 통달, 목적의식이다.

1. 자율성 : 우리가 무엇을, 어떻게, 언제할 지 통제할 수 있는 상태
2. 통달: 더 나은 장인, 더 나은 사람이 되기위해 계속 배우고 진화하는 것
3. 목적의식 : 지금 하는 일이 무언가를 개선시킨다고 느끼는 것

실용주의 장인정신

실용주의

XP, TDD 같은 실행 관례를 절대 불변의 진리라고 믿어서는 안된다.

항상 더 나은 방법을 찾아가야 한다. 변화하지 않으면 정체된다.

소프트웨어 장인은 여러 도구들 중 가장 적합한 것을 꺼내 쓸 줄 알아야 한다.

단순한 설계를 위한 네가지 원칙

1. 모든 테스트 통과
2. 중복의 최소화 : 동작이나 설정에 중복이 있어서는 안됨
3. 명료성의 최대화 : 명료하고, 충분히 표현되고 일관되어야함
4. 구성요소의 최소화 : 메서드 클래스, 모듈의 수는 가능한 적어야 함

테스트 코드를 통과하는 코드를 먼저 작성하고, 추상화를 위해 코드를 리팩토링 할 때 단순한 설계와 SOLID원칙을따라 시도해야한다.

당장의 합당한 이유 없이 단지 미래를 대비해야한다는 모호한 전제로 초기부터 추상화를 하면 어플리케이션이 엉망진창이된다. → 복잡도가 매우 올라간다.

무조건적으로 범용코드를 추구해서는 안된다.

소프트웨어 장인으로서의 커리어

커리어 만들어나가기

1. 나의 커리어로부터 나는 무엇을 원하는가?
2. 그것을 위한 다음 단계는 무엇인가?
3. 이 일은 나의 커리어 방향과 합치하는가?
4. 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?
5. 그러한 투자에 대한 이익을 무엇인가?
6. 그러한 투자는 대략적으로 얼마동안 지속되어야 하는가?
7. 내가 되고자 하는 프로페셔널에 이르는데 이 일은 어떻게 도움이 되는가?
8. 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있는가?
9. 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치를 얻고 행복할 수 있는가?