Как вы отслеживаете, какие классы и функции написала ваша команда?


43

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

Есть ли особая практика документирования подобных вещей? Как вы делаете их легко найти?

Если у вашей команды нет такой документации, как вы узнаете, существует ли ваше колесо?

РЕДАКТИРОВАТЬ:

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

Самый популярный ответ (Калеб) до сих пор - единственный, который мог бы использовать программист, который неспособен к документации и встречам, и делает только одно: программирование. Программирование - это то, что делает программист, и да, великий программист может писать документацию, модульные тесты и т. Д., Но давайте посмотрим правде в глаза - большинство из нас предпочитает программирование документированию. Его решение заключается в том, что программист распознает повторно используемый код и извлекает его в свой собственный класс или репозиторий или что-то еще, и благодаря тому, что он изолирован, он становится доступным для поиска и облегчает кривую обучения его использованию ... и это было достигнуто путем программирования.

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

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

Есть ли еще какие-либо идеи в этом духе ... для изолированных и ограниченных по времени разработчиков?


5
Я бы расширил вопрос, чтобы задать его в более широком масштабе, возможно, в компании из 100+ сотрудников, как вы делаете то же самое. Какие лучшие практики можно использовать, чтобы избежать дублирования ранее проделанной работы?
Асаф

1
@Asaf - Я подозреваю, что правильный ответ будет зависеть от численности населения - то, что работает для магазина на 5 человек, не будет работать для 50, а то, что работает для 50, не будет работать для 500. Ответы на все будут приветствоваться.
Дэн Пичельман

3
Это большой вопрос!
Роклан

4
Закон Конвея : «Организации, которые разрабатывают системы ... вынуждены производить проекты, которые являются копиями коммуникационных структур этих организаций».
Марк Рушаков

2
@nathanhayfield: это решение, которое может работать для 1 разработчика и в некоторой степени для 2, но не для 20 или 100. И даже когда я работаю один, я предпочитаю разделять вспомогательные функции тематически.
Док Браун

Ответы:


29

Библиотеки. Каркасы. Контроль версий.

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

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


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

2
Я думал, что технический термин был BBOM .
zzzzBov

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

3
@Caleb: сохраняйте спокойствие, полностью прочитайте мою публикацию. Моя точка зрения такова: копирование кода из другого места, настройка его и интеграция в библиотеку команд не обязательно приведет вас на «путь к гибели». Когда у вас есть две библиотеки с перекрывающимися функциями и две команды, каждая из которых отвечает за поддержку своей библиотеки, ситуация не так уж и плоха. Это не идеально, так как одна команда может выполнять какую-то работу, а другая - тоже, но иногда преимущество того, что эти команды продолжают оставаться независимыми, перевешивает двойную работу.
Док Браун

1
@DocBrown Там являются ситуации , в которых возникает необходимость скопировать код, но это должно быть сознательным решением , а не то , что вы вынуждены делать из - за того , каким образом код был общим в первую очередь.
Калеб

13

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

Самое сложное - заставить каждого в вашей команде постоянно поддерживать эту вики. Но любая другая документация страдает той же проблемой.

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


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

@Caleb общение является трудной частью
JK.

@jk - Проблемы общения усугубляются, если у вас нет источника контроля, упомянутого в C
JeffO

3
@Caleb: вопрос ОП был не в том, чтобы распространять код, а в том, чтобы сообщить и найти его позже.
Док Браун

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

7

Находясь в компании с 700 сотрудниками, в командах от 2 до 20 человек, вот мой опыт.

На командном уровне

У нас есть «встречи в режиме ожидания» каждый день по 15-20 минут. Мы можем быстро поделиться общими знаниями, такими как «Я сделал эту функцию вчера, она так крута».

У нас также есть вики на проект. Это означает, что мы можем делиться (технической) информацией о том, что сделано в проекте, включая встроенные пользовательские классы / функции.

На уровне агентства

На уровне агентства у нас есть 4 инструмента:

  • Еще одна вики. Он в основном предназначен для предоставления нам информации об оборудовании и прочем, но мы иногда используем его для обмена технической информацией, подлежащей проверке, прежде чем размещать ее на уровне компании.
  • Еженедельные встречи. Они в основном должны знать прогресс каждой команды / проекта, но, поскольку мы в основном технические энтузиасты, мы можем создавать интересные вещи.
  • Список рассылки. У нас есть рассылка со всеми в агентстве. Множество интересных вещей / забавных вещей / полезных вещей проходит через это.
  • Хранилище VCS. У каждого агентства есть свой личный репозиторий, где у нас есть небольшие проекты, в основном модули, которые мы используем в разных проектах.

На уровне компании

На уровне компании это более организовано.

Вики "уровня агентства" на самом деле является частью вики компании.

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

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

И VCS, конечно, лучшая система совместного использования кода.

Вывод

Подводя итог, нет четкого решения. Обмен знаниями всегда был большой проблемой и, вероятно, останется. Есть много решений для создания баз знаний , и, возможно, можно было бы удовлетворить ваш счет. Тем не менее, некоторые люди пытаются получить еще лучше KB, поскольку современные решения не всегда очень умны.


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

6

Ну, все сводится к общению.

Вики великолепны, и вам обязательно нужно установить и использовать их. Хорошая внутренняя сеть программистов хороша, если люди ее читают и обновляют, так что вы на самом деле говорите о проблеме людей. Вы могли бы предложить еженедельные встречи «Обновление команды», где все собираются вместе и дают обзор того, что происходит. Технические лидеры (по крайней мере!) Должны собираться вместе и болтать о том, что делает каждая команда. Неформальные сеансы «коричневой сумки» великолепны, запланируйте их на обед и заставьте людей говорить.

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

Если ничего подобного не делается, обсудите это с вашим боссом, объясните, как это пойдет на пользу компании, и предложите дальнейшие шаги :)


1
Я хотел бы продвинуть «общую» концепцию чуть выше в вашем ответе.
JeffO

4

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


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

2

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


0

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

TL; DR: проверка кода для каждой регистрации.


2
Не понимаю. Собираетесь ли вы выбросить проверенный и работающий код только потому, что он выглядит как дубликат в обзоре кода? Вопрос заключался в том, как избежать написания дублирующего кода. Сеанс как ответ @ daenyth кажется лучше.
Адриан

Если рецензент сказал мне, что я добавляю код, который дублирует функциональность, и я посмотрел и обнаружил, что они правы, черт возьми, да, я бы отказался от этого кода. (Возможно, я бы также проверил, лучше ли моя реализация, и если да, посмотрим, смогу ли я реорганизовать другую реализацию вместо добавления новой.)
Кэролин
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.