Поддержка Wiki программиста [закрыто]

Question

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

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

-- редактировать --

• Кроме того, есть ли хороший способ систематизировать информацию?(например, по слою (data, ui), по проекту или другому)

Answer 1

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

Другие вещи, которые я обычно выкладываю, это

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

Answer 2

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

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

По прошествии времени.Этот инструмент считался все более ценным.В итоге мы создали новые вики для разных продуктов, над которыми работала компания.

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

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

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

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

Answer 8

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

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

Answer 9

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

Принятие Wiki – сложная задача

Иметь чемпиона

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

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

Включите Wiki в процессы компании

Евангелизировать

Не сдавайся

Подумайте о том, чтобы не использовать Wiki для разговоров

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

Имейте план перехода

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

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

Answer 10

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

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

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

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

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

Answer 11

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

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

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