소프트웨어 장인 - Part 1 : 이념과 태도 (5 ~ 6장) (Software Craftsman)

[이전 장]

https://yrok.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%9E%A5%EC%9D%B8-Software-Craftsmanship-Part-1-%EC%9D%B4%EB%85%90%EA%B3%BC-%ED%83%9C%EB%8F%84-3-4%EC%9E%A5

소프트웨어 장인 - Part 1 : 이념과 태도 (3 ~ 4장) (Software Craftsmanship)

[5장] 영웅, 선의 그리고 프로페셔널리즘

'우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이해하려 하지 않았고 다른 대안을 제시하지도 않았다. 우리는 일을 잘못하고 있었다.' 

저자의 말이 또 뼈를 때렸다. 나는 그동안 일을 어떻게 해왔는지 되돌아보니... 전혀 프로답지 못 했다.

 

[‘아니오’라고 말하는 방법 배우기] - p108

릴리즈 버전에 버그라... '신뢰'는 별게 아니다. 늘 한결같이 정상적으로 동작하면 된다. 하지만 그만큼 지키기 어려운 것도 없는 것 같다.

 

<재앙의 기억> - p111

테스트를 수동으로 한다는 것은 안하는 것과 같다. 처음에는 열심히 테스트를 하게 될지 몰라도 점차 귀찮아지기 마련이다. 그렇다보면 테스트 코드조차도 작성 안하게 된다. 테스트를 안하는데 코드를 작성하겠는가...? 이게 바로 재앙으로 가는 길이다.

 

<교훈> - p114

영웅은 아무나 될 수가 없다. 아니. 누구도 되지 못 한다고 생각해야 한다. 아닐땐 아니라고 해야만 한다. 하지만 그럴 용기가...ㅠ

 

<프로답게 행동하기> - p114

그저 실망시키지 않기 위해 말하는 ‘네’는 거짓말에 지나지 않는다고 했다. 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이다. - 열정적인 프로그래머, 차드 파울러

소통을 통해 일정을 조정해야만 한다. 빠르면 빠를수록 좋다. 빠른 피드백을 통해 일을 할 필요가 있다.

저자는 다음과 같이 프로다운 행동에 대해 말했다.

1. '빡빡한 일정을 다루는 가장 좋은 방법은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다. 최대한 이른 시점에 문제제기해야 한다.'

2. '자신감을 갖는다는 것은 모든 기능이 테스트되고 실제 상용 서비스와 최대한 비슷한 환경에서 충분히 검증된 상태로 소프트웨어가 전달되어야 함을 의미한다.'

3. '다툼을 피하지 말고 부딪혀서 어려운 결정을 내릴 수 있어야 한다.'

 

[대안 제시] - p116

프로답게 문제해결만을 바라보고 행동하자.

 

<뜻밖의 실용적인 대안> - p119

저자는 프로젝트 도중의 인력 충원은 상황을 더 악화시킨다고 말한다.

예전(~3년)에는 인력이 많으면 많을수록 좋다고 생각했지만, 근래 들어서는 저자의 말에 동의한다.

인력 충원은 정말 물리적으로 인력이 부족하여 생긴 문제인가에 대해 충분한 검토 뒤에 이루어져야 한다.

 

[깨어 있는 관리자] - p121

관리자와 개발자는 한 배를 탄 동료이다. 서로 솎이는 상황이라면 그 배가 과연 목적지에 제대로 도착을 할 수 있을까...?

[6장] 동작하는 소프트웨어

[동작하는 소프트웨어만으로는 부족하다] - p127

저자의 말에 백번 동의한다. 동작'만' 하는 소프트웨어는 똥이다. 라고 과격하게 말하고 싶지만... 동작만 하는 소프트웨어는 완성이 아니라 그때부터가 시작이다. 테스트-리팩토링의 무한 반복!

 

[정원 돌보기] - p127

이 책에서 가장 기억에 남는 부분이다.

'프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 더 가깝다. - 실용주의 프로그래머

코드는 기계장치라기보다는 유기물이다. 코드는 정원처럼 지속적인 유지보수가 필요하다. 기본적이고 정기적인 유지보수만으로도 정원을 훌륭하게 가꿀 수 있다. 오래 방치할수록 다시 보고 즐길 수 있는 상태로 되돌리는데 더 많은 수고가 필요하다.'

그 동안에 프로그래머를 건축가와 가장 비슷하다고 생각했는데 '정원사'에 가깝다고 책을 읽고나서 깨달았다.

이 부분에 대해서 대학 친구와 열띤(?) 토론을 한 적이 있다. 그 친구는 '정원사'에 동의하지 못 하였지만 그 토론을 통해 깨달은 게 한가지 더 있다.

프로그래머는 때때로 '건축가'와 '정원사'를 넘나 들어야 한다는 것을.

 

[보이지 않는 위협] - p129

보이지 않는 위협에 대비하는 방법은 철저한 '관리' 뿐이다.

 

<자신이 만든 소프트웨어에 인질이 되는 상황> - p130

'프로'라면 코드의 품질도 책임져야한다.

 

<평범한 개발자가 아닌 장인을 고용하라> - p131

동작만 하는 소프트웨어를 만드는 개발자가 아닌 품질이 보장된 '프로'이자 '정원사'인 개발자가 필요하다.

 

