8. 실용주의 프로젝트

• 프로젝트가 진행됨에 따라 좀 더 큰 관점에서 프로젝트 전체 차원의 문제드렝 대해 이야기할 필요가 있습니다.

Item 41. 실용주의 팀

• 개인이 더 나은 프로그래머가 되게끔 도와주는 실용주의 기법들이 팀에도 적용됩니다.
• 팀 전체에 실용주의 기법들을 어떻게 적용할 수 있는지 간략하게 알아보도록 합니다.

깨진 창문을 없애라

• 품질은 팀의 이슈입니다.
• 품질에 무성한 팀에 부지런한 개발자가 가면, 개발자의 열정이 줄어들게 됩니다.
• 팀 전체가 깨진 창문(아무도 고치려고 하지 않는 사소한 결점, imperfection)을 용납하지 않아야 합니다.
• 몇몇 팀 방법론에는 품질 관리 담당자가 있어 상품의 품질에 대한 책임을 팀에게서 위임을 받습니다.

삶은 개구리

• 프로젝트 개발의 열기속에서 전체 환경의 변화에 계속 유의하는 것은 어려운 일입니다.
• 개인보다는 팀이 삶은 개구리가 되기 쉽습니다.
• 모든 사람이 적극적으로 환경 변화를 감시해야 합니다.

소통하라!

• 한 팀에 속한 개발자들이 서로 대화를 해야 하는것은 당연합니다.
• 팀은 나머지 세상과 명확히 의사소통해야 할 필요가 있습니다.
• 바깥의 사람들에게 무뚝뚝하게 과묵해 보이는 프로젝트 팀이야말로 최악입니다.
• 훌륭한 프로젝트 팀은 뚜렷한 특성을 갖습니다.
• 팀이 하나로서 의사소통하게 도와주는 간단한 마케팅 비결이 있습니다.
  • 프로젝트를 시작할 때 유별한 이름을 지어주는 것입니다.
  • 팀 이름을 거리낌 없이 사용함으로 정체성 확립의 기반을 얻고, 작업에 관련되어 기억할만한 것을 얻을 수 있습니다.

반복하지 마라

• 중복은 노력을 낭비하고, 유지보수의 악몽을 끌어들일 수도 있습니다.
• 어떤 팀은 팀원 한 명을 프로젝트 사서로 임명해서 문서와 코드 저장고를 관리하는 책무를 맡깁니다.
• 프로젝트가 한 사람의 사서가 감당하기에 너무 클 경우, 작업의 다양한 기능적 측면의 핵심 사안별로 사람들을 임명합니다.
• 질의응답을 주고받고 이를 저장 관리할 때는 그룹웨어 시스템과 유즈넷 뉴스그룹이 갖는 가치를 얻어야 합니다.

직교성

• 전통적인 팀 조직은 구식 소프트웨어 구축 모델은 폭포수 모델을 근간으로 합니다.
• 극잔적인 경우, 어떤 개발 문화에서는 책임을 엄격하게 분할하는데 이는 문제를 더욱 복잡하게 만듭니다.
• 프로젝트의 여러 활동이 독립적으로 이루어진다는 생각은 잘못입니다.

Tip 6. 팀을 기능 중심으로 조직하라

• 팀을 기능적으로 분리하는 것을 선호합니다.
  • 사람들은 작은 팀으로 나누고, 각 팀은 최종 시스템의 특정한 기능 측면에 대해 책임지도록 합니다.
  • 팀은 개개인의 강점 위에 스스로 내부를 조직하게 합니다.
• 기능 중심으로 팀을 조직하면 어떤 변화가 있더라도 전체가 영향받는 일이 없게 됩니다.
  • 책임감 있는 개발자들과 강력한 프로젝트 관리가 있을 경우에만 효과가 있습니다.
• 좀 더 큰프로젝트의 팀들은 추가적인 리소스를 필요로 합니다.

자동화

