我们应该构建什么是“标准框架”代码？

Question

我们处于这样一种状况，即我们有4名开发人员可以腾出一些空闲时间（谈论3-4周）。

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

1. 缓存
2. 登录

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

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

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

我们非常感谢任何想法 - 我们的开发人员渴望编写一些代码，而且我非常乐意为他们提供一些可以从长远来看对组织有益的事情。

干杯

Answer 1

• 单元测试基础设施 - 您可以轻松运行所有单元测试吗？你有单元测试吗？
• 构建过程 - 您是否可以从头开始构建/部署应用程序，只需要1或2个命令？

Answer 2

我们做的一些主要事情：

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

希望有所帮助

Answer 3

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

花一些时间研究您可以轻松利用的图书馆：

• 对于日志记录，我强烈推荐 Log4Net 。
• 用于测试 nUnit
• 对于模拟， Rhino 。

另外，看看控制容器的倒置，我推荐 Castle Windsor 。

• 对于索引，我建议 Solr （在Lucene之上）。

接下来，写一些包装器：

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

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

采用域驱动开发：

将API视为域和模块化抽象，内部使用其他常见API，例如常用的数据访问库。

建议：

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

我使用Fluent nHibernate作为关系数据库的东西，我将所有的方法调用都放到你的数据访问工具LINQ中，因为它是一个c＃语言特性。

使用LINQ查询DB，索引，文件，xml等。

Answer 4

有一件事可以让所有开发人员忙碌一个月：

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

现在，如果系统不是使用TDD编写的，那么它很可能是非常单一的，需要进行大量的重构来引入测试表面。希望在最后，你最终会得到一个更模块化，更不紧密耦合的东西。更可测试的系统。

Answer 5

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

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

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

• 看看Postsharp编织交叉切割问题，这将简化日志记录，异常处理或任何代码重复一遍又一遍
• 查看Automapper，以便从一种类型到另一种类型的转换由配置驱动，而不是在许多地方更改代码。
• 看看围绕TDD的教育（如果你不这样做）或BDD风格的单元测试。
• 投入时间简化自动化集成测试。 （由于这个很难设置和手动配置，它往往会在SDLC中被删除）
• 查看Resharper等开发工具的可行性

HTH

Answer 6

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

结果将非常像“标准库”，除非您知道它有效（您在每次更改后重新进行单元测试，对吗？），并且您将知道它将被使用，因为它已被使用。否则，您将冒着创建一个未使用的精彩标准库的风险，并且在 时使用它不起作用。