[황동준] 5,6장: 영웅, 선의 그리고 프로페셔널리즘/ 동작하는 소프트웨어

1장/황동준.md

@@ -0,0 +1,39 @@
+## 1장 21세기의 소프트웨어 개발
+
+### 중요하다고 생각한 내용과 나의 생각
+
+31p
+
+매일 코드를 작성하는 일은 행복이었다. 그떄 이후로 아침에 눈을 뜰 때마다 오늘 할 일이 하고 싶어 기대되는 일만 하기로 스스로와 약속했다.
+
+→ 자신이 하고 싶어 하는 일을 하는 것은 정말 중요하다고 생각합니다.
+
+→ 여기서 생각난 질문이 있는데 여러분은 ‘자신이 잘하는데 재미가 없는 일’과 ‘자신이 잘하는 것 같지는 않지만 재밌는 일’이 있다면 어떤 것을 선택하실 건가요??
+
+32p
+
+이제 개발자들은 개발뿐만 아니라 다음과 같은 여러가지를 할 수 있어야한다.
+
+- 고객과 대화하기
+- 테스트/배포 자동화하기
+- 전체 비즈니스에 영향을 미칠 기술 선정하기
+- 지리적으로 분산된 팀들과 협업하기
+- 고객을 도와 필요한 작업을 정의하기
+- 우선순위 선정하기
+- 진척 상황 보고하기
+- 변경사항과 기대일정 관리하기
+- 잠재 고객 및 파트너에세 제품 소개하기
+- 사전 영업 활동 지원하기
+- 개발 일정과 비용 산출하기
+- 채용 면접하기
+- 아키텍처 설계하기
+- 비기능적 요구사항과 계약 조건 검토하기
+- 사업 목쵸 이해하기
+- 주어진 여건에서 최적의 결정하기
+- 새로운 기술 주시하기
+- 더 나은 업무 방식 찾기
+- 고객에게 가치 있는 상품이 전달되고 있는지 고민하기
+
+소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시정른 지나갔다.
+
+→ 다양한 역량을 갖춘 개발자가 되어야 계속 발전하는 산업 속에서 살아남을 수 있을거라고 생각합니다.

2장/황동준.md

