서적/소프트웨어 장인

[CHAPTER 8] 길고 긴 여정, Part1 이념과 태도 마무리

Part1 이념의 태도의 마지막, 길고 긴 여정이다. 커리어가 중심이 된 주제로 저자의 어린 시절에 대한 이야기로 시작된다. 브라질 어느 십대 소년의 이야기 브라질 시골, 평범한 집안의 십대 소년이었던 당시의 나는 런던에서 사는 것이 꿈이였다... 부모님은 나의 이런 꿈에 대해서 길게 대화하는 것을 피했다... 가능성이 거의 제로에 가까웠기 때문이다... 설령 영국으로 간다고 한들... 세계 유수 대학을 졸업한 인재들 사이에서 나의 이력서는 보잘 것이 없었다. 누구나 가고 싶은 기업들이 있다. 이력서가 화려한 인재가 많이 지원할 것이다. 그런 인재들 사이에서 경쟁을 해야한다면, 그들에 비해 나는 보잘 것이 없을거다. 그럼에도 불구하고 나는 결심했다. 고등학교를 졸업할 때 진로를 정했다... 최선의 선택은..

[CHAPTER 7] 기술적 실행 관례

지금까지 읽은 내용으로 기술적 실행 관례가 얼마나 중요한지 알 것이다. 그렇지만 관리자 입장은 비지니스로 체감을 못하는 경우가 많다. 이번 챕터에서는 기술적 실행 관례를 도입할 때 동료나 관리자를 설득하는데 도움이 될 내용으로 구성되어있다. 올바르 일 vs 올바른 실행 애자일 방법론은 빠르고 짧은 피드백 루프를 제공하여 우리가 올바른일을 실행하고 있는지 점검하도록 도와준다... 이러한 실행 관례들이 애플리케이션의 품질 사애가 어떠한지는 알려주지는 않기 때문에 이 부분에서 문제가 된다. 품질 상태가 비즈니스의 발목을 잡을 정도로 나쁘다는 사실을 깨달았을 때는 이미 많이 늦었을 가능성이 높다. 코드가 망가지고 있는지를 비즈니스 담당이 눈치채기는 대단히 어렵다, 반면에 개발자가 그것을 숨기는 것은 너무나 쉽다..

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

소프트웨어 프로젝트가 실패하는 원인은 아주 다양하다. 잘못된 비즈니스 의사 결정, 우월한 경쟁자, 잘못된 프로젝트 관리 등 매우 많다. 소프트웨어 프로젝트에는 중요한 일들이 많아서 덜 중요해 보이는 것들이 있다. 어떤 조직에서는 유능한 관리자, 깊은 계층구조, 마이크로 매니지먼트, 엄격한 절차, 대량의 문서들이 프로젝트의 성공을 좌우한다고 생각한다. 많은 조직들이 소프트웨어 개발을 공장 라인으로 취급한다. 직접 경험한 SI 업계가 대다수 이런식으로 많이 진행한다. 이러한 조직에서 훌륭한 개발자를 끌어들이고 유지할 수 있는 경우는 거의 없다. 그저 그런 개발자들의 손에 전체 비즈니스를 맡기게 된다. 어떤 프로젝트에서는 개발자만 70~80명 있었는데, 대다수가 그저 그런 개발자였다. 함수선언도 못하던 10년..

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

이번 챕터에서는 저자의 안 좋은 프로젝트 경험을 이야기하면서 시작한다. 그 프로젝트는 내가 합류하기 10년도 더 전에 시작되었다... 프로젝트는 전형적인 폭포수 방식으로 진행되었다. 2년 반 동안 나는 고객을 한번도 만난 적이 없다. 나뿐만 아니라 개발자 중에서 고객과 이야기를 해본 사람은 없었을 것이다... 회사는 상파울루에 있었지만 100킬로미터 떨어져사는 개발자들까지 채용해서 통근 버스를 제공했다. 나는 새벽 5시 반에 오는 통근버스를 타기위해 새벽 5시 정각에 일어났다... 그 당시에는 야근이 흔해 퇴근 통근 버스를 놓쳐 대중 교통을 이용하면 자정이 훨씬 지나서야 집에 들어왔다. 상황은 점점 악화되었고, 어쩔 수 없이 자가용으로 운전하여 출퇴근했다... 회사는 통근버스를 이유로 출퇴근 비용을 보조..

