레거시 코드를 넘겨주는 모범 사례

몇 달 안에 한 동료가 새로운 프로젝트로 넘어갈 것이며 그의 프로젝트 중 하나를 물려받을 것입니다. 준비하기 위해 이미 Michael Feathers의 효과적인 레거시 코드 작업을 명령했습니다 .

그러나이 책과 지금까지 찾은 레거시 코드에 대한 대부분의 질문은 코드를 그대로 상속하는 경우와 관련이 있습니다. 그러나이 경우 실제로 원래 개발자에게 액세스 할 수 있으며 순서대로 인계 할 시간이 있습니다.

코드 조각에 대한 몇 가지 배경은 상속받을 것입니다.

• 작동 중 : 알려진 버그는 없지만 성능 요구 사항이 계속 증가함에 따라 먼 미래에 일부 최적화가 필요할 것입니다.
• 문서화되지 않음 : 메소드 및 클래스 레벨에 문서가 거의 없습니다. 그러나 코드가 더 높은 수준에서 수행되어야하는 것은 수년 동안 API에 대해 블랙 박스로 작성했기 때문에 잘 이해되고 있습니다.
• 더 높은 수준의 통합 테스트 만 해당 : API를 통해 다른 구성 요소와의 적절한 상호 작용을 테스트하는 통합 테스트 만 있습니다 (다시 블랙 박스).
• 매우 낮은 수준, 속도에 최적화 : 이 코드는 전체 응용 프로그램 시스템의 중심이기 때문에 많은 코드가 수년에 걸쳐 여러 번 최적화되었으며 매우 낮은 수준입니다 (일부 구조에는 특정 구조에 대한 자체 메모리 관리자가 있음) / 레코드).
• 동시 및 잠금없는 : 동시 및 잠금없는 프로그래밍에 대해 잘 알고 있으며 실제로이 코드에 몇 가지 부분을 기여했지만 복잡성이 더해집니다.
• 큰 코드베이스 : 이 특정 프로젝트는 1 만 줄 이상의 코드이므로 모든 것을 설명 할 수있는 방법은 없습니다.
• 델파이에서 작성 : 나는이 유형의 문제가 언어에 구애받지 않는다고 믿기 때문에 언어가 질문과 관련이 있다고 생각하지는 않지만 이것을 여기에 넣을 것입니다.

나는 그의 출발까지의 시간이 어떻게 가장 잘 소비 될지 궁금했다. 다음은 몇 가지 아이디어입니다.

• 내 컴퓨터에 모든 것을 구축하십시오 : 모든 것이 소스 코드 제어로 체크인되어야하지만 파일을 한 번에 한 번 체크인하지 않은 사람은 비즈니스의 첫 번째 순서 일 것입니다.
• 더 많은 테스트 : 더 많은 클래스 수준의 단위 테스트를 원하지만 변경 할 때 소개하는 모든 버그를 조기에 발견 할 수 있습니다. 현재 코드를 테스트 할 수 없습니다 (거대한 클래스, 긴 메소드, 너무 많은 상호 의존성).
• 문서화 할 내용 : 우선 저수준 / 고도로 최적화 된 특성으로 인해 이해하기 어려운 코드 영역에 문서화하는 것이 가장 좋습니다. 나는 추악하고 리팩토링 / 다시 쓰기가 필요할 수있는 몇 가지가 있지만 실제로 내가 놓칠 수있는 좋은 이유 때문에 거기에 있었던 최적화입니다 (참조, Joel Spolsky, 당신이해야 할 것들) 절대 안함, 파트 I )
• 문서화 방법 : 아키텍처의 클래스 다이어그램과 중요한 기능의 시퀀스 다이어그램이 가장 좋을 것이라고 생각합니다.
• 누구를 문서화 할 것인가 : 나는 무엇이 더 좋을지 궁금해했다. 문서를 쓰거나 나에게 설명하도록해서 문서를 쓸 수 있었다. 나는 그에게 명백하지만 나에게 그렇지 않은 것들이 제대로 덮이지 않을까 두려워한다.
• 페어 프로그래밍을 사용한 리팩토링 : 시간 제약으로 인해 불가능할 수도 있지만, 코드의 일부를 리팩토링하여 유지 보수가 용이 한 이유는 무엇인지에 대한 정보를 제공 할 수 있습니다.

