다른 사람의 과거 작업을 어떻게 문서화 할 수 있습니까? [닫은]

우리는 과거의 직원들이 비즈니스 크리티컬 시스템에 적용한 커스터마이징에 대한 문서가 거의없는 나쁜 상황에 처해 있습니다. ERP 소프트웨어를 위해 Crystal Reports, 데이터베이스 엔터티 및 독점 구성 / 프로그래밍 파일이 많이 변경되었습니다.

현재 문서는 일반적으로 다음과 같습니다.

이 프로그램은 인보이스 발행 전에 실행됩니다. 알려진 버그 : 없음

소프트웨어 X를 설치 한 후이 프로그램을 실행하십시오.

이 보고서에서 다음과 같은 필드가 변경되었습니다. (방법 및 이유에 대한 설명없이)

우리의 IT 샵은 규모가 작으며 ERP 소프트웨어의 경우 대부분의 작업이 한 사람 (지금은 나)에게 집중되어 있으므로 아무도 우리가 무엇을했는지 알 수 없습니다. IT 및 회계 부서는 비트와 조각 (종종 매우 유용한 것)을 알고 있지만 충분하지 않습니다.

또 다른 문제는 회계 부서 가 우리가 잘 문서화 되었다고 생각하는 것 같습니다 . 우리는 무엇이 잘못되었는지 에 대한 많은 기록을 유지했다는 것이 사실 이지만, 이러한 문제를 해결하기 위해 무엇을했는지에 대해서는 거의 설명하지 않습니다. 버그를 설명하는 수백 개의 논문이 있지만 위와 같이 변경 사항을 설명하는 문서는 거의 쓸모가 없습니다.

모든 작업이 무엇인지 모르는 경우 과거 변경 사항을 문서화하려면 어떻게해야합니까? 우리가 변경 한 것을 문서화 하는 것으로 시작할 수 있습니다 : 파일, 데이터베이스 테이블은 시스템이 작동하기 위해 필요합니다. 또한 우리 가 하는 일을 문서화 할 수 있습니다 . 보고서가 실행될 때 사람들에게 X 보고서 / 프로그램을 사용하도록 지시 한 이유. 그러나 이러한 맞춤형 것들 중 하나에 문제가 있으면, 나는 항상 정사각형으로 돌아갑니다.

이 자료를 본인과 다른 사람을 위해 사전에 문서화하려면 어떻게해야합니까?

나는 이것이 쓸데없는 운동이라고 생각합니다. 작동하면 작동하지만 작동하지 않으면 수정해야합니다.

오래된 자료를 문서화하는 가장 좋은 방법은 작업 할 때 수행중인 작업을 문서화하고 비즈니스 논리를 설명하는 것입니다 (문서화되지 않은 것으로 가정). 이것은 새로운 개발자에게 큰 도움이 될 것입니다.

오래된 코드 / 것들을 문서화하는 것에 대해 누군가가 그것을 소유해야했습니다. 이것이 현재 관리자라고 가정하겠습니다. 그에 대한 완전한 기술적 지식은 없지만 변경 내용을 알 수 있습니다. 이 경우, 귀하의 직업이 아닙니다. 관리자가 변경 내용에 대해 뭔가 쓸 수 있습니다. 그것은 역사를 유지하는 데 도움이 될 것입니다. 이와 같은 문제가 발생하면 해당 영역을 파고들 수 있습니다. 그러나 코드로 들어가서 변경 사항을 문서화하는 것은 매우 쓸모없는 IMO이며 아마도 불가능합니다.

변경 사항 을 문서화하려는 노력을 포기하십시오 .

대신 현재 작동하는 방식과 방법을 문서화하십시오 . 나중에 변경할 때 해당 설명서를 최신 상태로 유지하십시오.

소스 컨트롤이 있습니까?

그로부터 변경된 것을 해결할 수 있습니까?

그렇다면 새로운 기능이나 버그 수정 여부에 관계없이 비즈니스 변경 사항에 매핑 할 수 있습니다.

오래된 개발자 사서함을 다시 사용할 수 있습니까? (개인 정보 보호 문제로 실행 가능한지 여부는 확실하지 않습니다). 트롤링을 통해 얻을 수있는 많은 정보가있을 수 있습니다.

먼저 첫 번째 것들. 문서를 어디에 저장하고 있습니까? 아직 설치하지 않았다면 위키를 설정하십시오. 나는 dokuwiki를 선호 하며 , 너무 기울어지면 미리 빌드 된 vm 도 있습니다.

이것은 몇 가지 중요한 기능을 제공합니다.