• 일관성과 정확성을 보장하는 훌륭한 방법은 팀이 하는 모든 일을 자동화하는 것입니다.
• 자동화는 모든 프로젝트팀에게 필요불가결한 요소입니다.

덧칠을 언제 멈출지 알아라

• 팀은 개인들로 이루어집니다.
• 각 팀원이 자신의 방식대로 빛나게 해주어야 합니다.
• 프로젝트가 요구사항에 맞게 이루어지기에 딱 좋을 만큼의 구조를 제공합니다.

Item 42. 유비쿼터스 자동화

프로젝트에서 일관성과 반복가능성을 확보하는 것이 중요합니다. 수작업은 일관성을 운에 맡기는 행동입니다.

전자동

Tip 61. 수작업 절차를 사용하지 마라

• 사람들은 컴퓨터만큼 반복가능하지 않으며 그것을 기대해서도 안됩니다.
• 인기 있는 자동화의 예시로 cron 등이 있습니다.

프로젝트 컴파일

• 프로젝트 컴파일은 귀찮을 일이며 믿을 만하고 반복가능하게 만들어야 합니다.
• 대표적인 예시로 makefile로 프로젝트 컴파일을 하며 이는 스크립트로된 자동 과정이기 때문에 매우 좋습니다.

코드 생성

• 중복의 해악에서 공통의 소스에서 지식을 유도하기 위해서는 코드 생성을 하는 것이 좋습니다.
• 동일한 종류의 규칙들을 사용해서 소스코드, 헤더 파일 혹은 문서까지도 다른 형태의 자료에서 자동으로 생성할 수 있습니다.

회귀 테스트

• 개개 모듈 혹은 전체 서브시스템에 대해 회귀 테스트가 실행되도록 makefile을 사용할 수도 있습니다.

빌드 자동화

• 빌드는 비어있는 디렉터리 하나를 가지고 프로젝트를 밑바닥에서부터 만드는 과정
• 일반적인 빌드의 단계는 다음과 같습니다.
  • (1) repository에서 소스코드를 끄집어 냅니다.
  • (2) 프로젝트를 밑바닥부터 빌드합니다. (각 빌드마다 모종의 릴리스 번호나 버전, 날짜 등이 표시됩니다.)
  • (3) 배포용 이미지를 만듭니다.
  • (4) 테스트를 실행합니다.

최종 빌드

• 상품으로 선적하려고 하는 최종 빌드는 주기적인 빌드와는 다른 요구사항이 있을 수도 있습니다. 최종 빌드에서는 저장소를 잠그고 릴리스 번호를 태그로 붙이는 작업이 필요할 수도 있습니다.

자동화된 관리

• 프로그래머는 모든 시간을 프로그래밍에 투자할 수 없습니다.
• 기억은 잊기 때문에 의존하지 않도록해야합니다.
• 목표는 자동화, 무인화이며 내용 주도(content-driven)인 작업흐름을 유지하는 것입니다.

웹사이트 생성

• 많은 개발 팀들이 프로젝트 내에서 의사소통을 위해 내부 웹사이트를 사용하는데 이는 좋은 생각입니다.
• 다만, 웹사이트를 유지보수하는데 너무 많은 시간을 허비해도 안되고, 그렇다고 오랫동안 손을 안되는 것도 좋지않습니다.
• 코드에서 추출된 문서나 요구사항 분석, 설계 문서, 그림, 차트, 그래프 등 모두가 정기적으로 웹에 올라가야 합니다.

승인 과정

• 몇몇 프로젝트에서는 지켜야 할 여러 가지 다양한 행정 절차가 있습니다.

중 머리

• 소프트웨어를 개발하는 사람들이 때로는 형편 없는 도구를 쓰기도 합니다.
• 반복적이고 지루한 작업은 컴퓨터에게 시켜야 합니다. 이는 컴퓨터가 더 잘하는 일이고, 우리는 더 중요한 어려운 일들이 있습니다.