댓글을 달고 추가하십시오. 이 모든 작업을 수행 할 시간이 충분하지 않기 때문에 우선 순위를 매기는 방법에 특히 관심이 있습니다.

업데이트 : 인계 프로젝트가 끝나면 아래 답변 에서 자신의 경험 으로이 목록을 확장했습니다 .

개발자에게 액세스 할 때 코드 요청 :-

• 코딩 / 구현하기 가장 어려운 모듈 무엇이 문제였으며 어떻게 극복 되었습니까?

• 가장 많은 버그를 생성 한 모듈

• 버그를 해결하기 가장 어려운 모듈은 무엇입니까?

• 그가 가장 자랑스럽게 생각하는 코드는 다음과 같습니다.

• 어떤 코드를 리팩토링하고 싶었지만 시간이 없었습니다.

이 질문들은 당신에게 가장 큰 문제를 야기 할 수있는 것에 대한 통찰력을 제공 할 것이며, 아마도 아마도 개발자의 사고 과정과 관점에 대한 핸들링 일 것입니다.

인계 프로젝트가 끝났으므로 시간을내어 자신에게 가장 잘 맞는 것들이 포함 된 답변을 작성하겠다고 생각합니다.

• 모든 것을 버전 관리하에 가져 오기 : 빌드하는 데 필요한 모든 것이 버전 관리하에 있는지 확인한 후 이전 개발자의 하드 드라이브를 검색하여 응용 프로그램을 배포 및 / 또는 테스트하는 데 도움이되는 추가 스크립트 나 유틸리티를 찾았습니다. 체크인하지 않았습니다.
• 하향식 : 주요 수업에 대한 높은 수준의 살펴보기와 주요 지역의 오래된 개발자와의 가이드 투어로 시작합니다. 그런 다음 //TODO마커 로 나에게 이해가되지 않는 것을 표시하여 나머지 부분을 더 깊이 파고 들었습니다 .
• 모든 문서를 직접 작성 하십시오. 오래된 개발자가 문서를 올바르게 작성했는지 확인하기 위해 모든 것을 직접 작성해야했습니다. 이런 식으로 나는 글이 이전 개발자뿐만 아니라 나에게 의미가 있음을 확신 할 것이다.
• 모든 곳에서 의견 : 모든 클래스와 모든 방법 에 XML 문서 요약 을 추가했습니다 . 이런 식으로 나는 적어도 모든 코드 조각을 보았고 그것이 문장에서 무엇을했는지 요약 할만큼 충분히 이해했다. 또한 IntelliSense가이 정보를 선택함에 따라 요약 메소드 / 클래스를 사용하여 메소드를 쉽게 이해할 수있었습니다. 또한 여전히 살펴 봐야 할 코드 영역을 쉽게 식별 할 수있었습니다.
• 소스와 가까운 문서 : 소스 코드와 문서를 쉽게 연결할 수 있도록 대부분의 문서를 소스 코드에 넣었습니다. 다양한 하위 시스템 간의 상호 작용을 설명하는 고급 문서의 경우이 정보를 코드의 한 곳에만 배치해도 작동하지 않기 때문에 위키를 사용했습니다. 모든 문서는 전자적이고 전체 텍스트 검색이 가능해야합니다.
• 다이어그램 : 기본 개요를 위해 다른 하위 시스템에 대해 다양한 세부 단위의 클래스 다이어그램을 사용했습니다. 동시 부품의 경우 객체 및 상호 작용 다이어그램이 실제로 도움이되었습니다. 주제에 대한 다른 질문 도 참조하십시오 .
• 쌍으로 리팩토링 : 코드에 대한 느낌을 얻고 유지 보수가 용이하도록 이전 개발자와의 리팩토링을 수행하는 동안 좋은 리팩토링 도구가 부족하고 많은 불쾌한 프로세스로 인해 시간이 많이 걸리고 위험한 프로세스였습니다. 다양한 부분 간의 의존성. Michael Feathers의 레거시 코드를 효과적으로 사용 하는 것은 적절한 도구를 지원하지 않는 리팩토링이 여전히 어려움을 겪는 경우에도 실제로 도움이됩니다. 리팩토링하는 동안 마우스와 키보드를 제어 할 수있게되었는데, 그 방법이 더 재미 있었고 (마지막 글 머리 기호 참조), 내가 배우고있는 것을 자유롭게 적어 놓을 수있었습니다.
• 의견 및 변경 사항에 대한 별도의 체크인 :에 댓글을 작성하여 실수로 버그를 도입 한 후 override별도의 체크인에서 의견을 작성하고 변경하는 데주의를 기울였습니다. 체크인하기 전에 소스 코드에서 모든 주석을 제거하기 위해 작은 유틸리티를 사용했기 때문에 주석 전용 체크인의 차이는 0의 차이를 나타냅니다. 모든 변경 사항 (예 : 사용하지 않는 필드 제거)은 이전 개발자와 신중하게 검토하여 여전히 필요한 항목을 제거하지 않았는지 확인했습니다.
• 중요한 구절을 한 줄씩 살펴보기 : 가장 최적화 된 / 복잡한 구절을 위해 이전 개발자와 때로는 세 번째 동료와 함께 코드를 한 줄씩 살펴 봅니다. 이 방법으로 코드를 철저히 이해하고 더 많은 사람들이 코드를 조사 할 때 실제로 최적화 할 수있는 몇 가지 버그와 몇 가지 버그를 확인했습니다.
• 신속하고 이전 개발자에게 동기를 부여하십시오. 이전 개발자가 마지막 날이 다가옴에 따라 관심이 줄어들 었다는 사실을 알게되었습니다. 따라서 가장 중요한 부분을 먼저 넘겨주고 나머지 부분은 필요한 경우 스스로 알아 내야합니다. 또한 그에게 더 재미있는 것들 (예 : 페어 프로그래밍시 키보드 제어)을 남기고 문서 작성과 같은 지루한 일을 직접 시도했습니다.
• 기능 요청 식별 : 이전 개발자에게 사람들이 요청했지만 아직 추가하지 않은 기능 목록을 요청하는 것이 도움이되었습니다. 추가하기가 간단 해 보이는 몇 가지 사항이 있었지만, 구현할 때 다른 것을 깨뜨 렸기 때문에 처음에는 생각했던 방식으로 추가되지 않은 좋은 이유가있었습니다.

