Поддержание вики-программиста

Ответ 1

• Введение в исходную базу для новых программистов
• Общая документация (а не документация по API в отдельности, но больше учебника, как вещи)
• Списки сотрудников/кто делает то, что и как их достичь.
• Примечания/ресурсы/статьи, которые объясняют понятия, используемые в программном обеспечении.
• Документация процесса сборки и макета файловой системы для кода

Другие вещи, которые я обычно встречаю, есть

• Планирование/списки задач
• Информация, интересная для других читать
• Все остальное, что я чувствую, должно быть общим.

Ответ 2

У нас была разработка wiki, и это был отличный инструмент. Мы использовали его для всего!

• Когда мозговой штурм новых идей, мы будем захватывать их в вики. Низкий коэффициент трения wiki облегчил для любого в организации (мы были небольшим запуском), чтобы добавить идеи, как они думали о них. У нас была страница "мозгового штурма" на высоком уровне, которая была связана с подробными страницами, содержащими подробное описание каждой идеи.
• Для каждой итерации мы будем "перемещать" элементы идеи объектов из списка "мозговой атаки" в список функций для этой итерации. Детали этой функции были очищены, чтобы включить детали проектирования и реализации.
• По мере того, как функции были завершены, страница итераций стала нашей страницей выпусков выпусков - которая также включала тег релиза из нашей системы управления версиями.
• У нас была страница с ошибками, которая очень похожа на страницы функций. Исправленные ошибки были добавлены на страницы итерации/выпуска по мере их работы/завершения.
• Мы также создали нашу пользовательскую документацию на вики и экспортировали эти страницы с выпуском.

Со временем. Этот инструмент рассматривался все более и более ценным. Мы создали новые вики для разных продуктов, над которыми работала компания.

Надеюсь, вы найдете свою вики развития так же полезной, как и мы!

Ответ 3

Wikipatterns - это сайт, посвященный документированию лучших вики-практик. Они также описывают анти-шаблоны и говорят о способах борьбы с ними. Я прочитал их книгу, и для меня было большим преимуществом получить вики с земли в организации с более чем 150 лицами.

Ответ 4

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

Помимо стандартов кодирования, мы оставляем советы и рекомендации для работы с нашей базой кода, информацией о настройке для новых сотрудников и общей информацией об окружающей среде.

Ответ 5

• Таблицы Burndown
• общая информация о настройке для среды разработки (хорошо, когда начинаются новые люди)
• функции
• Известные проблемы и обходные пути с инструментами разработки.

Ответ 6

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

Беречь от вещей, требующих обсуждения. Я попробовал shoehorn в разделе обзора книги, но было слишком сложно заставить других прокомментировать вещи.

Примеры домашних библиотек хороши. И/или "раскадровки", идущие пользователем через процесс, когда вызывается MethodX.

Ответ 7

Каковы некоторые рекомендации, которые использует ваша команда разработчиков для своей внутренней вики?

Сделайте это хорошо. Я знаю, что это не очень важно, но если вы потратите немного времени на брендинг, это окупается с точки зрения людей, которые действительно используют его. И захват является ключевым, или он просто увядает и умирает.

Какая информация важна для вики-разработчика?

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

Если бы вы пошли в вики для своей команды разработчиков, какую информацию вы ожидаете увидеть?

Информация о проекте, кто работает над тем, что и т.д. Решения о конструкции. Также лучшие практики и ссылки на полезные сайты.

Есть ли какая-то информация, которая не должна идти на wiki, хотя это кажется хорошей идеей?

Списки низкоуровневых задач, как правило, колеблются и не сохраняются в актуальном состоянии и могут вводить в заблуждение. Кроме того, критические коммуникации между отделами лучше подходят для электронной почты, ТОГДА разговор можно скопировать в вики. Это слишком легко игнорировать в противном случае!

Ответ 8

Помните, что вики интерактивны. Если вы думаете о публикации, как и при публикации скриншотов, вы не думаете достаточно далеко. Распространение этой информации является лишь ее частью.

Например, вместо того, чтобы иметь страницу "Текущая диаграмма ожога", создайте страницу для "Диаграммы ожогов на неделю с 10 по 27 октября", а затем попросите людей прокомментировать график и что это значит и почему вы сделали это плохо на этой неделе.

Ответ 9

Самая сложная задача - заставить разработчиков использовать вашу вики. У меня есть несколько давних предложений здесь: http://possibility.com/wiki/index.php?title=GettingYourWikiAdopted

Получение принятой Wiki жесткой

Есть чемпион

Удалить возражения

Создать контент

Enmesh Wiki в корпоративных процессах

Евангелизация

Не сдавайтесь

Не используйте Wiki для разговоров

Просто сделай это! Не ждите бюджета

Есть план перехода

Продвижение вашей вики

Одна хорошая практика заключается в том, чтобы вся документация и исходный код для каждой сборки были доступны через вашу вики. Затем разработчики перейдут в wiki для доступа к информации о сборке, что делает ее неоценимой.

Ответ 10

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

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

Однако важно также не быть форматом czar: если у вас есть много документов, которые вы создаете, скажем, MS WORD, может быть идеально, чтобы делать их все в формате Wiki, но это требует времени и может быть раздражает, если у вас есть диаграммы, документы и т.д. В этих случаях лучше идти на компромисс и позволять людям хранить его в текстовом формате, пока единственный способ доступа к новейшей версии - через Wiki.

Если вы не менеджер, вам нужно получить менеджера на борту, потому что для этого потребуется некоторое "принуждение".

В Wikis были накоплены исследования и опыт, а также их использование в разработке программного обеспечения. Например, вы можете искать цифровую библиотеку ACM. Я являюсь соорганизатором ежегодного семинара по вики для SE, и у нас было несколько интересных отчетов об опыте, и на международном симпозиуме по Wikis есть дополнительные материалы.

Ответ 11

У нас есть домашняя опрос. И там мы размещаем всю необходимую информацию для каждого проекта, который мы разрабатываем:

• хранилищами
• адреса для виртуальных машин
• пароли
• документация по проекту
• Обзор проекта
• статус проекта

и все остальное, что мы заполняем, должно быть написано в проекте. И это самое полезное веб-приложение, в котором мы работаем (помимо Mantis). На более общих страницах мы приводим определение каждой используемой нами таксономии, общие руководящие принципы проекта, политику, кодирование и методы разработки, которые мы используем. Он есть, он прост и эффективен, и я думаю, что каждая команда должна иметь один из них.