[황동준] 7,8장 : 기술적 실행 관례, 길고 긴 여정

7장/황동준.md

@@ -0,0 +1,41 @@
+## 7장 기술적 실행 관례
+
+### 중요하다고 생각한 내용과 나의 생각
+
+152p
+어떤 실행 관례를 도입한다고 해서 프로젝트의 성공을 보증하지 않는다. 사람은 우리가 원하는 대로 행동하도록 프로그램할 수 있는 기계가 아니다. 단순히 준수할 실행 관례를 공표했다고 해서 기대하는 결과가 나오지 않는다. 실행 관례는 우리가 매일 같이 습관처럼 해야 하는 것이다.
+
+- 사람을 프로그램할 수 없다는 이야기에 깊이 공감했고, 그렇기에 실행관례를 부분적으로 하는 것이 아니라 실행관례에 대한 명확한 전략을 정의해 이를 진심으로 받아들이고 내재화해야 하기 위해 노력해야 겠다는 생각이 들었습니다. 이번에도 포부있게 애자일 방식으로 해보자! 라고 했지만 이를 더 깊이 이해하지 못한채 적용하려고 했기에 올바른 애자일 방식으로 개발을 하지 못했다는 생각이 듭니다. 상황이 바쁘더라도 애자일하게 개발을 하기위해 정한 실행 관례를 습관처럼 할 수 있도록 노력하고 더 공부해야겠다는 생각이 들었습니다. 그래서 이렇게 책을 읽을 수 있도록 기회를 준 독서 스터디에 감사하고 있습니다 :)
+
+153p
+기술적 실행 관례들 그 자체를 직접적으로 찰려고 드는 것은 아무런 의미가 없다. 그렇게 해서는 상대방을 납득시킬 수 없다. 실행 관례의 도입 자체를 관리자나 팀 구성원들에게 설득하려 하지 말고 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야한다.
+
+155p ~ 156p
+테스트 코드는 잘 정리된 요구사항의 역할도 하기 때문에 딱 필요한 만큼만 코딩되도록 유도하여 불필요하게 복잡해지거나 오버 엔지니어링을 하는 것을 줄여준다. 이러한 것들이 바로 비즈니스적인 가치다.
+
+- 해당 문장을 읽고, 개인 프로젝트에서라도 TDD 방식을 적용해보자라는 생각이 들었습니다. 해당 방식에 빠르게 익숙해지고 추후 팀 프로젝트에서 함께하는 팀원들에게도 알려줄 수 있는 개발자가 되기 위해 노력해야 겠다는 생각이 들었습니다.
+
+156p
+TDD 이름 자체에 '테스트'가 들어 있기는 있지만 사릿 TDD는 설계에 대한 실행 관례다. 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다.
+
+159p
+같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다. 그렇게 하면 전체 시스템에 대한 이해도나 개발자의 스킬이 팀 차원에서 누적되어 올라간다. 더불어 코딩 표준을 정의하고 유지하는 데도 도움이 된다.
+
+160p
+개발자들은 이해하기 어려운 코드를 만났을 때 그것을 개선해보려 하기 보다는 그대로 내버려둔다. 괜히 수정했다가 코드를 망가뜨릴 수 있기 떄문에다. 그래서 작은 워크 어라운드들과 중복 코드들을 만들면서 작업한다. 엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도도 빨라진다. 이것은 '깨진 유리창 법칙'으로도 알려져 있다. 지저분하고 엉망인 애플리케이션은 개발자들을 느리게 만들고 그로 인해 비즈니스도 느려진다.
+
+- 저의 뼈를 때리는 문장인 것 같습니다. 이번 프로젝트를 진행하면서도 이해하기 어려운 코드들이 있었는데 그냥 넘겼고, 이번에 상호 피드백을 하면서 수정해야 하는 부분을 많이 발견했습니다. 하지만 이미 진행하고 있고, 저도 시험기간 때문에 개발을 미루어 급하게 구현하다 보니 고치지 못하고 현재 개발을 하고 있습니다..ㅠㅠ 제가 리드인데 같이하는 팀원한테 너무 미안하네요..
+- 그래서 이번주까지 구현해야 하는 것을 최대한 마무리하고 다음주 혹은 이번주 토요일에는 리팩토링을 진행할 것 같은데 어떻게 하는게 효율적일지 걱정이 됩니다. 이렇게 많은 부분은 구현하고 리팩토링을 진행할 때 어떤 방식이 효율적인지 묻고 싶습니다! 현재 제 생각은 토요일에 회의하면서 고쳐야할 부분들을 함께 말하고 각자의 코드가 아니라 서로의 코드를 수정하며 프로그램 전체에 대해서도 이해를 하면 좋겠다라고 생각을 하고 있는데 이렇게 하면 괜찮을까요..??
+
+레거시 애플리케이션을 대상으로 일을 할 때, 전체 시스템을 한꺼번에 새로 작성하고 싶은 욕구를 조심해야 한다. 이럴 때는 수정되는 부분에 한정해서 리팩토링을 집중하는 것이 더 나은 방법이다.
+
+- 바로 알려주네요..ㅎㅎ
+
+실용주의적인 관념 없이 리팩토링하는 것은 대단히 위험하다. 프로페셔널로서 행동한다는 것은 트레이드오프를 이해한다는 것이다. 전체 시스템을 더 좋게 만들 수는 있겠지만, 그럴 필요 자체가 없을 수 있다. 몇년 동안 바뀐 적인 없는 부분을 리팩토링하는 것은 의미가 없다. 애당초 코드를 수정할 필요가 없다면, 리팩토링해야 할 이유도 없다. **리팩토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다.**
+
+163p
+어떤 실행 관례가 다른 실행 관레보다 더 나은지 알아보는 가장 좋은 방법은 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지 비교해 보는 것이다. 나머지는 상관이 없다. 만약 검토 중인 실행 관례가 우리에게 어떤 가치를 주는지 판단되지 않는다면 도입을 보류해야 할 수 있다.
+
+164p
+실행 관례에 대한 도입을 이야기하기 전에, 먼저 우리가 이루려는 것이 무엇인지 논의해야 한다.
+소프트웨어 개발/납품 절차 중에서 어떤 부분을 얼마만큼 개선하길 원하는가? 이러한 것이 정의되고 나면 그것을 달성하기 위해 어떤 실행 관례를 도입할지 말할 수 있다.