비슷한 상황에 있었기 때문에 다음 사항도 고려할 가치가 있다고 생각합니다.

• 배포를 수행하고 테스트 할 수 있는지 확인하십시오 . 제품을 처음부터 직접 배포하고 떠나는 사람이 수행 한 것과 동일한 지 확인 하십시오. 이를 통해 모든 스크립트와 지시 사항을 명확하게 확인할 수 있으며 버전 관리 시스템에 체크인하지 않은 구성 요소와 같은 우발적 인 감독을 포착 할 수 있습니다. (나는이 것을 말하는 게 아니에요 것 이 경우에 단지 일어날 한 일이 사람이 떠나기 전에, 지금 다루는 훨씬 쉽게 될 것입니다)

  (예 : Continuous Integration 또는 Continuous Deployment를 이미 수행하고있는 경우에는 이와 관련이 없을 수 있지만 경우에 따라 언급 할 가치가 있습니다 ...)

• 더 많은 테스트를 작성 : 이것은이다 정말 시스템의 이해를 테스트하는 좋은 방법. 코드의 영역을 더 자세히 살펴볼 수있게하고, 코드가 의심 할 정도로 버그가 없는지 확인하거나 의도를 이해 했다고 생각하는 영역을 밝히지 만 실제로는 동료가 떠나기 전에 설명을 요구해야합니다.

