Какой стандартный код фреймворка мы должны построить?

Мы находимся в ситуации, когда у нас есть 4 разработчика с небольшим количеством свободного времени (речь о 3-4 неделях).

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

  1. Кэширование
  2. логирование

Хотя эти 2 выше будут полагаться на такие библиотеки, как Enterprise Library, каждый новый проект будет писать свои собственные оболочки вокруг него и т. д., поэтому мы консолидируем весь этот код.

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

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

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

Ваше здоровье


c# standard-library
person Ash M    schedule 05.07.2010    source источник

Ответы (6)


arrow_upward
3
arrow_downward

Некоторые из основных вещей, которые мы делаем:

  • Ведение журнала (с некоторыми обертками вокруг TraceSource)
  • Оболочки сериализации (чтобы вы могли сериализовать/десериализовать в одной строке кода)
  • Сжатие (обертки для функциональности .NET, чтобы вы могли сделать это в одной строке кода)
  • Шифрование (то же самое, обертки для функциональности .NET Framework, чтобы разработчику не приходилось постоянно работать с byte[])
  • Контекст — класс, который просматривает трассировку стека, чтобы вернуть структуру данных, содержащую всю информацию о текущем вызове (сборка, класс, член, тип члена, имя файла, номер строки и т. д.).
  • и тд и тп...

надеюсь, это поможет

person Robert Seder    schedule 06.07.2010

arrow_upward
6
arrow_downward

  • Инфраструктура модульного тестирования — можете ли вы легко запустить все свои модульные тесты? у вас есть модульные тесты?
  • Процесс сборки — можете ли вы создать/развернуть приложение с нуля, используя только 1 или 2 команды?
person Peter Recore    schedule 05.07.2010
comment
очень нравится эта идея. это заставит 1 разработчика быть занятым :) еще нужно поработать для остальных 3 :) - person Ash M; 06.07.2010
comment
Модульное тестирование: вы получаете готовую инфраструктуру с чем-то вроде NUnit, особенно если вы используете ReSharper или аналогичный, который имеет хорошую интеграцию с VS для тестов. Однако настройка непрерывной интеграции — хорошая идея, если у вас есть виртуальная машина для ее размещения. - person Rup; 06.07.2010

arrow_upward
3
arrow_downward

ладно, главное, не изобретайте велосипед!

Потратьте некоторое время на изучение библиотек, которые вы можете легко использовать:

  • Для ведения журнала я настоятельно рекомендую Log4Net.
  • Для тестирования nUnit
  • За насмешку, Rhino.

Также взгляните на Inversion of Control Containers, я рекомендую Castle Windsor.

  • Для индексации я рекомендую Solr (поверх Lucene).

Затем напишите несколько оберток:

Это должна быть точка входа вашего API (общая библиотека, но думайте об этом как об API).

Сосредоточьтесь на абстрагировании всех библиотек, которые вы используете внутри своего API, поэтому, если вы больше не хотите использовать Log4Net или Castle Windsor, вы можете это сделать, написав хорошо структурированные абстракции и сосредоточившись на слабо связанных шаблонах проектирования.

Принять разработку, управляемую доменом:

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

Предложения:

Я бы начал с очень гибкой общей библиотеки DAL, которая упрощает доступ к любым типам данных и нескольким носителям.

Я бы использовал Fluent nHibernate для реляционной базы данных, и у меня были бы все вызовы методов в вашей реализации доступа к данным LINQ, поскольку это функция языка С#.

использование LINQ для запросов к БД, индексам, файлам, xml и т. д.

person andy    schedule 06.07.2010
comment
круто, спасибо, я проверю их. Любая причина, по которой вы предпочитаете их? - person andy; 07.07.2010

arrow_upward
1
arrow_downward

Вот одна вещь, которая может занять всех разработчиков на месяц:

  1. Запускайте модульные тесты своих приложений в профилировщике с покрытием кода (nUnit или VS Code Coverage).
  2. Выясните, какие области нуждаются в дополнительных тестах.
  3. Напишите модульные тесты для этих подсистем.

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

person Igor Zevaka    schedule 06.07.2010
comment
очень похоже на тесты покрытия кода. думая, что мы также можем включить некоторые тесты производительности для нашей кодовой базы и решать любые проблемные области по мере их возникновения. благодарю вас. - person Ash M; 06.07.2010

