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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

Если действительно соблюдать стандарты кодирования (возможно, прототип), то он будет помещен в \ sw_repository \ level0 \ ExamplePrototype.

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

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

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

Если действительно соблюдать стандарты кодирования (возможно, прототип), то он будет помещен в \ sw_repository \ level0 \ ExamplePrototype.

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

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

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

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

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

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

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

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

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

Затем он перейдет на уровень 2 и т. Д.

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

Затем он перейдет на уровень 2 и т. Д.

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