Messi Lover Messi Lover

1장 운영 환경의 현실 일단 개발자들의 잘못된 개발 태도를 꼬집고 시작한다. 내부 테스트와 qa를 통과하는 것에 초점을 맞춰 개발하면 안 된다는 것이다. 내부 테스트나 qa를 통과하는 것은 찐 목표의 과정일 뿐이다. 찐 목표는 바로 사용자가 서비스를 원활히 이용하게 하여 수익을 내는 것이다. 내부 테스트나 qa를 통과하는 것은 사용자가 서비스를 원활히 이용하는 것을 위한 과정일 뿐이어서, 이것들을 통과한다고 해도 사용자가 서비스를 원활히 이용하지 못하는 상황이 발생한다면 수익을 낼 수 없게 될 확률이 크다. 사실 이건 '목이 마르면 물을 마셔야 합니다.'처럼 당연한 소리이다. 당연한 소리가 이처럼 강조되는 것은 '모두가 알고는 있지만 실천하기는 어려운 이야기'라고 이해하면 되지 싶다. 즉, '아 그렇구나..

Gradle의 task outcome labels란? Gradle에서는 빌드를 여러 단계로 세분화할 수 있는데, 이 세분화 단위를 task라고 한다. 빌드도 하나의 task이다. gradle에서 빌드를 실행하면 빌드 내에 포함된 여러 task들이 실행되는데, 각 task는 실제로 실행이 될 수도 있고 그렇지 않을 수도 있다. 실제로 실행됐는지 나타내는 상태를 task outcome label이라고 한다.task outcome labels의 종류task outcome label은 아래 5개 종류로 구성되어 있다. label 이름task 실행 여부비고No label (or EXECUTED)O혹은 해당 task가 의존하고 있는 task가 실행됨.UP-TO-DATEXtask의 현재 입력이 이전 입력과 같아서 현..

소프트웨어 장인으로서 지녀야 할 태도와 커리어 방향 이번 장에서는 15장까지 이야기했던 것들을 종합한다. 역시 소프트웨어 장인에게는 '직무에 대한 열정'이 가장 중요하다는 것을 다시 한번 강조한다. 그리고 소프트웨어 장인은 자신의 커리어를 주체적으로 관리할 줄 알아야 한다. 이직이 필요한 이유는 매 시기마다 다르다. 어떤 때는 보상을 위해 어떤 때는 개인적인 시간을 위해 이직한다. 외부 요인에 의해 이유를 만들지 말고 주체적으로 판단해야 한다. 나에게 소프트웨어 개발이란 무엇일까? 309p~310p에는 소프트웨어 개발이 얼마나 숭고한 일인지를 설명한다. 소프트웨어가 바꾸는 세상을 설명하면서 다음 세대 개발자를 위해야 하고 소프트웨어 산업의 진흥을 위해야 한다고 하는데, 사실 크게 와닿지는 않았다. 마치 ..

실용주의 실천의 필요성 이번 장에서는 소프트웨어 장인에게 실용주의가 얼마나 중요한지를 설명한다. 오버 엔지니어링을 지양하고 요구 사항들에 충실히 집중하는 핏(?) 엔지니어링을 지향해야 함을 어필한다. 나를 포함하여 많은 개발자들에게 일침을 놓는다. 개발자들은 종종 자신의 개발 실력을 뽐내고 싶거나 개인적인 뿌듯함(혹은 성취감)을 느끼기 위해 투머치하게 개발하곤 한다. 조직의 목표에 영향을 끼치지 않는다면야 이런 모습들은 큰 문제가 되지 않겠지만 현실은 문제가 되는 경우가 많다. 소프트웨어 프로젝트는 우리를 위한 것이 아니다 소프트웨어 프로젝트는 공동의 산물이다. 내 입맛대로 만들거나 수정하는 것을 지양해야 한다. 다른 시각과 다른 방식을 받아들일 줄 알아야 한다. 소프트웨어 개발 능력에 인성 능력도 포함..

