Документирование решений, реализованных в программном проекте

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

Но я бы предпочел веб-приложение (например, центральный репозиторий), в котором определен рабочий процесс , который позволит мне хранить/документировать такого рода решения определенных проблем в программном проекте. Чтобы я мог снова искать и ссылаться на репозиторий в будущем, чтобы вспомнить, как я решил проблему, если столкнусь с ней снова.

Ведение блога помогает, но некоторые проблемы программирования очень малы и становятся очень тривиальными для сообщения в блоге. С другой стороны, нельзя описать целостное техническое решение по баг-трекерам.

Пожалуйста, предложите, есть ли какое-либо веб-приложение, подобное этому.

Ответы (2)

Я использую вики для аналогичного варианта использования.

Хорошая вещь: вы можете самостоятельно построить архитектуру/организацию/навигацию сайта.
Плохая вещь: вам придется самостоятельно создавать архитектуру/организацию/навигацию сайта.

Для вашего случая подойдет почти любая вики, но стоит изучить детали, которые вас интересуют.

В Википедии есть список и сравнение программного обеспечения вики. Сайт wikimatrix.org позволяет сравнивать вики на основе выбранных функций/требований.

Не стоит недооценивать внешний вид. Чтобы такая вики действительно имела смысл, вы должны часто посещать и редактировать ее. Но если редактирование не доставляет вам удовольствия (т. е. не простое/быстрое, некрасивое, плохое юзабилити) для вас, вы можете отложить его или прекратить после первых нескольких дней энтузиазма.

Лично я использую WikkaWiki ( ежедневно ежечасно в течение нескольких лет создал около 2000 страниц с более чем 35000 правок):

  • ФЛОСС.
  • PHP, MySQL.
  • Быстро, мелочь.
  • Поставляется с синтаксисом для блоков кода ( %% your code here %%) и поддерживает подсветку синтаксиса ( %%(php) your PHP code here %%). Вы даже можете указать имя файла (которое также позволяет загрузить файл кода) и начальные номера строк ( %%(php;15;test.php) your "test.php" here, starting from line 15 %%).
  • Его редактор по умолчанию поддерживает Tab(если вам нравится делать отступ в коде таким образом).
  • Поскольку URL-адреса «красивые», вы сможете напрямую вводить URL-адреса страниц, которые хотите посетить/отредактировать (что экономит много времени благодаря автозаполнению браузера):
    http://example.com/PHP
    http://example.com/PHP/edit

Возможные недостатки: довольно медленный процесс разработки (что для меня хорошо, пока проект не умер); нет полной поддержки Unicode (следующая версия, 1.4, переключится на полную UTF-8, но почти все должно работать нормально даже сейчас).

«Докувики» — еще одна хорошая вики. Это тоже FLOSS, использует PHP, но не требует базы данных (сохраняет все вики-страницы в текстовых файлах).

Наконец-то я решил остановиться на Git и Markdown . Для хостинга Git я выбрал GitLab, потому что это в основном GitHub с добавлением бесплатных частных репозиториев . Идея состоит в том, чтобы иметь одно репо для всех журналов, а затем иметь один каталог для каждого журнала или записи:

-root
  -Entry1
     Entry1.md
     file1.js
  -Entry2
     Entry2.md
     Entry2.html

Я также планирую использовать относительные ссылки и подсветку диапазона строк для ссылки на файлы кода в каталоге входа или во всем репозитории.

Возможно, когда-нибудь я даже смогу сделать репозиторий для своего блога.

Документирование решений, реализованных в программном проекте
СпросиСетьПолитика конфиденциальности1y, 0v