Как создать и поддерживать библиотеку повторного использования кода?
Я пытаюсь настроить репозиторий кода. Я думал о том, чтобы каждый многоразовый модуль кода имел определенный рейтинг "уровень зрелости". Рейтинг будет определяться как уровень, на котором многоразовый код находится в пределах определенного набора требований. Самый высокий уровень зрелости будет наивысшей степенью стандарта по предопределенному набору требований.
например:
Уровень; Требования; Описание
Уровень 0; код законно использовать; код законно использовать в коммерческой промышленности / по нескольким контрактам / и т. д.?
Уровень 1; базовая кодовая линия и соответствует требованиям уровня 0; Прототипированный код, сторонние инструменты и т. д.
Уровень 2; имеет интерфейс функции и комментарии и отвечает требованиям уровня 1; достаточная документация для каждого класса и функции; возможность определить функциональность из комментариев
Уровень 3; придерживается стандартов кодирования и соответствует требованиям уровня 2; следует определенным стандартам кодирования и проходит проверку кода утилиты тест
Уровень 4; включает тестовые случаи и соответствует требованиям уровня 3; имеет достаточное количество тестовых случаев для проверки всей функциональности кода
Уровень 5; одобрен Комитетом по повторному использованию и отвечает требованиям уровня 4; рассмотрен экспертами по повторному использованию и коллегами и проверен он соответствует всем уровням зрелости
Мне интересно, должен ли этот уровень зрелости быть иерархической структурой, где для перехода на следующий уровень вам нужно соответствовать требованиям всех предыдущих уровней (как у меня показано выше)?
или если это должно быть подмножество требований для удовлетворения следующего уровня?
например, у нас есть соответствие X из y требований, мы можем перейти на следующий уровень (требования будут такими же, как указано выше).
Уровень 0, соответствует 0 из 6 требований
Уровень 1, соответствует 1 из 6 требований
...
проблему я вижу с подходом подмножество некоторые требования должны быть сильнее утяжеления, и в этом подход, который не будет принят во внимание (если я не начну получать конкретные, как, встречает a из b и x из y и т. д.). Но потом все может усложниться.
кто-нибудь делал это раньше, и если да, то как вы настроили свою библиотеку? У вас есть уровень зрелости или какая-то другая структура? Любой вклад был бы весьма признателен.
9 ответов
настройка репозитория повторного использования кода-сложная задача. Основная трудность не в том, как вы его настроили, а в Как вы сообщаете о существовании различных библиотек в репозитории. Повторное использование библиотек только хорошо, если они используются, и они используются только, если они известны, и они только широко использоваться, если качество кода высокое и, если оно соответствует потребностям пользователей.
Мне нравится идея уровней зрелости, но как уже писали, есть вероятно, довольно много работы по настройке/сборке. Я думал о подобном подходе к сборкам приложения - я назвал их доверительными уровнями. В области построения приложений построение с низким уровнем доверия-это такое построение, которое не прошло модульные тесты; среднее доверие может включать в себя прохождение модульных тестов, но не интеграционных тестов и т. д. Это был хороший механизм для общения с QA и пользователями, чего ожидать. Аналогичный механизм может быть уместен и для библиотек.
документация комментарии являются обязательными, а также должны быть так же осторожны, как и в коде. Комментарии должны сообщить, что, почему, где, когда, как, что и т. д. Процесс сборки должен публиковать документацию в известном месте (опять же, связь является ключевой).
вдоль линий связи, не повредит время от времени представлять только то, что есть. Опять! связь.
Итак, как минимум, ваша сборка каждой библиотеки следует:
- опубликовать библиотеку (возможно, уведомить подписчиков)
- публикации документация
- запуск unit-тестов
- публикации уровень зрелости
Что касается уровней зрелости, я бы определил их с "именем уровня" и описанием того, что означает уровень. Опубликовать критерии, что значит двигаться вверх или вниз по уровню. На самом деле, теперь, когда я думаю об этом, возможно, Вам нужен набор ортогональных критериев: уровень для кода уровень документации, политики использования (т. е. должна иметь лицензию на XYZ) и другие атрибуты. Я рекомендую вам подходить к этому с небольшими шагами. в конце концов, предоставление функциональности конечным пользователям-это то, что имеет значение.
вы также должны сообщить мышление естественно толкать многоразовые биты в репозиторий. Разработчики должны иметь стимул делать это обычно. Инструменты проверки статического кода, которые ищут дублирование и одноранговое соединение отзывы идут только до сих пор. Кто-то должен фактически выполнить работу по перемещению кода в репозиторий.
наконец, я рекомендую вам использовать как можно больше поддержки инструментов в настройке, сборке, обслуживании и связи репозитория. В противном случае, как и любой не-код артефакта, вам придется столкнуться определенное количество энтропии, которое снижает ценность как артефакт код становится устаревшим.
Я думаю, вам будет трудно гарантировать, что вся команда разработчиков будет следовать этим рекомендациям достаточно точно. Особенно когда руководящие принципы могут быть истолкованы тем или иным образом. Более того, будет очень больно, если кто-то улучшит часть кода, добавив тесты, и внезапно ему придется перейти к другому проекту. Скорее всего, такой код останется в проекте, в который он был первоначально помещен, и со временем уровни зрелости станут бессмысленный.
один подход, который я видел, отлично работает в большой компании, это:
- все сторонние библиотеки привязаны к специальному каталогу и всегда включают номер версии.
- наши собственные общие библиотеки разделены на основе ссылки у них есть другие вещи. Е. Г. если утилита код ссылки
Infragisticsбиблиотека тогда этот бит кода утилиты переходит вInfragisticsUtilsбиблиотека. - наш собственный здравый библиотеки, которые образуют четко идентифицируемые "единицы", переходят в отдельные библиотеки. Например, библиотека кода, которая занимается ценообразованием ценных бумаг, является отдельным проектом.
- весь многоразовый код, который не удовлетворяет ни одному из вышеперечисленных, переходит в catch-all .
- наши собственные библиотеки компилируются и выпускаются в общее место, где проекты могут ссылаться на них. Это до команды разработчиков проектов, чтобы решить, хотят ли они ссылаться на составленный binary или просто включите проект утилиты в свое решение.
очевидно, качество кода, который вы найдете в catch-all Utilities библиотека может существенно различаться. Чтобы облегчить это, мы просто обеспечили, чтобы два человека из разных команд разработчиков рассмотрели все проверки на Utilities. Это выпалывает много вещей, которым там нет места!
Я думаю, что большой репозиторий кода будет включать инструмент CM и инструмент Wiki. Инструмент CM должен быть структурирован с использованием идеи уровня (как вы предложили), поскольку он структурирует код по качеству. Wiki должна выступать в качестве" рекламы " того, что может сделать программное обеспечение и как оно может помочь вам. Эта Вики также может хранить информацию, например, какие проекты используют код, рейтинг его использования и примеры его использования. Если кто-то беспокоится о следующей команде разработчиков в руководящих принципах уровня следует указать, как работает самоконтроль, и привести пример того, насколько хорошо он работает с Вики.
теперь важно структурирование инструмента CM. Он предназначен для передачи качества кода, поэтому вы знаете, что вы получаете, когда используете его. Например, если вы пишете простой класс почти без комментариев, и он не соответствует стандартам кодирования (возможно, прототипу), он будет введен в \sw_repository\level0\ExamplePrototype.
возможно, кто-то затем берет этот кусок кода и добавляет комментарии и доводит его до стандартов. Затем этот человек поместил бы его в \sw_repository\level1\ExamplePrototype.
затем тот же человек, некоторое время спустя, создает модульные тесты для ExamplePrototype. Затем это перейдет на level2 и так далее.
определение уровней должно занять некоторое время. Они действительно должны быть несколько последовательными, и даже если, например, вы написали модульные тесты для прототип кода, но он не удовлетворял комментариям и стандарту кодирования, тогда он все равно помещается в level0. Однако было бы легко перейти на уровень 2, если бы эти замечания и стандарты были удовлетворены.
для моей библиотеки я просто ввел код, который я написал, который можно использовать в нескольких приложениях. Если код специфичен для конкретного приложения, он не входит в библиотеку. Как больше приложений используют его, ошибки получают разработаны, поэтому я никогда не ожидаю, что это будет ошибка бесплатно сразу. Ошибки будут постоянно найдены и исправлены, поскольку ваша библиотека созревает и подчеркивается различными приложениями. Он никогда не будет свободным от ошибок, но со временем приблизится к надежности.
Также, когда я понимаю, что API для некоторых вещей неправильный, я не беспокойся об этом и рефакторинг API и как можно скорее.
Вот моя библиотека в c++
http://code.google.com/p/kgui/
в течение многих лет Microsoft была большим сторонником того, что известно как фабрики программного обеспечения, большая часть которого посвящена решению проблем повторного использования.
какие проблемы повторного использования? Во-первых, это трудно. Очень сложно придумать библиотеку и API,которые будут служить за пределами непосредственных потребностей проекта. Как вы предсказываете будущее? Кроме того, проблема централизованного репозитория, который служит как базой знаний, так и динамичным сообщество практики очень сложно. Как вы делаете что-то, что является очень гибким, но простым в использовании? Многие пытались и потерпели неудачу. Оба!--5-->софт фабрики и линейки программных продуктов попытки решить эти проблемы.
удачи!
комплект упомянул самая важная проблема: повторное использование. в остальном идея хорошая, но это не более чем деталь.
Я имею в виду, у меня самого есть проблемы с поддержанием моей собственной библиотеки повторного использования. иногда я делаю реализацию, которая очень специфична для проекта, или я делаю N-й прототип для какой-то идеи, и ни один из них никогда не попадает в мою библиотеку.
Если вам действительно удастся иметь библиотеку повторного использования кода, которая используется и поддерживается многими разработчиками, дисциплинированнее, чем победа. вам нужна система контроля версий и трекер ошибок, который используется как владельцами проектов, так и пользователями. вам нужны общение и средства для вклада. наличие нескольких разработчиков, использующих проект, значительно улучшает его качество. реализация становится лучше. создается документация. API и дизайн находятся на гораздо более высоком уровне. комитет-хорошая вещь, но он не может решить, насколько хорош данный код, не используя его на самом деле. он может решить соответствует ли код определенным стандартам, но соответствия стандартам недостаточно для хороших библиотек.
вам нужно сделать все возможное, чтобы убедиться, что у вас нет тонны фрагментов кода, плавающих вокруг, все из которых могут более или менее что-то сделать. хорошо, любое дизайнерское решение имеет плюсы и минусы, но я думаю, что имеет смысл начать с одного проекта для данной задачи и при необходимости его ветвить, но сохранить живую связь между проектными командами и рассмотреть (частично) слияние спина.
Не беспокойтесь слишком много о классификации качества различных проектов. если проект плох, то пользователи / разработчики подтолкнут его к лучшему уровню. большинство людей достаточно умны, чтобы видеть, когда библиотека хороша, а когда нет. вам действительно нужно вкладывать свою энергию в эти симбиотические эффекты, а не пытаться обременять участников строгими правилами.
просто мои 2 цента ... ;)
посмотрите на "исповеди продавца подержанных программ" Уилла Трача и материал раввина повторного использования HP Мартина Грисса.
Я думаю, что вы слишком много думаете о не проблеме.
как вы настроили мою библиотеку? легко, если вы используете тот же (или почти тот же) метод в двух или более проектах, переместите его в библиотеку.