개인 의견. 과거 vi 시절에만 이말이 먹히지, 현대 개발은 IDE에서 지원해주는 것도 너무 많다고 생각. 굳이 무기가 있는데 맨몸으로 싸워햐할까.

Q. 일할 때 자신의 습관을 보고, 반보고디는 작업이 있는가

Q. 프로젝트 문서 작업 가운데 얼마만틈을 자동화할 수 있을 지 생각해봐라.

Item 43. 가차 없는 테스트

• 많은 개발자가 테스트를 싫어합니다.
• 실용주의 프로그래머들은 당장 버그를 찾도록 내몰리지만, 이를 통해 나중에 다른 사람이 자기 버그를 발견하게 되는 수치를 피할 수 있는 것입니다.

Tip 62. 일찍 테스트하고, 자주 테스트하고, 자동으로 테스트하라.

• 코드를 작성하자마자 테스트해야합니다.
• 자동화된 테스트를 사용하는 것이 테스트 계획을 상세하게 짜는 것보다 성공 가능성이 높습니다.
• 버그가 빨리 발견될수록 고치는 비용이 적어집니다.
  • 코드 조금, 테스트 조금 이라는 격언도 있습니다.
• 훌륭한 프로젝트에는 제품 코드보다 테스트 코드가 더 많을지 모릅니다.
• 테스트를 통과했다는 것은 그 코드가 "완료되었다, done" 라고 말할 수 있는 높은 수준의 확신을 갖게 합니다.

Tip 63. 모든 테스트가 통과하기 전엔 코딩이 다 된 게 아니다.

• 프로젝트 범위에서 이루어지는 테스트는 세 가지 측면으로 봐야합니다. (무엇, 어떻게, 언제)

무엇을 테스트할지

단위 테스트

• 단위 테스트는 하나의 모듈을 테스트하는 코드입니다.
• 단위 테스트는 이 항목에서 논의할 다른 모든 형태 테스트의 근간이 됩니다.
• 모든 모듈을 갖고 진행하기 전에 단위 테스트를 통과해야합니다.

통합 테스트

• 통합 테스트는 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 보여줍니다.
• 계약(contract)이 제대로 되어 있고 테스트가 잘 되어 있다면, 어떤 통합 문제건 쉽게 발견할 수 있습니다.
• 시스템에서 버그의 큰 원인이 이를 제대로 구성하지 않아서인 경우가 많습니다.
• 통합 테스트는 단위 테스트의 확장이며, 전체 서브시스템이 계약을 제대로 지키는지 테스트하는 것 뿐입니다.

유효성 평가(validation)와 검증(verification)

• 실행가능한 사용자 인터페이스나 프로토타입이 갖춰지자마자, 사용자들이 정말로 필요로 하는지에 대한 확인이 필요합니다.
• 시스템의 기능적 요구사항을 충족하는지도 테스트해봐야합니다.

자원 고갈, 에러, 그리고 복구

• 이상적인 상황에서 시스템이 올바르게 작동한다는 확신이 있다면, 시스템이 실세계의 상황에서 어떻게 작동할지도 알아야합니다.
• 실세계에서 프로그램은 무한한 자원을 보장받지 못합니다. 여러 제한 사항에 대해 고려해야 합니다.
  • 메모리, 디스크 공간, CPU 대역폭, 벽시계 시간, 디스크 대역폭, 네트워크 대역폭 등등
• 모든 실패가 복구까능한 것은 아니지만, 이를 최선으로 방지할 수는 있습니다.

성능(performance) 테스트

• 성능 테스트의 테스트 역시 프로젝트의 중요한 부분입니다.
• 초당 예상 사용자 및 접속 혹은 트랜잭션 숫자를 염두에 두는 것이 좋습니다.
• 어떤 애플리케이션은 부하를 현실적으로 시뮬레이션하기 위해 특화된 테스트 하드웨어나 소프트웨어가 필요할 수도 있습니다.

사용편의성(usability) 테스트

