음성 검색
QR/바코드 검색
품목정보
| 발행일 | 2013년 03월 29일 |
|---|---|
| 쪽수, 무게, 크기 | 368쪽 | 670g | 188*240*30mm |
| ISBN13 | 9788998139179 |
| ISBN10 | 8998139170 |
제프 앳우드 저 / 임백준 역
|
위키북스
|
2013년 03월 29일
저자/출판사 더보기/감추기
- IT 모바일 top20 5주
eBook이 출간되면 알려드립니다.
eBook 출간 알림 신청
분철서비스 시작 시 알려드립니다.
분철서비스 알림신청
- 원서이동
- 이미 소장하고 있다면 판매해 보세요! 이 상품 팔기 매입가 1,300원 더보기/감추기
- 해외배송 가능
- 최저가 보상
- 문화비소득공제 신청가능
.jpg)
관련분류
이 상품의 태그
책소개 책소개 보이기/감추기
목차 목차 보이기/감추기
저자 소개 관련자료 보이기/감추기
저자 : 제프 앳우드(Jeff Atwood)
제프 앳우드는 캘리포니아 버클리에서 아내, 두 마리 고양이, 세 명의 아이들, 그리고 여러 대의 컴퓨터와 함께 살고 있다. 그는 80년대 자신의 첫 번째 마이크로컴퓨터였던 텍사스 인스트루먼트의 TI-99/4a를 이용해 다양한 마이크로소프트 베이직 프로그램을 구현하면서 소프트웨어 개발자의 길을 걷기 시작했다. 90년대 초반까지 계속 PC상에서 비주얼 베이직 3.0과 윈도우 3.1을 사용했고, 델파이의 최초 버전을 이용해 파스칼 코드도 많이 작성했다. 현재는 대소문자에 민감한 사악한 속성에도 불구하고 VB.NET 혹은 C# 프로그래밍에 익숙하다. 지금은 루비를 배우고 있다.
앳우드는 개발자가 읽어야 할 도서 목록에서 밝힌 것처럼 스스로를 소프트웨어 개발 과정에 존재하는 인간적인 측면에 특별히 관심이 있는, 상당히 경험이 풍부한 윈도웹(Windowsweb) 소프트웨어 개발자라고 생각한다. 그가 주장하는 바에 따르면 컴퓨터는 놀라운 기계이지만 사실상 그것을 사용하는 사람을 단순히 반영하는 기계에 불과하며, 소프트웨어 개발의 기술적인 측면은 코드를 학습하는 것만으로는 충족되지 않고 소프트웨어의 배후에 존재하는 사람도 함께 연구해야 한다.
앳우드는 개발자가 읽어야 할 도서 목록에서 밝힌 것처럼 스스로를 소프트웨어 개발 과정에 존재하는 인간적인 측면에 특별히 관심이 있는, 상당히 경험이 풍부한 윈도웹(Windowsweb) 소프트웨어 개발자라고 생각한다. 그가 주장하는 바에 따르면 컴퓨터는 놀라운 기계이지만 사실상 그것을 사용하는 사람을 단순히 반영하는 기계에 불과하며, 소프트웨어 개발의 기술적인 측면은 코드를 학습하는 것만으로는 충족되지 않고 소프트웨어의 배후에 존재하는 사람도 함께 연구해야 한다.
저자 : 임백준
서울대학교에서 수학을 전공하고, 인디애나 주립대학에서 컴퓨터 사이언스를 공부했다. 삼성SDS, 뉴저지 소재 루슨트테크놀로지스에서 근무했고, 지금은 월스트리트에서 금융 소프트웨어를 개발하고 있다. 뉴저지에서 아내와 두 딸과 함께 살고 있다. 《누워서 읽는 퍼즐북》(2010), [프로그래밍은 상상이다》(2008), 《뉴욕의 프로그래머》(2007), 《소프트웨어 산책》(2005), 《나는 프로그래머다》(2004), 《누워서 읽는 알고리즘》(2003), 《행복한 프로그래밍》(2003, 이상 한빛미디어), 《프로그래머 그 다음 이야기》(2011, 로드북)을 집필했고, 다수의 책을 번역했다.
책 속으로 책속으로 보이기/감추기
소프트웨어 개발자로서의 당신은, 자기 자신의 가장 큰 적이다. 이 사실을 일찍 깨달을수록 더 훌륭한 프로그래머가 될 수 있다.
물론 당신이 좋은 의도를 가지고 있다는 사실은 이해한다. 누구나 다 그렇다. 우리는 모두 소프트웨어 개발자다. 우리는 코드를 작성하는 사람들이다. 그것이 우리가 하는 일이다. 실력이 뛰어난 프로그래머인 우리는 약간의 이사용 테이프, 옷걸이, 그리고 바로 코드를 이용해서 해결할 수 없는 문제를 만난 적이 없다. 하지만 윌 쉬플리(Will Shipley)는 너무 많은 코드를 작성하고자 하는 우리의 자연스러운 내적 경향을 억제해야 한다고 주장한다.
*****
코딩의 근본적인 속성에 따르면 프로그래머인 우리가 내리는 모든 결정에는 그 자체로 장점과 단점이 동시에 포함돼 있다. 프로그래밍의 진정한 장인이 되는 길은 바로 그러한 장단점의 본질을 잘 이해하고, 우리가 작성하는 모든 코드의 구석구석에서 언제나 그러한 사실을 잊지 않는 데 있다.
코드를 평가할 때 우리가 취할 수 있는 측정 방법으로는 여러 가지가 있다.
? 코드의 간결함
? 기능의 풍부함
? 실행 속도
? 코드 작성에 걸린 시간
? 안정성
? 유연성
기억할 것은 이러한 측면들이 모두 각자 반대되는 방향으로 뻗어나간다는 사실이다. 예를 들어 당신은 정말로 아름답고 빠르게 동작하는 코드를 장장 삼일에 걸쳐 작성할 수 있다. 이 경우 두 개의 차원은 상승하는 방향으로 움직이지만, 코드를 너무 오랫동안 작성했으므로 하나의 차원은 완전히 하락하는 방향으로 움직인다.
그렇다면 어떤 상황에서 어떤 것에 가치를 둬야 할지 어떻게 알 수 있는가? 그러한 결정을 어떻게 내리는가? 이러한 질문에 대한 대답은 너무나 당연하고 간단하기 때문에 아무도 들으려고 하지 않는다. 대답은 바로 간결함에서 시작하라는 것이다. 테스트를 수행하는 과정에서 다른 차원으로 나아갈 필요가 있다고 생각되면 필요한 내용을 그때 추가해도 늦지 않다.
*****
나는 이러한 주장에 전적으로 동의한다. 개발자들에게 더 적은 코드(Code Smaller)를 작성하길 권장할 때 이와 비슷한 주장을 펼친 바 있다. 이것은 단지 코드의 물리적인 분량을 최소로 만들기 위해 우리가 아는 온갖 기법들을 총동원해야 한다는 식의, 귀류법에 대한 이야기를 하고 있는 것이 아니다. 어떤 프로그래머 개인이 읽고 이해해야 하는 프로그램 코드의 분량을 최소한으로 줄이기 위한 실질적이고 타당한 감소 전략에 대해 말하고 있는 것이다. 내가 말하고자 하는 바를 설명하기 위한 예를 살펴보자.
if (s == String.Empty) if(s == "")
이 두 if 구문 중에서 나는 두 번째 if가 더 낫다고 본다. 더 짧기 때문이다. 그렇지만 나는 String.Empty라는 장황한 표현이 컴파일러에게는 더 효율적이라는 주장에 목숨을 걸 정도로 확신하는 개발자를 만나게 되리라는 사실을 잘 알고 있다. 마치 그런 주장에 내가 관심이 있기라도 한 것처럼. 혹은 그런 주장에 관심을 갖는 사람이 마치 있기라도 한 것처럼 말이다!
그와 같은 극단적인 주장을 인정하는 것은 대부분의 프로그래머에게 괴로운 일일 것이다. 그들은 코딩이라는 행위를 너무나 사랑하기 때문이다. 하지만 최선의 코드는 아예 코드가 없는 것이다. 당신이 세상 안으로 끌어들이려고 애쓰는 코드는 모든 줄마다 반드시 디버깅해야 하고, 누군가 읽고 이해해야 하며, 유지보수해야 한다. 당신이 새로운 코드를 한 줄 작성할 때마다 이러한 일들을 반드시 수행해야 한다. 다른 선택의 여지가 없기 때문이다. 코드가 우리의 적인 이유는 결국 우리 프로그래머들이 터무니없을 정도로 많은 코드를 작성하기 때문이다. 그렇지만 아예 코드를 작성하지 않는 것은 말이 되지 않는다. 그렇다면 차선책은 바로 간결함에서 시작하는 것이다.
코드를 작성하는 것을 사랑한다면, 그러니까 진짜로 코딩을 사랑한다면 가급적 적은 분량의 코드를 작성하는 것조차 충분히 사랑할 수 있을 것이다.
물론 당신이 좋은 의도를 가지고 있다는 사실은 이해한다. 누구나 다 그렇다. 우리는 모두 소프트웨어 개발자다. 우리는 코드를 작성하는 사람들이다. 그것이 우리가 하는 일이다. 실력이 뛰어난 프로그래머인 우리는 약간의 이사용 테이프, 옷걸이, 그리고 바로 코드를 이용해서 해결할 수 없는 문제를 만난 적이 없다. 하지만 윌 쉬플리(Will Shipley)는 너무 많은 코드를 작성하고자 하는 우리의 자연스러운 내적 경향을 억제해야 한다고 주장한다.
*****
코딩의 근본적인 속성에 따르면 프로그래머인 우리가 내리는 모든 결정에는 그 자체로 장점과 단점이 동시에 포함돼 있다. 프로그래밍의 진정한 장인이 되는 길은 바로 그러한 장단점의 본질을 잘 이해하고, 우리가 작성하는 모든 코드의 구석구석에서 언제나 그러한 사실을 잊지 않는 데 있다.
코드를 평가할 때 우리가 취할 수 있는 측정 방법으로는 여러 가지가 있다.
? 코드의 간결함
? 기능의 풍부함
? 실행 속도
? 코드 작성에 걸린 시간
? 안정성
? 유연성
기억할 것은 이러한 측면들이 모두 각자 반대되는 방향으로 뻗어나간다는 사실이다. 예를 들어 당신은 정말로 아름답고 빠르게 동작하는 코드를 장장 삼일에 걸쳐 작성할 수 있다. 이 경우 두 개의 차원은 상승하는 방향으로 움직이지만, 코드를 너무 오랫동안 작성했으므로 하나의 차원은 완전히 하락하는 방향으로 움직인다.
그렇다면 어떤 상황에서 어떤 것에 가치를 둬야 할지 어떻게 알 수 있는가? 그러한 결정을 어떻게 내리는가? 이러한 질문에 대한 대답은 너무나 당연하고 간단하기 때문에 아무도 들으려고 하지 않는다. 대답은 바로 간결함에서 시작하라는 것이다. 테스트를 수행하는 과정에서 다른 차원으로 나아갈 필요가 있다고 생각되면 필요한 내용을 그때 추가해도 늦지 않다.
*****
나는 이러한 주장에 전적으로 동의한다. 개발자들에게 더 적은 코드(Code Smaller)를 작성하길 권장할 때 이와 비슷한 주장을 펼친 바 있다. 이것은 단지 코드의 물리적인 분량을 최소로 만들기 위해 우리가 아는 온갖 기법들을 총동원해야 한다는 식의, 귀류법에 대한 이야기를 하고 있는 것이 아니다. 어떤 프로그래머 개인이 읽고 이해해야 하는 프로그램 코드의 분량을 최소한으로 줄이기 위한 실질적이고 타당한 감소 전략에 대해 말하고 있는 것이다. 내가 말하고자 하는 바를 설명하기 위한 예를 살펴보자.
if (s == String.Empty) if(s == "")
이 두 if 구문 중에서 나는 두 번째 if가 더 낫다고 본다. 더 짧기 때문이다. 그렇지만 나는 String.Empty라는 장황한 표현이 컴파일러에게는 더 효율적이라는 주장에 목숨을 걸 정도로 확신하는 개발자를 만나게 되리라는 사실을 잘 알고 있다. 마치 그런 주장에 내가 관심이 있기라도 한 것처럼. 혹은 그런 주장에 관심을 갖는 사람이 마치 있기라도 한 것처럼 말이다!
그와 같은 극단적인 주장을 인정하는 것은 대부분의 프로그래머에게 괴로운 일일 것이다. 그들은 코딩이라는 행위를 너무나 사랑하기 때문이다. 하지만 최선의 코드는 아예 코드가 없는 것이다. 당신이 세상 안으로 끌어들이려고 애쓰는 코드는 모든 줄마다 반드시 디버깅해야 하고, 누군가 읽고 이해해야 하며, 유지보수해야 한다. 당신이 새로운 코드를 한 줄 작성할 때마다 이러한 일들을 반드시 수행해야 한다. 다른 선택의 여지가 없기 때문이다. 코드가 우리의 적인 이유는 결국 우리 프로그래머들이 터무니없을 정도로 많은 코드를 작성하기 때문이다. 그렇지만 아예 코드를 작성하지 않는 것은 말이 되지 않는다. 그렇다면 차선책은 바로 간결함에서 시작하는 것이다.
코드를 작성하는 것을 사랑한다면, 그러니까 진짜로 코딩을 사랑한다면 가급적 적은 분량의 코드를 작성하는 것조차 충분히 사랑할 수 있을 것이다.
--- 본문 중에서
출판사 리뷰 출판사 리뷰 보이기/감추기
배송/반품/교환 안내
배송 안내
| 배송 구분 |
예스24 배송
|
|---|---|
| 포장 안내 |
안전하고 정확한 포장을 위해 CCTV를 설치하여 운영하고 있습니다. 고객님께 배송되는 모든 상품을 CCTV로 녹화하고 있으며, 철저한 모니터링을 통해 작업 과정에 문제가 없도록 최선을 다 하겠습니다.
목적 : 안전한 포장 관리 |
반품/교환 안내
상품 설명에 반품/교환과 관련한 안내가 있는경우 아래 내용보다 우선합니다. (업체 사정에 따라 달라질 수 있습니다)
| 반품/교환 방법 |
|
|---|---|
| 반품/교환 가능기간 |
|
| 반품/교환 비용 |
|
| 반품/교환 불가사유 |
|
| 소비자 피해보상 |
|
| 환불 지연에 따른 배상 |
|