• 문서 쌍 쓰기 : 개요를 작성하는 효과적인 방법입니다. 난 당신이 기능이나 영역을 설명하기 위해 동료를 얻을 수 있음을 시사하고있어, 다음 당신은 당신 자신의 말로, 문서, 그것을 쓰기. 우리는 두 사람이 함께 할 때 이것이 훨씬 쉽다 는 것을 알았 습니다.

테스트는 아마도 문서를 작성하는 것보다 개인적으로 테스트 작성을 최우선으로 생각합니다.

pair-programming을 사용한 리팩토링 과 관련 하여 내가 말할 수있는 유일한 것은 특히 높은 수준의 테스트 만 받았다고 말했을 때 이것이 바닥이없는 구덩이가 될 위험이 있다는 것입니다. 원하는 시간보다 더 많은 시간을 사용하여 종료 될 수 있습니다.

질문에 이미있는 답변에 +1

가이드 투어
10k 줄의 코드는 많지만 다른 사람이 당신에게 '안내 투어'를 제공하는 것은 여전히 ​​불가능하지 않다고 생각합니다. 당신은 코드 앞에 함께 앉아 있으며, 그는 당신을 위에서 아래로 여행하면서 '계층'을 내려갑니다. 당신은 짧은 버스트로 그것을해야합니다-한 번에 모두 당신을 죽일 것입니다.

확대, 축소이
작업의 장점은 설명하는 동안 거의 문서화하려고하지 않았을 수도있는 "아, 그래, 이것도 있습니다"라는 순간이있을 것입니다. 그 혼자서. 그리고 귀하의 질문은 명백히 그에게 있지만 다른 사람에게는 그렇지 않은 비트에 집중하는 데 도움이 될 것입니다. 이런 종류의 확대 / 축소 상호 작용은 일대일로만 가능하며 그와 비슷한 것을 쓰거나 읽으려고 시도하는 것은 다루기 어렵습니다.

문서
나는 당신이 독립적으로 물건을 문서화해야한다고 생각합니다-그는 맨 아래에서 시작해야합니다 (함께 갈 시간이 없다면) 맨 처음부터 시작해야합니다. 그의 가이드 투어와 다른 사람을위한 것처럼 [이전 직장에서 나는 '레거시'코드를 물려 받았고, 단지 나 자신을 떠나기 전에 그것을 문서화 할 시간이 있었다).

어 Where 어?
이것의 대부분의 목적은 물건이 어디에서 일어나는지 느낄 수 있도록하는 것입니다. 따라서 특정 버그 또는 수정이 주어지면 코드에서 집중해야 할 곳을 매우 빨리 찾을 수 있습니다. 오래된 버그 목록을보고 문제의 위치를 ​​정확하게 예측할 수 있는지 확인하여 스스로 테스트 할 수 있습니다.

그를 말리십시오.
그가 당신을 미워하게되는 것은 중요하지 않습니다 (미소). 당신의 임무는 가능한 시간 내에 가능한 한 많은 사람의 뇌에서 많은 정보를 얻는 것입니다. 당신이 당신의 관리를 받고, 그들이 함께 떠나지 않는 한 "그들이 떠나기 전에 마지막 몇 가지 버그를 고치기"보다 지식 이전을 우선시하십시오.

다음 사항을 제안합니다 (이미 확인 된 것 외에)-먼저 관리자에게 가능한 한 많은 사람과 일할 시간을주고 변경을 할 때마다 그와 함께 앉으라고 요청하십시오. 당신은 그가하고있는 모든 것을 알 필요는 없지만 가능한 한 많이 잡으려고 노력하십시오. 그와 친구가 가장 중요합니다.

