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/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(작업 기억 공간)에서 인지 과정이 함께/상호보완적으로 일어난다.
읽기 좋은 코드가 좋은 코드다: 더 나은 코드를 작성하는 간단하고 실전적인 테크닉
인상 깊은 단락 p89 무엇, 왜, 어떻게 중에서 어느 것을 설명해야 하는가?
“무엇(혹은 어떻게)이 아니라 왜를 설명하라"는 말을 들어 봤을 것이다. 이러한 조언은 그럴 듯하게 들리기는 하지만 상황을지나치게 단순화하고 있으며. 사람에 따라서 다른 의미로 받아 들여지기도 한다. 우리가 하고 싶은 말은, 사람들이 코드를 더 쉽게 읽을 수 있다면 그것이 무엇이든 싱관없이 기꺼이 설명하라는 것이다. 그 내용이 무엇,어떻게 혹은 왜 (또는 셋 모두) 중에서 어느 것을 포힘해도 상관없다.
감상 2022-09-19 얼마 전에 차민창님을 만나서 최근 ‘구현 패턴'을 다시 읽으니 이전과는 또 다른 느낌이 든다는 이야기를 들었다. 나도 오랜만에 이 책을 펼쳐보니 책 날개에 있는 문장부터 많은 생각을 떠올리게 한다. TDD by exmaple도 두번째 읽었을때 처음 읽었을때 놓힌 것이 이렇게 많았는지 놀랬던 기억이 있다.
켄트백은 함축적, 추상적인 표현으로 추구하는 가치나 감정에 대한 이야기를 종종 한다. 경험이 쌓일수록 그런 문구에서 떠오르는 영감이 더 커지는듯하다. 전형적인 개발자는 다들 그러하듯이, 난 구체적인 표현을 좋아한다.
인상적인 내용 구현이 연구자와 필자들에게 경시되어온 또 다른 이유는, 다른 소프트웨어 개발활동과 비교했을 때 구현은 상대적으로 기계적인 과정이며 개선의 여지가 없다는 잘못된 생각 때문이다. 이는 사실과 완전히 다르다.
예술 비평가들이 모이면 그들은 형태와 구조, 그리고 의미에 대해 이야기를 나눈다. 하지만 예술가들이 모이면 그들은 값 싼 테레빈유를 어디서 살 수 있는지에 대해 이야기를 나눈다.
만약 6살짜리 꼬마에게 설명할수 없다면, 이해한다고 볼 수 없다.
http://www.yes24.com/Product/Goods/2160417
프리팩토링: 효과적인 시스템 설계와 변경을 위한 프리팩토링 지침 65가지
인상 깊은 단락 94쪽 테스트될 수 없다면, 요구하지도 말라.
128쪽 간단한 일을 잘하면 자주 불릴 것이다. 특정한 일을 수행하는 메서드가 클래스가 더 자주 재사용될수 있다.
151쪽 많은 원칙들을 생략할 수록 목표를 좀더 빨리 달성할 수 있을 것이라는 착각에 빠지게 된다. 이는 더 많은 코드를 작성하려고 먹는 시간을 줄이는 것과는 다르다. 먹지 않으면 결국 나중에 후회하게 될 것이다.
인상깊은 부분 113쪽 리팩토링을 하지 않을 때에도 잘 짜여진 테스트는 프로그래밍을 빠르게 한다는 것을 알게 되었다.
122쪽 버그리포트를 받으면, ㅁ너저 그 버글르 밖으로 드러나게 할 수 있는 단위 테스트를 작성하라.
123쪽 완전한 테스트를 실행시키지 않는 것보다는 불완전한 테스트라도 작성하고 실행시키는 것이 더 낫다.
? 한 벌의 테스트는 버그를 찾는데 걸리는 시간을 엄청나게 단축시키는 강력한 버그 탐지기이다.
? 테스트로 모든 버그를 잡을 수 없다는 걱정 때문에 대부분의 버그를 잡을 수 있는 테스트를 작성하는 것을 멈추지 마라.