@@ -0,0 +1,94 @@
+## 2장 애자일
+
+### 중요하다고 생각한 내용과 나의 생각
+
+_38p_
+
+애자일은 절자적인 부분과 기술적인 부분 두 종류로 나눌 수 있다.
+
+**절차적인 관점에서의 애자일**
+
+팀과 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들 규정
+
+- 회의 방식
+- 구성원 각각의 역할
+- 요구사랑 파악 방법
+- 작업 진척 속도 파악 방법
+- 점진적/반복적으로 일할 때 취하는 방식
+- 진행 상황을 개발팀 밖의 관계자에게 전달하는 방식
+- 비즈니스 피드백 방식
+
+⇒ 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중
+
+결론적으로 **팀이 올바른 목표를 향해 진행 중인지 확인**
+
+**기술적인 관점에서의 애자일**
+
+개발, 확장, 유지보수, 제품을 출시하면서 겪는 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드
+
+ex) TDD, 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등
+
+결론적으로 **목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게** 함
+
+**애자일의 의미**
+
+- 민첩하다고 해서 애자일을 실행하고 있는 것은 아니다.
+- 빠르고 짧은 피드백 루프에 대한 것
+  - 더 빨리, 더 짧게 피드백 루프를 만들수록 애자일해진다.
+- 애자일은 문제 자체를 해결해주지 않는다 문제를 드러나게 한다.
+- 특정 기능의 상용화 가능성을 일찍 알게 된다면 투자에 대한 위험도 줄일 수 있다.
+
+→ 애자일 방식을 채택한 이유에 대해 정확하게 이해하며 이번에 진행하는 밋업 프로젝트에 어떻게 적용하면 좋을지 생각할 수 있게 도움을 주는 내용이었습니다. 문제를 빠르게 찾아내는 것이 목표에 빠르게 다가가는 것에 큰 도움이 될것이라고 생각합니다.
+
+→ 하지만 잘못된 피드백 주기 선정으로 사소한 문제를 해결하는 과정에 시간을 뺏기면서 오히려 목표에 다가가는 길이 흐려지게 되면 안된다고 생각합니다. 적절한 애자일 주기를 선정하는 방법은 무엇이 있을지 궁금합니다.
+
+_40p_
+
+그저 계획에 맞춰서 지시 받은 일만 하는 것이 아니아, 비즈니스와 고객 가치 창출에 개발자들이 직접 함여하는 것도 매우 중요하다고 주장한다.
+
+→ 비즈니스 임팩트를 지닌 코드를 작성하는 것이 정말 중요하다고 생각합니다.
+
+_41p_
+
+기업들은 단순히 특정 분야만이 아닌 다방면에 걸친 저문가를 찾고 있다. 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다.
+
+_42p_
+
+**애자일의 12가지 법칙**
+
+1. 가치 있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.
+2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다.
+3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다.
+4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.
+5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 자원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다.
+6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 바업은 얼굴을 마주보고 대화하는 것이다.
+7. 프로젝트 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다.
+8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다.
+9. 기술적인 탁월함과 좋은 설게에 대한 지속적인 관심은 기민함을 높인다.
+10. 단순함, 즉 하지 않아도 되는 일은 최대한 하지 않아야 한다.
+11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.
+12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다.
+
+_44p -_ 안타깝게도 ‘애자일’이 과거에 일하던 방식의 그저 새로운 이름이 된 듯 싶다.
+
+_45p -_ 이러한 변화에도 불구하고 좋은 소프트웨어를 빠르게 공급하지 못하고 있는 것이 현실이다.
+
+→ 이번 밋업 프로젝트에서 TDD 방식을 도입해 애자일 방식으로 개발 및 프로젝트를 진행할 예정인데, 위와 같이 기본 방식의 그러 새로운 이름이 되지 않게 노력해야 겠다는 생각이 들었습니다.
+
+_48p_
+
+애자일의 모든 절차들에는 기술적 탁월함이 전제되어 있다.
+
+도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다.
+
+→ 기술적 탁월함을 갖추기 위해 노력해야겠다는 생각이 들었습니다.
+
+_53p_
+
+절차와 결과물 둘 다 중요하다는 점을 강조하기 위함이다.
+
+_54p_
+
+소프트웨어 장인정신은 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다. → 일을 올바르게 수행하도록 돕는다.
+
+→ 앞으로 이 책을 읽으면서 소프트웨어 장인정신을 품기위해 꾸준히 노력해야 겠다고 생각했습니다.

5장/황동준.md