인계를 프로젝트로 취급하고 계획을 세우고 경영진을 참여시킵니다.

0-시스템 사용법을 알고 있어야합니다.

1-솔루션 구성 요소, 각 구성 요소의 출처 및 위치 (확실한 저장소)의 명확한 인벤토리를 만듭니다.

2-지금 시작하는 다른 서버의 비밀번호를 가져오고 가능한 경우 관리하십시오. 모든 관리자 계정 정보가 있는지 확인하십시오

3-범위를 벗어나지 않는 한 각 외부 구성 요소의 라이센스를 가져옵니다 (예 : 특수 dll, 데이터베이스 등).

4-개발자 및 고객 (회사가 현지인 경우)으로부터 시스템의 현재 상태에 대한 서면 보고서를받습니다.

5-비즈니스 규칙, 계산 공식 등에 대한 문서를 받으십시오.이 작업을 수행 할 수 있습니다. 그에게 이메일, 회의 정보, 사용자 요구 사항 문서, 디자인 문서 등을 요청하십시오.

6-소프트웨어가 응답해야하는 예약 된 이벤트 목록 (월별 작업 실행, 주별 작업 실행)을 가져옵니다.

7-백업 / 복원 절차 배우기

8-응용 프로그램 작성에 사용 된 프레임 워크 이해

9-요청 / 예상 / 예정 수정 및 보류중인 사용자 요청의 상태를 파악합니다. 스스로하는 방법을 알아 내기 시작하십시오.

10-테스트 및 개발 환경이 매우 유사한 지 확인하십시오.

11-쉽게 발견 할 수없는 주요 종속성 (다른 시스템 또는 구성 요소 간)을 식별하십시오.

12-각 소프트웨어 사용에 필요한 버전과 공급 업체 담당자를 식별하고 문서화합니다 (필요한 경우).

13-도움이 될 수 있도록 사용하지 않은 특수 도구를 식별하십시오.

14-높은 수준의 시스템 흐름을 확보하십시오. 문서 라이브러리 구축을 시작하십시오

15-애플리케이션의 사용자 보안을 관리하는 방법 이해

16-버그 로그를 가져 와서 조치 및 조치가 이전 데이터에 미치는 영향을 이해하려고 시도하십시오 (해당되는 경우).

17-프로세스가 너무 오래 걸리고 적용 할 수있는 항목 (예 : 비정상적인 파일 크기, 중복 파일의 ftp 등)을 알고 있어야합니다.

18-프로덕션 서버 시계 확인

19-구성 위치를 식별하고 각 환경 구성을 프로덕션과 비교하여 어떤 매개 변수가 다르고 이유를 파악하십시오.

20-이 남자의 연락처 정보 받기

21-시스템이 내부 시스템 인 경우 시스템 사용자와의 미팅을 예약하고 (시스템 상태 및 역할을 알아야 함) 사용자에게 소개하십시오. 시스템과 현재 문제 (있는 경우)에 대한 의견을 들어보십시오. 관리자의 승인을받은 후 가능한 빨리 이메일에 포함 시키십시오

22-출발 1 주일 전에 이해를 평가하고 위험으로 간주되는 문제를보고하십시오.

데이터베이스가 없다고 언급 했으므로이 목록은 더 짧아졌습니다.

행운을 빕니다.

가장 복잡하고 성능이 최적화 된 부품을 먼저 고려합니다. 먼저 해당 부분을 문서화하고 한 번에 하나씩 설명하도록하고, 그런 다음 해당 부분에 대해 테스트를 작성하려고합니다 (성능 테스트 전후에 발생) ) 다른 사람에게 테스트를 검토하도록합니다. 이런 식으로, 그는 문서를 작성하고 설명하며, 설명을 사용하여 테스트를 작성하고 (다른 영역을 문서화하는 동안), 그의 검토는 테스트 대상을 이해하는 데 도움이됩니다. 이렇게하면 응용 프로그램의 가장 중요한 부분과 특수 성능 최적화 문서에 대한 추가 테스트 수렴을 얻을 수 있습니다.

