Coders at Work를 읽고 - 2

2009/12/21 - [Book Review] - Coders at Work를 읽고 - 1


Joshua Bloch 선 마이크로시스템즈에서 자바 작업. 현재 구글의 수석 자바 아키텍트

Another is Elements of Style, which isn't even a programming book. You should read it for two reasons: The first is that a large part of every software engineer's job is writing prose. If you can't write precise, coherent, readable specs, nobody is going to be able to use your stuff. So anything that improves your prose style is good. The second reason is that most of the ideas in that book are also applicable to programs. p. 171
역시 글쓰기의 중요성을 강조하는군요.
But when you choose a language, you're choosing more than a set of technical trade-offs - you're choosing a community. It's like choosing a bar. Yes, you want to go to a bar that serves good drinks, but that's not the most important thing. It's who hangs out there and what they talk about. p. 174
프로그래밍 언어의 선택이 단순히 기술적인 결정이 아니라는거죠. 단골 술집에의 비유가 참신하네요. 
James Gosling once said to me, discussing the birth of Java, "Occasionally you get to hit the reset button. That's one of the most marvelous things that can happen. " Usually, you have to maintain compatibility with stuff that's decade old; rarely, you don't, and it's great when that happens. But unfortunately, as you can see with Java, it only takes you a decade until you're the problem. p. 191
ㅎㅎ 새로 시작하는 것은 참 좋죠. 흔치 않은 기회고요. 하지만 가는 세월 앞에 새로웠던 코드가 리거시legacy 코드가 되는 것은 막을 길이 없는거겠죠... 꾸준한 리팩토링과 유지보수로 늦출 수는 있겠으나 엔트로피는 증가하게 마련.
But I think a big sin in our area, in engineering, is doing stuff just because it's neat, because it's good engineering, whatever. If you're not solving real problems for real users - in this case, Java programmers - then you shouldn't add the feature. p. 195
이 책을 관통하는 핵심 질문 중 하나인 프로그래머는 과연 공학자인가 과학자인가 예술가인가 장인인가 하는 문제와도 연관되는 내용. 게임 프로그래밍에서는 특히나 명심해야할 부분이겠는데... 역시 말처럼 지키기 쉽지만은 않은 명제입니다.
There's a brilliant quote by Tony Hoare in his Turing Award speech about how there are two ways to design a system: "One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." p. 196
아주 단순하게 만들여 '결함이 확실히 없도록' 하거나 아주 복잡하게 만들어 '확실한 결함이 없도록' 하거나...
But merely the fact that they're the smartest people in the organization doesn't mean they should be making all the decisions, because intelligence is not a scalar quantity; it's a vector quantity. And if you lack empathy or emotional intelligence, then you shouldn't be designing APIs or GUIs or languages. p. 203
지능은 스칼라가 아닌 벡터값이다!


Joe Armstrong 얼랭Erlang 언어와 그 대표적 응용프로그램 프레임웍인 Open Telecom Platform의 창시자

I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. p. 213
서서히 개체지향이 프로그래밍의 핵심 조류에서 밀려나는 느낌을 여러 곳에서 받습니다. 멀티코어 및 매니코어manycore의 필연적 대두가 그 주요 원인 중 하나입니다. 바나나를 원했는데, 나오는건 바나나를 든 고릴라와 정글의 온갖 것이다라... 왠지 마음에 와 닿습니다.
One that's tricky is slight spelling errors in variable names. So I choose variable names that are very dissimilar, deliberately, so that error won't occur. If you've got a long variable like personName and you've got personNames with an "s" on the end, that's a list of person names, that will be something that my eye wil tend to read what I thought it should have been. And so I'd have personName and then listOfPeople. And I do that deliberately because I know that my eye will see what I thought I'd written. p. 220
personName이란 변수가 있고 사람 이름 목록에 해당하는 변수가 필요하다면, personNames 보다는 listOfPeople을 택하겠다는 의견. 작명이 프로그래밍에서도 참 어렵고 중요한 문제입니다. 영어를 잘해야 하는 또 하나의 이유.
What we learned later was, it wasn't all that easy to discover new stuff. And it's incredibly difficult to get people to use new and better stuff. p. 220
새로운 것을 발견하고 만들어내기도 어렵지만, 새로운 것을 사람들이 받아들이게 하는 것은 훨씬 더 어렵다...
Things you don't do are difficult and things you've done are easy. So you don't even try. And I think that's a mistake. p. 223
심감독의 유명한 말이 생각나네요...;
Good to thrash your ideas out in front of the crowd. You're put in a position of explaining your ideas which, for me, moves them from one part of my brain to another part. Often when you explain things then you understand them better. p. 228
자신의 아이디어를 남에게 설명하는 과정에서, 생각이 정리되는 느낌, 다들 경험해 보셨죠?
The code shows me what it does. It doesn't show me what it's supposed to do. I think the code is the answer to a problem. If you don't have the spec or you don't have any documentation, you have to guess what the problem is from your answer. You might guess wrong. I want to be told what the problem is. p.231-232
코드는 문제에 대한 답이다. 문서나 명세가 없다면 답에서 문제를 추측해낼 수밖에 없다. 문서화의 필요성에 대한 명쾌한 설명!
And Hamming said, "I always spend a day a week learning a new stuff. That means I spend 20 percent more of my time than my colleagues learning new stuff. Now 20 percent at compound interest means that after four and a half years I will know twice as much as them. And because of compound interest, this 20 percent extra, one day a week, after five years I will know three times as much," or whatever the figures are. p. 234
매일 조금씩의 학습에 대한 투자가 나중에는 복리로 크게 불어난다는 이야기. 제가 사람을 뽑을 때 가장 중요하게 보는 부분 중 하나입니다. 얼마나 학습 열의가 있느냐 하는 것이죠.


* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다. 


크리에이티브 커먼즈 라이선스
Creative Commons License

'Book Review' 카테고리의 다른 글

Coders at Work를 읽고 - 3  (0) 2010/02/03
Coders at Work를 읽고 - 2  (0) 2010/01/16
Coders at Work를 읽고 - 1  (4) 2009/12/21
프로그래밍 언어의 창시자들  (0) 2009/09/17
글쓰기 공작소 - 나도 글 잘 쓰고 싶다  (4) 2009/07/31
수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘  (0) 2009/07/13
Trackback 0 Comment 0
top