• 사용편의성(usability) 테스트는 위의 테스트와 다르게 실제 환경의 조건 하에 실제 사용자들이 시행합니다.
• 인간적 요소라는 측면에서 사용편의성을 바라봅니다.
• 유호성 평가와 검증과 마찬가지로, 사용편의성 테스트는 보정할 시간이 있을 때에 되도록 일찍 시행해야 합니다.

설계/방법론 테스트

• 코드 설게 자체와 소프트웨어를 만드는데 사용한 방법론을 모두 테스트할 수 잇습니다.
• 메트릭(코드의 다양한 측면에 대한 측정)을 분석해서 가능합니다.
• 가장 단순한 메트릭은 코드 줄 수 입니다.
• 어던 메트릭은 '통과 점수'를 제공하도록 만들어졌지만, 어떤 것들은 그 점수를 서로 비교해야지만 의미가 있습니다.
• 특히 어떤 모듈이 다른 것들과 큰 차이가 있을 경우, 그래도 괜찮은지 자문해봐야합니다.

어떻게 테스트할까

회귀 테스트

• 이전 값과 현재 테스트의 출력을 비교합니다.
• 오늘 고친 버그가 어제 작동하던 것들을 망치지 않는다고 확신할 수 있습니다.
• 위에서 언급한 모든 테스트는 새로운 코드를 개발하면서 이전의 것을 잃지 않았다는 것을 확신시켜 주는 회귀 테스트로 실행할 수 있습니다. (성능, 계약, 유효성 등을 검증하기 위해)

테스트 데이터

• 테스트를 실행할 데이터는 실세계 데이터와 합성 데이터입니다.
• 실세계 데이터는 현실에서 옵니다.
• 합성(synthetic) 데이터는 어떤 통계적 조건하에서 인공적으로 생성됩니다.
  • 실세계 샘플이 제공하는 것보다 많은 데이터가 필요한 경우
  • 경계 조건을 테스트할 데이터가 필요한 경우
  • 특정 통계 특성을 보이는 데이터가 필요한 경우

GUI 시스템 구동

• GUI의 비중이 큰 시스템을 테스트하려면 많은 경우 특화된 테스트 도구가 필요합니다.
• 조금 덜 세련된 도구는 테스트되는 소프트웨어의 버전과 테스트 스크립트 자체 간에 높은 결합(coupling)을 요구합니다.
• 모든 것을 자동화할 수는 없습니다.
• 결합도가 낮은 코드를 작성하는 많은 이점 중 하나는 좀 더 모듈화된(modular) 테스트가 가능하다는 것입니다.

테스트를 테스트하기

• 완벽한 소프트웨어을 작성할 수 없기 때문에, 완벽한 테스트 소프트웨어 역시 작성할 수 없습니다. 그렇다면 테스트를 테스트할 필요가 있습니다.
• 어떤 버그를 감지해내는 테스트를 작성한 후, 그 버그가 의도적으로 생기도록 한 다음 테스트가 불평을 해대는지 확인합니다. 이를 통해 테스트가 버그를 잡아낼 것이라는 확신을 할 수 있습니다.

Tip 64. 파괴자를 써서 테스트를 테스트하빈다.

• 정말 테스트에 대해 심각하게 생각한다면 프로젝트 파괴자를 임명할 수 있습니다.
  • 파괴자는 소스 트리의 카피를 별도로 만든다음 고의로 버그를 심고 테스트가 잡아낼지 검증하는 것입니다.

철저히 테스트하기

• 테스트가 올바르다는 확신이 들고, 버그를 찾아내도 철저하게 테스트했는지는 확신할 수 없습니다.
• 이때는 완벽을 바라지말고 커버리지 분석 도구를 통해 테스트 중의 코드를 보고, 어느 라인이 실행되지 않았는지 기억합니다.
• 코드가 모든 라인이 실행되더라도, 정말로 중요한 것은 프로그램이 갖는 상태 수입니다.

