Які дорожні блоки стикаються з процесом розробки для використання мов розміщення простого тексту, на відміну, наприклад, від Microsoft Word? [зачинено]

На даний момент я стажувався у державного підрядника і відчуваю (прикро неминуче) відчуття, що Word є фактичним стандартом у процесі розробки програмного забезпечення.

Її двійковий формат дуже важко співпрацювати з документами так, як я звик співпрацювати на основі коду. Використання простої розмітки тексту (з такими мовами, як LaTeX, Markdown, ReStructured Text тощо ) дозволяє створити документ, що відрізняється сприятливістю, що добре працює з нормальним робочим процесом розробника. Що стосується коментарів, де мова не підтримує їх (наприклад, Markdown), існує багато існуючих рішень, які дозволяють спільні коментарі щодо кодових баз (наприклад, GitHub, Bitbucket), які можна легко застосувати до інших текстових файлів, що містять розмітку.

Я розумію, що необхідність співпраці з технологічно неграмотним менеджментом потребує певного графічного інтерфейсу до всього, але такі інтерфейси існують для більшості цих форматів. Наприклад, у LaTeX є своєрідна «вилка» під назвою LyX, яка додає графічний передній край до синтаксису, подібного до LaTeX. Цей файл, хоч і в основному графічний у своєму редагуванні, все ще відрізняється зручністю. (У нього навіть є коментарі у стилі Word.) Багато з цих рішень ще можна використовувати замість Word, і переважна більшість є безкоштовними або з відкритим кодом.

Однак ми використовуємо Word навіть для власної внутрішньої документації, яку ніхто більше не бачить. Ми працюємо з текстом для значної частини нашої кар’єри --- чому документація така особлива? Крім тривіального "Ми не знали нічого кращого і тепер ми застрягли тут", повинні бути причини, що підтверджують таке рішення. Які проблеми стоять перед процесом розробки програмного забезпечення у використанні текстової документації замість інших, більш розмовних (і, очевидно, менш потужних) засобів написання документів?

Оскільки причини будуть різними, можливо, відповіді на ці два тісно пов'язані сценарії окремо повинні бути в порядку.

• Використання текстової документації з самого початку
• З часом переходить на текстову документацію

Багато учасників процесу розробки програмного забезпечення не є розробниками та потребують можливості взаємодії з документацією незалежно. Чи повинні QA / маркетинг використовувати слово та розробники повністю використовувати щось інше? Це було б непослідовно, це додало б ще один інструмент у ланцюжок технічного обслуговування, і ІТ-частина компанії може не мати уявлення, що робити з файлами, коли вони повністю знають, як керувати / підтримувати сховище документів.

Перш за все, багато не розробників витратили роки в університеті, використовуючи Microsoft Word, щоб повернути свою роботу, часто проходили фактичні заняття з того, як користуватися словом. Вони знають це набагато краще, ніж альтернативи. Я навряд чи можу сказати різницю, коли я працюю в Open Office vs Word, але коли я змусив сестру використовувати її для економії грошей, через тиждень вона змусила чоловіка придбати слово та проголосила "З моменту отримання слова я люблю мій новий ноутбук! ". Подумайте про умонастрої, що поєднують такі речі, незначна зміна того, до чого вони звикли, не є для них «незначною».

Сучасне слово дозволяє різниці версій, анотації з відстеженням версій і зміненням змін. Це може бути не таким прямим, як злиття коду, але я бачив, що багато керівників проектів роблять це легко, тому, безумовно, і розробникам це вдається.

Крім цього, серед команд розробників стало досить часто робити документацію у вікі, тому що вона повертається до текстового подання, залишаючись досить простою, щоб не розробники могли вносити зміни.

Особисто я думаю, що це питання освіти.

Більшість людей надумали думати, що використання такого інструменту, як MS Word, полегшує виготовлення якісних документів, але з того, що я бачив, насправді це ускладнює. Вам доводиться нескінченно відладжувати форматування і боротися зі своїми інструментами, щоб отримати бажаний результат.

Такі інструменти, як Scrivener, дозволяють вам трохи наблизитись до реальності документа, без того, щоб боротися з ним, як у Word. Частково через реалізацію WYSIWYG насправді не дуже добре працює.

У моїй власній організації тим чим більше людей я переїжджаю до використання MarkDown для більшості своїх документів, тим більше людей щасливіші та продуктивніші.

У вас дійсно є 2 питання:

По-перше: Чому групи, що не розробляють, не використовують LaTeX або іншу Markdown в процесі розробки програмного забезпечення?

Проблема з переходом на LaTeX - це сприйнята крива навчання, особливо коли ви маєте справу з не технічними користувачами. Користувачі вже знають інші формати і не хочуть вивчати інший метод того ж, що вони робили. Вони мало що знають про те, як відрізняти 2 документи, і тому для зміни тексту на текстовому форматі для них мало значення. Пояснення людині, що у вас є рішення проблеми, про яку вони не знали, є досить складною продажем.

Ви також не можете недооцінювати значення імпульсу вперед. Для того, щоб перейти до нового формату, вам дійсно доведеться переконати інших людей у ​​вашій мережі, варто вкласти гроші в вивчення чогось нового. Навіть якщо ви не очікуєте, що вони щось редагують, потрібен час і багато зусиль, щоб перейти до нового формату, коли існуючий формат працює (навіть якщо він поганий).

Друге питання: Чому моя команда продовжує використовувати текстові документи, коли є кращі варіанти, і вони більш ніж здатні їх вивчити?

Це те, про що ви повинні поговорити з людьми вашої команди. Можуть бути поважні причини, що вони вирішили зберігати текстові документи, або це може бути просто тому, що це було завжди.

Існують витрати, пов’язані з будь-якими змінами, і перенесення сотень чи тисяч документів у новий формат може бути дорого і забирає багато часу. Якщо ви збираєтеся спробувати змінити своє оточення, розраховуйте, що вам доведеться зробити справу, чому ви повинні змінитись