• 회사 LAN의 어느 곳에서나 문서에 액세스 할 수 있습니다 (새 컴퓨터에 설치 중 ...)
• 모든 문서는 한 곳에 있습니다
• 모든 문서를 검색 할 수 있습니다
• 협업 가능 (새로운 동료, 소프트웨어 사용자)

지금, 당신의 문서가 종이 형태라면, 나는 당신에게 최선을 다하길 바랍니다. 워드 문서가있는 경우 가져 오기 스크립트를 작성하십시오 .

마지막으로 stuff 만 사용하십시오 . 무언가를 설치해야 할 때마다 위키에 메모를 작성하십시오. 가장자리가 맞으면 위키에 넣으십시오. 다른 사람들이 당신을 위해 일을하게하기 때문에 협업이 빛을 발하는 곳입니다.

보다 구체적인 문서로 넘어 가서 다양한 프로젝트의 소스로 작업해야하는 경우 적절한 개발 환경이 설정되어 있는지 확인하십시오 ! 물건 점검표를 위해 :

• 버전 관리 ( git , mercurial , fossil )
• 버그 추적 ( TRAC , 사마귀 , 레드 마인 , 화석 )
• 빌드 시스템 ( autotools , scons , buildbot )
• 프로젝트 제어 ( eclipse , 지정된 디렉토리 구조, 편집기 플러그인 )
• 소스 문서 (README, TODO, INSTALL, 소스 주석)

마지막으로, 문서는 지루할 수 있으므로 게임으로 만드십시오. 점검표의 각 항목에 대해 "점"을 제공하고 주기적으로 "점수"를 확인하십시오. 성취 한 내용과 결과를 확인할 수있는 좋은 방법입니다. 또한 다음에 가야 할 곳을 보여줍니다.

이것을 적절한 개발 환경을 설정하는 방법에 대해 많은 것을 배울 수있는 기회로보고, 시도하고 계속하는 것을 두려워하지 마십시오. 좋아하는 것을 찾고 환경을 마이그레이션하여 상황이 개선되도록하십시오 . 이를 최상의 솔루션을 구축하려는 프로젝트로 접근하십시오.

편집하다:

아래의 리그 의견에 따르면, 또 다른 유용한 방법은 소스 코드의 다이어그램을 만드는 것입니다. Freecode 물건을 가지고 ,이 문서 목록 인기있는 언어에 대한 몇 가지.

당신이 할 수있는 최선은 당신이 아는 모든 것을 문서화하고 회사 주변에 다른 사람들도 아는 것을 문서화하도록 요청하는 것입니다. 모든 사람이 최신 문서에 액세스 할 수 있도록 문서를 Wiki 또는 이와 유사한 방식으로 중앙 집중화하는 것이 좋습니다.

당신이 모르는 것을 문서화 할 수 없으므로, 왜 어떤 일이 일어 났는지 배우고 발견하려고하거나 문서화하지 않은 채로 둔다. 그렇기 때문에 회사는 문서를 작성하는 데 더 많은주의를 기울여야하지만 알고있는 문서는 여전히 거기에 고용되어 있습니다.

이해하지 못하는 코드를 문서화하려는 경우 기능을 테스트하기 위해 단위 테스트를 작성하는 것이 좋습니다. 이렇게하면 코드의 기능과 테스트 자체가 문서로 제공 될 수있는 것을 더 잘 이해할 수 있습니다.

행운을 빕니다!

더 이상 프로젝트 나 회사에 소속되지 않은 다른 사람이 한 일을 문서화하려고 할 때 나는 항상 다음과 같은 태도를 취합니다.

이 프로젝트가 찾은 문서 형태 인 이유는 모든 작업에 대한 문서가 프로젝트를 실행하는 데 다소 부수적이기 때문입니다. 따라서 변경 사항을 문서화하고 데이터베이스의 특정 필드와 특정 코드 블록이 무엇인지 알아 내면 다른 사람의 이익이 아닌 자신의 이익을 위해

자동 탐색 테스트를 작성할 수 있습니다. 여기에는 몇 가지 장점이 있습니다.

• 시스템을 작성할 때 시스템 작동 방식을 학습합니다

• 그것들은 나중에 실행 가능한 문서로 사용됩니다.

• 정기적으로 또는 심지어 지속적으로 실행하는 경우 변경 사항이 중단되거나 업데이트가 필요한시기를 감지 할 수있는 훌륭한 보안 망을 제공합니다.

그래도 특정 환경에서 이러한 종류의 테스트를 작성하는 것이 가능한지 모르겠습니다.