Какой код «стандартной структуры» мы должны построить? - PullRequest
Новая
       22

Какой код «стандартной структуры» мы должны построить?

7 голосов
/ 06 июля 2010

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

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

  1. Кэширование
  2. Ведение журнала

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

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

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

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

Приветствия

Ответы [ 6 ]

6 голосов
/ 06 июля 2010
  • Инфраструктура модульного тестирования - можете ли вы легко запустить все свои модульные тесты? у вас есть юнит-тесты?
  • Процесс сборки - можете ли вы создать / развернуть приложение с нуля, используя всего одну или две команды?
3 голосов
/ 06 июля 2010

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

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

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

Кроме того, посмотрите на инверсию управляющих контейнеров, я рекомендую Castle Windsor .

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

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

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

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

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

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

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

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

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

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

3 голосов
/ 06 июля 2010

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

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

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

1 голос
/ 06 июля 2010

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

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

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

0 голосов
/ 06 июля 2010

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

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

0 голосов
/ 06 июля 2010

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

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

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

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

HTH

...