arrow_upward
0
arrow_downward

Я считаю, что почти никогда не следует писать стандартные библиотеки. Вместо этого следует реорганизовать существующий работающий код, чтобы удалить дублирование и упростить использование и тестирование.

Результат будет очень похож на «стандартную библиотеку», за исключением того, что вы будете знать, что она работает (вы перезапускали свои модульные тесты после каждого изменения, верно?), и вы будете знать, что она будет использоваться, поскольку она уже была быть использованным. В противном случае вы рискуете создать замечательную стандартную библиотеку, которая не используется и не работает, когда она используется.

person John Saunders    schedule 06.07.2010
comment
не уверен, что согласен с вами. Раньше, когда мы работали в консалтинговой/программной компании, всякий раз, когда мы приступали к новому проекту, мы добавляли стандартные библиотеки и несколько конфигураций, и ведение журнала, обработка исключений и отчеты об исключениях работали сразу. Это то, что даст вам преимущество, когда дело доходит до сжатых сроков. - person Ash M; 06.07.2010
comment
Я не согласен, вот. Существует масса возможностей для написания кода фреймворка (по сравнению с кодом приложения). Если все сделано правильно, многие проекты увидят выгоду! - person Robert Seder; 06.07.2010
comment
Я полностью согласен, Джон. Написание кода, который не используется, — пустая трата времени. Написание кода, для которого у вас нет четких вариантов использования, обречено на провал. И любой, кто утверждает, что может предсказывать будущее, должен прислать мне несколько выигрышных номеров лото. Я хочу добавить, что создание кода, который можно легко построить и протестировать, требует много времени и подпадает под рефакторинг существующего кода. - person Philip Rieck; 06.07.2010
comment
Выполняйте рефакторинг после каждого проекта, чтобы создать свою стандартную библиотеку. Затем включите его в каждый проект. Таким образом, вы получите свою библиотеку и будете знать, что она полезна и работает. - person John Saunders; 06.07.2010
comment
Проблема в том, что если вы занимаетесь разработкой программного обеспечения, то обычно весь код, который вы только что написали, принадлежит вашему клиенту. Вы не можете использовать его повторно, если только вы не списали его с контракта в такой период простоя, как этот. По крайней мере, вы можете извлечь уроки из последней версии проекта. - person Rup; 06.07.2010

arrow_upward
0
arrow_downward

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

  • Перенесено с .net на WCF.
  • Поиск болевых точек в коде, с которыми все разработчики просто ненавидят работать, и их рефакторинг.
  • Внедрите хорошую автоматизированную систему сборки, которая будет запускать модульные тесты и рассылать электронные письма о неудачных сборках. Он также будет упаковывать и размещать эту версию в общем каталоге, чтобы QA мог ее подобрать.
  • Написал сценарий БД, чтобы вы могли легко обновить базу данных, вместо того, чтобы быть вынужденным брать устаревшую копию, загрязненную неактуальными данными, с которыми играли другие разработчики.
  • Введен надлежащий процесс отслеживания ошибок и сортировки
  • Исследовал, как мы могли бы перейти с winforms на wpf
  • Посмотрел CAB (составное приложение) или фреймворки плагинов, чтобы упростить настройку. (В то время установка и настройка занимала колоссальное количество времени)

Другие вещи, которые я бы сделал сейчас, могут быть

  • Посмотрите на Postsharp, чтобы сплести сквозные проблемы, которые упростили бы ведение журнала, обработку исключений или любой другой код, который повторялся снова и снова.
  • Посмотрите на Automapper, чтобы преобразования из одного типа в другой управлялись конфигурацией, а не изменением кода во многих местах.
  • Посмотрите на обучение TDD (если вы этого не делаете) или модульные тесты в стиле BDD.
  • Потратьте время на оптимизацию автоматизированных интеграционных тестов. (Поскольку его сложно настроить и настроить вручную, он имеет тенденцию отбрасываться в SDLC)
  • Посмотрите на жизнеспособность таких инструментов разработки, как Resharper.

ХТН

person aqwert    schedule 06.07.2010
comment
рефакторинг, автоматическая сборка и сценарии БД — хорошие предложения. Остальное мы уже практикуем, включая postsharp и automapper, tdd и т. д. спасибо за отзыв - person Ash M; 06.07.2010