[CHAPTER 4] 소프트웨어 장인의 태도

오래 전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면, 그것은 그동안 배운 것이 없다는 뜻이다. 소프트웨어 장인이라면 스스로가 만든 것에 애정과 자부심을 가져야 함은 기본이다. 계속해서 더 나은 프로페셔널이 되기 위해 일평생 정진해야 한다 챕터 처음에 나오는 문구다. 누구라도 공감이 될거다. 동료와 같은 시기에 같은 직위로 입사해 1년 정도 같이 일했다... 동료에게 요즘 일하는 것이 어떤지 물었더니 "나는 정말 이 회사가 싫다. 진절머리 나는 회사다."라는 대답에 적잖이 놀랐다. 나는 당시 ,정말 즐겁게 일하고 있었기 때문이다... 커리어의 주인이 누구라고 생각하느냐고 물었다. 동료는 내 질문을 잘 이해하지 못한 듯 했고... 같은 회사, 같은 프로젝트에서 누구는 즐겁게 일하고 배우고, ..

[CHAPTER 3] 소프트웨어 장인정신

시작부터 아래의 내역은 소프트웨어 장인정신이 아니라고 한다. 아름다운 코드 테스트 주도 개발 스스로 조직화된 개발 그룹 특정 기술 또는 방법론 자격인증 종교 개발자라면 중요하다고 생각할 요소인데 아니란다. 도대체 소프트웨어 장인정신의 실체는 무엇일까? 드디어 이 주제에 대한 언급이 시작되며 여러가지 정의를 언급한다. 위키피디아에서의 정의 '소프트웨어 장인정신'은 소프트웨어를 개발할 때 개발자 스스로의 코딩 스킬을 강조하는 개념이다...(생략) 저자는 이러한 정의가 굉장히 딱딱하고, 핵심 의미를 담아내지 않는다며 좋아하지 않는다고 한다. 좀더 주관적인 정의 소프트웨어 장인정신은 마스터가 되어가는 긴 여정이다. 소프트웨어 장인정신은 소프트웨어 개발자가 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새..

[CHAPTER 2] 애자일

2001년 2월, 당시 방대한 문서 작업을 기반으로 하는 소프트웨어 개발 방법론에 어떤 대안이 있을지 토론하기 위한 모임에서 애자일 매니페스토가 창안되었고 애자일 연합이 만들어졌다. 애자일이란 용어를 자주 접하는데, 많은 기업에서 애자일을 쓴다는 말이 있고 하니, 지금까지 경영 & 경제학에서 생긴 개념으로 알았다. 개발 방법론에서 나온 용어라니 기분이 생소하다. 애자일 애자일은 어떤 단일 개념이 아니다, 애자일은 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합이다. 애자일은 절차적인 부분과 기술적인 부분의 두 종류로 나눠진다. 절차적인 관점에서의 애자일 팀의 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들을 규정한다. 회의 방식 구성원 각각의 역할 요구사항 파악 방법 작업 진척 속도 파악 방법 점..

[CHAPTER 1] 21세기의 소프트웨어 개발, Part1 이념과 태도 시작

저자는 1990년대 복잡하고 난해한 코드로 남이 이해 못하면 실력이 좋다고 한다. 그리고 7년차에 '숙련된 개발자'가 아닌 '소프트웨어 아키텍트'로 커리어가 전환이 되면서 겪는 이야기를 한다. 아키텍처 팀은 개발자들이 따라야만 하는 디자인 패턴 북을 만드는 막강한 권한이 있다 (생략) 아키텍트는 비즈니스 분석가와 대화하며 요구사항의 기능적/비기능적 요소들을 이해하고 (생략) 요구사항과 고객 환경이 어떻게 바뀔지 무당이 점치듯 추측해야 한다. 예측하는 것은 거의 불가능했다. (생략) 시스템이 커지더라도 부작용이 적을지 고민해야 했다. 이에 대한 대응책이 추상화를 하고, 요소마다 디자인 패턴을 적용하는 것이다. 오늘날에는 그런 방식을 오버 엔지니어링이라고 한다. 어리석지만 그 당시에는 아키텍트의 혜안이라고 ..