我是一名Web开发人员，打算在自己的职业生涯中获得“出版的一流图书馆”成就，而且我还在发汗（我整夜都在紧张地工作）。我很乐意利用社区的经验，看看是否有人有任何建议或建议，以确保尽可能顺利进行。有什么我需要注意的细节或陷阱吗？关于构建过程有什么特别之处可以让我难忘吗？

我在这里：

• 库已经过单元测试，代码覆盖率约为97％
• API有充分的文档说明，并且已经创建了用于智能感知的xml文档
• 我确保公共/私有类访问器是正确和正确的。所有获取者/设定者也是如此
• 错误处理并不像我希望的那样优雅，但是我已经到了最后期限，并且已经接受了它的“现在的样子”
• 没有友好的日志记录。Debug.Writeline被广泛使用...我最近了解到这反映了我的经验不足:(

非常感谢您的建议！

该库将用于生成报告。标准帽子-连接到只读数据库，执行计算，格式化并将数据输出到响应流。

我被当作一种边缘资源来填补一位辞职的程序员，而这项任务是作为“割牙”项目而交给我的。该类库将发布给公司中的其他程序员，以供他们编写生产代码时使用。

锁定API

有效地构建API的技巧与管理期望以及结构有关。

当我说API时，我指的是公共/内部类/方法的命名方式以及它们的访问级别（即私有/公共/内部）。

如果您担心代码在黄金时段可能还没有完全准备好，可以随时将其最初发布为Beta。

发布：

• Beta（即1.0版之前的版本）

  • 可能包含多个API重大更改
  • 可能缺少版本之间的向后兼容性更改
  • 可能缺乏抛光

• 官方（1.0+）

  • API已锁定，直到下一个主要版本
  • 引入的任何更改都应保证向后兼容

• 次要（ex 1.1）

  • 包含错误修复和/或功能实现
  • 可能会添加但不会脱离已定义的API

如果您认为该API需要经过严格的处理，则可以将其作为Beta发布一段时间。这表明它可以使用，但不应用于生产和/或关键任务代码。

许多人将带编号的版本控制方案当作hogwash对待，但是当有效地使用它们时，可以使用它们来提供一些摆动空间，直到您整理出结构为止。

您关于如何使用它的假设是错误的

无论某件产品的设计水平如何，人们都会找到一种滥用或创建替代用途的方法。

解决此问题的一种方法是使用访问器（即私有/公共/内部）来锁定尽可能多的实现，但是没有多少设计或工程给您带来比向用户发布代码一样多的洞察力。

您认为代码可以变得多么“完美”并不重要，您的用户将证明事实并非如此。

我认为这是使用现有代码库总比完全重写更好的主要原因。充其量可以说是完全重写，但很可能新代码库将包含与原始代码库一样多（甚至更多）的错误。

在您的情况下，您正在从头开始进行战斗，因此您不妨上手。

听起来您的其他基地已经覆盖。API文档至关重要，测试对于确保将来进行更改时的稳定性非常有用。

在将代码发布用于生产之前，实现一致的日志记录方案非常重要，因为您将需要一种全局启用/禁用/过滤日志的方法。顺便说一句，在大多数情况下，日志记录实际上仅涉及到导入库并将Debug.WriteLine（）的输出调用更改为Logging.Debug（），Logging.Info（），Logging.Error（）之类的东西。记录器本身仅提供配置，过滤和更广泛的输出方案（例如文件，控制台等）的标准实现。

除此之外，我希望将代码发布并使用。即使仅由少数用户启动。

我发现以下两点是发布软件的关键：

• 确切知道你发布了什么
• 管理期望

您希望能够回过头来对发布的内容进行错误修复，并且希望人们理解您的代码将解决什么问题。

知道你发布了什么

确保您已正确对其进行版本控制和签名（如果适当）。使用源代码控件来标记\标签与正式发布的版本关联的代码。这样可以帮助您更轻松地识别错误，因为您可以准确地返回已发布的源代码。当您可能有一些不同的发行版本时，它也将帮助解决问题。

尝试使最新版本易于掌握和更新。是安装程序，还是简单地将其放置在公共共享区上，取决于运送的人，时间和频率。

确保有人请您审查最终版本，包括文档。对发布软件感到紧张或兴奋，很容易错过一些东西。

管理期望

记录这些限制，并使它们对开发人员合理地显而易见。找到它们真是太好了。如果人们知道您的软件的局限性，那么人们通常会更加了解，特别是如果您有解决它们的计划。

记录您希望反馈的好坏。由于这是一个内部项目，因此如果每个人都可以访问通用的错误跟踪系统，请要求他们针对适当的项目提交错误。

将来，如果可能，请避免更改API，这可能会惹恼您的客户。请记住，异常也是API的一部分，即使在C＃中也不是方法文档的一部分。它可能是能够提高在以后的日子被抛出的异常，但你会需要跟最终用户，看看它会产生什么样的影响。

我有一份部署清单，您可能会觉得有用。我进行桌面开发，但是其中一些应该翻译。这是其中的一些：

一般：

• 对不应该为null的函数参数进行null检查。这可以帮助我尽早失败。
• 删除不必要的注释和注释掉的文件。这些导致将来的工作。
• 搜索任何“ // TODO”注释。有时我会给自己留下笔记。有时我会忘记他​​们。
• 尽可能使用生产数据库运行我的代码测试。这有助于确保我将所有数据库更改都在生产服务器上就位。
• 进行大量日志记录。特别是对于初始部署。实际上，我将日志保存到了最后，因为此时我的代码通常已经胶合。您不希望遇到崩溃的情况，并且对自己说：“如果我现在知道X的值，那么”。尝试提前计划。
• 尝试将第三方库调用包装在Facades中。这使得将来更改库变得容易，并提供了从库中需要的清单。

.NET特定：

• 确保我在一次性对象上调用Dispose（）。我使用代码分析或FxCop帮助查找这种情况。
• 确保我正确解开了所有事件处理程序。这样可以防止内存泄漏。