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

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

Например:
Уровень; Требования; Описание
Уровень 0; Код является законным для использования; Является ли код законным для использования в коммерческой индустрии/в нескольких контрактах/и т.д.

1-й уровень; Базовая кодовая линия и соответствует требованиям уровня 0; Прототипированный код, сторонние инструменты и т.д.
Уровень 2; Имеет функциональный интерфейс и комментарии и отвечает требованиям уровня 1; Достаточная документация для каждого класса и функции; Возможность определения функциональности из комментариев
Уровень 3; Придерживается стандартов кодирования и соответствует требованиям уровня 2; Выполняет определенные стандарты кодирования и проходит проверку утилиты проверки кода
Уровень 4; Включает тестовые примеры и отвечает требованиям уровня 3; Имеет достаточные тестовые примеры для проверки всех функциональных возможностей кода
Уровень 5; Утверждается комитетом по повторному использованию и отвечает требованиям уровня 4; Пересмотрены экспертами по повторному использованию и сверстниками и подтвердили, что они соответствуют всем уровням зрелости

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

Или, если это должно быть подмножество требований для соответствия следующему уровню?

Например, мы удовлетворим x из требований y, мы можем перейти на следующий уровень (требования будут такими же, как указано выше).

Уровень 0, соответствует 0 из 6 требований
Уровень 1, соответствует 1 из 6 требований
...

Проблема, которую я вижу с подмножеством, заключается в том, что некоторые требования должны обладать более сильным весовым коэффициентом, и в этом подходе, который не будет учитываться (если я не начну получать конкретные значения, встречается из b и x из y, и т.д). Но тогда это может начать усложняться.

Кто-нибудь сделал это раньше, и если да, то как вы настроили свою библиотеку? У вас есть уровень зрелости вообще или какая-то другая структура? Любой вход был бы оценен.

ОТВЕТЫ

Ответ 1

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

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

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

По линиям связи не вредно представлять время от времени только то, что есть. Еще раз! коммуникации.

Итак, как минимум ваша сборка каждой библиотеки должна:

  • опубликовать библиотеку (возможно, уведомлять подписчиков)
  • опубликовать документацию
  • выполнить тесты модулей
  • опубликовать уровень зрелости

Что касается уровней зрелости, я бы определил их с "именем уровня" и описанием того, что означает уровень. Опубликуйте критерии для того, что означает перемещение вверх или вниз по уровню. На самом деле, теперь, когда я думаю об этом, возможно, вам нужен набор ортогональных критериев: уровень для кода, уровень для документации, политики использования (т.е. Должен иметь лицензию для XYZ) и другие атрибуты. Я рекомендую вам приблизиться к этому с небольшими приращениями. В конце концов, предоставление функциональности конечным пользователям важно.

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

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

Ответ 2

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

Один из подходов, который я видел, работает отлично в крупной компании:

  • Все сторонние библиотеки привязаны к специальному каталогу и всегда включают номер версии.
  • Наши собственные общие библиотеки делятся на основе ссылок, которые они имеют на другие вещи. Например. если код утилиты ссылается на библиотеку Infragistics, тогда этот бит кода утилиты переходит в библиотеку InfragisticsUtils.
  • Наши собственные библиотеки, которые образуют четко идентифицируемые "единицы", входят в отдельные библиотеки. Например, библиотека кода, которая занимается ценными ценными бумагами, представляет собой отдельный проект.
  • Весь код многократного использования, который не удовлетворяет ни одному из вышеперечисленных, входит в проект Utilities для всех.
  • Наши собственные библиотеки скомпилированы и выпущены в общую папку, где проекты могут ссылаться на них. Команда разработчиков проектов может решить, хотят ли они ссылаться на скомпилированный двоичный файл или просто включить проект утилиты в свое решение.

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

Ответ 3

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

Теперь важно структурирование инструмента CM. Он предназначен для передачи качества кода, поэтому вы знаете, что вы получаете, когда используете его. Например, если вы пишете простой класс с едва заметными комментариями и на самом деле не поддерживаете стандарты кодирования (возможно, прототип), то он будет введен в \sw_repository\level0\ExamplePrototype.

Возможно, кто-то затем берет этот фрагмент кода и добавляет комментарии и подводит его к стандартам. Затем этот человек поместил бы его в \sw_repository\level1\ExamplePrototype.

Затем тот же самый человек спустя некоторое время создает модульные тесты для ExamplePrototype. Затем он перейдет на уровень 2 и т.д.

Определение уровней должно задуматься. Они действительно должны быть несколько последовательными, и даже если, например, вы написали модульные тесты для кода прототипа, но он не удовлетворял комментариям и стандарту кодирования, то он все равно помещается в level0. Однако было бы легко перейти на уровень2, если бы эти комментарии и стандарты были удовлетворены.

Ответ 4

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

Вот моя библиотека в С++
http://code.google.com/p/kgui/

Ответ 5

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

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

Удачи!

Ответ 6

В Kit упоминается самая важная проблема: повторное использование. остальная идея хороша, но это не более чем деталь.

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

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

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

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

только мои 2 цента...;)

Ответ 7

Посмотрите на Will Tracz "Исповедь продавца, использующего программу", и материал повторного использования HP Рабби Мартином Грисом.

Ответ 8

Я думаю, что вы слишком много думаете о проблемах.

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

Ответ 9

Он считал хорошим подходом иметь одну собственную библиотеку, но тысячи строк - это руины!