2009-11-20 2 views
1

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

  • командной строки парсеры
  • File Utilities
  • Framework Помощники
  • и т.д. ...

Некоторые из них хорошо продуманны, а некоторые дублирующие функции найдены в Apache commons-lang, commons-io и т. Д.

Какие у вас есть в вашей общей библиотеке, и что еще более важно, как вы структурируете общие библиотеки, чтобы их было легко улучшить и включить в другие проекты?

ответ

3

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

Отдельные библиотеки (проекты/сборки, если вы в .Net) необходимы для разных уровней приложений (например, очевидно, что нет смысла вводить код пользовательского интерфейса и доступа к данным).

Держите все как можно проще; то, что вы не помещаете в общую библиотеку, часто не менее важно, чем то, что вы делаете. Пользователи библиотеки не захотят думать, поэтому использование должно быть очень простым.

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

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

Настроить своеобразное простое и ясное управление библиотеками - кто-то, кто может «владеть» конкретной библиотекой и обеспечивать ее избыточное качество (например, старшего разработчика или руководителя команды).

+0

И SRP хорош для общих проектов - http://en.wikipedia.org/wiki/Single_responsibility_principle – Jon

1

Я до сих пор написал большинство общих библиотек, которые мы используем в нашем офисе.

  • У нас есть определенные классы кнопок, которые только немного более полезным для нас, чем стандартные кнопки
  • Класс управления базами данных, которая делает некоторые внутренние кэширования и может подключаться к ODBC, OLEDB, SQL и доступа к базам данных, даже флип параметра
  • Некоторые элементы управления сеткой и списками, которые многопоточны, поэтому мы можем добавлять к ним большие объемы данных без замедления программы и без необходимости писать весь код многопоточности каждый раз, когда возникает проблема производительности со списком box/combo box.

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

Что касается организации, все библиотеки DLL хранятся вместе с исходным кодом на общем диске разработки в офисе, к которому у всех нас есть доступ. (Мы довольно маленький магазин)

1

Мы разложили наши библиотеки по функциям.

Commmon.Ui.dll имеет базовые классы для элементов ui. Common.Data.Dll - это своего рода оболочка вокруг корпоративных классов доступа к данным. Common.Business - это свалка для других общих классов, которые не вписываются в один из них.

Мы создаем другие специализированные DLL по мере необходимости.

Смежные вопросы