그것들을 다루고 나서 시간이 있다면, 다음으로 몇 년 동안 가장 자주 변경이 필요했지만 문서화 된 첫 번째 그룹에 속하지 않은 응용 프로그램의 부분들과 비슷한 프로세스를 진행할 것입니다.

그런 다음 남은 것을 문서화하십시오.

큰 코드를 잡는 가장 좋은 방법은 하향식 접근법이라고 생각합니다. 먼저 큰 그림을 이해 한 다음 점차적으로 구성 요소를 하나씩 자세히 살펴보십시오.

이제 각 파기 단계에서 가장주의를 기울여야 할 부분의 우선 순위를 정하십시오. 그에게 가능한 많은 설명을하도록하지만 항상 직접 문서화하십시오.

직접 문서화하는 가장 좋은 점은 나중에 다시 올 때 설명 할 때와 동일한인지 상태를 다시 불러오는 데 아무런 문제가 없다는 것입니다. 다른 사람보다 자신 이 쓴 내용 을 훨씬 쉽게 이해할 수 있습니다 . 내 경험상 두 사람이 동일한 코드 조각을 문서화하면 비슷한 모양의 텍스트 조각이 생성되지 않습니다.

이를 통해 "무엇을 어떻게 문서화 할 것인지"문제를 해결할 수 있습니다. 그가 모든 것을 설명 할 때, 코드로 돌아 왔을 때 원하는 것을 스스로 결정하고 그 부분 만 문서화 할 수 있습니다.

아이디어는 먼저 코드를 완전히 이해 한 다음 나중에 (그가 없을 때) 코드를 읽을 수 있도록 모든 것을 작성하고 수행하는 것입니다.

코드를 완전히 이해하면 큰 그림을 느끼고 각 구성 요소가이 큰 그림과 어떻게 관련되는지 알아야합니다. 각 조각이 전체를 어떻게 구성하는지 추적하는 것이 특히 유용하다는 것을 알았습니다. 고립 된 것을 이해하려고 시도하지 마십시오. 문맥에 대한 시야를 놓치지 마십시오.

마지막으로, 일단 위의 작업을 수행하면 사전에 제어권을 갖습니다. 단위 테스트 적용 범위가 필요한 부분을 스스로 결정하십시오. 어떤 부품을 최적화해야하는지 (또는 최적화 할 수 있는지), 어떻게 일부 구성 요소를 리팩토링 할 수 있는지 등

나는 당신을 느낀다.

몇 가지 제안 :

1. 떠나는 프로그래머와의 모든 대화를 녹음하십시오!
2. "큰"문제 뒤에 동기를 요청하십시오. API를 이해하는 것이 좋지만 내부 의사 결정을 파헤칩니다. 왜 코드가 그대로 분할 되었습니까? 책임은 무엇입니까?
3. 실제로 코드를 연구하기 위해 노력하십시오. 유지 관리 및 지원 업무를 수행 할 때 "진행 중 코드를 연구"해야하는 경우가 있습니다. 가능하면 저항하고 실제로 코드를 연구하십시오.
4. 시나리오를 찾으십시오. API를 알고 있습니다. 코드의 작동 방식을 확인하십시오. 기억해야 할 예로는 팩스 모듈이 있습니다. API 사용자는 페이지 이미지를 준비하고 코드를 전송하여 페이지를 전송하라는 명령을 보내야했습니다. 이 시나리오가 어떻게 진행되는지 알아 보려면 떠나는 프로그래머에게 코드에서 추적하도록 요청하십시오. 그런 다음 "수신 페이지"시나리오로 이동하십시오.
5. 80/20-더 일반적인 시나리오를 먼저 다루십시오.
6. 다시 쓰십시오. 코드가 오래되었고 인터페이스가 잘 정의되어 있으면 기술이이를 정당화하기에 충분히 변경되었을 수 있습니다.
7. 나는 이것을 말하기 싫어하지만 새로운 일자리를 찾는 것을 고려하십시오.

