이미지 출처 : https://www.yes24.com/Product/Goods/125116480
언급된 도서 Sometimes you win, sometimes you learn 아주 작은 습관의 힘’(Atomic Habits) 결정적 순간의 대화 감상 2024.05.05 긴 호흡으로 경력을 돌아보고 내다보라는 격려를 책에서 받았습니다.
인상 깊은 단락 p8 밑으로 떨어지는 경험을 해봐야 감사하는 마음으로 다시 올라갈 힘이 생긴다. 인간 관계는 수단이 아닌 목적이어야 한다고, 실패는 나침반이라고 나 자신에게 전해주고 싶다.
p20 하지만 후반기(3년)에는 시장에서 야후가 구글에 밀리면서 회사 내부가 정치적으로 변해갔다.
이미지 출처 Yes24 (https://www.yes24.com/Product/Goods/124187392)
감상 인상 깊은 부분 p27 ~ p28 아무리 분석 방법을 잘 알고 분석 실력도 출중하더라도 분석 데이터의 질이 좋지 않으면, 좋은 분석이 나올 수 없다는 뜻이다. 그래서 분석 실력만큼 중요한 것이 데이터의 가치를 판단하는 능력이다. 이를 위해서는 분석하려는 분야에 대한 전문성이 필요하고 기초적인 통계 지식을 갖추는 것이 중요하다.
p33 데이터 사이언스를 사용한다(혹은 학습한다)는 것은 데이터를 이용해 내가 일하는 분야에서 발생한 특정 문제를 해결하고자 하는 목적일 가능성이 높다.
인상 깊은 내용 p65 “Some people will say incorrectly that objects are passed “by reference.” In programming language design, the term pass by reference properly means that when an argument is passed to a function, the invoked function gets a reference to the original value, not a copy of its value. If the function modifies its parameter, the value in the calling code will be changed because the argument and parameter use the same slot in memory.
(이미지 출처 : https://www.yes24.com/Product/Goods/118547742)
감상 전체적으로 잘 짜여진 책이다. 친절한 설명이 있어서 개발자가 아닌 분에게도 추천할만한하다.
정리 1. 웹 웹 구성요소 : HTML, URL, HTTP 웹 3.0은 2000년대부터 차세대 웹을 가리키는 용어로 꾸준히 거론됨. 초기의 웹3.0은 주로 시맨틱 웹을 의미함. 2. 네트워크 개념 LAN : 지리적으로 가까운 기기들이 서로 연결된 소규모 네트워크 WAN : 넓은 영역을 연결하는 광역 네트워크. 예: 네트워크 OSI 7계층 Open Systems Interconnection. 개방 시스템 상호 연결.
https://www.yes24.com/Product/Goods/119108069
책의 제목
(원서) The Missing Readme: A Guide for the New Software Engineer (번역서) 필독! 개발자 온보딩 가이드: 지속 가능한 소프트웨어와 원활한 협업 문화를 이해하는 프로페셔널 개발자의 탄생 감상 2023.10.23 많지 않은 분량으로 실무 개발자의 폭넓은 업무를 다루면서 결코 얄팍하지 않은 지식을 전달하는 책입니다. 협업, 설계, 구현, 테스트, 문서화, 긴급 대응, 경력 관리 등 다양한 분야에 대한 알찬 조언을 책 한권에 눌러 담았고 더 많은 분량을 학습하고 싶은 독자를 위한 참고자료들도 매 장마다 소개하고 있습니다.
https://www.yes24.com/Product/Goods/6006038
인상 깊은 단락 p39 클래스명의 어휘는 경험과 함께 향상된다.
‘숙련도별 자주 이용되는 클래스명'은 우리 나라 개발자과도 비슷한 느낌이다.
p49 ~ 50 변수의 스쿠프 관련. 옛날에 적었던 https://blog.benelog.net/1382604.html 글이 생각났다.
p115 ArrayList vs LinkedList
이미지 출처 : http://www.yes24.com/product/goods/97919905
감상 2022-09-16 개발자가 기획자/디자이너의 직무를 이해하기에도 좋은 책이다.
인상 깊은 단락 p48 반면 목적지를 아는 사공들이 탄 배는 노 없이 맨손으로 젓게 되더라도 조금씩 목적지에 가까워진다.
p55 기획의 정의
어떤 대상에 대해 그 대상의 변화를 가져올 목적을 확인하고, 그 목적을 성취하는 데에 가장 적합한 행동을 설계하는 것
p85 이때 기획자들이 많이 하는 실수 중 하나가 화면 설계서를 개발 요청서로 생각하는 것이다. 그러나 화면 설계서는 개발 진행 시에 발생할 수 있는 이슈나 정책 보완점을 미리 고려하고 문제 발생 시에 다른 우회 방안을 찾는 등 협업자들의 의견을 수렴하고 개선하는 커뮤니케이션을 위한 문서다.
인상 깊은 단락 p30 대부분의 프로그래머는 단위 테스트를 실천하고 중요성을 알고 있다. 단위테스트를 적용해야하지는 더 이상 논쟁거리가 아니다.
논쟁은 ‘단위 테스트를 작성해야 하는가?‘에서 ‘좋은 단위 테스트를 작성하는 것은 어떤 의미인가?‘로 바뀌었다.
p32 테스트하기 쉬운 코드는 좋은 코드의 필요조건이지만 충분 조건은 아니다.
코드를 단위 테스트하기 어렵다면 코드 개선이 반드시 필요하다는 것을 의미한다.
코드베이스를 쉽게 단위 테스트할 수 있다고 해도 반드시 코드 품질이 좋은 것을 의미하지는 않는다.
( 이미지 출처 : http://www.yes24.com/product/goods/105911017)
감상 2022.04.03 연구자가 쓴 학구적인 책이다. 많은 논문을 인용한 점은 로버트 L Glass의 책을 생각나게도 한다. 이 책의 독자의 뇌 안에서는 경험적,직관적으로 알고 있던 코딩에 대한 노하우와 인지과학에 대한 상식이 통합되어 정리가 될듯한다.
참고자료 저자의 발표 영상 : Programming is writing is programming - Felienne https://www.hedycode.com/ : 저자가 만든 교육용 프로그래밍 언어 https://embrava.com/pages/flow : 집중상태를 알려주는 램프 정리 PART I 코드 더 잘 읽기 CH 1 코딩 중 겪는 혼란에 대한 이해 코드를 읽거나 작성할 때 LTM(장기 기억 공간), STM(단기 기억 공간), Working memory(작업 기억 공간)에서 인지 과정이 함께/상호보완적으로 일어난다.
이미지 출처 : http://www.yes24.com/product/goods/105645204
정리 핵심키워드 정리
엔지니어링 역량 : 성장하는 10년 개발에 대한 기본 지식 : 언어, 도구, 비판적 사고(Critical thinking) 제품 디자인 : A/B Testing, 데이터 주도개발, 도그푸딩 등 개발 주기 지식 : 애자일 매니지먼트 역량 : 리딩하면서 일하는 10년 프로젝트 리드 : 계획 세우기, 역할 나누기, 시간 아끼기, 문제 해결, 우선 순위 테크니컬 리드 : How to를 고민, 모르는 일을 쪼개기 피플 매니징 : 성향 파악하기, 면담, 성과 평가, 행복 만들기, 성장시키기 프로세스 관리 : 프로세스 정립, 시스템 도입 등 비즈니스 역량 : 서포트하는 10년 채용 : 채용 목표와 원칙 세우기, 프로세스 운용 사업 만들기 : 성장 전략, 수익화, 팀빌딩 비전과 조직 문화 만들기 시간관리 목표,계획,실천,측정 싸이클 우선 순위 관리 이메일, 회의 최적화, 휴식 인상 깊은 단락 프롤로그 p12 저는 농담으로 디렉터를 정의하며 이런 표현을 씁니다.
( 이미지 출처 : http://www.yes24.com/Product/Goods/3661437 )
https://play.google.com/store/books/details?id=mIFfAtBD3JUC : 구매한 URL인데 현재 Google play 에서 검색하면 이 페이지로는 나오지 않는다.
인상 깊은 단락 p18 <뉴욕타임스>의 기자인 데이비드 플로츠는 <천재공장The Genius Factory: The Curious History of the Nobel Prize Sperm Bank, 2005>이라는 책에서 이러한 공장에서 생산된 217명의 아이 중에서 30명의 삶을 추적하여 한 인간의 잠재력이 IQ가 높은 부모의 결합으로 담보되는 것이 아님을 보임으로서 인간 생명의 존엄성을 환기시켰다
p21 그렇지만 비네는 자신이 개발한 방법이 아이들의 지적능력에 서열을 매기기 위한 방법이 아니라 특수한 교육이 필요한 발달이 더딘 아이들을 구별해내기 위한 것임을 시종일관 강조했다
(이미지 출처 : http://www.yes24.com/Product/Goods/17947564)
정리 Linux 성능 분석 도구 sar vmstat ps iostat netstat top pstack : 비교적 부하가 낮음 strace : 비교적 부하가 큼 인상싶은 내용 p71 시간 동기화는 NTP 사용 slew 모드 : 시간을 조금씩, 아주 짧은 시간만 조정. p110 성능데이터는 경험상 2주 정도 저장해야 함.
p116 원인조사를 할때의 태도
또는 ‘가르쳐 주세요'식읜 접근법도 좋다. 처음에는 차가운 태도를 보일 수도 있겠지만, ‘내가 가지고 있는 정보로 당신의 문제를 설명할 수 있습니다'나 ‘당신이 가진 정보로 내가 가진 의문이 해결될 수 있습니다'하는 분위기로 작업을 진행하다 보면, 엔지니어 간의 사이도 좋아지고 문제도 더욱 서우러하고 해결될 수 있다.
정리 Netflix의 도구들
Eureka : Service Discovery Hystrix : Circuit breaker Ribbon : Client side load balancing Archaius : Library for configuration management API runtime에 설정 변경 지원 Prana : Sidecar Raigad : ElasticSearch 관리도 Chaos Engineering The Netflix Simian Army key-value 저장소 EVCache : Memcached 기반의 분산 메모리캐쉬 Moneta : A unified interface for key/value stores 모니터링 Atlas : Time series 데이터 관리 Servo : Application Monitoring Library Spectator : About Client library for collecting metrics Vizceral : 트래픽 흐름 시각화 도구 Turbine : Server Side Event Stream Aggregator Titus : 컨테이너 플랫폼 https://netflix.
메모 외래어 공식 표기법은 많이 쓰이는 관례와 다를 수 있다. 예: 윈도 vs 윈도우, 파이썬 vs 파이튼 사용자 입장의 릴리즌 노트, 체인지 로그 쓰기. 요약이 있으면 더 친절하다. 비지니스 영향성을 고려한 장애 보고서 쓰기 개발 가이드의 처음은 범주/용도/특징 순서로 인상 깊은 부분 44쪽 ‘파이썬’ 표기의 유래
95페이지 404 에러가 죄송할 일인지에 대한 의문
106페이지 확인, 취소보다 가급적 구체적인 말쓰기
108 페이지 윈도우와 macOS에서 ‘취소’ 버튼의 위치가 다름
감상 2022.09.05 책도 얇은 편이지만 재미가 있어서 중간에 끊지를 못하고 끝까지 읽었던 기억이 있습니다. 웹 어플케이션의 구조를 어떻게 잡을지는 프로젝트마다 매번하는 고민인데, 이 고민에 생각할 거리를 더 던져주는 점에서 유익했습니다. 엉클밥 아저씨의 ‘클린 아키텍처'가 코드가 없어서 아쉬웠던 점을 이 책에서 많이 채워주는 면도 있습니다.
이 책에서 권장하는 구조가 꼭 정답은 아닐 수도 있습니다. 이 책에서 제시한 ‘계층형 아키텍처'의 문제점이 계층형을 쓰면서 극복이 불가능한 문제는 아닐수도 있다는 생각도 듭니다. 책에서 제시한 persistent layer와 serice layer의 의존관계 역전을 실무 사례를 아직까지 못 본적은 없습니다.
Audible에서 Audio Book으로도 들을 수 있다.
https://www.audible.com/pd/Microservices-Patterns-Audiobook/B07ZFZ464G
참고 링크 https://microservices.io/patterns/microservices.html https://eventuate.io/ 인상 깊은 단락 (번역판 페이지 기준)
p92 DDD와 마이크로서비스 아키텍처는 거의 찰떡궁합입니다. DDD의 하위 도메인, 경게 컨텍스트 개념은 마이크로서비스 아키텍처의 서비스와 잘 맞고, 마이크로서비스 아키텍처의 서비스 자율팀 개념은 도메인 모델을 개별 팀이 소유/개발한다는 DDD 사고방식과 어울립니다. 자체 도메인 모델을 가진 하위 도메인이라는 개념 덕분에 만능 클래스를 제거하고 서비스로 분해하기가 더 수월해집니다.
p109 ‘하위 호환되는 소규모 변경'에 ‘속성을 응답을 추가'로 해당.
http://www.yes24.com/Product/Goods/2495264?OzSrank=1
인상 깊은 단락 p22 최근까지도 국내에서 수행되는 대부분의 성능 시험 프로젝트의 경우 성능 시험 도구 라이센스에 대한 비용 부담 및 Think 시간 측정의 어려움, 성능 시험 소요 시간의 단축, 관련자들의 이해 부족 등의 이유로 Think 시간을 배제하거나 대폭 줄인 채로 성능 시험을 실시하고 있는 상황입니다. 이는 시험 목표와는 전혀 다른 결과를 도출할 수 있는 비현실적인 상황을 재현하는 것으로 이를 통해 성능을 개선하는 것은 의미가 없다고 단언할 수 있습니다.
인상 깊은 단락 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.
인상 깊은 단락 p21 1997년 대한항공 괌 추락사고로 인해 비상 사태시에 승객이 취해야할 자세에 대한 안전 수칙이 추가 됨.
p35 페트리어트 시스템의 오류는 10진수와 2진수 사이의 변환 오차로 인한 것
p56 큐리오시티의 성공에는 분명 MCO의 실패에서 얻은 교훈이 녹아 있었을 것이다. NASA는 MCO 사례 이후 모든 프로젝트 진행시 도량형을 미터법으로 통일하도록 규제했기 때문이다. 도량형 문제로 3억 2,760만 달러(한화 약 4,00억 원, 환율 1,100원 기준)를 허공에 날리면서 얻은 귀중한 교훈이었다.
인상깊은 단락 서문 반면, 좋은 설계는 이렇나 복잡한 특징을 활용할 기회를 만들어 줄 수 있다.
p2 모델은 대상을 단순화한 것이다. 즉, 모델을 어떤 사실을 해석한 것으로 볼 수 있고, 당명한 문제를 해결하는 것과 관련된 측면을 추상화하고 그 밖의 중요하지 않은 세부사항에는 주의를 기울이지 않는다.
p3 도메인 모델은 어떤 특정한 다이어그램이 아니라 다이어그램이 전달하고자 하는 아이디어다. 도메인 모델은 단지 도메인 전문가의 머릿속에만 존재하는 지식이 아니라 해당 지식을 엄격하게 구성하고 선택적으로 추상화한 것이다.
원서 : Dynamic Programming for Coding Interviews: A Bottom-Up approach to problem solving 번역서 (종이책) 다이내믹 프로그래밍 완전 정복 빠르고 우아한 상향식 문제 풀이법 (이북) 다이내믹 프로그래밍 완전 정복: 빠르고 우아한 상향식 문제 풀이법 (View 옵션이 Original Pages만 지원 ) 감상 2020.07.21 Kindle로 약간 보다가 번역서가 편집이 더 이쁘고 가독성이 좋아서 종이책으로 구입했다. 기술 면접에 적절한 난이도의 문제를 친절히 차근차근 설명했다. 원서의 제목이 저자의 의도에 더 부합하는 듯하다.
감상 2020.07.20 Java8이 나오기 전에 쓰여진 책이라 현시점에서는 오래된 지식이 많다. 기술 역사서로는 의미가 있다. 알고리즘 구현예제들도 최적화의 여지가 있어보인다. 예: Quick Sort는 책의 예제보다 공간복잡도를 더 줄여서 구현할 수 있다. 인상 깊은 단락 p99 Collections.newSetFromMap() 언급. 책에는 오타로 Collection.netSetFromMap() 이라고 되어 있다.
p158 Integer.MAX_VALUE 등에 대한 언급. 2의 보수 원리. 아래와 같이도 확인할 수 있다.
assertThat(-Integer.MIN_VALUE).isEqualTo(Integer.MIN_VALUE); assertThat(Math.abs(Integer.MIN_VALUE)).isEqualTo(Integer.MIN_VALUE); assertThat(Integer.MIN_VALUE -1).isEqualTo(Integer.MAX_VALUE); p320 https://code.google.com/archive/p/dbdeploy/ 소개.
참고 링크 http://dagyeom.net/ : 저자의 회사 책에 나온 추천 자료 빅데이터 비지니스 (p128-129) 빅데이터 기초：개념, 동인, 기법 인공지능 시대의 비즈니스 전략 빅데이터가 만드는 제4차 산업혁명 빅데이터 비즈니스 이해와 활용 빅데이터 분석과 활용 데이터 마이닝(p134) 데이터 마이닝 개념과 기법 패턴 인식 데이터마이닝 기법과 응용 자격증 교재(p140) 데이터 분석 전문가 가이드 경영 빅데이터 분석사 SQL 전문가 가이드 데이터 분석 코딩(p150) 파이썬 라이브러리를 활용한 데이터 분석 파이썬으로 데이터 주무르기 빅데이터 분석 도구 R 프로그래밍 R라뷰 수리 통계학 수리통계학개론 딥러닝 딥 러닝 제대로 시작하기 인프런 강좌 모두를 위한 딥러닝 - 기본적인 머신러닝과 딥러닝 강좌 밑바닥부터 시작하는 딥러닝 DB Database Concepts 몽고디비 인 액션 추천 알고리즘 Recommender Systems: The Textbook Building Recommender Systems with Machine Learning and AI Deep Neural Networks for YouTube Recommendations Infra (p244) 아마존 웹 서비스 AWS Discovery Book Python 어플리케이션 개발 (p245) 깔끔한 파이썬 탄탄한 백엔드 파이썬으로 배우는 알고리즘 트레이딩 파이썬 GUI 프로그래밍 쿡북 인상 깊은 단락 p39 서울대학교 컴퓨터 공학부 정원이 55명인데 반해 스탠퍼드는 739명
감상 2020.06.30 ( ‘SI에서 비지니스는 쿼리에 있어야 합니다.’ 등 70, 81, 82, 85페이지를 읽고 소감)
‘ArrayList 가 thread safe 하기 때문에'라고 적어놓은 것이 우선 흥미롭다. ‘ArrayList'의 JavaDoc을 보면 그렇지 않다는 것을 바로 알 수 있기 때문이다. ‘Note that this implementation is not synchronized.’ 라는 문구가 굵은 글씨도 강조되어 있다. 저자가 그런것은 관심을 둘 필요가 없다는것을 강조하기 위해 위와 같이 정확하지 않게 기술한 것일수도 있겠다.
암튼 SQL에 최대한 많은 로직을 두고, Java단에는 Map만 넘기는 개발스타일이 SI에서 선호되는 이유는 다음과 같다고 나는 생각한다.
인상 깊은 단락 맥락에 따라 이해해야하므로 책을 사서 전문을 꼭 읽어봐야한다.
들어가며 과학적 패러다임과 프로그래밍 패러다임과 차이점
p3 우리가 사용하는 패러다임은 ‘한 시대의 사회 전체가 공유하는 이론이나 방법, 문제의식 체계'를 의미한다.
p5 프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다. 또한 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다.
p6 쿤은 상이한 두 가지 패러다임이 있을 때 두 패러다임은 함께 존재할 수 없다고 주장했다.
감상 2020.04.18 멘티 개발자, TL, 매니저 등 단계별로 신경을 써야 할 일들을 이 책에서 체계적으로 정리했다고 느껴집니다. 미국 IT 업계를 배경으로 하고 있지만 국내 IT회사에 다니는 분들도 공감이 갈만한 지점이 많습니다. 1On1 미팅을 강조하고 있다는 점도 인상적입니다.
2020.06.30 ‘실리콘밸리의 팀장들’ , ‘개발7년차, 매니저 1일차’, ‘슬랙’ 을 읽고 느낀 점
다른 사람과 협업을 하는 모든 개발자는 ‘관리'의 영역에 있는 일을 신경써야 한다. 관리 업무에서 가장 중요한 지점은 ‘명확한 피드백'을 전달하는 것이고, 때로는 불편한 피드백을 주어야 하는 경우도 있다.
도메인 주도 설계 핵심 : 핵심을 간추린 비즈니스 중심의 설계로 소프트웨어 개발 프로젝트 성공하기
인상깊은 단락 67p 문서 자체는 도메인 모델이 아니다. 더 정확히 말하면 도메인 모델 개발을 두와주는 도구일 뿐이다.
### 129p
규칙2 : 작은 애그리게잇을 설계하라.
자바코딩, 이럴 땐 이렇게: PMD로 배우는 올바른 자바코딩 방법
https://www.yes24.com/Product/Goods/13151261
인상 깊은 단락 p96 boolean 반환할때 불필요한 if문 없애기 - 코드리뷰 때 종종 이야기하던 패턴인데 책에서보니 반가웠다.
p128 K&R과 1TBS
감상 구글/애플에서 관리자를 경험을 하고, 애플대학교에서 ‘애플경영법'을 강의했던 킴스콧이 쓴 책. ‘조직 내에서 건설적이지만 불편할 수도 있는 피드백을 어떻게 잘 주고 받을 것인가?‘가 이 책의 핵심 화두이다. 중간중간 나오는 쉐릴 샌버그, 에릭슈미츠, 스티브잡스 같은 거물들의 일화들도 흥미롭다.
인상 깊은 단락 33 (‘최고의 상사는 감정노동의 달인’ 단락)
사람들은 상사가 느끼는 ‘감정 노동'을 과소평가하며, 대개 서비사람들은 상사가 느끼는 ‘감정 노동'을 과소평가하며, 대개 서비스나 의료 산업에 종사하는 사람들, 예를 들면 정신과 의사나 간호사, 웨이터 항공 승무원이 느끼는 일로 치부한다.
나는 LINE 개발자입니다 : 라인의 개발 고수 12인의 도전과 기회, 성장의 개발 라이프
감상 2019.09.21 책의 저자분들이 다들 글을 잘 쓰셔서 잘 읽혔고, 출퇴근길에 재밌게 빠르게 읽을수 있었다. 아는 분들이 나와서 반갑기도했다. 개발자들이 경험을 풀어놓은 이런 책을 좋아해서 가급적 사본다. 책이 아니었다면 술자리에서 몇시간 동안 이야기해야 들을수 있는 이야기일법하다. 이 책의 책값 만이천원으로 12번의 술자리를 대신한 느낌이다.
https://www.facebook.com/benelog/posts/2422516247784435
인상 깊은 단락 p44 B2B 회사인 경우, 스티브 블랭크 교수는 C-레벨 사람들보다는 중간 레벨 관리자들과 인터뷰를 시작하는 것을 추천하고 있다. 약속을 잡기 더 수월할 것이며, 반복적인 대화를 하기에도 더욱 쉬울 것이다. 가장 중요 한 것은 더 높은 사람을 만나기 전에 더 잘 배울 수 있는 기회를 갖는 것 이다
p98 헨리 포드 (역자주: 포드 자동사 회사 창립자)가 말한 유명한 Henry Ford 문구가 있다. ‘제가 사람들에게 무엇을 원하는지 물었다면, 더 빠른 말 이라고 답할 것입니다’
인상 깊은 단락 Kindle판 기존
Location 502 Batch processing, for this book’s purposes, is defined as the processing of a finite amount of data without interaction or interruption.
Location 506 A ComputerWorld survey1 in 2012 stated that over 53% of those enterprises surveyed used COBOL for new business development.
Location 1,186 The worst part about maintaining batch processes is that when they break, it’s typically at 2:00 a.
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년 전을 잘 되돌아봅니다. 아마 그때 열심히 자기투자를 했을 겁니다. 반대로 올해 읽은 책도 몇 권 없고 새로 얻은 통찰도 없다면 지금 당장은 별 문제없는 것 같지만 (예를 들어 올해 내 연봉은 만족스러우나) 내년이나 내후년에는 분명 추락을 경험할 것입니다.
인상 깊은 단락 2ed
p76 scale cube
참고 http://theartofscalability.com/ https://microservices.io/articles/scalecube.html 요약 x축 : 애플리케이션을 복제해서 수평적으로 확장 y축 : 서로 다른 기능들을 분리 Z축 : 데이터 파티셔닝 또는 샤딩 p188 https://github.com/Nilhcem/FakeSMTP 를 이용한 테스트 환경 구성
https://github.com/benelog/devnote/blob/master/smtp.adoc 에 관련 도구들을 정리했다.
p218 공유 데이터 모델, 공유 스키마, 공유 테이블은 좋지 못한 방법이며, 마이크로서비스 개발을 재앙으로 이끌 수도 있다. 처음에는 좋은 수도 있지만, 복잡한 마이크로서비스를 개발하다 보면 데이터 모델 사이에 계속 관계를 추가하고, 조인 쿼리를 만들어내게 된다.
http://www.yes24.com/Product/Goods/38894134?OzSrank=1
인상 깊은 단락 148 제임스 고슬링이 자바 언어를 만들었던 의도가 웹을 만나면서 현실화 된 것이다.
149 이희승 님 언급
203 초등학생이라면 피지컬 컴퓨팅 추천
284 네이버 D2 소개
인상 깊은 단락 52p 글을 쓴다는 것은 어려운 작업이다. 명확한 문장은 그냥 나오는 것이 아니다. 처음부터, 심지어 세번째에도 제대로 된 문장이 나오는 경우는 드물다. 절망의 순간에 이것을 이억하라. 글을 쓰는 것이 힘든 이유는 그것이 원래 힘든 일이기 때문이다. - 엘리엄 진저 ‘글씨기 생각쓰기’ 돌베개, 2007년 중에서
116p 극단적으로 없앤 애플스토어의 엘레베이터 사례
144p 색상을 사용해 정보의 레이어를 구분하는 것은 인간 두뇌의 동작 원리를 이용하는 것이기 때문에 사용자에게 주는 부담이 매우 적다.
정리 116쪽 MSDN 원문일부 (https://msdn.microsoft.com/en-us/library/27db6csx%28v=vs.90%29.aspx)
In an “is a” relationship, the derived class is clearly a kind of the base class.
인상싶은 내용 31쪽 외부의 도움을 무시한 채 모든 것을 스스로 처리하려고 하는 전지전능한 객체(god object)는 내부적인 복잡도에 의해 자멸하고 만다.
68쪽 소프트웨어 안에 구축되는 객체지향 세계는 현실을 모방한 것이 아니다. 현실의 모습을 조금 참조할 뿐 궁극적인 목적은 현실과 전혀 다른 새로운 세계를 창조하는 것이다. 또한 객체지향 세계는 현실의 추상화가 아니다. 오히려 객체지향 세계의 거리는 현실 속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다.
131쪽 이름에서 풍기는 늬앙스와는 달리 테스트-주도 개발은 테스트 작성이 아니다.
인상 깊은 단락 p42 옆자리 증후군 (the next-bench syndrome) 이라는 단어의 유래도 HP다. 옆자리 동료에게 도움이 될 만한 기술이라면 개발할 가치가 있다는 뜻이다. 휴렛이 어느날 거대한 계산기를 보며 주머니에 들어가는 휴대용 계산기가 있으면 좋겠다는 아이디어를 낸다. 마케팅 부서에서 그런 계산기는 10배나 비쌀텐데 누가 사겠냐고 묻자, 휴렛은 가니느 살 거라며 개발을 시작한다. 거기에서 휴대용 전자 계산기 시장이 생겨났다.
p87 신규 직원 한명당 평균 350만원 정도다. 이해를 돕기 위해 비교를 해보자면, 구인활동에 쓰는 비용이 직원 한 명을 훈련하는 비용의 세 배에 이른다고 한다.
스프링을 이용한 RESTful 웹 서비스: 구축하기 실전 예제로 배우는 REST 방식의 스프링 웹 서비스
인상 깊은 단락 p194 http://goessner.net/articles/JsonPath/ https://github.com/FasterXML/jackson-module-jaxb-annotations/wiki
http://www.yes24.com/Product/Goods/13488109?OzSrank=1
11쪽 함수형 스타일은 객체 지향 프로그램(OOP) 방법을 거스르는 것이 아니다. 실제 패러다임의 변화는 명령형 스타일에서 서술적 스타일로 변경됐다는 것이다.
73쪽 파라미터 라우팅
177쪽 이거(eager) 방식은 간단하지만 레이지(lazy)방식은 효율적이다.
http://www.yes24.com/24/Goods/13486433?Acode=10
인상 깊은 단락 184,185 우선 역할을 세가지로 나눴다. 지금을 보는 역할, 1개월 후를 보는 역할, 그리고 3개월 후를 보는 역할이다. (중략.) 그리고 3개월후를 보는 역할을 맡은 사람은 이른바 인프라 전략을 담당한다. 인프라 구축에는 아무리 해도 시간이 걸리는 일이 있다. 서버 구매와 데이터 센터 스페이스 증강에는 보통 몇개월씩 걸린다. 회사로서도 투자액이 많은 부분이기도 하니, 경영진의 결재를 얻기 위해선 자료를 많이 준비할 필요가 있다.”
이미지 출처 : http://www.yes24.com/Product/Goods/8489379
인상 깊은 단락 p20 설령 예전에 작성한 것을 이용하여 재구현하기로 결정한 경우라도 주석 처리했던 코드는 통상적으로 딱 들어맞는 경우가 흔치 않다.
p39 침실 밖에서 일하라
p60 일정이 너무 상세하고 인도날짜가 너무 자주 다가온다면 진행하면서 애플리케이션의 세부사항을 실험하고 재고려할 재량권이 없어진다. 우리는 마치 무지하면서 사소한 일까지 챙기는 관리자가 끊임없이 우리 주위를 맴도는 것과 같이 추측된 태스크의 융퉁성 없는 일정을 고수할 수 밖에 없는 상황에 놓일 것이다.
https://www.yes24.com/Product/Goods/11524934
인상싶은 내용 226쪽 기업 내외의 환경을 분석할때 이용되는 프레임워크로는 다음과 같은 것이 있다.
3C분석 : Customer, Company, Competitor PEST 분석 : Politics, Economy, Society, Technology
인상 깊은 부분 62쪽 비록 자바 8이 스칼라나 C#의 람다에서 사용하는 ‘=>’ 기호 대신 작대기를 하나 슬그머니 내려놓은 ‘->’ 기호를 사용하는 것이 거슬리긴 하지만. 그 정도의 수준에서 자존심을 세우려는 것은 참아줄 수 있다
64쪽 (Joshua Bloch의 인터뷰)
우리가 자바에 클로저를 더 한다면 그것은 이미 지원되고 있는 문법의 테두리 안에서 조심스럽게 이루어져야할 것입니다. 즉, 클로저가 내부에 하나의 메서드만 가지고 있는 인터페이스를 구현하는 형태를 가져야한다는 뜻입니다. Runnable 같은 인터페이스나 TimerTask같은 클래스처럼 말입니다.
인상깊은 부분 p16 우울증을 앓는 사람은 우울한 기분의 원인을 외부에서 찾으려는 경향성을 나타낸다. … 자신의 내면을 통제하고 관리하는 사람은 다른 사람이 자신을 좋아하지 않는다는 사실을 받아들일 수 있다. 타인이 자신을 싫어한다고 하여 자신을 증오하는 우를 범하지 않는다.
p27 미육군의 리더십 메뉴얼에는 “리더는 스트레스 상황에서도 평성심을 유지하고 자신이 긍정적으로 영향을 줄 수 있는 일들에 대해서 에너지를 쏟으며, 자신이 영향을 끼칠 수 없는 일을 걱정하지 않는 것이 무척 중요하다"는 항목이 있다.
( 이미지 출처 Yes24 : http://www.yes24.com/24/Goods/3937865?Acode=101 )
감상 선배로부터 들었던 주옥같은 조언들, 평소 막연히 생각은 했지만 체계화하지 못했던 원칙들이 잘 정리되어 있다. 특정 개발환경에만 국한되지 않는 보편적인 원칙들로 채워져 있어서, 시간이 지나도 이 책의 가치는 바래지지 않을듯..
인상 깊은 부분 p65 동시에 여러 개를 변경하면 잘못된 결론에 이를 수 있다.
p68 뭐든지 우리가 이해하지 못하는 부분은 잠재적인 버그다.
p76 디버깅은 순간이지만 테스트는 남는다.
디버거가 디버깅 방법 중에서 가장 강력한 것임에는 틀림없다.
http://www.yes24.com/Product/Goods/11261731?OzSrank=1
인상 깊은 단락 32쪽 nanoTime()메서드는 만든 목적은 수행된 시간 측정이기 때문에 오늘의 날짜는 알아내는 부분에는 사용하면 안 된다.
157쪽 JDK5부터는 -XXX:+UseBiasedLocking라는 옵션을 통해서 biased lock이라는 기능을 제공한다.
210쪽 일부 회사에서는 자체 개발한 프레임워크를 사용하는데, 필자는 제발 그러지 말아줬으면 좋겠다.
214쪽 Apache Httpd의 keep alive 설정을 on
358쪽 GC로그 분석 툴소게. HPJmeter는 아파치의 JMeter와는 전혀 상관이 없는 모티러링 및 분석툴.
408쪽 AWStats와 Piwik소개
423쪽 튜닝결과 정리시의 유의점
감상 고등학교 때 축제 준비로 게임을 만든 이야기는 비슷한 추억이 있어서 반가웠고, 벤츠를 사는 걸 30대의 목표로 했다는 부분은 내가 차에 관심이 없어서인지 그다지 와닿지는 않는다. 벤츠는 언제 나오나 계속 궁금해하면서 읽었는데, 책의 후반부에 ‘그림6-1'로 나온다.. 그외에도 애자일, 게임 개발, 오픈소스 프로젝트, 개인사업 등 다양한 분야에 대한 저자의 경험을 이야기했다.
우리 나라 저자가 쓴 이런 종류의 책을 좋아하는데, 개인적으로 다른 분의 경험을 깊이 들으려면 책값보다 훨씬 비싼 술값, 시간이 들어간다고 생각하기 때문이다.
https://www.yes24.com/Product/Goods/8769400?Acode=101
인상 깊은 단락 p28 SOA에 대한 과거 예측
p48 SI의 한계.
훌륭한 프로그램은 남의 집에서 만들어지지 않는다.
p57 물질 문명 사회에서는 미처 생각하지 못한 부와 권력의 재구성이 지금 일어나고 있다.
p61 정부의 역할
p63 SI사들은 종합건설사 풍의 턴키 제공업자가 아닌 비트이 무역업, 즉 매시업을 지향하는 종합상사로 거듭난다.
p69 가상화의 혜택
p82 흉내내기 전략, 차별화, 사실상의 표준
p96 CD의 종말
p114 표준은 많은 경우 승자의 논리다.
감상 입문자에게 눈높이를 맞춰서 맛뵈기로 다양한 도구를 잘 소개했다. 해킹을 예방하는 규칙은 단순하다. 네트워크와 포트는 최소한도로 개방하고, 어플리케이션에 과도한 권한 안주고, 비밀번호 단순하게 하지 않고, 각종 패치 적용 잘하고.. 몰라서 못 지키는것은 아닌데, 설마하는 마음에 지나치기 쉽다. 이 책을 보면 해커들이 얼마나 편하게 쓸 수 있는 도구가 많은지를 알게 되어서 조금은 더 부지런하게 보안에 대비하게 될 것 같다.. 핵심 요약 1. 침투 테스트 소개 백트랙 리눅스 침투 테스트를 위한 종합 백화점
감상 저자 중 네 분이 지인이라 반가웠다. (유석문 님, 황상철 님, 이상민 님, 김성박 님)
p203 만약 여러분들이 신입사원이라면, 3~5년차 이내의 IT 회사에 있는 개발 직군의 직원이라면 개발을 하라. 뒤도 돌아 보지 말고, 주변을 둘러보지 말고 개발을 하라.
p212 IT 회사는 머리로 일하는 회사다. 머리를 지속적으로 사용하는 데에는 한계도 있고, 만약 지속해서 개발만 하다 보면 악성 코드가 양성되기 마련이다. 8시간 동안 일한 사람과 12시간 동안 일한 사람 중 누가 더 집중적으로 일할까?
감상 2010년 출판된 책이라서 2012년 현 시점에는 다소 맞지 않는 내용이 있다. 예를 들면 Google App Engine이 Python만 지원한다고 써 있는 내용. 관심가는 솔류션 http://www.valtira.com/ http://www.opentext.com/ : CMS 솔류션 http://mesh.com : 각종 디바이스 동기화, 원격 제어 클라우드 관리 솔류션 : http://enstratus.com/, http://www.rightscale.com/ 인상 깊은 내용 p20 마이크로소프트, Xen, VMWare 같은 엔터프라이즈 가상화 기술은 CPU제조업체가 지원하는 하드웨어 지원 가상화 기술을 제공하고, 실제 물리적 서버와 거의 유사한 수준까지 성능을 낸다.
이미지 출처 Yes24 (https://www.yes24.com/24/Goods/6982605?Acode=101)
감상 105페이지의 얇은책이고 전문적인 내용은 아닐꺼라 생각해서 큰 기대는 안 했다. 그런데 이외로 영감을 주는 사례들이 많았고 재밌었다. 빅데이터로 검찰, 국세청 개혁도 가능하다는 주장이 독창적이다. 빅데이터하고 직접적인 관련이 없는 소감이지만.. 아이폰 출시가 2009년 11월28일, 서울버스 앱은 2009년 12월 3일 출시.. 제작자는 만들면서 무척 재미있었을 것 같다.. 대기업에서는 혹시나 아이디어가 있는 사람이 있었어도 기획서 쓰고, 높으신 분 일정 맞춰서 기획 회의 한 5번하고, 서울시 담당자 한 5번 만나고, 상위기획서, 상세기획서하고 디자이너 할당하고, 개발할 엔지니어 찾는다고 한 2주 걸리고.
읽기 좋은 코드가 좋은 코드다: 더 나은 코드를 작성하는 간단하고 실전적인 테크닉
인상 깊은 단락 p89 무엇, 왜, 어떻게 중에서 어느 것을 설명해야 하는가?
“무엇(혹은 어떻게)이 아니라 왜를 설명하라"는 말을 들어 봤을 것이다. 이러한 조언은 그럴 듯하게 들리기는 하지만 상황을지나치게 단순화하고 있으며. 사람에 따라서 다른 의미로 받아 들여지기도 한다. 우리가 하고 싶은 말은, 사람들이 코드를 더 쉽게 읽을 수 있다면 그것이 무엇이든 싱관없이 기꺼이 설명하라는 것이다. 그 내용이 무엇,어떻게 혹은 왜 (또는 셋 모두) 중에서 어느 것을 포힘해도 상관없다.
생각 메모 프로젝트 목표 공유의 중요성. not list 케이크 - full stack web developer 인상적인 내용 사용자 스토리의 원칙..(INVEST - independent, negotiable, valuable, estiable, small, testable)
감상 편하게 잘 읽히는 책. ‘정신없이 개발한 소프트웨어가 제 정신일리 없다’, ‘협업에 대처하는 가장 좋은 방법은 역설적이게도 협업이 필요한 부분을 최소화하는 것인지도 모르겠다’ 같은 마음에 드는 문구들이 몇개 기억에 남는다. 이 시리즈 계속 나왔으면..
인상 깊은 단락 p20 문명 붕괴의 패턴을 읽다가 소프트웨어 역시 비슷한 양상으로 붕괴한다는 걸 깨달았다.
p47 그러나 개발자로서 가장 중요한 language는 우리말입니다.
p67 정신없이 개발한 결과물이 제 정신이 있기를 기대하는 건 좀 심하다는 생각이 든다.
인상 깊은 내용 p5 (번역판) 매쉬업과 리믹스라는 용어는 대중가요에서 유래된 말이다. 개략적으로 말하면 리믹스는 원본 음악의 변형된 버전인 반면 매쉬업은 두개나 그 이상의 음악요소를 합친 것을 의미한다.
p29 API에 대한 보다 공식적인 정의로서, Programmableweb.com의 존 무써는 다음과 같이 말하고 있다. “하나의 프로그램이 다른 프로그램의 접근을 허용해주어 직접 자신과 통신할 수 있도록 해주는 함수의 집합”
p401 23hq의 플리커 API 지원 사례
p668 Firefox에서 Microformat의 학습을 도와주는 Operator 확장기능
인상적인 단락 p5 단위테스트를 ‘다른 단위에 종속되지 않는 하나의 단위에 대한 테스트’
p71 개발자 입장에서 무언가를 잘못 수정할 때마다 바로바로 알려주는 누군가가 곁에 있어주는 것만큼 마음 든든한 일도 없다. 단위 테스트는 잘못된 부분을 찾기 위해 어플리케이션을 디버깅할 필요성을 줄여준다. 기능 테스트가 버그가 존재하는 유즈케이스를 골라주는 수준이라면, 단위 테스트는 어떤 메서드가 어떤 이유로 실패했는지도 이야기해준다. 즉 문제를 찾아 몇시간씩 헤매던 일에서 해방된다.
p99 숨겨진 종속성과 전역상태를 피하라 싱글톤은 애플리케이션에 전역 상태를 만들어낸다는 명백한 취약점이 존재한다.
감상 2014/03/07 임백준님, 이주연님의 뛰어난 글솜씨, 나와 같은 회사를 다니셨던 박재성님의 공감할만한 이야기 덕분에 재미있게 읽었다.
6명의 저자 중 4명이 기술사라서 다양한 진로의 경험을 전달하지 못한 점이 아쉽다. 기술사 시험에 합격하기 위해 얼마나 많은 노력을 했는지 이야기하는 내용이 몇 번 반복되고, 100여자루의 다쓴 볼펜 사진이 두 번이나 나온다. (이춘식님이 147쪽에, 신재용님이 300쪽에)
인상깊은 부분 p133 프로그래머가 프로그램을 실제로 코딩하는데 드는 시간은 얼마나 될까? 1985년 Fairly의 조사에 의하면 프로그래밍 작성에 13% 정도만 소요된다고 한다.
인상싶은 내용 72쪽 ps -Lf -p [pid]
208쪽 vmstat, sar
217쪽 리눅스 커널에서는 메모리의 내부 단편화를 해결하기 위해 슬랩 할당자라는 것을 사용한다.
229쪽 pstree
236쪽 pmap
263쪽 sar로 네트워크 사용량 확인
342쪽 –XX:+PrintConcurrentLocks –XX:+PrintClassHistorygram
인상깊은 내용 40쪽 버너스-리는 다음 날부터 구현하기 시작해, 그 해 크리스마스 휴가에 첫 버전의 서버와 브라우저를 완성시켰습니다.
54쪽 REST는 웹의 아키텍처 스타일입니다.
아키텍쳐 스타일은 ‘(매크로)아키텍처 패턴'이라고도 하며, 복수의 아키텍처의 공통된 설질, 양식, 규정 호근 독특한 방식을 가리키는말입니다. 아키텍처 스타리엔는 VMC와 파이프 앤 필터, 이벤트 시스템 등이 있습니다.
58쪽 리소스를 한마디로 설명하는, ‘웹상에 존재하는 일믕 가진 모든 정보'가 됩니다. … 리소스의 일므이란 URI를 말합니다.
http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788994120157&orderClick=LAH&LINK=PSM
인상 깊은 단락 트럭으로 된 MS 데이터 센터 스쿠터를 타고 다니는 구글 데이터 센터 kWh당 11센트 대신 2센트 정도의 수력전기 지대.. 수강신청,이벤트. 하이브리드 클라우드 Rackspace, Amazon 데이터센터 규모를 보여주는 자료.. Cloudwatch, Autoscaling,elastic load balancing MS. 30만대.. 구글 데이터센터 서버 초계 50만~60만대. 대규모 데이터센터들 중에서 서버를 4만5천대 이상 보유한 곳은 없다. 애플, 오레곤에 새 데이터센터 짓는다 밤에는 온도가 내려가 자연 냉각을 이용 가능 많은 수력발전을 만드는 콜롬비아 강에 있는 여러 댐 덕분에 토지와 전력비용이 저렴 VMWare hyperic HQ : x86 하드웨어의 명령집합을 소프트웨어에서 모방 EC2는 Xen 가상머신을 수정 p104 : VMWare의 수석과학자 리눅스는 군살 빼기에 좋다.
인상 깊은 단락 6쪽 기교로써 단지 대화에 익숙해지는 것만으로는 충분하지 않습니다. 존경심을 가지고 사람을 대하는 것을 배우고, 사람에 대한 성급한 판단을 버리는 것을 배우는 것이 영리한 아키텍트가 유능한 아키텍트로 변하는 핵심 기술 중 하나입니다.
38쪽 좋은 아키텍트는 사례르 통해 팀을 이끌어야 합니다. 아키텍트는 네트워크를 설치하고 빌드 프로세스를 설정하는 것에서부터 단위 테스트를 작성하고 벤치마킹을 수행하는 것까지 자신의 팀 내 어떠한 역할도 수행할수 있어야 합니다. … 훌륭한 아키텍트는 문제를 찾아내어 팀을 소집하고, 희생자를 지적해내지 않고, 무엇이 문제인지 설명하고, 정교한 대안이나 해결책을 제시할 수 있어야 합니다.
인상 깊은 단락 p42 반면 소프트웨어의 경우는 소프트웨어 프로젝트마다 독특하며 이전 프로젝트에서 했던 것을 가져다 활요할 수 있는 것이 많지 않다. 덴버공항 수하물 처리 시스템이 그러 했다. 독일 스트라우스공항에서 수하물 처리 시스템을 만들었던 경험은 덴버공항 수하물 처리 시스템 개발에는 결정적인 도움이 되지 않았다.
p237 고객이 요청한 것 하나를 들어주면 우리는 다른 서비스나 기능 하나를 제거해야 한다. 이렇게 해야 고객의 요청을 부담 없이 처리하면서 다른 부담스러운 일을 제거할 수 있다.
인상깊은 부분 p16 디자인은 한번 굳어버리는 순간 바로 구식이 된다 -프레드브룩스
p81 테이블이 사용 중일 때는 위험을 최소화하기 위해 컬럼 제거에 대한 시간 계획이 필요하다. 다른 방법으로는 ALTER TABLE 명령의 SET UNUSED 옵션을 이용하여 컬럼을 사용되지 않는 컬럼으로 표기하는 것이다. SET UNUSED 명령은 보다 빠를 뿐만 아니라 위험을 최소화할 수 있다.
p205 데이터 마이그레이션 기법 : 오라클의 SQLLDR이나 bul loader와 같은 데이터베이스 유틸리티를 이용할 수 있다.
생각 메모 체계적으로 잘 정리되어 있으나, 책 두께에 비하면 핵심은 많지는 않음 많은 용어가 경험있는 사람에게는 섬세한 구분으로 와 닿을듯하나, 그렇지 않은 사람에게는 부담이 될 수도 있을듯 관련 링크 http://xunitpatterns.com/ https://martinfowler.com/bliki/TestDouble.html 정리 Fixture : SUT(System under test)를 실행하기 위해 필요한 모든 것 픽스처를 설치하기 위해 호출하는 테스트 로직부분 setup : 테스트 대상 시스템(SUT)에서 원하는 로직을 실행시키기 위해 설치해야 하는 테스트 선조건, 모든 객체와 객체의 상태 뒷문설치 공유 픽스처 신선한 픽스쳐(Fresh Fixture).
http://osdi.insightbook.co.kr/
인상깊은 부분 25쪽 커널 관점에서는 특정 태스크나 워크로드에서 0.5~1% 아끼는 게 전체적인 면에서는 그다지 중요하지 않습니다. 커널 개발 프로젝트 입장에서는 그렇게 아끼는 것보다 장기적으로 봤을 때 코드가 관리, 지속 가능하고 장기 목표를 얼마나 잘 성취할 수 있을까 하는 것이 중요하죠. 아껴서 돈을 버는 게 아니라 프로젝트를 건강하게 오래 유지하는 것이 목표니까요. 서로 목표가 다른 것이라고 볼 수 있습니다. 서비스 제공사는 서비스 개선에 우선순위를 두고 개발하는 것이 중요하지만 저는 아무래도 업스트림 커널 개발자이다 보니 장기적인 목표에 관심이 더 많았습니다.
감상 다양한 주제(특히 GWT)를 다룬 점과 예제를 모두 돌려보고 정리한 역자의 역할이 돋보인다. 그런데 getter/setter까지 굳이 다 인쇄하고, 개선이 가능해보이는 예제코드는 다소 아쉬운 점이 남는다. 보면서 따라서 입력해보고 스스로 개선해보라는 의도였을지도..
감상 개인적인 성장을 위해서 팀이나 고객을 이용하려 하기보다 공동체의 다양한 관심사를 기꺼이 더 우선시하는 것은, 장인 정신에 바탕한 접근 방식의 특징적인 면 중 하나이다”
개발자로서의 명예욕구가 큰 사람이 팀과 잘 조화를 이루지 못하는 경우를 보기도해서, 눈에 띄는 문구
인상 깊은 부분 p67 시간이 지남에 따라 이런 벤더 테스트 코드는 라이브러리를 최신 버전으로 업그레이드 했을 때 시스템에 문제를 발생시키는지 검사하는 용도로도 쓸 수 있다.
p71 http://erlangish.blogspot.com/2007/05/shape-of-your-mind.html 의 내용 프로그래밍 언어가 미치는 영향성.
인상깊은 내용 36쪽 번다운 차트 사용
38쪽 또 다른 위험은 ‘자원 안배를 잘 못해서 잃어버리는 시간'이다. 어려운 문제인 줄 정작알았더라면 개발자를 두세 명 더 투입하거나 선임 개발자를 붙였을 게다. 팀원들이 프로젝트 위험을 줄이려고 노력하기보다 기능 날짜를 맞추는데만 급급하다면 프로젝트는 그만큼 소중한 시간을 잃는다.
40쪽 기존공학이 수백 아니 수천 년에 걸쳐 쌓아온 경험적 예측성을 소프트웨어 공학에서 기대해서는 안된다.
42쪽 기능 완료일을 맞추라고 팀을 닦달하면 팀은 편법으로날짜를 맞추거나 거짓말을 둘러댄다.
감상 Java의 기초를 테스트코드로 설명한 Agile Java를 보고, 프레임웍도 그렇게 설명했으면 좋겠다고 생각했었는데,Toby님의 책이 그러한듯하다. testability, 좋은 설계 같은 핵심은 시간이 지나도 빛이 바래지 않을 것이고, 최신버전은 오히려 부차적 것일지도
감상2 (2012/11/25 추가) 아래는 일민형의 부탁으로 토비의 스프링 3.1에 들어간 추천사
토비님의 블로그를 통해 이 책의 집필 소식을 알게 되었고, 출판을 오랫동안 기다렸었다. 마지막까지 인쇄 사고로 배송이 지연되는애 태우는 일정 끝에 책을 받아들고는 비싼 전자기기를 산 기분보다 더 뿌듯했었다. 책을 받은 다음날부터 무거운 책을 출퇴근길에 들고 다니면서 완독을 했었다.
감상 2010.06.20 만일 당신이 때때로 실패하지 않는다면, 그건 안이하게 살고 있다는 확실한 증거다. -우디앨런
JUnit, Mock 라이브러리 등에 대한 최신 설명이 잘 정리되어 있다. 내년도 신입사원 교육도 내가 하게 된다면, 이 책을 참고도서로 강추할 예정.
인상 깊은 단락 p98 JUnit 탄생 일화
p249 Mock 프레임워크 트렌드
p321 실패라는 건 없다. 모든 건 피브백일 뿐이다. - 로버트 알렌
p446 SI에서 TDD
감상 2010-06-05 ‘위피'의무 탑재가 폐지된 것이 불과 2009년4월이였다니..
결국 혁신은 정책에 의해 하사되지 않았고, 시장경제의 압력을 타고 유입되었다. 밖에서는 의미없는 국지적 아류작이 될 수밖에 없는 ‘우리만의 플랫폼'의 한계. 여기서 교훈을 얻을 수 있는 사람들이 더 많았으면.
2010-02-10 어제 Adobe 세미나 때문에 생각나서 이 책의 2장을 다시 펴봤다. 실버라이드, 닷넷 서버프레임웍, 윈도우즈 OS, WPE 등까지 모든 스택을 다 가지고 있는 MS와 대응하는 스택을 제시하려면, Adobe는 Java 기술들과 계속 친하게 지내야 할듯하다.
감상 몇년전에 이 책을 봤을 때에는 ‘상식적인 내용을 체계적으로 잘 정리했군’ 정도로 큰 감흥이 없었다. 그런데 상식이라고 생각한 것을 결론으로 내든 근거로 쓰든 간에, 여러 상식을 묶어서 다른 이를 설득하려면 체계성이 가장 중요하다는 것을 이제서야 조금 깨닳은 듯 하다.
https://www.yes24.com/Product/Goods/3600609
감상 2024.02.15 다시 읽어보면 떠오르는 일들이 더 많을 것 같다.
2010.01.21 특히나 더 인상 깊은 단락들
모든 설계 결정을 내리는 영웅이나, 모든 요구사항을 결정하는 영웅이나, 모든 아키텍처 결정을 내리는 영웅이 바로 병목을 일으키는 원인이다
최근 ‘지나친 의욕은 민폐를 불러일으킨다'라는 말이 몇번 떠올랐는데, 일맥상통하는 내용이이다.
흔히 프로세스 개선 그룹, 표준 제정 그룹, 품질 부서 등이 업무 프로세스나 수행방식을 명시한다. (중략) 대개 그들은 업무를 제대로 이해하지도 못하면서 업무 방식을 정해주는 외부인에 불과하다
감상 SOA는 구체적인 기술이 아니라, 구조를 의미한다.
SOA를 하기 위해서 꼭 특정기술을 써야한다는 주장만이 들리고 있고, 다른 선택을 말할 수 없는 상황이라면, 시스템의 이해관계자 중 솔류션 벤더사나 특정 개발 조직의 이익만이 정치적으로 관철되어 있는 상황이 아닐까?
인상깊은 부분 20쪽 SOA는 엔터프라이즈 기술 표준이 아니다. 이는 SOA가 IIOP나 SOAP 같은 특정 단일 기술 프로토콜에 의존적이지 않다는 것을 의미한다. 대신 SOA는 아키텍처 청사진을 뜻하여, 이는 많은 상이한 기술들을 통합할 수 있고, 특정 프로토콜이나 연계기술을 요구하지 않는다는 것을 의미한다.
감상 시간이 지나서 다소 빛이 바랜 내용도 있지만, 이 책이 2002년도에, 그것도 당시 32살정도였던 사람이 썼다니 감탄이 나올 뿐이다.
인상 깊은 단락 p120 Strictly seaping, this is a special case of the Strategy design pattern: it appears different because the interfaces involved are so simple. )
소개된 도구 https://gant.github.io/ http://schemaspy.sourceforge.net/ http://www.jroller.com/pulse/entry/getting_started_with_pulse : 개발환경 동기회 Eclipse plugin. 지금은 사라진듯. 인상깊은 부분 53쪽 하지만 일반 사용자에겐 편한 환경에 파워 유저의 능률은 오히려 떨어뜨린다. .. 지난 20년간 있었던 가장 기막힌 변화 중 하나는 파워유저의 단순 반복 작업 처리 속도가 오히려 느려진 점이다. 예전 유닉스 상요자가 이보다 훨씬 효율적이었던 이유는 모두 자동화했기 때문이다.
138쪽 오버엔지니어링 사례 : EJB, JSF
인상 깊은 단락 p27 빨간눈 승려 문제
p57 폰 노이만 일화
p59 1~100중 하나의 숫자가 남았을때 남은 숫자 확인
99개의 값을 저장할 수 있는 배열 item[O], item[1], , item[98]이 있댜 1부터 100까지의 값이 들어 있는 집합 {1, 2, 3, , 100}에서 무작위로 수를 꺼내서 배열에 저장했다. 집합에 들어 있는 원소의 수는 100개인 데 반해서 배열은 값을 99개까지만 저장할 수 있으므로 집합 안에 하나 의 숫자가 남았다. 남은 것이 어느 수인지 확인할 수 있는 프로그램을 작성하라.
인상깊은 부분 많은 C개발자들이 플랫폼마다 달라지는 코드를 처리할때 조건부 컴파일을 이용한다. 나는 여러분에게 조건부 컴파일을 피하라고 제안한다. 코드를 지저분하게 만들기 때문이다. 또한 특정 상황에서 어떤 코드가 실제로 컴파일 되는지 알아보기도 힘들다.
(중략) 플랫폼마다 따로 구현될 함수들의 프로토타입을 정의하는 헤더 파일을 만들었다. 그런 다음 각 플랫폼 구현을 해당 디렉터리에 넣어서 분리시켰다. 우리는 전처리기 대신에 컴파일러와 링커를 사용했다.’
추천사 … 이 책 ‘임베디드 C를 위한 TDD'는 기존의'코딩 많이 하고 디버깅 시작하기’ 식의 개발 방법과 TDD가 어떻게 다른지 본질적인 차리를 잘 보여준다.
인상 깊은 단락 p42 멜빈 콘웨이 (Melvin Conway) 는 168년 데이터메이션(Datamation)지에서 이렇게 설명했습니다. “시스템을 설계하는 조직들은 자신들의 조직 사이에 의사소통 구조(communication structure)를 모방한 형태의 설계를 만든다. 이것은 콘웨이 법칙(Conway’s law)이라고 합니다. 예를 들자면, ‘네 개의 팀이 하나의 컴파일에서 작업할 때, 2단계(four-pass) 컴파일럴르 얻는 것'이 바로 대표적인 콘웨이 법칙입니다.
p128 이렇듯 맛없는 개떡을 먹을 때보다 더 고약한 경험인 남이 만든 방법론을 맹목적으로 따를 때, 구성원 에게서 ‘책임감의 부재’ ‘동기부여의 상실’ ‘악의적인 순응'이라는 문제가 발생한다고 하니다.
인상 싶은 부분 Chapter 2 (번역판 p109) 유즈케이스는 새로 만든 시스템이나 소프트웨어 변경 사항에 대한 요구사항을 찾아내는 방법입니다. 각 유즈케이스는 특정목표를 달성하기 위해 시스템이 사용자 또는 다른 시스템과 어떻게 상호작용하는지를 전달하는 하나 이상의 시나리오를 제공합니다.
https://www.yes24.com/Product/Goods/108192370
2판에서 달라진점 페이지별 제목이 큰 흐름 맥락에서의 목적을 드러내는 방식으로 바뀌고 기존 제목은 작게 표시 예: 바뀌는 부분을 찾아내봅시다 -> 최첨단 피자코드 만들기(바뀌는 부분을 찾아내봅시다) 복습하거나 중간에 있는 내용을 찾아보기에는 더 편해진 느낌이다. 낱말퀴즈가 전반적으로 바뀌어 있음. 2장 옵져버 패턴 java.util.Observer를 쓰던 예제가 2판에서는 직접 정의한 인터페이스를 쓰도록 변경 Java8이후에는 java.util.Observer 등이 거의 안 쓰인다는 설명도 추가 됨. 5장 싱글턴 패턴 Q&A에서 2가지 질문 추가 (p218) 리플렉션, 직렬화 역질력화에서의 문제는 없는지 느슨한 결합 원칙에 위배되지 않는지 Enum을 이용한 싱글턴 구현 소개 (p219) 6장 커맨드 패턴 구상 커맨트 객체를 람다 표현식으로 바꾸는 예제 추가 (p250) Swing 예제로도 커맨드 패턴 설명 (p265, p270) 7장 템플릿 메서드 Applet 예제를 AbstractList를 활용하는 예제로 대체 (p343) 8장 반복자 패턴, 컴포지트 패턴 Iterable 인터페이스, 향상된 for 구문에 대한 설명 추가 (p377-379) 복합 반복자, 널 반복자 등의 내용은 삭제됨 (1판의 p406~p413) 패턴과 설명 연결 퀴즈에서 스테이트 패턴이 빠지고 전략 패턴이 들어감(1판 p417, 2판 p409) 11장 프록시 패턴 동적 클래스 다운로딩 방식 설명 삭제(1판 p486) 인터페이스 이름 변경 PersonBean -> Person (1판 p513-514, p517, 2판 p504-505, p508) Q&A에서 RMI관련 질문 2개 삭제(1판 p524, 2판 p514) 정리 7장 템플릿 메서드 Array.
참고 5장 내용은 http://www.hanbit.co.kr/web/example/1594/progimagine_chapter5.pdf 에
인상깊은 부분 p124 충분히 무르익은 기술은 눈에 보이지 않게 된다는 아서 클라크(Arthur C. Clark)의 말처럼 컴퓨터의 물리적 존재는 점점 우리의 논앞에서 사라지고 있다.
p184 미국에서 대학원을 다니던 시절에 잠깐 용돈을 벌기 위해서 심리학과 교수의 ‘인터뷰 자료 수집 프로그램'을 비주얼베이식으로 작성해준 적이 있는데, 내가 만들어 놓은 프로그램을 보고 심리학과 학생이 비슷한 프로그램을 금방 작성했던 것이 기억난다.
p259 시간이 부족하다는 변명과 유닛테스트라는 개념에 대한 혼동은 확실히 취향의 문제가 아니라 수준의 문제이다.
29 스포츠 기자였던 레드 스미스(Red Smith 1906~1982)는 “글쓰는 것은 쉽다. 그저 혈관을 열고 피를 흘리면 된다.“고 말하기를 좋아했습니다.
126 브루스 슈나이더의 말
“기술이 보안 문제를 해결할 수 있다고 생각한다면, 문제도, 기술 자체도 이해하지 못한 것입니다.”
339 포넬리의 법칙 - 예제는 아무리 많아도 지나치지 않다.
341 인류학자인 마가렛 미드(Margaret Mead, 1901 ~ 1978)가 “사려 깊고 헌신적인 작은 그룹의 시민이 세상을 바꿀 수 있음을 절대 의심하지 말라. 실로 세상을 바꾼 것은 그런 소그룹뿐이었다.
지속적인 통합: 소프트웨어 품질을 높이고 위험을 줄이기
인상 깊은 단락 47쪽 품질이란 누가 보지 않을 때에도 제대로 돌아가는 걸 뜻한다.
137쪽 테스트 분류
단위테스트 컴포넌트 테스트 시스템 테스트: JWebUnit 처럼 기능테스트(=인수테스트) : 실제 브라우저 사용 JWebUnit 예제
156쪽 테스트 케이스 하나에 ASSERT 하나로 제한하기
167쪽 수년간 이 메트릭에 대해 다양한 연구를 했는데, 10보다 큰 CCN을 가진 메서드는 같은 코드의 다른 코드보다 결함이 발생할 위험이 크다는 게 밝혀졌습니다.
인상싶은 내용 185쪽 로거에서 메서드 정보 등을 알아내기 위해 일부러 예외를 던지는 기법
241쪽 Apache Httpd의 ThreadsPerChild
273쪽 JMX를 쓸 때 별도의 파일로 id,pw를 지정하는 방법
282쪽 웹로그 분석툴 http://www.awstats.org/
323쪽 JDK의 -Xss 옵션 : 스레드 스택 크기
감상 2022-09-19 얼마 전에 차민창님을 만나서 최근 ‘구현 패턴'을 다시 읽으니 이전과는 또 다른 느낌이 든다는 이야기를 들었다. 나도 오랜만에 이 책을 펼쳐보니 책 날개에 있는 문장부터 많은 생각을 떠올리게 한다. TDD by exmaple도 두번째 읽었을때 처음 읽었을때 놓힌 것이 이렇게 많았는지 놀랬던 기억이 있다.
켄트백은 함축적, 추상적인 표현으로 추구하는 가치나 감정에 대한 이야기를 종종 한다. 경험이 쌓일수록 그런 문구에서 떠오르는 영감이 더 커지는듯하다. 전형적인 개발자는 다들 그러하듯이, 난 구체적인 표현을 좋아한다.
http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=2657930&CategoryNumber=001001003005006001
감상 2007.10.22 마이크로소프트웨어지에 ‘커뮤니티 노트'라는 컬럼을 연재하고 계신 최재훈님이 번역하신 책입니다. 사실 처음 책의 목차만을 보았을 때는 ‘실용주의 프로그래머'와 겹쳐지는 내용이 많을 것 같은 느낌에 큰 기대를 하지는 않고 읽기 시작했었습니다. 아마 제가 블로그를 통해서 이 책을 알지 못하고 서점에서 우연찮게 만났다면 책을 안 사고 지나쳤을 수도 있었을 것입니다. 그런데 다 읽고나니 다음에 프로젝트 시작할 때는 사비로라도 이 책을 사서 프로젝트 팀원들에게 돌리고 싶다는 생각이 들더군요.
이 책에서는 프로젝트를 성공적으로 이끄는 해결책으로 다음의 방법들을 제시하고 있습니다.
인상적인 내용 구현이 연구자와 필자들에게 경시되어온 또 다른 이유는, 다른 소프트웨어 개발활동과 비교했을 때 구현은 상대적으로 기계적인 과정이며 개선의 여지가 없다는 잘못된 생각 때문이다. 이는 사실과 완전히 다르다.
예술 비평가들이 모이면 그들은 형태와 구조, 그리고 의미에 대해 이야기를 나눈다. 하지만 예술가들이 모이면 그들은 값 싼 테레빈유를 어디서 살 수 있는지에 대해 이야기를 나눈다.
만약 6살짜리 꼬마에게 설명할수 없다면, 이해한다고 볼 수 없다.
인상 깊은 내용 puzzle 57 (141쪽) hashCode() 미구현 사례
puzzle 61 (151쪽) Calendar 클래스의 월지정 실수
puzzle 62(155쪽) String 상수와 IdentityHashMap을 쓸 때의 문제
puzzle 68(172쪽) 변수와 타입이 같은 이름을 갖고 있고, 이 둘이 같은 영역에 있을 때는 변수 이름의 우선 순위가 높다. 비슷하게 변수와 타입의 일므을 패키지 이름을 가릴 수 있다.
상수 이름과 클래스 이름 간의 충돌을 방지하기 위해서는, 클래스 이름을 지을 때 약어를 보통 단어처럼 취급하는 것이 좋다. [EJ Item 38].
인상 깊은 단락 p53 업무의 구분
프로젝트 업무 임시 업무 지속 업무 정기 업무 관리 p83 사람은 한 번에 한 프로젝트에 배치하세요
p89 팀과 부서의 차이
일반적으로 작다. 즉 다섯명에서열 명의 구성원으로 이뤄진다. 공동의 목적이나 목표가 있다. 일 처리시 서로 합의한 접근 방식이 있다. 서로 보완하는 능력이 있다. 상호 관련되거나 서로 독립적인 임시 목표가 있다. 서로에게 넘겨줄 작업을 약속한다. p200 효과적인 피드백을 위한 지침.
원서 : https://www.amazon.com/Software-Conflict-2-0-Science-Engineering-ebook/dp/B002GYWP1K/
인상 깊은 단락 p19 업계 실무에서 최고 수준과 평균 수준이 이렇게 차이가 나는 분야는 거의 없다.
p37 설계의 핵심 요소는 해결책을 제안하고 실패를 허용하는 능력이다.
성공하려면 실패하는 능력과 실패를 극복하는 능력이 필수적이다.
p40 ‘The Mythical Man Month'와 최근 ‘Sillver Bullet’ 논문에서 프레드 브룩스는 현존 최고 제품, 즉 개념적 일관성이 있다고 우리 모두가 인정하는 작품은 개인이 설계한 작품이라는 사실을 지적한다.
p41 설계 수행 면에서, 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실을, 오히려 시행착오를 거쳐가며 반복하던 엉성한 절차가 바로 설계 핵심이란느 사실을 이해해야한다.
https://www.yes24.com/Product/UsedShopHub/Hub/121164506
감상 2023.10.17 한 2년차 쯤에 책으로 웹표준을 처음 공부했었던 기억이 난다.
당시에 쓴 글 : https://blog.benelog.net/1314658.html 2013년도에 개정판이 나와었고, 지금은 개정판도 절판되었다.
http://www.yes24.com/Product/Goods/1418676?OzSrank=1
인상 깊은 단락 p24 저자의 화려한 경력
p29 많은 프로젝트의 성공과 실패는 어떻게 수행하는가보다 누가 수행하는가에 따라 결정된다.
p31 사람 경시 풍조
사람은 빡빡한 스케쥴과 압박 하에서 일을 더 잘 한다고 주장한다.
p33 잃어버린 곳이 아닌 밝은 곳에서 물건 찾기 일화
소프트웨어 분야에 있는 우리는 모두 마음속으로는 기술자라고 생각하며, 우리의 작업을 쉽게 하는 새로운 기술을 고안하는 것을 더 좋아한다. 마음속 깊은 곳에서는 사람과 관련된 문제가 더 중요하다는 것을 알면서도 말이다.
http://www.yes24.com/Product/Goods/2160417
프리팩토링: 효과적인 시스템 설계와 변경을 위한 프리팩토링 지침 65가지
인상 깊은 단락 94쪽 테스트될 수 없다면, 요구하지도 말라.
128쪽 간단한 일을 잘하면 자주 불릴 것이다. 특정한 일을 수행하는 메서드가 클래스가 더 자주 재사용될수 있다.
151쪽 많은 원칙들을 생략할 수록 목표를 좀더 빨리 달성할 수 있을 것이라는 착각에 빠지게 된다. 이는 더 많은 코드를 작성하려고 먹는 시간을 줄이는 것과는 다르다. 먹지 않으면 결국 나중에 후회하게 될 것이다.
인상깊은 부분 73쪽 특정 변수를 선언할 때 volatile 키워드를 지정하면, 컴파일러와 런타임 모두 ‘이 변수는 공유해 사용하고, 따라서 실행 순서를 재배치해서는 안된다'고 이해한다. volatile로 지정된 변수는 프로세서의 레지스터에 캐쉬되지도 않고, 프로세서 외부의 캐시에도 들어가지 않기 때문에 volatile 변수의 값을 읽으면 항상 다른 스레드가 보관해둔 최신의 값을 읽어갈 수 있다.
205쪽 더군다나 자바에는 스레드가 가업을 실행하고 있을때 강제로 멈추도록 하는 방법이 없다.
210쪽 스태틱으로 선언된 interrupted 메서드를 호출하면 현재 스레드의 인터럽트 상태를 해제하고, 해제학 이지너의 값이 무엇이썼는지를 알려준다.
인상깊은 부분 385쪽 역자주: 사실 국어 실력과 프로그래밍 실력 사이에는 깊은 관련이 있다.
484쪽 해당 영역에서 개인 퍼포먼스의 최고 수중는 경험을 오래했다고 해서 자동으로 획득되지 않을뿐 아니라, 개선하려는 의도적 노력의 결과로서 가능하며, 심지어 매우 경험이 많은 개인들조차도 자신의 퍼포머스 레벨을 높일 수 있다.
인상깊은 부분 113쪽 리팩토링을 하지 않을 때에도 잘 짜여진 테스트는 프로그래밍을 빠르게 한다는 것을 알게 되었다.
122쪽 버그리포트를 받으면, ㅁ너저 그 버글르 밖으로 드러나게 할 수 있는 단위 테스트를 작성하라.
123쪽 완전한 테스트를 실행시키지 않는 것보다는 불완전한 테스트라도 작성하고 실행시키는 것이 더 낫다.
? 한 벌의 테스트는 버그를 찾는데 걸리는 시간을 엄청나게 단축시키는 강력한 버그 탐지기이다.
? 테스트로 모든 버그를 잡을 수 없다는 걱정 때문에 대부분의 버그를 잡을 수 있는 테스트를 작성하는 것을 멈추지 마라.
https://www.yes24.com/Product/UsedShopHub/Hub/1809610
감상 2023.10.17 입문서인데 RMI와 EJB를 소개한 내용이 당시의 시대 경향을 반영한다.
인상 깊은 단락 p89 원수 변수와 레퍼런스 변수를 설명한 페이지. 레퍼런스 변수는 컵에 담겨진 리모컨으로 비유를 했다.
인상 깊은 단락 31 지식노동자는 ‘무아지경'이라는 ‘흐름flow'에 빠져들어야 생산성을 최대로 발휘할수 있다는 사실을 우리 모두 잘 알고 있습니다.
101 게임회사의 출시일정. vaporware에 많이 올라와있음.
105 과업은 날짜 단위가 아니라 시간 단위로 측정할 수 있어야만 합니다.
125 스티브맥코넬이 일일 빌드에 대해 쓴 글
138 오픈소스의 사용성에 대한 글 링크
221 C에서의 상수 비교 습관. 조엘은 좋은 프로그래머의 습관이라고 생각함.
239 개발자는 멀티태스킹 기계가 아닙니다.
277 개발자 대부분은 바이트를 이동하는 대신에 API를 호출하는 방법으로 이 시대를 살아가고 있습니다.
인상 깊은 부분 25쪽 TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다. “일주일간 종이에다 설계한 다음 코드를 테스트 주도로 개발한다면 이것도 TDD인가” 물론, TDD다. 결정과 그에 대한 피드백 사이의 간격을 인지하고, 또 의식적으로 제어했기 때문이다.
26쪽 동시성 테스트와 CSP
145쪽 TDD로 구현할 땐 테스트 코드이 줄 수와 모델 코드의 줄 수가 거의 비슷한 상태로 끝난다.
인상 깊은 부분 49쪽 사람들은 안전하다고 느끼지 않는 한 변화를 수용하지 않는다.
62쪽 협박은 실적을 유도하기에는 불완전한 방법이다.
98쪽 최소한 단기간에 생산성을 높이기 위해서 할 수 있는 일은 사실상 아무것도 없기 때문에 제 생각에는 시간을 헛되게 쓰지 않도록 하는데 전적으로 맞추게 될 거에요
102쪽 생산성에 관한 단기적인 해결방법은 없다. 생산성 향상은 장기적인 투자의 결과다.
112쪽 프로젝트 초기에 잃어버린 한시간은 프로젝트 마지막에 잃어버린 하루와 같은 손실이 된다.
인상 깊은 단락 6쪽 소프트웨어 엔지니어링은 소프트웨어의 개발, 운영, 그리고 유지보수에 대한 체계적이고, 훈련되고, 측정 가능한 접근 방식의 애플리케이션이다. 즉, 소프트웨어에 대한 엔지니어링 애플리케이션이다.
18쪽 어쩋든 노동의 분할은 산업혁명의 기초였다. 더 작고 잘 정의된 작업으로 제조 활동을 나누는 것에 의해, 그룹의 생산성은 급격히 증가되었다. 물론 이 접근 방식은 소프트웨어 개발에도 적용될수 있을 것이다. … 그러나 그렇지 않다. 작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는데에 더 많은 시간이 걸린다.
인상싶은 내용 68쪽 “공학"의 사전적 의미는 수학의 원리와 과학을 응용하여 실세계의 문제를 해결하는 것이다. … 공학이 현실적이지 않다면 그것은 공학이 아니다.
75쪽 브룩스는 .. 소프트웨어 개발의 본질은 서로 맞물러 돌아가는 여러 컨셉들을 명세화하고 설계하며 검증하는 것이라고 주장했다. 또, 그는 솔프트웨어가 어려운 이유가 그 본질적인ㄴ 복작성, 일치성, 변화가능성, 비가시성 때문이라고 했다.
77쪽 그렇다면 1968년에는 변하지 않는 핵심(stable core)이 얼마나 있었을까? (별로 없었음)