Microsoft Word와 달리 일반 텍스트 마크 업 언어를 사용할 때 개발 과정에 어떤 장애물이 있습니까? [닫은]

저는 현재 정부 계약 업체의 인턴이며 Word가 소프트웨어 개발 프로세스에서 사실상의 표준이라는 느낌을 받고 있습니다.

이진 형식을 사용하면 코드 기반 공동 작업에 익숙한 방식으로 문서에서 공동 작업하기가 매우 어렵습니다. (LaTeX의, 마크 다운, 구조 조정 텍스트, 같은 언어를 일반 텍스트 마크 업의 사용 등 ) 개발자의 정상적인 흐름과 잘 작동하는 DIFF 친화적 문서 수 있습니다. 언어가 지원하지 않는 주석 (예 : 마크 다운)에 대해서는 마크 업이 포함 된 다른 일반 텍스트 파일에 쉽게 적용 할 수 있는 코드 기반 (예 : GitHub, Bitbucket)에 대한 협업 주석을 허용하는 기존 솔루션이 많이 있습니다.

기술적으로 문맹 인 관리와 협력해야한다는 것은 모든 것에 대한 일종의 그래픽 인터페이스가 필요하다는 것을 이해하지만 이러한 인터페이스는 대부분의 형식에 존재합니다. 예를 들어 LaTeX에는 그래픽 프론트 엔드를 일반 텍스트 LaTeX와 유사한 구문에 넣는 LyX라는 '포크'종류가 있습니다. 이 파일은 편집시 주로 그래픽으로 표시되지만 여전히 친숙합니다. (또한 Word 스타일의 주석도 있습니다.) 이러한 솔루션 중 상당수는 Word 대신 사용할 수 있으며 대다수는 무료 또는 오픈 소스입니다.

그러나 우리는 아무도 볼 수없는 내부 문서에도 Word를 사용합니다. 우리는 경력의 상당한 부분을 위해 텍스트로 작업합니다. 문서가 왜 그렇게 특별합니까? 사소한 것 외에도 "우리는 더 이상 잘 알지 못했고 지금 우리는 여기에 갇혀 있습니다"외에도 그러한 결정을지지하는 이유가 있어야합니다. 문서를 작성하는 다른 구어체 (구체적으로 덜 강력한) 수단 대신 일반 텍스트 문서를 사용할 때 소프트웨어 개발 프로세스에 어떤 어려움이 있습니까?

이유가 다를 수 있으므로이 두 가지 밀접한 관련 시나리오에 대해 개별적으로 답변해야합니다.

• 처음부터 일반 텍스트 문서 사용
• 시간이 지남에 따라 일반 텍스트 문서로 마이그레이션

소프트웨어 개발 프로세스에 참여하는 많은 참가자는 개발자가 아니며 문서에 관계없이 문서와 상호 작용할 수 있어야합니다. QA / 마케팅에서 단어를 사용해야하고 개발자가 다른 것을 완전히 사용해야합니까? 일관성이없고 유지 관리 체인에 다른 도구를 추가하고 회사의 IT 부분은 파일 문서 저장소를 관리 / 유지 관리하는 방법을 완전히 알고있을 때 파일로 무엇을 해야할지 전혀 모를 수도 있습니다.

무엇보다도 많은 비 개발자들은 대학에서 몇 년 동안 Microsoft Word를 사용하여 업무를 시작했으며 종종 단어를 사용하는 방법에 대한 실제 교육 수업을 받았습니다. 그들은 대안보다 훨씬 더 잘 알고 있습니다. Open Office와 Word에서 일할 때 그 차이를 거의 알 수 없지만 법에 동생이 돈을 저축하기 위해 사용할 때 일주일 후 그녀는 남편에게 단어를 사서 "내가 사랑하는 단어를 얻었으므로 나의 새로운 노트북! ". 그런 것들을 팽팽하게하는 사고 방식에 대해 생각하십시오. 예전의 약간의 변화는 그들에게 '약간'이 아닙니다.

현대 단어는 버전 차이, 버전 추적 및 변경 병합 기능이있는 주석도 허용합니다. 코드를 병합하는 것만 큼 간단하지는 않지만 많은 프로젝트 관리자가 쉽게 수행하는 것을 보았으므로 개발자도 그렇게 할 수 있습니다.

그 외에도 개발자 팀 사이에서 위키로 문서를 작성하는 것이 매우 일반적이되었습니다. 개발자가 아닌 사람도 편집 할 수있을 정도로 단순하게 유지하면서 텍스트 표현으로 되돌아 가기 때문입니다.

개인적으로 나는 그것이 교육의 문제라고 생각합니다.

대부분의 사람들은 MS Word와 같은 도구를 사용하면 양질의 문서를보다 쉽게 ​​만들 수 있지만 실제로는 더 어렵게 만듭니다. 결국 포맷을 끝없이 디버깅하고 원하는 결과를 얻기 위해 도구와 싸워야합니다.

Scrivener 와 같은 도구를 사용하면 Word와 달리 문서와 싸울 필요없이 문서의 현실에 좀 더 가까워 질 수 있습니다. 실현으로 인해 WYSIWYG는 실제로 잘 작동하지 않습니다.

내 조직에서는 대부분의 사람들이 MarkDown을 사용하여 문서의 대부분을 필요로할수록 더 많은 사람들이 더 행복하고 생산적입니다.

실제로 두 가지 질문이 있습니다.

첫째 : 비 개발 그룹이 소프트웨어 개발 프로세스에서 LaTeX 또는 기타 Markdown을 사용하지 않는 이유는 무엇입니까?

LaTeX로 마이그레이션 할 때의 문제는 특히 기술이 아닌 사용자를 다룰 때 인식되는 학습 곡선입니다. 사용자는 이미 다른 형식을 알고 있으며 동일한 방식으로 수행하는 다른 방법을 배우고 싶지 않습니다. 그들은 2 문서를 비교하는 방법에 대해 거의 알지 못하므로 텍스트 기반 형식으로 변경하는 데 아무런 가치가 없습니다. 자신이 알지 못하는 문제에 대한 해결책이 있다고 설명하는 것은 꽤 힘든 일입니다.

또한 순방향 모멘텀의 가치를 과소 평가할 수 없습니다. 새로운 형식으로 마이그레이션하려면 체인에있는 다른 사람들을 설득해야 새로운 것을 배우는 데 투자 할 가치가 있습니다. 아무 것도 편집하지 않아도 기존 형식이 제대로 작동하지 않을 때 새 형식으로 마이그레이션하려면 많은 시간과 노력이 필요합니다.

두 번째 질문 : 더 나은 옵션이 있고 더 잘 배울 수있을 때 팀에서 단어 문서를 계속 사용하는 이유는 무엇입니까?

이것은 팀원들과 이야기해야 할 내용입니다. 그들이 단어 문서를 유지하기로 선택한 정당한 이유가있을 수도 있고 그것이 항상 행해졌 기 때문일 수도 있습니다.

변경과 관련된 비용이 있으며 수백 또는 수천 개의 문서를 새로운 형식으로 옮기는 데 많은 비용과 시간이 소요될 수 있습니다. 환경을 변화 시키려고한다면 왜 변화해야하는지에 대한 사례를 만들어야합니다