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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

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

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

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

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

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