Работая над кодом, я сталкиваюсь со многими из тех же проблем, что и мои товарищи по команде, и я написал несколько полезных функций и классов, и они тоже. Если будет хорошее общение, я услышу о какой-то замечательной вещи, которую кто-то собрал, и через шесть месяцев, когда мне это понадобится, я могу вспомнить это и вызвать эту функцию, сэкономив себе время. Если я этого не помню или никогда не знал об этом, я, вероятно, заново изобрету колесо.
Есть ли особая практика документирования подобных вещей? Как вы делаете их легко найти?
Если у вашей команды нет такой документации, как вы узнаете, существует ли ваше колесо?
РЕДАКТИРОВАТЬ:
Все ответы, кроме одного, до сих пор касаются идеальной ситуации, поэтому позвольте мне обобщить эти решения: документация и связь; вики, регулярные встречи и т. д. Все это замечательные вещи, но они полагаются на то, что у программистов есть время (и навыки), чтобы написать документацию и посетить собрания, делать записи и помнить все.
Самый популярный ответ (Калеб) до сих пор - единственный, который мог бы использовать программист, который неспособен к документации и встречам, и делает только одно: программирование. Программирование - это то, что делает программист, и да, великий программист может писать документацию, модульные тесты и т. Д., Но давайте посмотрим правде в глаза - большинство из нас предпочитает программирование документированию. Его решение заключается в том, что программист распознает повторно используемый код и извлекает его в свой собственный класс или репозиторий или что-то еще, и благодаря тому, что он изолирован, он становится доступным для поиска и облегчает кривую обучения его использованию ... и это было достигнуто путем программирования.
В некотором смысле я вижу это так: я только что написал три функции, и мне приходит в голову, что о них должен знать кто-то другой. Я мог бы задокументировать их, записать их, объявить их на собрании и т. Д. - что я могу сделать, но это не моя сила - или ... Я могу выделить их в класс, назвать его хорошо, заставить их функционировать как черный ящик и вставьте его туда, куда идут другие файлы классов. Тогда короткое электронное письмо, объявляющее, что это легко. Другие разработчики могут сканировать код и понимать его лучше, чем отдельные функции, используемые в коде, который они не полностью понимают - этот контекст удаляется.
Мне это нравится, потому что это означает, что наличие набора файлов с именами классов с хорошо названными методами является хорошим решением, которое достигается хорошим программированием. Это не требует встреч, и это смягчает необходимость в подробной документации.
Есть ли еще какие-либо идеи в этом духе ... для изолированных и ограниченных по времени разработчиков?
источник
Ответы:
Библиотеки. Каркасы. Контроль версий.
Если у вас есть код многократного использования, самое последнее, что вам нужно, это чтобы разные члены команды скопировали исходный код в свой проект. Если они это сделают, есть вероятность, что они немного изменятся здесь и немного доработаются, и вскоре у вас появятся десятки функций или методов, которые имеют одинаковое имя, но каждый из которых работает немного по-своему. Или, возможно, более вероятно, оригинальный автор продолжит дорабатывать код, исправлять ошибки, повышать его эффективность или добавлять функции, но скопированный код никогда не будет обновляться. Техническое название для этого - огромный беспорядок .
Правильное решение состоит в том, чтобы извлечь эти повторно используемые ресурсы из любого проекта, для которого вы их изначально создали, и поместить их в библиотеку или инфраструктуру в своем собственном репозитории контроля версий. Это облегчает поиск, но также препятствует внесению изменений без учета всех других проектов, которые могут его использовать. Вы могли бы рассмотреть возможность использования нескольких разных библиотек: одна для хорошо протестированного кода, который, скорее всего, не изменится, другая для материала, который кажется стабильным, но который не был тщательно протестирован и проверен, другая для предлагаемых дополнений.
источник
Одним из подходов для этого является создание Wiki для этой цели и написание нескольких высокоуровневых документов о том, какие компоненты можно использовать повторно, как вы решили проблему и т. Д.
Самое сложное - заставить каждого в вашей команде постоянно поддерживать эту вики. Но любая другая документация страдает той же проблемой.
Часть вашего кода также может быть достаточно хорошей, чтобы поместить ее в библиотеку многократного использования. Это также облегчает поиск кода позже.
источник
Находясь в компании с 700 сотрудниками, в командах от 2 до 20 человек, вот мой опыт.
На командном уровне
У нас есть «встречи в режиме ожидания» каждый день по 15-20 минут. Мы можем быстро поделиться общими знаниями, такими как «Я сделал эту функцию вчера, она так крута».
У нас также есть вики на проект. Это означает, что мы можем делиться (технической) информацией о том, что сделано в проекте, включая встроенные пользовательские классы / функции.
На уровне агентства
На уровне агентства у нас есть 4 инструмента:
На уровне компании
На уровне компании это более организовано.
Вики "уровня агентства" на самом деле является частью вики компании.
И затем вики делится на основе технологий. Таким образом, любой может улучшить его, поискать в нем и дать жизнь вики.
Есть также доступные списки рассылки, на которые мы можем подписаться. Каждый в агентстве может подписаться, и большинство людей используют по крайней мере одну или две технологии, на самом деле большинство людей используют 5-10 из них.
И VCS, конечно, лучшая система совместного использования кода.
Вывод
Подводя итог, нет четкого решения. Обмен знаниями всегда был большой проблемой и, вероятно, останется. Есть много решений для создания баз знаний , и, возможно, можно было бы удовлетворить ваш счет. Тем не менее, некоторые люди пытаются получить еще лучше KB, поскольку современные решения не всегда очень умны.
источник
Ну, все сводится к общению.
Вики великолепны, и вам обязательно нужно установить и использовать их. Хорошая внутренняя сеть программистов хороша, если люди ее читают и обновляют, так что вы на самом деле говорите о проблеме людей. Вы могли бы предложить еженедельные встречи «Обновление команды», где все собираются вместе и дают обзор того, что происходит. Технические лидеры (по крайней мере!) Должны собираться вместе и болтать о том, что делает каждая команда. Неформальные сеансы «коричневой сумки» великолепны, запланируйте их на обед и заставьте людей говорить.
Вам также нужен способ делиться кодом, упаковывать его, создавать версии и распространять его. Все было бы проще, если бы у вас был действительно хорошо управляемый репозиторий исходного кода, хорошо организованный в «общие» и проектные папки.
Если ничего подобного не делается, обсудите это с вашим боссом, объясните, как это пойдет на пользу компании, и предложите дальнейшие шаги :)
источник
Сессии проверки кода могут помочь. Если ваша команда регулярно встречается, чтобы обсудить то, что было разработано, то человек, который придумал решение, может показать остальным, как его использовать. Если кто-то поднимает вопрос, на котором он придерживается, другие члены команды могут предложить подход, который увеличивает повторное использование существующих компонентов.
источник
Лучший способ справиться с чем-то подобным - это иметь структуру репозитория, которая имеет несколько простых соглашений, так что я, как программист, знаю, если есть функция
doXYZ, где примерно я должен искать эту функцию. Независимо от того, используете ли вы пространства имен, каталоги, модули, плагины, пакеты и т. Д., Ваш код должен быть модульным, чтобы функции, выполняющие одно и то же или обращающиеся к одним и тем же источникам данных, находились в основном в одном месте.источник
В идеале должен быть хотя бы один человек, кроме автора, который проверяет код при каждой регистрации. Процесс проверки кода может помочь решить проблему проверки множества дублирующих методов. Конечно, вы ограничены знаниями рецензентов.
TL; DR: проверка кода для каждой регистрации.
источник