Tip 65. 코드 커버리지보다 상태 커버리지를 테스트하라

• 훌륭한 코드 커버리지가 있어도 테스트를 위해 사용하는 데이터는 여전히 상당한 영향을 미칠 뿐 아니라, 실행하는 순서가 가장 큰 영향을 미칠 수 있습니다.

언제 테스트할까

• 테스트는 대부분 자동화되어야 합니다.
  • 여기서의 자동화는 테스트 결과 해석의 자동화를 포함합니다.
• 테스트를 되도록 자주, 소스 저장소에 넣기전 등에 하는 것이 좋습니다.
• 자동화를 하는 것이 힘들다면 task에 모든 필요 자원을 넣고 일정표에 넣어둡니다.

그물 조이기

• 현존하는 테스트의 그물을 빠져 나가는 버그가 있으면 다음번에는 그걸 잡아낼 수 있도록 새 테스트를 추가해야 합니다.

Tip 66. 버그는 한 번만 잡아라

• 인간 테스터가 버그를 찾으면, 그 이후는 인간이 잡으면 안됩니다. 즉 자동화해야합니다.
  • 무조건, 매번, 예외없이, 아무리 사소한 것일지라도 자동화 테스트를 수정화해야 합니다.

Item 44. 결국은 모두 글쓰기

• 개발자들은 문서화를 그리 대단하게 생각하지 않습니다.
• 실용주의 프로그래머들은 문서화를 전체 개발 프로세스의 필요불가결한 부분으로 포용합니다.
  • 노력을 중복거나 시간을 낭비하지 않고, 문서를 늘 손에 닿는 가까이에 둡니다.
• 실용주의 원칙 모두를 코드느 물론 문서화에 적용시키면 좋습니다.

Tip 67. 한국어도 하나의 프로그래밍 언어인 것처럼 다루라.

• 프로젝트에서 생산되는 문서에서 기본적으로 내부, 외부의 두 종류가 있습니다.
  • 내부 문서에는 소스코드, 주석, 설계와 테스트 문서 등이 포함됩니다.
  • 외부 문서에는 사용자 메뉴얼 같이 외부 세계로 출간되거나 출하되는 모든 것이 포함됩니다.
• 모든 문서는 코드의 거울이며 불일치가 있으면 중요한 것은 코드입니다.

Tip 68. 문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어넣으려고 하지 말라.

코드 내의 주석

• 코드에는 주석이 있어야 하지만 너무 많은 것은 너무 적은 것만큼 좋지 않습니다.
• 일반적으로 주석은 왜 이렇게 되어 있는지,. 그 목적을 논해야 합니다. 코드가 이미 어떻게 되어 있는지 보여 주기 때문에 이에 대해 주석을 다는 것은 DRY원칙 위반입니다.
• 소스코드에 주석을 다는 것은 예컨대 공학적인 트레이드오프나 어떤 결정의 이유, 어떤 대안을 버렸는지 등 다른 곳에서 문서화할 수 없는, 바로 프로젝트에서 잘 빠져 나가는 부분들을 문서화하기 위한 완벽한 기회가 됩니다.
• 변수 이름은 물론 선별해서 유의미한 것으로 해야합니다.
• 의미 없는 이름보다 더 고약한 것은 오해를 불러일으키는 이름입니다.
• 대표적인 문서화 도구는 JavaDoc이 있습니다.

/**

* 주어진 날짜 범위 안의 표본에서 정점(최대) 값을 찾습니다.

*

* @param aRange 데이터를 찾아볼 날자의 범위

* @param aThreshold 유효한 값으로 간주할 최소값

* @return 찾은 값, 만약 최소값과 크기가 같거나 더 큰 값을 찾을 수 없으면 <code>null</code>을 돌려줍니다.

*/

public Sample findPeek(DataRange aRange, double aThreshold)

소스 주석에 나오지 말야 할 것들의 목록은 다음과 같습니다.