@@ -0,0 +1,26 @@
+## 5장 영웅, 선의 그리고 프로페셔널리즘
+
+### 중요하다고 생각한 내용과 나의 생각
+
+107
+우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이래하려 하지 않았고, 다른 대안을 제시하지도 않았다. 고객을 만날수도 없기는 했지만, 요구사항에 대해서 질문을 하지도, 실행할 수 없다는 이야기도 하지 않았다. 우리는 그냥 주어진 환경을 있는 그대로 두고, 무작정 일을 밀어 붙였다. 그때는 그것이 프로페셔널이라고 생각했다.
+우리가 노예처럼 일할 때, 영업, 비즈니스 부서 사람들은 항상 정시에 퇴근해 가족과 시간을 보냈다.
+-> 그저 순응하는 것이 아닌 나 자신이 할 수 있는 정도를 파악하고 함께하는 팀원에게 이야기하는 것도 정말 중요하다는 생각이 들었습니다.
+
+114
+개발자들이 일정이 너무 짧다고 이야기를 해도 관리자들이 그냥 흘려 들을 때가 많다. 관리자와 개발자 간에 협상이 되어야 하지만 협상 기술이나 제대로 된 근거 자료가 부족해서 개발자들이 압ㄺ에 그냥 굴복하고 말 떄가 부지기수다
+개발자들은 논쟁하고 싶디 않아서 또는 긍정적인 태도를 보여주고 싶어서 "최선을 다해 노력하겠다"라고 대답해버린다.
+-> 평소에 소통하는 능력을 어느정도 갖추고 있다고 생각하는데 취업시장에서 이러한 점들을 강점으로 어필하면 좋을거 같다는 생각이 들었습니다.
+
+116
+항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다.
+모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다.
+-> 매우 중요하다고 생각합니다.
+
+118
+무언가 약속은 할 수 없더라도 문제 대응이 어떻게 되고 있는지 진척 상황을 계속 공유해야한다.
+
+122
+최대한 이른 시점에 붉은 깃발을 세워서 뭔사 잘못되고 있음을 지적하고 팀과 다른 사람들로 하여금 현실적인 다른 대안을 찾아 나설 수 있도록 해야 한다.
+-> 현재 진행하고 있는 밋업 프로젝트에서 애자일 방식으로 프로젝트를 진행하고 있는데 불확실성이 큰 요구사항에 대해 살짝 어려울거 같다는 이야기는 했지만, 해보겠다고 했는데, 이런 상황에서 문제가 생긴다면 빠르게 전해야겠다고 생각이 들었습니다.
+-> 혹시 이렇게 할 수 있을지 없을지 잘 판단이 안서는 요구사항에 대해서는 어떻게 대처하는 것이 좋은지 궁금하기도 합니다.

6장/황동준.md

@@ -0,0 +1,25 @@
+## 6장 동작하는 소프트웨어
+
+### 중요하다고 생각한 내용과 나의 생각
+
+126
+전통적인 관리자들과 비즈니스 컨설턴트들이 절차와 문서의 중요성을 아무리 강조하고 싶어하더라도 소프트웨어 프로젝트에는 소스 코드 그 자체만큼 중요한 것은 없다. 나머지는 모두 부차적이다.
+
+128
+코드는 기계장치라기보다는 유기물이다. 코드는 정원처럼 지속적인 유지보수가 필요하다.
+
+130
+나쁜 코드를 다루어야 하는 기업은 경쟁력이 떨어지게 된다.
+
+132
+기술적 부채를 줄이는 것은 기존의 더러운 것을 청소하는 것이다. 이미 깨끗한 상태를 더럽혀서는 안된다. 즉 어떤 상황이든 추가 코드로 인해 기술적 부채가 더해져서는 안 된다. 하지만 이 개발자는 그렇게 해도 된다고 생각하고 있었다.
+-> 해당 개발자처럼 잘못된 이해와 지식에 확신을 가지는 것에 주의해야 겠다는 생각을 했습니다.
+
+133
+빨리 하는 것과 허술한 것은 다르다. 우리의 결정이 어떤 의미이고 어떤 결과를 가져오는지 우리는 잘 이해하지 못할 때가 많다.
+
+137
+테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다. 단위 테스트는 코드가 제대로 구현되었는지 확인하는 가장 좋은 방법이다.
+테스트 주도 개발을 접해보지 못한 보통의 개발자들은 주어진 요구사항에 맞춰 동작할 거라고 '기대만 하는' 상태로 코드를 작성하고는 바로 다음 요구사항의 구현에 들어간다. 즉 제대로 된 테스트 없이 코딩을 마무리한다. 기능 구현이 완료되었다고 할 수 있으려면 반드시 테스트까지 되어야 한다.
+-> 현재 TDD 방식으로 개발을 진행하고 있는데 생각보다 쉽지 않고, 함께하는 팀원은 어려울거 같다고 해서 일단 저만 진행하고 있는데 이 글을 읽고, 다음 스프린트에서 요구사항 정의와 레드 단계의 테스트 코드를 작성하여 팀원도 같이 TDD를 할 수 있게 해야겠다는 확신이 생겼습니다.
+-> 그리고 필자가 작성한 것처럼 테스트 코드를 작성하는 것까지 기능구현의 단계로 생각해여 개발해야 겠다는 생각 또한 들었습니다.