기술적 변화 방법 이번 장에서는 기술적 변화를 위해 동료들을 설득하는 방법에 대해 설명한다. 이번 장을 읽다 보니 꼭 기술적인 변화의 설득에만 적용되는 것이 아닌 모든 설득에 적용되는 것 같다는 생각이 들었다. 타인을 설득하는 것은 모두 어렵다. 타인을 설득하기 위해선 지피지기가 필요하다. 우선 나를 알아야 한다. 내가 무엇을 설득하고자 하는지부터 알아야 뭘 할 수 있을 테니 말이다. 그다음엔 상대방이 설득될 수 있는 상태인지 확인해야 한다. 상대방이 설득될 수 없는 상황이라면 설득이 소용없다. 나도 상대방도 모두 준비가 되었다면, 이제 설득 방법을 정하면 된다. 상대방의 시각과 눈높이에 맞추는 것이 중요하다. 물건을 파는 것과 비슷하다. 고객의 입장에서 설득력이 있어야 물건을 사든 의견을 받아들이든 할..

배움의 필요성 이번 장에서는 개발자에게 열정을 불어넣어 주고 자기 계발을 유도(?)하는 방법들에 대해 설명한다. 그리고 개발자들 스스로도 이 방법들을 익혀야 한다는 점을 강조한다. 잡으려 할수록 멀어지고 신경 쓰지 않으면 오히려 잡히는 진리가 이번에도 통하는 것 같다. '열정적이어야 한다! 자기 계발해라!'라고 명령하면 오히려 잘 안 듣는다. 오히려 자유를 부여하면서 간접적으로 유도하면 의도한 결과를 얻을 확률이 더 높을 수 있다. 리더 입장에서는 쉽지 않은 말이긴 한데, 회사를 위해서라면 그래도 어쩔 수 없다. 배움에 필요한 자세 개발자들도 스스로 배움의 자세를 익히고 실천해야 한다. 그래야만 소프트웨어 장인에 한걸음 다가설 수 있다. 동료들과 함께 해도 좋다. 단, 동료들에게 강요하면 안된다. 동료들..

낮은 사기의 결과와 해결 방법 이 장에서는 개발자들의 사기가 프로젝트와 회사에 어떤 영향을 미치는지, 그리고 맥 빠진 팀에 다시 열정을 불어넣으려 할 때 소프트웨어 장인이 어떤 도움을 줄 수 있는지를 설명한다. 업무에 대한 동기가 부여되지 않으면 그 업무는 비효율적으로 진행된다. 그러면 동일한 결과를 얻는 데에 훨씬 많은 비용을 치르게 된다. 직원들의 사기를 잘 관리하지 않으면 회사는 불필요한 비용을 지출하게 된다. 어떠한 직군이라도 그렇겠지만, 개발에 관해서는 특히 더 그런 것 같다. 개발자들의 사기를 관리하는 간단한 방법은 바로 '소프트웨어 장인 수혈'이다. 소프트웨어 장인은 기술적으로도 도움을 줄 수 있겠지만 동료 개발자들에게 열정을 주입시켜 줄 수 있는 능력도 탁월하다. 역시 돈이 해결해 주는 것..

탄수화물 테스트 주도 개발은 짜릿하다. 지루하고 지난한 '테스트 코드 작성'이라는 고된 시간을 잘 견뎌내고 얻게 되는 든든함은 심신에 평안을 가져다준다. 테스트 코드를 완성할 때 까진 비지니스 코드를 '잘' 작성하는 것에 신경을 쓰지 않는다. 테스트 코드가 통과되는 것에만 집중한다. 비지니스 코드가 더러워져도 문제없다. 테스트 코드가 '잘' 완성되면 더러워진 비지니스 코드를 매우 빠르게 씻겨낼 수 있으니 걱정하지 않는다. 테스트 코드를 '잘' 완성하면 그 때부터는 더러워진 비지니스 코드를 과감하게 리팩토링 한다. 리팩토링한 것들을 직접 검증할 필요는 없다. 잘 완성된 테스트 코드가 사람의 테스트와는 비교하지도 못할 빠른 속도로 코드가 잘 리팩토링 됐는지 검증해 줄 것이다. ‘리팩토링 -> 테스트 코드 실..