• 파일 내의 코드가 익스포트(export) 하는 함수들의 목록
  • 대신해 소스 코드를 분석해주는 프로그램을 사용할 것, 최신 버전을 보장 받을 수 있음.
• 리버전 기록
  • 이는 소스코드 관리 시스템이 해주는 일입니다.
• 이 파일이 사용하는 파일 목록
  • 자동화 도구를 사용하면 훨씬 더 정확한 목록을 얻을 수 있습니다.
• 파일 이름
• 만약 이것이 파일 속에 드러나야 한다면 수작업으로 관리하면 안됩니다.

소스 파일에 나타나야만 하는 가장 중요한 정보 중 하나는 저자의 이름입니다.

적절한 주석이 제자리에 있으면 JavaDoc이나 DOC++ 같은 도구가 API 수준의 문서를 자동으로 추출, 포맷까지 해줄 수 있습니다.

실행가능한 문서

• 명세 문서를 소스로 선택하는 것도 좋은 방법 중 하나입니다. (DRY 원칙을 위해)
• 문서가 데이터베이스 스키마인 경우, 프로세스의 모델이나 뷰가 대표적인 예시가 됩니다.
• 문서가 마크업 명령어로 된 일반 텍스트로 저장되어 있다면 펄과 같은 도구를 통해 추출할 수도 있습니다.
• 이를 통해서 문서는 프로젝트 개발에서 중요한 부분이 됩니다.
• JavaDoc이나 DOC++ 같은 도구를 이와 유사한 방식을 사용해서 소스코드에서 API 수준의 문서를 만들 수 있습니다.

만약 문서가 일반 텍스트가 아니라면? 아래의 방법이 있습니다.

• 매크로 작성.
• 문서를 종속시키기

테크니컬 라이터

• 프로젝트에 관련된 전문 테크니컬 라이터들이 있다고 해도, 프로그래머들이 신경을 써야합니다.
• 글을 쓴느 사람이라면 실용주의 프로그래머가 가진 것도 동일한 기본 원칙을 지키는 것이 중요합니다.
  • DRY 원칙, 직교성, 모듈-뷰 개념, 자동화, 스크립팅의 사용

찍기나 짜기

• 문서화는 단지 스냅숏입니다.
• 문서의 외양은 내용과는 독립되어 있어야합니다.
• 마크업 시스템을 사용하고 있으면 다양한 출력 포맷을 구성할 수 있습니다.
• 워드 프로세서도 비슷한 기능이 있습니다.

마크업 언어

• 규모가 큰 문서화 프로젝트에서라면 좀 더 현대적인 문서 마크업체계를 사용할 것을 권하고 싶습니다.
• 대표적인 예시로 문서를 정의하는데 DocBook을 사용합니다.
• 원본 마크업이 하이퍼링크를 포함해 필요한 모든 개념을 표현하기에 부족함이 없으면, 다른 형태로 변환이나 자동화가 싶습니다.
• 문서와 코드는 밑에 깔려 있는 동일 모델에 대한 서로 다른 뷰이며, 다른 것은 오직 뷰입니다.
  • 즉, 문서화를 프로젝트 작업 흐름에 어긋나게 둬서는 안됩니다.
  • 코드를 다룰 때와 똑같은 관심을 문서화에도 주어야 합니다.

Q. 작성한 소스코드를 설명하는데 주석을 제대로 달았는지, 안달았는지? 안달았다면 이유는?

Q. 때로는 설계가 명확하지 않으므로 설계를 문서화하는 것이 불편할 때가 있습니다. 근데 이경우에는 굳이 필요할까요?

Item 45. 위대한 유산

• 이론적으로 명세를 올바르게 구현했다면 성공적인 애플리케이션이나, 돈도 이론적으로 벌게 됩니다.
• 현실적으로 프로젝트의 성공은 사용자들의 기대를 얼마나 잘 충족하는가에 따라 측정됩니다.

Tip 69. 사용자의 기대를 부드럽게 넘어서라

