Tag: 도서

옛날 책 버리기 전에 훑어보기

그냥 한번 훑어보면 될만한 책이다

사서 보기는 좀 아깝고…

다 아는 입장에서 보면 인덱스는 잘 돼 있네~ 라는 느낌인데

모르고 보면… 뭐가뭔지 싶을 것 같다.

예전에 본 책들 너무 쌓여서 정리중인데
이 책도 정리 대상으로 확정 되었다.
앞으로 다신 볼 것 같지도 않고 직원이나 동료나 후임이나 .. 등등 추천 해 줄 것 같지 않아서

문제점

요즘 책은 개념적인 부분만 나오고 실용적인 부분은 예제만 제공 해 주면 된다.
어차피 세부적인 코드나 설명은 다 기억도 못 하고 요즘엔 책을 레퍼런스로 보지 않으니까
예제를 실행이 되게 만들어 놓는다면 긴 설명도 필요 없다.

이 책은 개념 설명이 짧고 코드가 길다.

• Spring, Django, RoR, WPF, … 스타트 할 때 사용할만한 기술이면 코드가 필요할 수 있는데
  특정 상황에서만 사용하는 RabbitMQ, Kafka, ElasticSearch 등등은 필요없다.
• 요즘은 책을 다시 찾아보지 않고 인터넷에서 레퍼런스나 Stackoverflow 등을 검색한다.

책 내용

첫번째 장에서 짧게 RabbitMQ 구조와 개념 설명을 하고 뒤에서부터는 자바코드와 함께 개념을 조금씩 설명하는데…
개념이 겨우 이해가 안갈정도만 설명이 되어 있다.(이해가 안간다고. 다시 인터넷 찾아봄)
지식의 밀도가 낮다 보니 더 기억에 안 남는 것 같다.

소프트웨어 회사들이 흔히 하는 실수를 다 써 놨다.
이 업계에서 일하는 누가 읽어도 이거 우리회사 얘긴데.. 싶을거다.
(진짜 잘되는 회사 제외)

프로덕트 매니저의 업무 프레임워크

프레임워크라는 것은 베이스가 부족한 경우에도 필요하고
능숙하더라도 간혹 실수를 방지 해 주는 장치로 작용한다.

프로덕트 매니저로써 능숙하게 일을 하는 사람도
지금 프로덕트 매니저로 취업하거나
프로덕트 매니저 업무를 떠맡게 된 누구에게나 도움이 되지 않을까

인상깊은 내용

• 프로덕트 매니저란?
  • 번뜩이는 아이디어, 최첨단 기술이 아닌 프로덕트를 통해 해결해야 하는 문제에 주목
• 아무도 쓰지 않는 쓰레기를 만드는 것 = 개발함정
• 성과물 vs 산출물
  • 기능의 실제 가치를 확인하지 않고 개발하는것은 산출물… 뭔가가 나왔다
  • 성과물은 핵심 목표를 달성할 수 있는 것
• 이해관계자별 다른 목표(동상이몽) [목표]-[이유]
  • CEO 매년 30% 성장을 해야돼 – 그래야 다음라운드 투자를 받아
  • CTO 모바일 전략이 중요해 – 그래야 성과급을 받지
  • COO 비지니스 회원을 늘려야 해 – 그러면 수입이 늘어날거야
  • 그런데 이런식으로 각자 목표를 세우는게 문제라면… 이 문제의 해결책은 OKR이 아닐까

…

OKR과 마찬가지로 읽으면서 씁쓸하다
이건 상당히 센스의 영역이다.
읽고나서도 여기서 뭔가 느끼고 바꿀 수 있는 경영진이 얼마나 되려나

그리고 이 책이 프로덕트매니저의 시각에서 자기중심적으로 쓰여져서 그렇긴한데…
그 직무를 맡은 사람이 없어도 모든 구성원이 이렇게 사고해야한다.
우리나라 보통 IT회사에서는 개발팀장, 기획자, 디자이너, 그냥PM등 다양한 사람이 사실상 이 책에서의 프로덕트 매니저 포지션이기도 하고
프로젝트에 따라 누구나 프로덕트 매니저가 되기도 하니까

내용이 너무 자바처럼 verbose하다

짧은 내용을 너무 길게 설명해서 지겨워서 볼 수가 없다.