8장/황동준.md

@@ -0,0 +1,24 @@
+## 8장 길고 긴 여정
+
+### 중요하다고 생각한 내용과 나의 생각
+
+170p
+다음은 기회를 만들어 내기 위해 할 수 있는 몇 가지 활동들이다.
+
+- 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식을 확장한다. 예를 들어 새로운 프로그래밍 언어나 기술들을 배운다.
+- 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다.
+- 다른 개발자, 비즈니스맨들과 교류한다.
+- 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅한다.
+- 오픈 소스 프로젝트에 참여한다.
+- 프로젝트를 만들고 공개한다.
+- 콘퍼런스에 참석한다.
+- 콘터런스에 연사로 나선다.
+
+각자 다른 꿈과 열망이 있고 완전히 다른 상황에 있지만 커리어에 대한 열망을 실현하려 노력한다는 점에 있어서는 매우 비슷하다. 거쳐가는 모든 직장, 프로젝트들 하나 하나를 투자로 인식하는 것이 가장 중요하다.
+...
+소프트웨어 장인은 거치는 자리마다 끊임없이 지식과 열정에 몰입 그리고 프로페셔널로서의 태도를 키워나간다. 따라서 다른 형태의 투자로서 우리가 기대하는 보상이 어떠한 것인지 명확히 할 필요가 있다.
+
+- 위와 같은 소프트웨어 장인으로서의 태도와 프로페셔널을 갖추기 위해 노력해야겠다는 생각이 들었습니다.
+
+176p
+성공적인 커리어는 공짜로 오지 않는다. 스스로 만들어 나가야 한다. 특정 회사 안에서의 커리어보다 개인으로서 우리 자신의 커리어가 항상 우선해야 한다.