7

我们的情况是，我们有 4 名开发人员手头有一点空闲时间（大约 3-4 周）。

在我们的代码库中，对于不同的项目，有许多框架类型的代码会为我们开始的每个新项目重新编写。由于我们手头有一些空闲时间，我正在创建所有项目都可以重用的“标准”库集，例如：

  1. 缓存
  2. 日志记录

尽管上面的这 2 个将依赖于诸如 Enterprise Library 之类的库，但每个新项目都会围绕它编写自己的包装器等，因此我们正在整合所有这些代码。

我正在寻找有关您在内部构建并在许多项目中共享的标准库的建议。

为了给您一些背景信息，我们构建了 LOB 内部应用程序和面向公众的网站 - 即，我们不是销售收缩包装的软件公司，因此我们不需要许可模块之类的东西。

任何想法都将不胜感激 - 我们的开发人员渴望编写一些代码，我非常愿意给他们做一些事情，从长远来看这将使组织受益。

干杯

4

6 回答 6

6
  • 单元测试基础设施——你能轻松运行所有的单元测试吗？你有单元测试吗？
  • 构建过程——你能从头开始构建/部署一个应用程序，只需要 1 或 2 个命令吗？
于 2010-07-05T23:35:59.430 回答
3

好的，最重要的是，不要重新发明轮子！

花一些时间研究可以轻松利用的库：

  • 对于日志记录，我强烈推荐Log4Net。
  • 用于测试nUnit
  • 为了嘲笑，犀牛。

另外，看看 Inversion of Control Containers，我推荐Castle Windsor。

  • 对于索引，我推荐Solr（在 Lucene 之上）。

接下来，编写一些包装器：

这些应该是您 API 的入口点（公共库，但将其视为 API）。

专注于抽象您在 API 内部使用的所有库，因此如果您不想再使用 Log4Net 或 Castle Windsor，您可以通过编写结构良好的抽象并专注于松散耦合的设计模式。

采用领域驱动开发：

将 API 视为域和模块化抽象，它们在内部使用其他通用 API，例如通用数据访问库。

建议：

我将从一个超级灵活的通用 DAL 库开始，这使得访问任何类型的数据和多种存储介质变得非常容易。

我将 Fluent nHibernate 用于关系数据库的东西，并且我将所有方法调用都调用到你的数据访问实现 LINQ 中，因为它是 ac# 语言功能。

使用 LINQ 查询数据库、索引、文件、xml 等。

于 2010-07-06T01:03:16.027 回答
3

我们做的一些主要事情：

  • 日志记录（带有一些围绕 TraceSource 的包装器）
  • 序列化包装器（因此您可以在一行代码中序列化/反序列化）
  • 压缩（.NET 功能的包装器，以便您可以在一行代码中执行此操作）
  • 加密（同样是 .NET Framework 功能的包装器，因此开发人员不必一直在 byte[] 中工作）
  • 上下文 - 遍历堆栈跟踪以带回包含有关当前调用的所有信息（程序集、类、成员、成员类型、文件名、行号等）的数据结构的类
  • 等等等等……

希望有帮助

于 2010-07-06T00:40:19.913 回答
1

这是一件可以让所有开发人员忙上一个月的事情：

  1. 在具有代码覆盖率（nUnit 或 VS 代码覆盖率）的分析器中运行应用的单元测试。
  2. 找出哪些区域需要更多测试。
  3. 为这些子系统编写单元测试。

现在，如果系统不是使用 TDD 编写的，那么它很可能是非常单一的，并且需要大量重构来引入测试表面。希望最终你会得到一个更加模块化、耦合度更低的产品。更可测试的系统。

于 2010-07-06T00:47:30.613 回答
0

我的态度是几乎不应该编写标准库。相反，应该重构现有的工作代码以消除重复并提高易用性和易于测试。

结果将非常像一个“标准库”，除了你会知道它可以工作（你在每次更改后重新运行你的单元测试，对吗？），你会知道它会被使用，因为它已经正在使用。否则，您将冒着创建一个未使用且在使用时不起作用的出色标准库的风险。

于 2010-07-06T00:38:14.567 回答
0

在业务整理下一个版本应该是什么时，以前的工作遇到了一点停机时间。我们做了一些有帮助的事情

  • 从 .net reoting 迁移到 WCF
  • 搜索代码中所有开发人员讨厌使用的痛点并重构它们
  • 引入一个良好的自动化构建系统，该系统将运行单元测试并为失败的构建发送电子邮件。它还会将该版本打包并放置在共享目录中，以供 QA 获取
  • 编写数据库脚本，以便您可以轻松升级数据库，而不是被迫获取被其他开发人员一直在使用的不相关数据污染的过时副本。
  • 引入了适当的错误跟踪和分类流程
  • 研究了我们如何从 winforms 迁移到 wpf
  • 查看了 CAB（复合应用程序）或插件框架，因此配置会变得更简单。（当时设置和配置是一个巨大的时间量）

我现在要做的其他事情可能是

  • 看看 Postsharp 来编织横切关注点，这将简化日志记录、异常处理或任何重复重复的代码
  • 查看 Automapper，以便从一种类型到另一种类型的转换是由配置驱动的，而不是在许多地方更改代码。
  • 查看有关 TDD（如果您不这样做）或 BDD 样式单元测试的教育。
  • 花时间简化自动化集成测试。（由于这个很难手动设置和配置，它往往会在 SDLC 中被丢弃）
  • 查看 Resharper 等开发工具的可行性

高温高压

于 2010-07-06T00:33:54.693 回答