적절한 문서를 합리적으로 고통없이 Pascal Analyzer (PAL) 사본을 구입하려면 Delphi 프로젝트에서 이것을 사용했으며 훌륭했습니다. 문서 기능을 잘 모르는 제품으로 분리했을 수 있습니다 (Pascal Browser) 따라서 PAL은 모두 300 달러 미만을 구매해야 할 수도 있지만 PAL은 함수가 호출되는 위치에서 변수가 사용되는 위치를 이해하고 코드와 관련된 모든 종류의 잠재적 문제를 포착하는 데 유용한 도구입니다.

PAL을 사용하여 코드의 구조와 내 경험이 계속 진행되는 경우 약 1000 가지 제안 개선 사항에 대한 아이디어를 얻으십시오. 목록을 살펴보면 코드의 품질이 향상되고 크게 단순화되며 미래의 삶이 더 쉬워집니다. 델파이 자체는 최근 버전 (최근 5 년 정도)에서 리팩토링을 지원합니다. 내가 그것을 할 때 실제로 제대로 작동하려면 dpr 파일에 모든 것을 포함시켜야했습니다.

단위 테스트를 원할 경우 DUnit을 다운로드 하고 원래 코더로 테스트를 시작하십시오. 아마도 시간의 일부를 사용하는 건설적인 방법 일 것입니다.

백엔드 데이터베이스에 대해서는 언급하지 않았지만 데이터베이스가 있다고 가정하면

1. 특히 열과 PK-FK로 문서화 된 데이터 모델을 얻습니다.
2. SQL 추적을 설정하고 응용 프로그램을 사용하는 동안 발생하는 모든 쿼리를 기록하십시오. 쿼리 실행 순서는 응용 프로그램의 흐름에 대한 좋은 아이디어를 제공하고 디버깅에도 도움이됩니다.

저는 우리 건축가가 호주로 이주하여 지난 8 년 동안 회사에서 일했던 것처럼 많은 유산을 남긴 상황과 같습니다. 그는 계약자였던 이전 건축가의 유산을 스스로 물려 받았습니다.

당신과 다른 사람들은 이미 좋은 점을 언급했지만 여기에 우리가 떠난 후에 직면 한 문제는 더 잘 준비 할 수 있다는 것입니다 ...

1) (기술자) 그가 다루고있는 고객의 연락처.

2) 소프트웨어 라이센스를 구매 한 그의 계정, 매년 갱신해야하는 키 및 갱신을위한 프로세스 / 비용.

3) 귀하의 제품과 통합 된 타사 소프트웨어 라이브러리 / 구성 요소 및 제품의 설치 문서. 우리는 4 일 동안 IT 공간을 확보하고 잃어버린 기계를 가져 와서 잘못된 지시를 전달하기 위해 4 일 동안 어려움을 겪었습니다.

4) 소스 코드를 소프트웨어 예치금 회사 (예 : 에스크로)에 예치하는 데 사용되는 문서 / 단계.

5) 아직 긴 목록이 있지만 귀하에게 적용되지 않을 수도 있습니다. 실제 사람을 대체 할 수있는 문서의 양이 없으므로 그의 세부 정보를 편리하게 유지하고 좋은 조건과 행운을 유지하십시오 :)

또한 이것이 당신에게 처음인지 모르겠습니다. 나를 위해 5/6 명의 고용주와 함께 일했으며 항상 나쁜 문서가 있거나 전혀 문서가없는 코드를 상속했습니다. 따라서 모든 문서와 함께 긍정적으로 유지하십시오 :)