[시간에 대한 잘못된 인식]

<기술적 부채에 대한 이야기> - p132

'기술적 부채를 줄이는 것은 기존의 더러운 것을 청소하는 것이다. 이미 깨끗한 상태를 더렵혀서는 안 된다. 즉 어떤 상황이든 추가 코드로 인해 기술적 부채가 더해져서는 안 된다. 백로그의 기술적 부채 항목을 보고 언젠가 고칠 거라고 생각들을 하지만 그런 일은 절대 일어나지 않는다.'

책을 읽으면 읽을수록 저자의 팩폭에 온몸이 만싱창이가 되는 것 같다... 일하다보면 안다. 절대로 나중이란 없다...

 

<우리는 올바른 것을 하길 원한다> - p133

빨리만 해야하는 것이 아닌 올바르게, 제대로 빠르게 해야한다. 빨리한다고 해서 놓치는게 있으면 안된다.

 

<시간적 여유가 없는 바쁜 팀> - p135

'"이제 문제의 원인이 밝혀졌는데, 해당 부분에 대한 단위 테스트를 만드는 게 바람직하지 않을까요?"

왜 단위 테스트 코드를 애당초 작성하지 않고 반복해서 디버깅하고 있는 건지 따지고 싶었다.'

... 나를 비롯한 많은 개발자들이 깨달음을 얻었으면 한다...

 

<내겐 없는 여유, 다른 누군가에겐 있는 여유> - p136

언제까지 수동화된 테스트환경에서 디버깅할 것인가... 미루지 말고 여유를 챙길 수 있도록 노력하자.

 

<단위 테스트 작성은 별개의 업무인가> - p137

'절대 그래서는 안 된다. 첫 번째로, 단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다. 테스트 주도 개발을 접해보지 못한 보통의 개발자들은 주어진 요구사항에 맞춰 동작할 거라고 '기대만 하는' 상태로 코드를 작성하고는 바로 다음 요구사항의 구현에 들어간다. 즉 제대로 된 테스트 없이 코딩을 마무리 한다. 기능 구현이 완료되었다고 할 수 있으려면 반드시 테스트까지 되어야 한다.'

이쯤되면 업무 프로세스를 검토해봐야 하는 게 아닌가 싶다... 나는 정말 제대로 맞게 일을 하고 있는 걸까?

 

<효율적인 시간 활용> - p140

좋은 개발 환경 또한 뒷받침되어야 한다. 장인은 도구를 가리지 않는다고 하지만 엉터리 도구로 일을 하지는 않을 것이다.

 

<몇 개월 후>

-

 

[레거시 코드] - p141

태도는 큰 차이를 가져올 수 있는 작은 요소다. - 윈스턴 처칠

 

<태도의 변화> - p142

'무언가가 마음에 들지 않는다면 바꾸어라. 그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라. - 마리 엥겔브레이트

무언가 나아지길 원한다면 그에 맞는 행동을 취해야 한다.

레거시 코드로 일하는 것은 거대한 직소 퍼즐을 푸는 것과 비슷하다. 즉 점진적으로 기존 코드에 대한 테스트 코드를 작성하면서 코드에 대한 이해도를 높이고 리팩토링을 해나간다. 재미있고 도전적인 문제로 바라 보는 것이다. 나라면 더 잘 만들 수 있는가?라고 스스로에게 물어보아야 한다.'

레거시 코드를 바라보는 나의 태도를 고치도록 노력해야겠다... :)

 

<고객과 개발자 모두의 만족>

-

 

[요약] - (책 발췌)

1. 프로답게 행동하고 고객을 만족시킨다는 것이 고객의 요구사항을 모두 받아들이라는 뜻은 아니다. 고객이 무엇을 가장 필요로 하는지, 그것을 얻기 위한 최선의 방법을 도우며 조언하는 것이 우리의 일이다.

2. 고객은 문제를 들고 프로페셔널을 찾아 간다. 프로페셔널들이 그들의 경험과 지식을 활용해 그 문제를 다룰 방법들에 어떤 것들이 있고 각각의 장단점은 무엇인지를 알려주길 기대한다.

3. 고객의 결정은 프로페셔널이 제공한 충분한 정보와 이해를 기반으로 이루어져야 한다. 프로페셔널이 생각하기에 올바르지 않은 결정을 고객이 밀어붙이려 한다면 당연하게도 프로페셔널은 그것을 거부한다. 우리도 그래야 한다.

4. 소프트웨어가 얼마나 빨리 변경 또는 개선될 수 있느냐에 따라 비즈니스의 민첩성이 드러난다. 소프트웨어의 품질이 좋지 않을수록 변경하기가 더 어려워진다.

5. 회사와 개발자들은 정기적으로 도끼날을 가는 시간이 낭비가 아니라는 사실을 이해해야 한다. 바로 그것이 시간을 절약하고 끊임없이 빨리 움직일 수 있는 최선의 방법이다.

 

[다음 장]

https://yrok.tistory.com/entry/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%9E%A5%EC%9D%B8-Software-Craftsmanship-Part-1-%EC%9D%B4%EB%85%90%EA%B3%BC-%ED%83%9C%EB%8F%84-7-8%EC%9E%A5

소프트웨어 장인 - Part 1 : 이념과 태도 (7 ~ 8장) (Software Craftsmanship)