소프트웨어 장인정신

인상 깊은 단락

6쪽

소프트웨어 엔지니어링은 소프트웨어의 개발, 운영, 그리고 유지보수에 대한 체계적이고, 훈련되고, 측정 가능한 접근 방식의 애플리케이션이다. 즉, 소프트웨어에 대한 엔지니어링 애플리케이션이다.

18쪽

어쩋든 노동의 분할은 산업혁명의 기초였다. 더 작고 잘 정의된 작업으로 제조 활동을 나누는 것에 의해,  그룹의 생산성은 급격히 증가되었다. 물론 이 접근 방식은 소프트웨어 개발에도 적용될수 있을 것이다. … 그러나 그렇지 않다. 작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는데에 더 많은 시간이 걸린다. 생산 라인 접근 방식은 수작업 노동에는 잘 맞을수 있다. 그러나 지적인 작업에는 형편없이 실패한다.

25쪽

MacCready의 이야기는 개발자들에게 영감을 주었는데, 그것은 제도판에 완전한 설게도를 만들기보다는 테스트될 수 있는 진화해가는 설계가 더욱 효과적이라고 지적했기 때문이다.

31쪽

이와 병행해서 CASE툴을 정의하려는 반복된 시도가 나타났는데, 그것은 프로그래머에 대한 수요를 없애고자 했다. 이 두가지 접근 방식 모두 실패했다.

68쪽

과학적 관리는 소프트웨어 개발자를 관리하는 적당한 방법이 아니다.

69쪽

Watts Humphrey에 의해 정외딘 ‘포스널 스프트웨어 프로세스(PSP)는 Taylor의 개념과 유사하다. 그러나 PSP는 개발자로 하여금 그들 자신의 기술을 개선하도록 하는 것에 중점을 둔다.

77쪽

소프트웨어 장인정신은 지식의 실체라기보다는 사고 방식이며 태도이다.

97쪽

소프트웨어 개발에 관한 중요한 문제는, 어떤 것을 해내는 방법에 관한 ㅣ식이, 그 근본을 이루는 원리에 관한 깊은 이해가 없이는 비효괒거이라는 것이다.

117쪽

프로세스를 가지는 것은 그 프로세스를 수행할 기술을 가지는 것과는 다르다.

비숙련 노동력으로 소프트웨어 개발 프로세스를 진해시키는 것은 불가능하다. 타스크(task)가 더 작은 단계로 세분화될수록, 한 사람으로부터 다른 사람으로 정보를 전달하는 데는 더 오랜 시간이 걸린다.

 118쪽

비록 문서화가 의사결정과 동의사항을 기록하는 데는 매우 좋다 하더라도, 소프트웨어 애플리케이션이 실제로 작동하는 방법에 관한 상세한 지식을 보존하고, 전달하는 데에는 매우 비효과적이다.

훌륭한 관례는 기계적 세계에는 잘 맞지만, 정신적 활동에는 적용되지 못한다.

119쪽

훌륭한 관례는 프로세스 혁신을 적극 방해한다.

121쪽

1986년에 Panas와 Clements는 “합리적인 프로세스: 어떻게 그리고 왜 그것을 모조하는가?“란 제목의 글을 썼다.

123쪽

실제로 소프트웨어 개발의 가장 좋은 방법은 점진적이고 진화적인 방법이다.

125쪽

정말로 큰 시스템을 다루는 것에 의해, 소프트웨어 엔지니어링 커뮤니티가 배운 것은, 모듈 단위의 분해(decomposition)를 통해 전체적인 복잡성이 처리할수 있는 수준으로 끌어내려 질수 있다는 것이다. 시스템을 느슨하게 결합된 모듈들로 분해함으로써 복잡성은 감소되고, 모듈들은 서로 독립적으로 기능하게 된다.