ex) ch07. 객체분해 p216~217 2페이지는 대략 이정도로 표현할 수 있다

일반적으로 작업기억은 7개의 chunk를 가지고 있다. 즉, 한번에 기억할 수 있는 숫자는 7개까지로 아래 11개의 연속된 숫자를 한번에 기억할 수 있는 사람은 드물다

29689928269

하지만 아래처럼 변환하면?

2968-992-8269

한번에 인식 가능하고 외울수도 있다.
11자리 숫자를 한번에 기억했다면 아마도 무의식중에 숫자를 나눴을 가능성이 높다

이런식으로 큰 문제를 작은 문제로 분해decomposite하면 문제를 이해하기 쉽고 더 좋은 해결이 가능하다.

이거 볼 시간에 DDD, JPA를 보자.
그래도 시간이 남으면 매트릭스와 에일리언을 보자

그냥 개발수필에 가깝다
코딩호러의 어쩌고 했던책이 더 재밌었던듯

이 책에서 뭔가 내용이 많이 나오긴 하는데
맞는말이긴 한데 그냥 맞는말뿐이라서 별로 뭔소린지 기억에 남지 않는다

마틴파울러나 GoF같은 유명한 책은 많이 읽은 사람인 것 같다
개발방법론이나 조직에 대해 많이 생각해봤던
10~20년쯤 소프트웨어 개발을 했던 프로그래머
대부분 그정도 근방의 이력을 가진 사람이면 해 봤을법한 생각들

아예 초년생이라면
감명받을 수도 있겠고
뭔소린가 싶을수도 있겠는데
한번 훑어보는게 도움이 되려나

이 책의 태그를 자기계발서로 넣은건…
기술서적이 아니기 때문.

자기계발서 읽는 느낌이다
다 맞는 말인데
머리에 남는건 별로 없는

• 이미 하고 있는 것들
• 하면 좋은 것들
• 해야만 하는 것들
• 할 수 없는 것들

이렇게 분류 해 볼 수 있을까

그냥 한번 읽어보고 넘어가면 될 것 같다
잠재의식 속에 남아있겠지

커맨드라인

find . -name '*.c' -newer Makefile -print
zip archive.zip *.h *.c
tar cvf archive.tar *.h *.c
find . -name '*.java' -mtime +7 -print
find . -name '*.java' -mtime +7 -print | xargs grep 'java.awt'
grep '^import '*.java |
  sed -e's/.*import *//' -e's/;.*$//' |
  sort -u > list

여기서 할 줄 아는게……압축하는거

내용

• Prototype – 두 번째 시스템
  : 첫번째 시스템은 프로토타입이다
• 1:10 업무효율
  : 같은 조직내에서 비슷한 급여를 받는 살마들 사이에도 업무능력 차이는 10배
• 일정 늘어짐
  : 일정은 항상 늘어진다. 일정을 너무 루즈하게 잡은게 아니라면. 돌발상황에 대비해 조금 타이트하게 업무처리
• 문서화
  : 워크북. 요즘은 위키를 주로 사용
• 급하다고 많은 인원 투입
  : 의사소통 비용 증가
• 소수정예
  : 큰 프로젝트 불가
• 핵심개발인력과 보조인력 구조
  : 아키텍트와 모듈분할
• 구체적인 마일스톤의 정의
• 프로젝트 관리자는 의사 결정이 아닌 의사 소통

대상

오히려 개발자보다
한국에서의 특이직군인 기획자, PM
그리고 스타트업 대표, PO, 원청업체담당자가 봐야 할 책

읽고나서

소프트웨어 공학을 모를 때도
개발 업무를 하면서 맞딱뜨리게 되는 불편한 점들과 개선점을 생각했었는데
내가 찾아낸 최선의 방법의 핵심은 빠른 프로토타이핑과 작은 개선의 반복이었다.

이 책에서는 이것을 포함해서 그리고 더 다양한 상황에서의 대응법이 잘 정리가 되어 있다. 현업을 겪어보지 못했다면 그렇구나.. 하면서 감흥없이 넘어갔을 것 같다. 어차피 한번 겪어보고 다시 읽어야 됐었겠지
소프트웨어 개발 싸이클틀 겪어 본 사람이라면 이 책을 읽으면서 자기가 겪었던 문제점이 그대로 다 써 있다는데 놀라지 않을까

1975년 초판이라는데
아직도 그대로라니