읽던 책에 인상 깊었던 구절을 적어두고 관련된 책을 엮어서 칼럼을 써볼까 합니다.
클린 코드, CS(컴퓨터사이언스)와 객체지향 관련해서 다룰 예정이며
클린 코드의 경우 읽기 좋은 코드가 좋은 코드다, PPP 시리즈 Clean Code를 정리하고 나서 칼럼을 써 볼까 하며
CS 의 경우 PPP 시리즈 CODE, 밑바닥부터 만드는 컴퓨팅 시스템
객체지향의 경우 객체지향의 사실과 오해, 오브젝트 책을 정리하고 칼럼을 적어 볼까 합니다.
그에 앞서 모든 범주에 속하는 기본적인 개발교양 책 한권에 대한 정리자료부터 올립니다.
니시오 히로카즈 저 / 김완섭 역
비제이퍼블릭
프로그램 어떤 것을 편하게 하기 위해 고안된 것이다. 편하게 하는 것은 부실하게 하는 것과는 다르다. 부실하게 만들어서 나중에 고생케 하는 것은 편하게 만들었다고 볼 수 없다. p11
올바른 설계는 사용하는 사람이 무엇을 목적으로 하고 있는지에 따라 달라진다. 다양한 설계 언어가 있는 것은 사람에 따라 다양한 목적이 있기 때문이다. 빠른 속도를 위해 만들어진 C++과 수운 코드 해석을 위해 설계된 Python을 비교해서 C++이 읽기 어렵다느니 Python이 느리다느니 하는 것은 유익하지 못한 논쟁이다. p13
이해력을 확인하기 위해서는 결과물(Output)을 확인한다. p23
'무엇을 배울지, 무엇을 배우면 좋을지'를 정할 때 필연적으로 지표가 될 수 있는 것이 '무엇을 만들고 싶은가?' 즉 목적을 명확히 하는 것이다 그리고 목적을 달성하기 위해 필요한 것부터 배우면 된다. p26
if ans, while 문, for 문을 사용하지 않아도 프로그램을 짤 수 있다. 그러나 사용하는 것이 보다 알기 쉬운 코드를 구성할 수 있다. 알기 쉬운 코드를 만들기 위해 적극적으로 사용하도록 하자. p40
'전지'라는 이름으로 인해, 전지를 사용한 시스템을 간단히 이해할 수 있다. 전지의 구조를 상세히 알지 못해도 '전지는 전기를 만들어 내는 것이다'라는 지식만으로 초등학생이라도 무선 조정 자동차를 조립할 수 있다 . 그리고 무선 조정 자동차가 느려지면 '전지가 약해졌다'고 생각할 수 있다. 이것은 함수가 이해를 도와주는 것과 비슷하다. p43
세상은 계속 바뀌고 있다. 즉, 응용 범위가 제한된 구체적인 하우투는 점점 그가치를 잃어간다. 하우투뿐만 아니라 의적으로 응용범위가 넓은 추상적 개념을 배울 필요가 있다.
반면 추상적인 지식을 배워도 여러분이 가지고 있는 경험과 연관시키지 못하면 응용할 수 없다. 벚꽃이 가지고 싶다고 꽃이 피어있는 가지를 잘라와도 꽃이 죽어버리면 그만이다. 매년 꽃을 피게 하기 위해선 뿌리가 필요하다 p81
저자가 직접 쓴 자료나 소스가 가장 상세하다고 치자. 그러나 '어렵다', '양이 많다', '영어라서 읽을 수 없다' 등의 변명으로 다른 사람이 쓴 쉬운 설명을 찾으려고 한다. 그것은 '원래 고기는 너무 크고 먹기가 어려워'라고 하며, 안전한지 확인도 안하고 다른 사람이 만든 다진 고기를 먹는 것과 동일하다. P82
전체 모두 읽지 않는 것이 께름칙한가? 하지만 좌절하고 전혀 읽지 않는 것보다는 낫다. '전부 읽지 않으면'이라는 완벽 주의가 배우고자 하는 동기를 짓누르고 있다면, 버려버리는 것이 낫다. 동기는 매우 중요하다. p84
대략적인 부분을 잡아서 조금씩 상세화한다. p139
명확히 '하고 싶은 것', '조사하고 싶은 것'이 없어 '대충 읽으면' 읽은 내용이 뇌를 그냥 스쳐 지나갈 뿐이다. 이런 상태에서 어떻게 배울까를 고민한다고 해도 판단을 위한 지식자체가 없기 때문에 무의미하다. 그래서 지식의 밑바탕을 만들기 위해서 교과서를 그대로 베껴 쓴다.(25분간 어디까지 베낄 수 있는지 도전) 237p
How(어떻게 만들까?)에 주력하기 쉽지만, What(무엇을 만들까?), Why(왜 만들까?)도 잊어서는 안 된다. How는 수단에 불과하다. 239p
