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

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

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

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

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

Вдоль линий связине больно время от времени представлять то, что есть.Снова!коммуникация.

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

Удачи!

Answer 6

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

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

Answer 7

Посмотрите на «Признания продавца подержанных программ» Уилла Тракса и прочее повторное использование HP раввина Мартина Грисса.

Answer 8

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

Answer 9

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

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