https://www.yes24.com/Product/Goods/119108069
책의 제목
(원서) The Missing Readme: A Guide for the New Software Engineer (번역서) 필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생 감상 2023.10.23 많지 않은 분량으로 실무 개발자의 폭넓은 업무를 다루면서 결코 얄팍하지 않은 지식을 전달하는 책입니다. 협업, 설계, 구현, 테스트, 문서화, 긴급 대응, 경력 관리 등 다양한 분야에 대한 알찬 조언을 책 한권에 눌러 담았고 더 많은 분량을 학습하고 싶은 독자를 위한 참고자료들도 매 장마다 소개하고 있습니다.
인상 깊은 단락 Introduction Agile acceptance testing breaks down traditional boundaries around testing, requirements and specification processes in a way that significantly improves communication on a project.
It is intentionally not too technical or suited only for programmers, because agile acceptance testing is not a programming technique: it is a communication technique that brings people involved in a software project closer.
One of the main messages I want to convey with this book is that the biggest benefit of agile acceptance testing is improved communication and mutual understanding, not test automation.
인상 깊은 단락 p44 B2B 회사인 경우, 스티브 블랭크 교수는 C-레벨 사람들보다는 중간 레벨 관리자들과 인터뷰를 시작하는 것을 추천하고 있다. 약속을 잡기 더 수월할 것이며, 반복적인 대화를 하기에도 더욱 쉬울 것이다. 가장 중요 한 것은 더 높은 사람을 만나기 전에 더 잘 배울 수 있는 기회를 갖는 것 이다
p98 헨리 포드 (역자주: 포드 자동사 회사 창립자)가 말한 유명한 Henry Ford 문구가 있다. ‘제가 사람들에게 무엇을 원하는지 물었다면, 더 빠른 말 이라고 답할 것입니다’
http://ebook.insightbook.co.kr/book/65 에서 PDF로 구매할 수 있다.
https://www.yes24.com/Product/Goods/67350256?OzSrank=1
관련 링크 https://zzsza.github.io/etc/2018/12/16/agile-together/ 인상깊은 내용 p31 자기계발이 왜 중요하다고 생각하냐면, 현재 나에게 무엇을 투자했느냐가 1년, 혹은 2년 후의 나를 결정한다고 느끼기 때문입니다. 예를 들어 올해 업무도 잘한 것 같고 사람들에게 인정을 받은 것 같다면 1~2년 전을 잘 되돌아봅니다. 아마 그때 열심히 자기투자를 했을 겁니다. 반대로 올해 읽은 책도 몇 권 없고 새로 얻은 통찰도 없다면 지금 당장은 별 문제없는 것 같지만 (예를 들어 올해 내 연봉은 만족스러우나) 내년이나 내후년에는 분명 추락을 경험할 것입니다.
생각 메모 프로젝트 목표 공유의 중요성. not list 케이크 - full stack web developer 인상적인 내용 사용자 스토리의 원칙..(INVEST - independent, negotiable, valuable, estiable, small, testable)
감상 편하게 잘 읽히는 책. ‘정신없이 개발한 소프트웨어가 제 정신일리 없다’, ‘협업에 대처하는 가장 좋은 방법은 역설적이게도 협업이 필요한 부분을 최소화하는 것인지도 모르겠다’ 같은 마음에 드는 문구들이 몇개 기억에 남는다. 이 시리즈 계속 나왔으면..
인상 깊은 단락 p20 문명 붕괴의 패턴을 읽다가 소프트웨어 역시 비슷한 양상으로 붕괴한다는 걸 깨달았다.
p47 그러나 개발자로서 가장 중요한 language는 우리말입니다.
p67 정신없이 개발한 결과물이 제 정신이 있기를 기대하는 건 좀 심하다는 생각이 든다.
인상 깊은 단락 p42 반면 소프트웨어의 경우는 소프트웨어 프로젝트마다 독특하며 이전 프로젝트에서 했던 것을 가져다 활요할 수 있는 것이 많지 않다. 덴버공항 수하물 처리 시스템이 그러 했다. 독일 스트라우스공항에서 수하물 처리 시스템을 만들었던 경험은 덴버공항 수하물 처리 시스템 개발에는 결정적인 도움이 되지 않았다.
p237 고객이 요청한 것 하나를 들어주면 우리는 다른 서비스나 기능 하나를 제거해야 한다. 이렇게 해야 고객의 요청을 부담 없이 처리하면서 다른 부담스러운 일을 제거할 수 있다.
인상깊은 내용 36쪽 번다운 차트 사용
38쪽 또 다른 위험은 ‘자원 안배를 잘 못해서 잃어버리는 시간'이다. 어려운 문제인 줄 정작알았더라면 개발자를 두세 명 더 투입하거나 선임 개발자를 붙였을 게다. 팀원들이 프로젝트 위험을 줄이려고 노력하기보다 기능 날짜를 맞추는데만 급급하다면 프로젝트는 그만큼 소중한 시간을 잃는다.
40쪽 기존공학이 수백 아니 수천 년에 걸쳐 쌓아온 경험적 예측성을 소프트웨어 공학에서 기대해서는 안된다.
42쪽 기능 완료일을 맞추라고 팀을 닦달하면 팀은 편법으로날짜를 맞추거나 거짓말을 둘러댄다.
https://www.yes24.com/Product/Goods/3600609
감상 2024.02.15 다시 읽어보면 떠오르는 일들이 더 많을 것 같다.
2010.01.21 특히나 더 인상 깊은 단락들
모든 설계 결정을 내리는 영웅이나, 모든 요구사항을 결정하는 영웅이나, 모든 아키텍처 결정을 내리는 영웅이 바로 병목을 일으키는 원인이다
최근 ‘지나친 의욕은 민폐를 불러일으킨다'라는 말이 몇번 떠올랐는데, 일맥상통하는 내용이이다.
흔히 프로세스 개선 그룹, 표준 제정 그룹, 품질 부서 등이 업무 프로세스나 수행방식을 명시한다. (중략) 대개 그들은 업무를 제대로 이해하지도 못하면서 업무 방식을 정해주는 외부인에 불과하다
인상 깊은 단락 p42 멜빈 콘웨이 (Melvin Conway) 는 168년 데이터메이션(Datamation)지에서 이렇게 설명했습니다. “시스템을 설계하는 조직들은 자신들의 조직 사이에 의사소통 구조(communication structure)를 모방한 형태의 설계를 만든다. 이것은 콘웨이 법칙(Conway’s law)이라고 합니다. 예를 들자면, ‘네 개의 팀이 하나의 컴파일에서 작업할 때, 2단계(four-pass) 컴파일럴르 얻는 것'이 바로 대표적인 콘웨이 법칙입니다.
p128 이렇듯 맛없는 개떡을 먹을 때보다 더 고약한 경험인 남이 만든 방법론을 맹목적으로 따를 때, 구성원 에게서 ‘책임감의 부재’ ‘동기부여의 상실’ ‘악의적인 순응'이라는 문제가 발생한다고 하니다.
인상 싶은 부분 Chapter 2 (번역판 p109) 유즈케이스는 새로 만든 시스템이나 소프트웨어 변경 사항에 대한 요구사항을 찾아내는 방법입니다. 각 유즈케이스는 특정목표를 달성하기 위해 시스템이 사용자 또는 다른 시스템과 어떻게 상호작용하는지를 전달하는 하나 이상의 시나리오를 제공합니다.
29 스포츠 기자였던 레드 스미스(Red Smith 1906~1982)는 “글쓰는 것은 쉽다. 그저 혈관을 열고 피를 흘리면 된다.“고 말하기를 좋아했습니다.
126 브루스 슈나이더의 말
“기술이 보안 문제를 해결할 수 있다고 생각한다면, 문제도, 기술 자체도 이해하지 못한 것입니다.”
339 포넬리의 법칙 - 예제는 아무리 많아도 지나치지 않다.
341 인류학자인 마가렛 미드(Margaret Mead, 1901 ~ 1978)가 “사려 깊고 헌신적인 작은 그룹의 시민이 세상을 바꿀 수 있음을 절대 의심하지 말라. 실로 세상을 바꾼 것은 그런 소그룹뿐이었다.
지속적인 통합: 소프트웨어 품질을 높이고 위험을 줄이기
인상 깊은 단락 47쪽 품질이란 누가 보지 않을 때에도 제대로 돌아가는 걸 뜻한다.
137쪽 테스트 분류
단위테스트 컴포넌트 테스트 시스템 테스트: JWebUnit 처럼 기능테스트(=인수테스트) : 실제 브라우저 사용 JWebUnit 예제
156쪽 테스트 케이스 하나에 ASSERT 하나로 제한하기
167쪽 수년간 이 메트릭에 대해 다양한 연구를 했는데, 10보다 큰 CCN을 가진 메서드는 같은 코드의 다른 코드보다 결함이 발생할 위험이 크다는 게 밝혀졌습니다.
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=2657930&CategoryNumber=001001003005006001
감상 2007.10.22 마이크로소프트웨어지에 ‘커뮤니티 노트'라는 컬럼을 연재하고 계신 최재훈님이 번역하신 책입니다. 사실 처음 책의 목차만을 보았을 때는 ‘실용주의 프로그래머'와 겹쳐지는 내용이 많을 것 같은 느낌에 큰 기대를 하지는 않고 읽기 시작했었습니다. 아마 제가 블로그를 통해서 이 책을 알지 못하고 서점에서 우연찮게 만났다면 책을 안 사고 지나쳤을 수도 있었을 것입니다. 그런데 다 읽고나니 다음에 프로젝트 시작할 때는 사비로라도 이 책을 사서 프로젝트 팀원들에게 돌리고 싶다는 생각이 들더군요.
이 책에서는 프로젝트를 성공적으로 이끄는 해결책으로 다음의 방법들을 제시하고 있습니다.
원서 : https://www.amazon.com/Software-Conflict-2-0-Science-Engineering-ebook/dp/B002GYWP1K/
인상 깊은 단락 p19 업계 실무에서 최고 수준과 평균 수준이 이렇게 차이가 나는 분야는 거의 없다.
p37 설계의 핵심 요소는 해결책을 제안하고 실패를 허용하는 능력이다.
성공하려면 실패하는 능력과 실패를 극복하는 능력이 필수적이다.
p40 ‘The Mythical Man Month'와 최근 ‘Sillver Bullet’ 논문에서 프레드 브룩스는 현존 최고 제품, 즉 개념적 일관성이 있다고 우리 모두가 인정하는 작품은 개인이 설계한 작품이라는 사실을 지적한다.
p41 설계 수행 면에서, 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실을, 오히려 시행착오를 거쳐가며 반복하던 엉성한 절차가 바로 설계 핵심이란느 사실을 이해해야한다.
http://www.yes24.com/Product/Goods/1418676?OzSrank=1
인상 깊은 단락 p24 저자의 화려한 경력
p29 많은 프로젝트의 성공과 실패는 어떻게 수행하는가보다 누가 수행하는가에 따라 결정된다.
p31 사람 경시 풍조
사람은 빡빡한 스케쥴과 압박 하에서 일을 더 잘 한다고 주장한다.
p33 잃어버린 곳이 아닌 밝은 곳에서 물건 찾기 일화
소프트웨어 분야에 있는 우리는 모두 마음속으로는 기술자라고 생각하며, 우리의 작업을 쉽게 하는 새로운 기술을 고안하는 것을 더 좋아한다. 마음속 깊은 곳에서는 사람과 관련된 문제가 더 중요하다는 것을 알면서도 말이다.
인상 깊은 부분 49쪽 사람들은 안전하다고 느끼지 않는 한 변화를 수용하지 않는다.
62쪽 협박은 실적을 유도하기에는 불완전한 방법이다.
98쪽 최소한 단기간에 생산성을 높이기 위해서 할 수 있는 일은 사실상 아무것도 없기 때문에 제 생각에는 시간을 헛되게 쓰지 않도록 하는데 전적으로 맞추게 될 거에요
102쪽 생산성에 관한 단기적인 해결방법은 없다. 생산성 향상은 장기적인 투자의 결과다.
112쪽 프로젝트 초기에 잃어버린 한시간은 프로젝트 마지막에 잃어버린 하루와 같은 손실이 된다.
인상 깊은 단락 6쪽 소프트웨어 엔지니어링은 소프트웨어의 개발, 운영, 그리고 유지보수에 대한 체계적이고, 훈련되고, 측정 가능한 접근 방식의 애플리케이션이다. 즉, 소프트웨어에 대한 엔지니어링 애플리케이션이다.
18쪽 어쩋든 노동의 분할은 산업혁명의 기초였다. 더 작고 잘 정의된 작업으로 제조 활동을 나누는 것에 의해, 그룹의 생산성은 급격히 증가되었다. 물론 이 접근 방식은 소프트웨어 개발에도 적용될수 있을 것이다. … 그러나 그렇지 않다. 작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는데에 더 많은 시간이 걸린다.