Какова “стандартная платформа” код, который мы должны создать?
Мы находимся в ситуации, посредством чего у нас есть 4 разработчика с небольшим количеством свободного времени на наших руках (говорящий приблизительно 3-4 недели).
Через нашу кодовую базу, для различных проектов, существует много типов платформы-y кода, который переписывается для каждого нового проекта, который мы запускаем. Так как у нас есть некоторое свободное время на наших руках, я нахожусь в процессе создания "стандартного" набора библиотек, как которые все проекты могут снова использовать, такие:
- Кэширование
- Вход
Хотя эти 2 выше полагались бы на библиотеки, такие как Библиотека Предприятия, каждый новый проект запишет свои собственные обертки вокруг этого, и т.д., таким образом, мы консолидируем все, что они кодируют.
Я ищу предположения на стандартных библиотеках, что Вы создали внутренний, который совместно используется через многие проекты.
Чтобы дать Вам некоторый контекст, мы создаем LOB внутренние приложения и общедоступные веб-сайты - т.е. мы не фирма по разработке программного обеспечения, продавая термоусадочную пленку, таким образом, мы не должны наполнять как модуль лицензирования.
Любые мысли очень ценились бы - наши разработчики очень хотят писать некоторый код, и я очень любил бы давать им что-то, чтобы сделать, который принесет пользу организации в конечном счете.
Удачи
6 ответов
Некоторые из основных вещей, которые мы делаем:
- Ведение журнала ( с некоторыми оболочками вокруг TraceSource)
- Обертки сериализации (чтобы вы могли сериализовать / десериализовать в одной строке кода)
- Сжатие (оболочки для функциональности .NET, чтобы вы могли делать это в одной строке кода)
- Шифрование (то же самое, оболочки для функциональности .NET Framework, поэтому разработчику не нужно постоянно работать с byte [])
- Контекст - класс, который просматривает трассировку стека, чтобы вернуть структура данных, которая содержит всю информацию о текущем вызове (сборка, класс, член, тип элемента, имя файла, номер строки и т. д.)
- и т. д. и т. д.
Надеюсь, что это поможет
Хорошо, самое главное, не изобретайте велосипед!
Потратьте некоторое время на изучение библиотек, которые вы можете легко использовать:
- Для ведения журнала я настоятельно рекомендую Log4Net.
- Для тестирования nUnit
- Для издевательства, Rhino.
Кроме того, взгляните на Инверсию контрольных контейнеров, я рекомендую Castle Windsor.
- Для индексации рекомендую Solr (поверх Lucene).
Затем напишите несколько оболочек:
Они должны быть точкой входа в API (обычная библиотека, но думайте о ней как об API).
Сосредоточьтесь на абстрагировании всех библиотек, которые вы используете внутри своего API, поэтому, если вы больше не хотите использовать Log4Net или Castle Windsor, вы можете, написав хорошо структурированные абстракции и сосредоточившись на слабо связанных шаблонах проектирования.
Примите domain Driven Development:
Думайте об API как о доменах и модульных абстракциях, которые внутренне используют другие распространенные API, такие как общая библиотека доступа к данным.
Предложения:
Я бы начал с супер гибкой общей библиотеки DAL, которая позволяет очень легко получить доступ к любому типу данных и нескольким носителям данных.
Я бы использовал Fluent nHibernate для реляционной БД, и у меня были бы все вызовы методов в реализации LINQ для доступа к данным, поскольку это функция языка C#.
Использование LINQ для запроса БД, индексов, файлов, xml и т. д.
- Инфраструктура модульного тестирования - можете ли вы легко запустить все свои модульные тесты? у вас есть модульные тесты?
- Процесс сборки - можете ли вы создать / развернуть приложение с нуля, используя всего 1 или 2 команды?
Вот одна вещь, которая может занять всех разработчиков на месяц:
- Запустите модульные тесты ваших приложений в профилировщике с покрытием кода (nUnit или VS Code Coverage).
- Выясните, какие области нуждаются в дополнительных тестах.
- Напишите модульные тесты для этих подсистем.
Теперь, если система не была написана с использованием TDD, есть шанс, что она будет очень монолитной и потребует значительного рефакторинга для внедрения тестовых поверхностей. Надеюсь, в конце вы получите более модульную, менее тесно связанную и более тестируемую систему.
Мое отношение таково, что почти никогда не следует писать стандартные библиотеки. Вместо этого следует рефакторить существующий, рабочий код, чтобы убрать дублирование и улучшить удобство использования и простоту тестирования.
Результат будет очень похож на "стандартную библиотеку", за исключением того, что вы будете знать, что она работает (вы же перепроверили свои модульные тесты после каждого изменения, верно?), и вы будете знать, что она будет использоваться, поскольку она уже использовалась. В противном случае вы рискуете создать замечательную стандартную библиотеку, которая не используется и не работает, когда она используется.
При выполнении предыдущего задания возник небольшой простой, пока компания решала, какой должна быть следующая версия. Было несколько вещей, которые мы сделали, которые помогли
- Переход с .net на WCF
- Поиск болевых точек в коде, с которыми все разработчики просто ненавидят работать, и их рефакторинг
- Внедрение хорошей автоматизированной системы сборки, которая будет запускать модульные тесты и рассылать электронные письма о неудачных сборках. Он также упакует и поместит эту версию в общий каталог для QA, чтобы забрать
- Написал сценарий базы данных, чтобы вы могли легко обновить базу данных, вместо того, чтобы быть вынужденным брать устаревшую копию, загрязненную нерелевантными данными, которые другие разработчики играли с.
- Введен надлежащий процесс отслеживания ошибок и сортировки.
- Исследовал, как можно перейти с winforms на wpf
- Взглянул на CAB (составное приложение) или фреймворки для упрощения настройки.(В то время установка и конфигурирование занимали уйму времени)
Другие вещи, которые я бы сделал сейчас, могут быть
- Посмотрите на Postsharp, чтобы объединить общие проблемы, которые упростили бы ведение журнала, обработку исключений или везде, где код повторялся, и еще раз
- Посмотрите на Automapper, чтобы преобразование одного типа в другой происходило за счет конфигурации, а не за счет изменения кода во многих местах.
- Посмотрите на образование в области TDD (если вы этого не делаете) или модульных тестов в стиле BDD.
- Потратьте время на оптимизацию автоматизированных интеграционных тестов. (Поскольку его сложно установить и настроить вручную, он обычно не используется в SDLC)
- Посмотрите на жизнеспособность таких инструментов разработки, как Resharper
HTH