후임자를 위해 무엇을 남겨 두어야합니까?

당신이 일을 떠나는 유일한 개발자라고 가정하십시오. 코드 외부에서 어떤 종류의 정보 / 자료를 작성하여 교체해야합니까?

분명한 대답은 "새 직장에서 무엇을 원 하든지"라는 것입니다. 그러나 새 직장을 시작한 지 얼마되지 않아서 제가 가장 중요한 것이 무엇인지 잊었습니다.

나는 생각 중입니다:

• 계정 / 암호
• 장비, 백업, 소프트웨어 CD의 위치

또 뭐요?

• 계정 및 비밀번호
• 서버 정보
• 좋은 코드
• 선적 서류 비치
  • 데이터베이스 다이어그램 및 설명은 훌륭합니다
  • 코드의 홀수 목록
• 절차
• 수동 프로세스 또는 간혹 비 명확한 작업에 대한 설명
• 그들이 사용했거나 유용하다고 생각한 프로그램 목록
• 연락처 정보;)

강한 커피 한잔과 사과 노트.

내가 남길 바라는 것 입니다.

• 선적 서류 비치. 몇 가지 의견을 작성하는 것이 얼마나 어려운가요? 빌드 노트, 배치 노트, 시스템 노트 이동. 다시 시작할 때해야 할 일과 모든 것이 사라졌습니다.
• 서류. 왜 이런 식으로 수행 되는지 적어보십시오. 그래서 왜 다른 방식으로하지 않는지 궁금하지 않습니다. 백업 시스템 작동 방식, 서버가로드, 테스트, 테스트 사례, 사용 사례에 어떻게 대응합니까?
• 노트. "데이터베이스를 사용할 때 절대 말하지 마십시오 SELECT * FROM clients. 왜 데이터베이스를 덤프하는지는 확실하지 않습니다 . "

내 이메일 주소 또는 전화 번호.

내 경험상 모든 세부 사항을 기록하기가 어려우므로 후속 작업에 더 많은 정보가 필요한 경우 가장 좋은 방법은 어느 정도 사용할 수있는 것입니다.

작성한 프로그램, 예를 들어 목적, 향후 개발을위한 소스 파일의 위치, 비밀번호 등의 문서

이것은 코드 내에서 주석으로 또는 외부에서 알 수 있습니다.

단순한 문서 그 이상으로 특정 결정이 내려 졌을 때 왜 결정을 내 렸는지 알고 싶습니다. 현재 프로젝트에서 SWIG를 사용하고 있으며 다른 개발자 중 한 명이 왜 Boost :: Python을 사용하지 않았는지 알고 싶어했습니다. 간단한 대답은 고객이 당시 Boost 사용을 허용하지 않았다는 것입니다. 지금은 다른 이야기입니다.

이러한 것들이 프로젝트를 이해하는 데 도움이 될뿐만 아니라 구현이 극복 한 한계 / 제약 / 도전에도 도움이 될 것입니다. 향후 유지 관리 및 기능 보강을위한 시작점을 제공합니다.

다른 사람이 언급하지 않은 한 가지 사항은 간과했지만 개발자 환경을 설정하는 방법을 문서화하는 것입니다. 나는 대부분의 경우 단지 몇 가지를 설치하고 최신 정보를 얻고 컴파일하면 끝났다는 것을 알고 있습니다. 그러나 때로는 그것보다 더 많은 것이 있습니다 (SharePoint는 염두에 두어야 할 상황입니다).

데스크톱 프로그램 인 경우 전체 시스템을 처음부터 새로 작성하는 방법 (여러 개의 별도 프로그램 일 수 있음), 배포 용 패키지를 만드는 방법 (예 : .NET 버전 등의 종속성) 및 서버에 배포하는 방법 해당되는 경우 다운로드하거나 CD 또는 DVD에 굽습니다.

웹 기반 프로그램 인 경우 FTP 및 서버에 대한 SSH 액세스 (해당되는 경우) 및 코드를 로컬로 작성하고 테스트하는 데 사용되는 도구

임베디드 시스템 인 경우 이진 이미지 작성, 사용되는 도구, 코드를 제품에 다운로드 및 플래시하는 방법, 장치에 파일 시스템을 설정하는 방법 (있는 경우)에 대한 지시 사항을 완료하십시오.

나는 최근에 당신과 비슷한 상황에서 직장을 떠났습니다 (저는 유일한 개발자는 아니지만 실제로 우리 중 두 명만 있었으므로 다른 사람에게는 없었던 많은 지식이 있었고 그 반대도 마찬가지였습니다. 물론이야)).

일반적인 문서와 관련하여 전체 시스템의 개요를 문서화하는 것이 중요합니다. 개별 구성 요소는 이미 코드에 문서화되어 있지만 구성 요소 간의 상호 작용 및 이것이 수행하는 이유 또는 해당 구성 요소와 대화해야하는 이유는 중요하며 코드를 디버깅 / 보는 것만으로 쉽게 파악할 수있는 것은 아닙니다.

그리고 나서 떠나기 한 달 전쯤에 내가 할 수 있는 일을 할 때마다 무슨 일이 있었는지,해야 할 일과 그 이유를 정확히 적었습니다. 이것은 일반적으로 "xyz 구성 요소에 버그가 있었으며,이를 해결하기 위해 X 때문에 abc 파일을 살펴 보는 것을 알고있었습니다.

물론, 스스로 알아낼 수없는 일이 생길 경우를 대비하여 이메일 주소와 전화 번호를 남겨 두었습니다. 처음 몇 주 동안 몇 건의 전화를 받았지만 천천히 끊어졌습니다.

우리는 모두 기능 요구 사항 목록이있는 시스템의 완전한 데이터 흐름도를 원합니다. 당신이 처음에 시스템을 썼을 때 아마 당신은 그것을 얻지 못했습니다! 대부분의 장소와 마찬가지로 최고의 문서는 아마도 코드 자체 일 것이므로 내가 가장 좋아하는 것은 잘 문서화 된 코드입니다. 기술 및 기능적으로 수행하려는 작업을 설명하는 코드의 줄 및 설명 줄

문서에 대한 # 1 규칙은없는 것 그것이 않고 왜 . 실행되는 프로그램의 배경은 무엇이며 어떻게해야합니까?

평소 외에도 문서에서보고 싶은 것은 어떤 기능이 빠져 있었을 것이라고 생각합니다. 같은 특정 아이디어는 이유 NOT 구현 또는 특정 플랫폼이나 방법은 NOT (명백한 선택은 그렇지이었다) 사용.

이렇게하면 후임자가 항상하지 말아야 할 일을 알 수 있거나 더 유능한 경우 해결 방법을 찾고 특정 기능을 작동시킬 수 있습니다.

이것은 특히 오픈 소스 프로젝트에 적용됩니다. 많은 시간과 두뇌 능력을 절약 할 수 있습니다!