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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Что касается коммуникации, не помешает время от времени представлять только то, что есть.Снова!коммуникация.

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Удачи!

Answer 6

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

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

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

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

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

просто мои 2 цента...;)

Answer 7

Посмотрите «Исповедь продавца использованных программ» Уилла Трэча и материал Мартина Грисса, раввина HP по повторному использованию.

Answer 8

Мне кажется, ты слишком много думаешь о непроблеме.

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

Answer 9

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