진짜 소프트웨어 개발이야기

1802, 제프 엣우드, 진짜 소프트웨어 개발 이야기

코딩 호러 블로그로 유명한 사람인데, 결국 stackoverflow라는 성공한 서비스를 개척했다. 하여 읽게 된 책.

20, to do list를 비판하며, 매일 아침 일어날때 신이 제작한 완벽한 장치인 뒤노를 이용해 그날 해야할 가장 중요한 일 세가지를 떠올릴 수 없다면 그 상황을 진지하게 개선할 필요가 있다. 도구라는 것은 있다가도 없을 수도 있지만 두뇌와 본능은 평생함께한다.

29, 다른 사람에게 영향을 미치기를 조금이라도 희망한다면 그들을 설득할 수 있어야 한다.

스티브 예그는 소프트웨어 엔지니어가 반드시 배워야할 단한가지가 있다면 그것은 놀라운 코드를 작성하는 방법이 아니라 자기 자신과 프로젝트를 어떻게 마케팅할 것인가라고 주장한다.마케팅에서 설득을 빼면 뭐가 남겠는가..

51, 나는 스케쥴이나 목록에 목을 매는 사람이 아니다. 하지만 작업 목록이 없으면 스케쥴도 없다. 정확한 작업에 대한 정의 없이 시케쥴을 세우려고 하는 것은 중력의 법칙을 거스르는 것과 같다. 프로젝트를 항상 그런식으로 진행하기 때문에 우리는 항상 90퍼센트만 완료한 상황에 머문다.

131, 앱은 언제나 웹을 필요로한다. 앱이 최종적으로 의지할수 있는 모선으로서 다양한 앱을 다운할수 있는 장소로서, 데이터 소스로서의 기능을 위해서라도 웹사이트가 있어야 한다.

172, 극단적인 단위테스트는 극단적으로 드물게 나타나는 버그를 잡아낼지도 모른다. 버그가 존재하지만 사용자가 그버그를 만날일이 없다면 그게 무슨 상관이란 말인가. 단위테스트 보다는 실제 사용에 근거한 데이터를 이용해 버그를 수정하는 편이 더 낫지 않을까?

182. 예외주도 개발. 예외 로그는 고객의 피드백이 가질수 있는 최고의 형태다. 유닛 테스트 보다는 실제 사용예에서 나오는 버그를 고치는게 더 낫다는 필자의 의견임.

190, 사용자들이 본인의 의사와 상관없이 당신의 앱을 사용할수밖에 없으면 그것은 내부 프로젝트다. 내부 소프트웨어중에는 엉망인것이 너무많다. 고객이 어플을 사용할 수밖에 없다면 내가 그들이 필요로하는게 무엇인지 굳이 신경쓸 필요가 무엇인가

최소한 내가 일하는 내부프로젝트의 고객이 실제로 돈을 지불하는 것처럼 일하는 방식을 선호한다. 어플을 사용하는 사람은 돈을 지불하고, 조직 내부의 사람들에게 마케팅하여 팔게하는 것이다. 이렇게 하면 아무 짝에도 쓸모없는 프로젝트는 자연스럽게 사라진다.

195, 대부분의 사람들은 정규분포상에서 영구적으로 중간단계의 전문가 수준에 머무르게 된다. 따라서 우리에게 의미가 있는 사용자는 중간단계의 사용자들 뿐이다. 양 끝단 분포(초보&전문가)를 둘다 만족시키려다 보면 핵심적인 사용자 기반-중간-을 희생시킬 뿐이다

204, 얼마나 많은 사용자가 실제로 당신이 만든 어플을 사용하는가? 그것이 바로 성공의 척도이다.

215, 너무 많은 기능은 오히려 해가 될수도 있다며, 소프트웨어를 어떤 기능들의 총합-즉 끝없이 먹을 수 있는 디지털 뷔페-라고 판단하는 것을 멈춰야 하는 것일지도 모른다.


279, 말하는 것과 글쓰는 것은 완전히 다르다. 말하는 것은 혼란스러운 감정을 더하지만 글을 쓰는 것은 더 체계적이고 해결책에 기초한 접근을 가능하게 한다.