1. 길거리에서 중요한 것
•
본인이 일을 얼마나 빨리 하느냐가 가장 중요하다. 아무도 우아한 설계, 알고리즘 지식, 고품질의 코드를 신경 쓰지 않는다.
◦
여러분을 고용한 사람들은 주어진 시간에 얼마나 많은 것을 해줄 수 있느냐에만 관심이 있다.
•
당신의 코드의 품질을 신경쓰는 것은 바로 동료들이다. 다른 사람의 코드를 아이 돌보듯 다루고 싶어하는 사람은 없다.
◦
그들은 당신의 코드가 제대로 동작하며 이해하기 쉽고 유지보수가 어렵지 않기를 원한다.
◦
만약 당신이 나쁜 코드를 쓰고 있다면 당신은 동료들의 속도를 저하시키고 있는 것이다.
•
당신이 수행하는 모든 작업은 처리량으로 가치가 매겨진다.
•
잘못된 코드라 하더라도 처리량이 높을 수 있으나 이는 요구사항이 변경되는 경우, 수많은 작업을 요하게 된다.
2. 누가 스트리트 코더인가?
•
이 책에서 언급하는 스트리트 코더란 소프트웨어 개발 경험을 가진 모든 업계의 사람들을 의미한다.
•
무엇이 가장 중요한지 알아차리기 위한 전문 지식인, 길거리 지식을 많은 시행착오를 겪어야 알게 된다.
3. 훌륭한 스트리트 코더
•
스트리트 코더는 업계의 인정, 명예, 충성심 외에도 이상적으로 다음과 같은 자질을 가지고 있다.
◦
적극적인 질문
◦
결과 중심적
◦
높은 처리량
◦
복잡성과 모호성 수용
•
훌륭한 소프트웨어 개발자는 훌륭한 코더가 아니다. 단순히 코드를 잘 작성하는 것 외적으로도 많은 능력을 요한다.
1. 질문하기
•
이 책은, 좋은 질문을 위한 방법들을 다룬다.
◦
모범 사례를 어떻게 다룰 것인지
◦
장점을 기준으로 상충관계에 적합한 우선순위를 어떻게 세울 것인지
◦
대안적 접근법의 장단점을 어떻게 따져볼 것인지
•
기술에 대한 비평은 그것이 형편없다고 치부하는 것이 아니다. 다른 기술이 실제로 더 나을 수 있다는 사용 사례를 상황에 근거하여 판단할 수 있도록 시야를 넓히는 것이다.
2. 결과 중심적
•
이론으로 충분히 완성되어있더라도 결과가 없다면 그것을 증명할 수 없다.
•
결과 중심적이기 위해 포기해야할 관계들도 있다. 우아한 설계라던가, 모든 분기에 테스트 코드를 넣는다던가.
•
중요한 것은 이런 관점을 가지는 동시에 내가 무엇을 하고 있는지, 이는 무엇을 위한 것인지를 지속적으로 피드백하는 것이다.
3. 높은 처리량
•
개발 속도에 영향을 미치는 가장 큰 요인들은 경험, 명확한 요구 사항이다.
4. 복잡성과 모호성 수용
•
복잡성과 모호성은 가장 다루기 어려운 주제들이다.
◦
마이크로소프트 채용 담당자가 면접에서 질문하는 핵심 기술 중 하나이기도 하다.
▪
서울에 바이올린 수리점이 몇 개가 있을까요?
▪
로스앤젤레스에는 주유소가 몇 개가 있을까요?
•
이러한 문제를 해결하는 요령은, 문제에 대해 알고 있는 지식들을 모두 명확히 수치화하여 나열하고, 이러한 사실을 바탕으로 근사치에 도달하는 것이다.
•
추상적인 문제의 껍질을 하나씩 벗길수록 우리는 근사치에 가까워질 수 있다.
4. 최근 소프트웨어 개발의 문제점
•
다루는 문제의 수준이 더 올라갔기 때문에 생긴 문제들 같다.
◦
도구들 또한 그 수가 많아지고 복잡해졌다.
◦
물리적으로 처리 속도가 높아져 오버헤드를 덜 신경쓰게 되었다.
•
지루하다고 생각될 수 있는 핵심 개념을 검토하거나 실용성과 단순성을 우선하며, 의심 없이 받아들였던 것들을 되돌아보게끔 한다.
•
이를 해결하기 위해 가장 중요한 것은 우리가 하는 모든 것에 의문을 제기하는 것이다.
1. 너무 많은 기술
•
최고의 기술을 찾아 헤매는 것은 진시황이 영생의 약을 찾는 것과도 같다. 쓸데 없는 욕심이다.
•
모든 기술에는 상충 지점이 존재하며 단순히 이들은 도구일 뿐이라는 것을 인지해야 한다.
2. 패러다임의 패러글라이딩
•
우리는 패러다임을 광신하고는 한다. 이런 도구를 맹목적으로 사용하면 나중에 더 많은 문제가 발생할 수 있다.
•
이 책은 패턴을 올바로이 사용하는 방법, 더 자세히 따져보는 방법, 코드 검토를 더 잘할 수 있는 방법에 대한 확신을 줄 것이다.
3. 기술의 블랙박스
•
프레임워크나 라이브러리는 일종의 패키지다. 설명서를 읽고 적절하게 입력을 하면 그에 맞는 출력을 제공한다. 내부 구조를 몰라도 말이다.
•
이처럼 패키지나 프레임워크에 대한 무조건적인 신뢰는 중대한 실수를 범하게 만들수도 있다.
•
기술을 두려워하지 않고 저수준에서 받아들일 수 있어야 한다.
4. 오버헤드 과소평가
•
보통은 기술을 덕지덕지 붙이다보면 하나의 기능이 버벅이곤 한다.
•
이럴 때, 특수한 상황에서 오버헤드를 줄일 수 있는 방법을 알게 된다면, 시간을 절약하는데 도움을 줄 수 있다.
5. 내 일이 아니다
•
복잡성을 다루는 방법 중 하나는, 일단 시야를 좁혀 우리의 책임에만 집중하는 것이다.
6. 시시해 보이는 일도 도움이 될 수 있다
•
복사-붙여넣기같이 시시한 일이라고 무가치해보이는 것들이 도움이 될 수도 있다.
5. 이 책에서 다루지 않는 것
•
어떤 주제에 대한 종합적인 가이드북이 아니다.
•
이 책은 잘 알려지고 인기 있는 대부분의 훌륭한 책이 다루지 않는 내용들을 다루고 있다. 이는 확실히 프로그래밍을 배우기 위한 용도는 아니다.
6. 주제
•
특정한 주제는 이 책의 전체에 걸쳐서 반복된다.
◦
거리에서 살아남기에 충분한 최소한의 기초 지식
◦
특정한 경우에 더 효과적일 수도 있는 안티패턴
◦
CPU 수준의 최적화 기술과 같이 관련 없어 보이는 일부 프로그래밍 기술
▪
의사 결정과 상위 수준의 코드 작성에 좋은 영향을 줄 수 있다. 직접 사용하지 않더라도 내부를 확인하여 구조를 아는 것만으로도 가치가 있다.
◦
생산성을 높이는데 도움이 될 수 있으며 일상적인 프로그래밍 활동에 유요한 몇 가지 기술들
7. 요약
•
전문 소프트웨어 개발의 세계, 이 거리의 냉혹한 현실은 정규 교육에서 가르치지 않거나 우선하지 않는 놓치기 쉬운 일련의 기술을 요구한다.
•
새로운 소프트웨어 개발자들은 이론에 너무 신경 쓰거나 완전히 무시하는 극단적인 경향이 있다. 결국은 시간이 흐름에 따라 자리를 찾아 가겠지만 어떤 확실한 관점을 가지게 되면 더 빠르게 얻을 수 있다.
•
최신 소프트웨어 개발은 과거보다 훨씬 더 복잡하다. 단순한 애플리케이션 하나를 개발하기 위해서 다양한 수준의 수많은 지식이 필요하다.
•
프로그래머는 소프트웨어를 직접 만들어 보는 것과 이론을 공부하는 것 사이의 딜레마에 직면하곤 한다. 좀 더 실용적인 방법으로 주제를 재구성하여 이를 극복할 수 있다.
•
작업할 내용에 대한 명확한 이해가 부족하면 프로그래밍이 일상적이고 지루한 작업이 되어 실제 생산성이 낮아진다. 여러분이 지금 다루고 있는 주제를 더 깊이 있게 이해할 수록 재미가 느껴질 것이다.
