감상 2020.06.30 ( ‘SI에서 비지니스는 쿼리에 있어야 합니다.’ 등 70, 81, 82, 85페이지를 읽고 소감)
‘ArrayList 가 thread safe 하기 때문에'라고 적어놓은 것이 우선 흥미롭다. ‘ArrayList'의 JavaDoc을 보면 그렇지 않다는 것을 바로 알 수 있기 때문이다. ‘Note that this implementation is not synchronized.’ 라는 문구가 굵은 글씨도 강조되어 있다. 저자가 그런것은 관심을 둘 필요가 없다는것을 강조하기 위해 위와 같이 정확하지 않게 기술한 것일수도 있겠다.
암튼 SQL에 최대한 많은 로직을 두고, Java단에는 Map만 넘기는 개발스타일이 SI에서 선호되는 이유는 다음과 같다고 나는 생각한다.
나는 LINE 개발자입니다 : 라인의 개발 고수 12인의 도전과 기회, 성장의 개발 라이프
감상 2019.09.21 책의 저자분들이 다들 글을 잘 쓰셔서 잘 읽혔고, 출퇴근길에 재밌게 빠르게 읽을수 있었다. 아는 분들이 나와서 반갑기도했다. 개발자들이 경험을 풀어놓은 이런 책을 좋아해서 가급적 사본다. 책이 아니었다면 술자리에서 몇시간 동안 이야기해야 들을수 있는 이야기일법하다. 이 책의 책값 만이천원으로 12번의 술자리를 대신한 느낌이다.
https://www.facebook.com/benelog/posts/2422516247784435
인상 깊은 단락 p42 옆자리 증후군 (the next-bench syndrome) 이라는 단어의 유래도 HP다. 옆자리 동료에게 도움이 될 만한 기술이라면 개발할 가치가 있다는 뜻이다. 휴렛이 어느날 거대한 계산기를 보며 주머니에 들어가는 휴대용 계산기가 있으면 좋겠다는 아이디어를 낸다. 마케팅 부서에서 그런 계산기는 10배나 비쌀텐데 누가 사겠냐고 묻자, 휴렛은 가니느 살 거라며 개발을 시작한다. 거기에서 휴대용 전자 계산기 시장이 생겨났다.
p87 신규 직원 한명당 평균 350만원 정도다. 이해를 돕기 위해 비교를 해보자면, 구인활동에 쓰는 비용이 직원 한 명을 훈련하는 비용의 세 배에 이른다고 한다.
이미지 출처 : http://www.yes24.com/Product/Goods/8489379
인상 깊은 단락 p20 설령 예전에 작성한 것을 이용하여 재구현하기로 결정한 경우라도 주석 처리했던 코드는 통상적으로 딱 들어맞는 경우가 흔치 않다.
p39 침실 밖에서 일하라
p60 일정이 너무 상세하고 인도날짜가 너무 자주 다가온다면 진행하면서 애플리케이션의 세부사항을 실험하고 재고려할 재량권이 없어진다. 우리는 마치 무지하면서 사소한 일까지 챙기는 관리자가 끊임없이 우리 주위를 맴도는 것과 같이 추측된 태스크의 융퉁성 없는 일정을 고수할 수 밖에 없는 상황에 놓일 것이다.
인상 깊은 부분 62쪽 비록 자바 8이 스칼라나 C#의 람다에서 사용하는 ‘=>’ 기호 대신 작대기를 하나 슬그머니 내려놓은 ‘->’ 기호를 사용하는 것이 거슬리긴 하지만. 그 정도의 수준에서 자존심을 세우려는 것은 참아줄 수 있다
64쪽 (Joshua Bloch의 인터뷰)
우리가 자바에 클로저를 더 한다면 그것은 이미 지원되고 있는 문법의 테두리 안에서 조심스럽게 이루어져야할 것입니다. 즉, 클로저가 내부에 하나의 메서드만 가지고 있는 인터페이스를 구현하는 형태를 가져야한다는 뜻입니다. Runnable 같은 인터페이스나 TimerTask같은 클래스처럼 말입니다.
인상깊은 부분 p16 우울증을 앓는 사람은 우울한 기분의 원인을 외부에서 찾으려는 경향성을 나타낸다. … 자신의 내면을 통제하고 관리하는 사람은 다른 사람이 자신을 좋아하지 않는다는 사실을 받아들일 수 있다. 타인이 자신을 싫어한다고 하여 자신을 증오하는 우를 범하지 않는다.
p27 미육군의 리더십 메뉴얼에는 “리더는 스트레스 상황에서도 평성심을 유지하고 자신이 긍정적으로 영향을 줄 수 있는 일들에 대해서 에너지를 쏟으며, 자신이 영향을 끼칠 수 없는 일을 걱정하지 않는 것이 무척 중요하다"는 항목이 있다.
감상 고등학교 때 축제 준비로 게임을 만든 이야기는 비슷한 추억이 있어서 반가웠고, 벤츠를 사는 걸 30대의 목표로 했다는 부분은 내가 차에 관심이 없어서인지 그다지 와닿지는 않는다. 벤츠는 언제 나오나 계속 궁금해하면서 읽었는데, 책의 후반부에 ‘그림6-1'로 나온다.. 그외에도 애자일, 게임 개발, 오픈소스 프로젝트, 개인사업 등 다양한 분야에 대한 저자의 경험을 이야기했다.
우리 나라 저자가 쓴 이런 종류의 책을 좋아하는데, 개인적으로 다른 분의 경험을 깊이 들으려면 책값보다 훨씬 비싼 술값, 시간이 들어간다고 생각하기 때문이다.
감상 저자 중 네 분이 지인이라 반가웠다. (유석문 님, 황상철 님, 이상민 님, 김성박 님)
p203 만약 여러분들이 신입사원이라면, 3~5년차 이내의 IT 회사에 있는 개발 직군의 직원이라면 개발을 하라. 뒤도 돌아 보지 말고, 주변을 둘러보지 말고 개발을 하라.
p212 IT 회사는 머리로 일하는 회사다. 머리를 지속적으로 사용하는 데에는 한계도 있고, 만약 지속해서 개발만 하다 보면 악성 코드가 양성되기 마련이다. 8시간 동안 일한 사람과 12시간 동안 일한 사람 중 누가 더 집중적으로 일할까?
감상 편하게 잘 읽히는 책. ‘정신없이 개발한 소프트웨어가 제 정신일리 없다’, ‘협업에 대처하는 가장 좋은 방법은 역설적이게도 협업이 필요한 부분을 최소화하는 것인지도 모르겠다’ 같은 마음에 드는 문구들이 몇개 기억에 남는다. 이 시리즈 계속 나왔으면..
인상 깊은 단락 p20 문명 붕괴의 패턴을 읽다가 소프트웨어 역시 비슷한 양상으로 붕괴한다는 걸 깨달았다.
p47 그러나 개발자로서 가장 중요한 language는 우리말입니다.
p67 정신없이 개발한 결과물이 제 정신이 있기를 기대하는 건 좀 심하다는 생각이 든다.
감상 2014/03/07 임백준님, 이주연님의 뛰어난 글솜씨, 나와 같은 회사를 다니셨던 박재성님의 공감할만한 이야기 덕분에 재미있게 읽었다.
6명의 저자 중 4명이 기술사라서 다양한 진로의 경험을 전달하지 못한 점이 아쉽다. 기술사 시험에 합격하기 위해 얼마나 많은 노력을 했는지 이야기하는 내용이 몇 번 반복되고, 100여자루의 다쓴 볼펜 사진이 두 번이나 나온다. (이춘식님이 147쪽에, 신재용님이 300쪽에)
인상깊은 부분 p133 프로그래머가 프로그램을 실제로 코딩하는데 드는 시간은 얼마나 될까? 1985년 Fairly의 조사에 의하면 프로그래밍 작성에 13% 정도만 소요된다고 한다.
인상 깊은 단락 p42 반면 소프트웨어의 경우는 소프트웨어 프로젝트마다 독특하며 이전 프로젝트에서 했던 것을 가져다 활요할 수 있는 것이 많지 않다. 덴버공항 수하물 처리 시스템이 그러 했다. 독일 스트라우스공항에서 수하물 처리 시스템을 만들었던 경험은 덴버공항 수하물 처리 시스템 개발에는 결정적인 도움이 되지 않았다.
p237 고객이 요청한 것 하나를 들어주면 우리는 다른 서비스나 기능 하나를 제거해야 한다. 이렇게 해야 고객의 요청을 부담 없이 처리하면서 다른 부담스러운 일을 제거할 수 있다.
참고 5장 내용은 http://www.hanbit.co.kr/web/example/1594/progimagine_chapter5.pdf 에
인상깊은 부분 p124 충분히 무르익은 기술은 눈에 보이지 않게 된다는 아서 클라크(Arthur C. Clark)의 말처럼 컴퓨터의 물리적 존재는 점점 우리의 논앞에서 사라지고 있다.
p184 미국에서 대학원을 다니던 시절에 잠깐 용돈을 벌기 위해서 심리학과 교수의 ‘인터뷰 자료 수집 프로그램'을 비주얼베이식으로 작성해준 적이 있는데, 내가 만들어 놓은 프로그램을 보고 심리학과 학생이 비슷한 프로그램을 금방 작성했던 것이 기억난다.
p259 시간이 부족하다는 변명과 유닛테스트라는 개념에 대한 혼동은 확실히 취향의 문제가 아니라 수준의 문제이다.
인상 깊은 단락 31 지식노동자는 ‘무아지경'이라는 ‘흐름flow'에 빠져들어야 생산성을 최대로 발휘할수 있다는 사실을 우리 모두 잘 알고 있습니다.
101 게임회사의 출시일정. vaporware에 많이 올라와있음.
105 과업은 날짜 단위가 아니라 시간 단위로 측정할 수 있어야만 합니다.
125 스티브맥코넬이 일일 빌드에 대해 쓴 글
138 오픈소스의 사용성에 대한 글 링크
221 C에서의 상수 비교 습관. 조엘은 좋은 프로그래머의 습관이라고 생각함.
239 개발자는 멀티태스킹 기계가 아닙니다.
277 개발자 대부분은 바이트를 이동하는 대신에 API를 호출하는 방법으로 이 시대를 살아가고 있습니다.