• 이러한 팁을 실행하기 위해서는 몇 가지 작업이 필요합니다.

기대를 상호 소통하기

• 사용자는 처음에 그들이 원하는 바에 대한 어떤 비전을 가지고 우리르 찾아옵니다.
  • 불완전하고 모순이 있거나 혹은 기술적으로 불가능할 수도 있지만, 그 기대는 사용자의 것입니다.
• 그들의 필요에 대한 이해가 깊어질수록, 그들의 기대가 충족될 수 없는 영역이나 혹은 그들의 기대가 너무 보수적으로 보이는 영역을 발견하게 됩니다. 이 부분을 소통하는 것이 우리의 역활 중 하나입니다.
  • 애플리케이션이 해결하기로 한 비지니스 문제에 대해 절대로 눈을 떼지 않는 것이 중요합니다.
• 이러한 과정을 몇몇 컨설턴트들은 이 과정을 '기대 관리'라고 부릅니다.
  • 사용자가 시스템에서 무엇을 얻기를 기대해야 할지에 대해 적극적으로 제어(control)하는 것을 일컫는 말입니다.
• 프로세스를 용이하게 하기 위해 사용할 수 있는 기술로는 예광탄이나 프로토타입과 포스트잇이 있습니다.
  • 위 두가지 방법을 통해 사용자와 소통하는 훈련을 하게 해줍니다.

한 계단 더

• 사용자와 가깝게 그들의 기대를 공유하고 하는 일에 대해 소통하면서 작업을 했다면, 프로젝트가 끝나고 산출물이 전달되었을 때 사용자를 놀래켜 주려고(기쁘게) 노력해야합니다.
• 일반적인 사용자가 좋아할만한 것은 아래와 같습니다.
  • 풍선 혹은 툴 팁 도움말
  • 키보드 단축키
  • 사용자 메뉴얼의 부록으로 만든 빠른 참조
  • 색깔 입히기
  • 로그 분석기
  • 자동 설치
  • 시스템의 상태를 체크하는 도구
  • 훈련 목적으로 여러 버전의 시스템을 실행시킬 수 있는 기능
  • 각 회사나 조직을 위해 만든 스플래시 스크린
• 위의 기능은 표면적인 부분이므로 시스템에 부담을 주지 않습니다. 다만 이 부분이 장애를 만들어서는 절대 안됩니다.

Q. 프로젝트에 대해 실망했던가 있는가 (만들었는게 별로 맘에 안들때)

Q. 소프트웨어를 전달할 때 사용자는 뭐라고 언급하는가

Item 46. 오만과 편견

• 실용주의 프로그래머들은 책임을 회피하지 않습니다. 도전을 수용하고 전문 지식이 널리 알려지는 것을 기뻐합니다. 설계 혹은 코드에 대한 책임을 맡는다면, 스스로 자랑스러워할 만한 일입니다.

Tip 70. 자신의 작품에 서명하라

• 프로젝트에 서명하는 것을 자랑스러워야 합니다.
• 프로젝트에서는 코드 소유권 때문에 협력에 차질이 생길 수도 있습니다.
  • 코드는 고립되어서는 안됩니다.
• 개발자간에 황금률(자신에게 해주기 바라는 대로 남에게 행하라)와 상호 존중이라는 기반을 지키는 것이 핵심입니다.
• 익명성은 특히 큰 프로젝트에서 적당주의, 실수, 태만 그리고 나쁜 코드의 번식지가 될 수 있씁니다.
• 코드에는 주인이 있어야하지만 꼭 개인일 필요는 없습니다.
• 소유권에 대한 긍지를 가져야합니다.
• 서명이 품질의 보증수표로 인식되게 만들어야 합니다.
  • 우리의 이름을 보고 튼튼하고 잘 작성되고 제대로 테스트되었으며 또 훌륭히 문서화되었을 것이라고 기대하게 만듭니다.
  • 그것이 프로페셔널입니다.