Как продвигать повторное использование кода и документацию? [закрыто]

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

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

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

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

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

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

Я также согласен с комментариями Euphoric по этому вопросу. Часто невозможно что-либо повторно использовать между различными проектами (обычно все операции CRUD выглядят одинаково, но обычно вы не можете их повторно использовать).

Помимо уже упомянутых факторов «документация», «легко найти и ориентироваться», «дисциплина» и «просмотр кода»

повторно используемый код должен быть

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

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

Я думаю, что лучший способ заставить их повторно использовать код - это мотивация. Если вы добавляете повторно используемые компоненты в дополнительные проекты, как предлагал Euphoric, приложите немало усилий. Там, где я работаю, мы создали проект, который запускает набор предопределенных интерфейсов в настраиваемых планах выполнения и предоставляет несколько сервисов (например, различные классы для DB_interaction, FTP-Service, ...). Проект имеет большой успех, потому что наши разработчики действительно хотят использовать микро-фреймворк, потому что он экономит им много времени на написание шаблонного кода для подобных проектов. То же самое относится и к Utility-библиотекам для Lists, Strings и т. Д., Но в этом случае вы захотите использовать существующий один раз. (зачем изобретать велосипед?)

Заключение. Позвольте вашим разработчикам испытать преимущества хорошо протестированных повторно используемых компонентов. Но я также согласен с ответом Анджея Бобака: многие вещи нельзя использовать повторно, потому что они похожи, но не одинаковы.

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

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

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

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

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

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

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

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

Парное программирование также значительно ускоряет распространение знаний.

Я думаю, что это на самом деле два вопроса в одном - я постараюсь ответить на оба.

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

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

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

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

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

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

ИММО ключ это не документация или инструменты, ключ это СВЯЗЬ. 10+ разработчиков это не много людей, некоторые вещи, которые улучшают это общение:

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

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

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

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

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

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

Вам нужен инструмент, который поможет вашим разработчикам сделать это без проблем. Если ваши разработчики узнают, сколько времени они могут сэкономить, повторно используя фрагменты кода (не только с точки зрения написания кода, но, очевидно, для обеспечения качества, интеграции и т. Д.), С помощью эффективного инструмента, который прост в использовании и Будучи непосредственно интегрированными в среду разработки, они МОГУТ МОЛИТЬСЯ принять такой инструмент!

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

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

Есть несколько инструментов для управления фрагментами, я рекомендую этот: http://www.snip2code.com .

(Отказ от ответственности: я один из основателей Snip2Code, и я - вместе с моими соучредителями - некоторое время назад придерживался того же мнения: именно поэтому мы решили начать этот проект, который собирает все функции, которые я как указано выше, т.е. совместное использование фрагментов команды, интеграция в IDE, такие как Visual Studio, Eclipse, IntelliJ, Notepad ++ и т. д.)