ET
Да, не техпис, всего лишь программист 😊 Я к тому, что при правке доков обычно не требуется компилить проект, прогонять тесты, на измененный код - а это бывает непросто. По крайней мере на моей практике. Ок, может не самое простое, но не такое сложное, как правки кода.
:)
я правила доки для простой программы в качестве тестового задания. понадобилось несколько часов, чтобы все себе установить (инструкции устарели и не помогали; нужный дитрибутив был запрятан где-то очень глубоко) и поизучать, что это и к чему. дальше просто.
если же это проект, соизмеримый (простите за пафос) с тем, что есть по работе, то изучать вот это все можно месяцами: ставить каверзные:) вопросы и простые, но многочисленные тесты, чтобы уточнить, что дает комбинация тех или иных опций и какой от этого профит пользователю/админу (такая экскавация юзкейсов). иногда и тестингом этого не выяснишь, нужно смотреть в код. это возможно, и те, кто пишут для разработчиков, знают структуру своего проекта и где что искать. но опять-таки, чтобы въехать, нужно время.
итого, техпис часто один из немногих, кто знает проект в целом, а не отдельные куски. да, отдельную фичу можно описать быренько, особенно если это простая пользовательская программа, но в большинстве других случаев контекст большой, только при пользовании/настройке вскрываются «нюансы» и никем не озвученные взаимозависимости (обожаю быть детективом).
—-
если речь была о «простой редакторской работе»: поправить чужой английский, а смыслы менять не нужно, там и так все збс - то это, и правда, просто (если ты хорошо знаешь тему, опять), но это редкий случай. часто нужно не просто «добавить окончания», поправить стиль или даже упорядочить то, что есть в чужом тексте, а самой наметить, что нужно раскрыть, - и собсно этим и заниматься.
—-
если же речь шла больше про техническую реализацию, то поправить md-файл, и правда, несложно. но я хотела всем нам рассказать, что делать это нужно осознанно. надеюсь, получилось)
я правила доки для простой программы в качестве тестового задания. понадобилось несколько часов, чтобы все себе установить (инструкции устарели и не помогали; нужный дитрибутив был запрятан где-то очень глубоко) и поизучать, что это и к чему. дальше просто.
если же это проект, соизмеримый (простите за пафос) с тем, что есть по работе, то изучать вот это все можно месяцами: ставить каверзные:) вопросы и простые, но многочисленные тесты, чтобы уточнить, что дает комбинация тех или иных опций и какой от этого профит пользователю/админу (такая экскавация юзкейсов). иногда и тестингом этого не выяснишь, нужно смотреть в код. это возможно, и те, кто пишут для разработчиков, знают структуру своего проекта и где что искать. но опять-таки, чтобы въехать, нужно время.
итого, техпис часто один из немногих, кто знает проект в целом, а не отдельные куски. да, отдельную фичу можно описать быренько, особенно если это простая пользовательская программа, но в большинстве других случаев контекст большой, только при пользовании/настройке вскрываются «нюансы» и никем не озвученные взаимозависимости (обожаю быть детективом).
—-
если речь была о «простой редакторской работе»: поправить чужой английский, а смыслы менять не нужно, там и так все збс - то это, и правда, просто (если ты хорошо знаешь тему, опять), но это редкий случай. часто нужно не просто «добавить окончания», поправить стиль или даже упорядочить то, что есть в чужом тексте, а самой наметить, что нужно раскрыть, - и собсно этим и заниматься.
—-
если же речь шла больше про техническую реализацию, то поправить md-файл, и правда, несложно. но я хотела всем нам рассказать, что делать это нужно осознанно. надеюсь, получилось)
