[책] 소프트웨어 컨플릭트 2.0 - 시대를 뛰어넘는 즐거운 논쟁

  소프트웨어 컨플릭트 2.0 - 시대를 뛰어넘는 즐거운 논쟁  

로버트 L. 글래스 지음, 박재호 외 옮김
바쁘게 돌아가는 소프트웨어 개발 업계에서 '늘 그래왔다'는 변명이란 이름으로 반복되는 오류를 한 번쯤 제거하고 싶었던 적이 있었다면 이 책에 귀 기울여 보자. 50년 실무 개발 경력자가 소프트웨어 개발 업계에 던지는 날카로운 비평과 시대를 뛰어넘는 논쟁의 세계로 여러분을 초대한다.

회사에 책을 신청해 구매 뒤 읽은 책이다.
이전에 소프트웨어, ... 개떡 ... ( Why software SUCKS...) 역시 신청해서 읽은책.

역사는 반복된다. ... 15년전에서 몇 발자국 벗어나지 못한 현재 상황을 바라보면서 심지어 절망을 느낄지도 모른다.

이 책은 1990년에 출판 되었다가 2006년에 재판되었다. 예전의 내용이 그대로 들어 있어서, 지금과는 맞지 않는 내용이 있지만 최근과도 거의 맞아 떨어지는 내용들이다. 저자는 예전의 글들에서 최근과 달라진 점, 혹은 최근에 다시 느끼고 있는 점을 각 장의 마지막에 몇페이지 추가해 두었다.


여전히 그렇듯이 읽었던 부분에서 줄 친 부분을 옮겨 적어 보도록 한다.

은총알은 없다.

1. 가능하다면 소프트웨어를 제작하지 말고 구매하라.
2. 점진적으로 소프트웨어를 제작하라.
3. 뛰어난 소프트웨어 설계는 뛰어난 설계자로 부터 나온다는 사실을 기억하라. 창의적인 소프트웨어 인재를 고용하고 양성하라.
..... 상호소통을 통해 서로 자극이 되는 만남의 기회를 제공하기 등을 제시한다.

가장 뛰어나고 명석한 두뇌들이 내 놓은 보고서

향수 십년동안 소프트웨어 생산성, 안정성, 직시성을 10배 이상 향상시킬 기술적 발전은 눈 씻고 찾아봐도 없다.
업계 실무에서 최고 수준과 평균 수준이 이렇게 차이가 나는 분야는 거의 없다.
진짜 문제는 기술이 아니다. 오늘날 정말로 심각한 문제는 관리다.

... 그래서 명세를 반복해서 조정하지 않고서는, 소프트웨어 시스템의 동작 요구사항을 정확히 내 놓지 못한 다고 믿는다. 오늘날에 구축되는 시스템은 머리속으로만 분석해서 전체 정황을 예측하기에는 너무나 복잡하다.

인지적 견해: 소프트웨어 설계를 보는 다른 시각

.... 강사가 모두에게 요구사항을 설명하자 마자, 내 급우 중 한명인 보잉사에서 온 똑똑하고 젊은 친구가 설계안을 내 놓았다. 당시 나는 문제조차 이해하지 못해서 고심하는 중이었는데 그 친구는 즉석에서 설계안을 떠 올렸던것이다! 그 때 나는 깨달았다. 설계는 마음속에서 번개처럼 떠오르는 무언가임을. 그리고 어떤 사람의 번개는 다른사람의 번개보다 훨씬 빠르다는 사실을.

프로그래밍에서 첫번째 단계는 상상이다. 일어날 일을 마음속으로 명확히 구체화 한다. 이와 같은 초기 단계에서 나는 연필과 종이를 사용한다. 진짜 그림은 마음속에 있기 때문에... 그저 끄적일 뿐이다.

어느 순간에 (설계가) 폴발적으로 떠올라서 머리 속에 모두 들어있다... 머리속에 온갖 생각이 들어 있어서 종이에 옮기지 못한다. 마음속으로 계속 고치기 때문이다.

설계자들이 무(無)에서 시작하는 경우는 거의 없다. 앞서 유사한 문제에 사용했던 해결책에서 가져온다는 뜻이다. 돌아 보면 에이다 수업에서 보잉사에서 온 젊은 친구가 내 기를 죽였던 방법이 바로 그것이다. 그는 유사한 문제 유형을 이미 풀어 보았고, 그래서 머리속에 잠정적인 해결책이 들어있었던 것이다!

소프트웨어 오류에 대한 단상

2. 사람 목숨이나 돈이 걸린 시스템의 소프트웨어는 소프트웨어 오류에 대비해서 오류 제거를 넘어선 주의를 기울여야한다. 오류가 없도록 아무리 노력하고 바란다고 해도, 제품은 여전히 오류가 있다는 가정하에 취급해야 한다.
3. 소프트웨어 오류 제거에서 가장 중요한 요소는(사실상 모든소프트웨어 제작에서 가장 중요한 요소는) 업무에 투입할 인력 선택이다. 우수한 인력은 우수한 해결책을 내놓는다. "나쁜" 인력은 훨씬 나쁜 해결책을 내 놓는다.

프로토타이핑에 대한 단상

두 논문의 실험 방식은 기본적으로 동일하다. 개발 팀 여럿을 대상으로 몇 팀은 생명주기 접근방법을, 다른 몇개 팀은 프로토타이핑 접근 방법을 사용해서 소프트웨어를 개발했다. 개발 후에는 명확한 기준에 의거하여 점수를 매겼다.
그렇다면 결과는 어땠을까? 이 질문에 대답하기 위해, 사용자들과 소프트웨어 개발 자들에 대한 인터뷰를 진행했다. 사용자들은 일반적으로 프로토타이핑으로 만든 제품이 사용하기 더 편하고 좀 더 정확하고 쓸만한 인터페이스를 제공했지만 기능면에서는 부족하다고 판단했다.

프로토타이핑을 어떻게 관리할까?... '대충 급조한' 첫번째 제품이 형편없는 최종 제품이 되어 버리지 않도록 만드는 방법은? ... 프레드 브룩스가 'The Mythical Man-Month'에서 "버릴 수 있도록 만들어라" 라고 말한지 십여 년이 넘었지만, 우리는 아직도 방법을 제대로 파악하지 못한 상태이다. 단지 프로토타이핑이 장래성이 있는 기술이라는 사실만은 안다.

-_- 빌어 먹을 -_- IE7 -_-
또 한참 써 두었는데 -_- 뻗어 버렸다. -_-;;;;
지금보다 3배는 더 많이 적었지만 -_-  그것도 2번씩이나!!!
걍 요까지만 -_-;;;