답변:
IMHO, 프로젝트를 직접 또는 간접적으로 전달하기 전에 한 가지만 수행 할 수 있다면 소스 제어에서 그대로 컴파일되는지 두 번 확인하고 삼중 검사하는 것이 좋습니다.
웃지 않지만, 소스 컨트롤에서 "최신"을 몇 번 받았으며 컴파일에 실패했는지, 나중에 "Fred 's old box"에 있지 않다는 것을 알아 내기 위해 코드가 " 프레드의 오래된 상자에 컴파일 ". 나는 심지어 전직 고용주가 큐브에서 내 데스크탑을 즉시 제거하고 "Fred 's old box"로 교체하여 내가 생각했던 프로젝트에서 작업 할 수있게했습니다.
위의 권장 사항의 확장으로 때로는 최신 버전을 얻는 것이 응용 프로그램을 컴파일하는 데 필요한 전부가 아니기 때문에 README.txt를 만들어 응용 프로그램의 루트 디렉토리에 놓고 소스 제어에 두는 것이 좋습니다. 이 README 문서에는 소스 제어 (있는 경우)로 확인할 수없는 외부 종속성 목록, 데이터베이스 설정 방법 및 응용 프로그램의 컴파일, 실행 또는 배포주기에 대한 기타 이상한 내용이 포함되어 있어야합니다.
위의 두 가지 제안을 넘어 서면 아무 문제가 없지만 IMHO는 "Hello World"보다 큰 프로젝트에서 거의 필요합니다.
편집하다:
문서 주제에 대해 ...
수년에 걸쳐 개발자의 전환을 완화하기 위해 소프트웨어 문서에 대한 공정한 부분을 작성하고 읽었습니다. 그러한 문서는 인쇄 된 용지의 가치가 거의 없다고 말하고 싶습니다. 개발자 (자신 포함)는 그러한 문서를 작성하는 동안 응용 프로그램의 중요한 부분을 거의 생각하지 않으며, 가장 최근에 발생한 화재에 대해서만 생각하는 경향이 있습니다. 이 문서들이 소프트웨어의 모든 중요한 측면을 다루지 않는 경향이 있다는 사실을 넘어서서, 그들은 또한 매우 빨리 구식이되었습니다. 문서가 구식이되면 장래의 개발자는 실제 상황에 맞게 문서를 다시 가져 오는 대신 문서를 완전히 무시할 가능성이 높습니다 (변화하는 요구 사항 생각).
문서 자체 대신 단위 테스트를 권장합니다. 이 시점에서 아마도 오래 된 것처럼 들리지만 코드가 문서화를하도록하십시오. 부서진 단위 테스트는 Word 문서보다 무시하기가 쉽고 찾기 쉽습니다. 또한 영어는 소프트웨어 디자인의 끝점을 분명히 표현하는 데있어 매우 부정확합니다. 심지어 가장 간단한 영어 문장의 의미를 해석하는 방법은 너무 많으며 이는 혼란과 버그로 이어집니다.
readme파일에 언급 된 항목 만 설치 하십시오. 코드가 컴파일되고 실행되면 모든 설정이 완료된 것입니다.
한 번의 명령 / 클릭으로 코드가 최종 양식으로 컴파일 및 패키징되는지 확인하십시오.
답을 공감할 수 없습니다 . 프로젝트를 진행할 때 알아야 할 사항은 무엇입니까? 충분하므로 다시 써야합니다.
이 원 클릭 컴파일에 대해 매우 까다 롭습니다. . 작은 버그를 수정 해야하는 프로젝트를 실제로 컴파일하거나 패키지하는 방법을 알아내는 데 이미 많은 시간을 투자했기 때문입니다. 최종 ZIP, JAR 또는 EAR을 패키지하기 위해 프로젝트에 배치 / bash 스크립트를 거의 사용하지 않았습니다.
그 외에도 전반적인 디자인 , 복잡한 부분 및 프로젝트 환경 을 설명하는 루트 디렉토리에 README.txt를 추가 합니다 (다른 부서 또는 개인과의 커뮤니케이션 측면에서).
이 README.txt를 작게 유지 하려고 합니다. 원하는 경우 버그를 수정하고 컴파일하고 패키지하는 것만으로도 200 페이지 이상의 사양 문서를 읽는 사람 이 없기 때문입니다. 구현 세부 사항은 단위 테스트에 문서화되어 있으므로 책에 다시 적을 필요가 없습니다 ...