我需要开始设计和开发新框架，以便与开源ECM进行交互。这包括一个自定义的数据模型，以帮助网站开发人员与此ECM进行交互，因此他们无需关心节点操作的细节和其他低级细节。那只是一堆要开发的类和方法。

我对如何处理该项目的组织和管理有一些疑问：开发此类项目是否需要遵循一些一般规则，技巧，最佳实践或一些注意事项？

我确信框架或库的开发与应用程序之间会有一些区别。

首先，这是我避免框架浪费综合症的2条规则：

• 没有现有的，可以满足我80％的需求，并且可以扩展以适应最后20％的需求
• 可以肯定的是，我将在另一个应用程序中再次使用它

通过这些之后，请检查以下内容：

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

1）仅当从工作代码中提取功能时，才应将其添加到框架中。换句话说，在将新颖的想法添加到新颖的框架之前，请确保它确实可以在现实的应用程序中增加价值并减少重复性。

2）文档，文档，文档。

3）文档，文档，文档。

痛苦的经验和大量的浪费的工作导致了这一建议：从工作软件中提取或重构框架。构建该软件时要记住，您认为将来会希望提取一个框架，但不要首先构建该框架。

我建议本书《框架设计指南》。它已经存在了两年，但是原理仍然是正确的。它有很多模式，并解释了在构建框架时要做出的决策背后的原因。

1）从一开始就坚持良好的约定，确保您已记录了非常特定的约定，最好的框架是内部一致的框架。

2）确保所有内容都被高度记录，从良好的代码注释一直到解释最重要的功能要求和产生的内容，即使您觉得超级简单，也可能有人连续第14小时使用它，并且他们然后只需要一件事。

3）为自己制定一个项目简介，其中包含您希望框架实现的目标，切合实际的目标和总体优先级。

4）如果可供人们使用，请确保您已准备好某种形式的支持过程/错误跟踪。我们所有人都会碰到bug，但是如果您能从头开始管理它们，那将使您的生活更轻松。

总而言之，构建任何应用程序的方法都是相似的，但是开发人员比用户更为挑剔，最好的框架是我们可以选择，理解并不需要战斗的框架。

我不同意很多说法，但我觉得还有更多遗漏，因此我将从头开始。

敏捷方法

在框架开发过程中采用敏捷方法论，以便您可以适应变化，快速应对障碍并确保最终产品的功能和质量。敏捷方法论是根据“敏捷宣言”确定的优先事项：

个体和交互比过程和工具
可以工作的软件比全面的文档
客户合作，在合同谈判
响应变化在遵循计划

那就对了。我说功能比文档更重要。请注意，“敏捷宣言”提到右手优先事项仍然很重要，只比左手优先事项少。

通讯

制作框架的人需要知道：

1. 如何使用：目标应用程序
2. 打算解决什么问题：目标问题
3. 谁将使用它：目标受众

例如，如果一家公司打算使用ASP .NET开发最终应用程序，那么不告诉他们的程序员“告诉他们”做这个框架是愚蠢的。如果程序员不知道目标应用程序，他们可能就不会使其面向Web。如果他们不知道问题所在，他们可能会为其他目的创建框架。如果他们不了解读者，则可以使用C ++对框架进行编程。这些情况中的任何一种都会使生成的框架无用。

样式

不用说，建立一种编程风格/格式并坚持下去。

E的

1. 模块化：以编程方式而不是从字面上重用代码。
2. 效率：您的代码旨在重用。任何对速度的损害都会成倍增加。
3. 可维护性：您希望能够编辑框架以更新多个程序，而不必修改所述程序。
4. 可用性：应用程序是否可以实际使用您的框架而不会陷入困境？
5. 实用性：不必重新发明轮子。您的框架可以依赖于其他框架。
6. 冗余：捕获异常/错误。到处。处理它们。到处。即使您知道这样做，也不要信任任何代码，而是在本地范围内的代码来处理错误。

我确信框架或库的开发与应用程序之间会有一些区别。

开发过程本质上是相同的。尽管我发现最大的差异通常是在项目范围和定义方面，但是差异可能归结于营销和部署问题。请记住，应用程序可能包含或使用框架或库，框架可能是库的集合。

我对如何处理该项目的组织和管理有一些疑问：开发此类项目是否需要遵循一些一般规则，技巧，最佳实践或一些注意事项？

对于任何开发项目，项目组织和管理都相同。同样，它涉及范围。但是，在编写框架时，必须对自己要实现的目标有一个非常清晰的愿景，并在框架的公共接口上放置严格的设计规则，以确保API表示形式的一致性。如果允许每个开发人员做自己的事情，那么最终将导致一团糟，并且API设计也非常笨拙。

尽管本书本身旨在开发基于.NET的框架，但我还是赞同Ryan Hayes的建议以阅读《框架设计指南》，因为不管您选择使用哪种具体的实现技术，通用建议都适用。

根据经验，我建议先遵循最简单的公共接口，然后再扩展以提供更大的控制力和深度，以遵循经典的YAGNI原则，但是要小心使用有用的名称来说明为什么要扩展方法或类。我从来都不喜欢在方法名称中添加“ Ex”或其他类似的后缀，或者在扩展的接口定义中添加数字。在功能上有所区别，并且您的界面/方法名称应该变得更清晰，并且希望不会被混淆。