软件开发原则
Patrick Cauldwell is one of the architects on our Next Generation Banking System. A while back I asked him to write up our guiding principles for not only educating new developers but also for indoctrinating existing team members into our world view. He published it on his blog as This I Believe...The Developer Edition.
Patrick Cauldwell是我们下一代银行系统的架构师之一。 不久前，我请他写下我们的指导原则，不仅要教育新开发人员，还要将现有团队成员灌输到我们的世界视野中。 他在博客上发布了“ This I Believe ... The Developer Edition” 。
It's a great list. Here's a partial listing of the first two levels of his outline. Be sure to visit his post for the complete outline. It's bent towards .NET, because the stuff he's doing is .NET, but the general ideas are usable elsewhere.
这是一个很棒的清单。 这是他的大纲的前两个级别的部分列表。 请务必访问他的帖子以获取完整的概述。 它倾向于.NET，因为他正在做的事情是.NET，但是一般的想法在其他地方都可以使用。
Our "guiding principles"
我们的“指导原则”
- Test Driven Development 测试驱动开发
- Continuous Integration 持续集成
Our "guiding principles"
我们的“指导原则”
Unit Tests
单元测试
- Two kinds of tests 两种测试
- Automation is equally possible for both sets of tests 两组测试均可以实现自动化
All UI development should follow the MVP pattern for ease of testing
所有UI开发都应遵循MVP模式，以便于测试
Unit Tests
单元测试
Test Coverage
测试范围
- 90%+ is the goal 90％+是目标
- NCover runs as part of the build, and reports are generatedNCover作为构建的一部分运行，并生成报告
Test Coverage
测试覆盖率
Buy, Not Build
购买，不建造
- Take full advantage of the platform, even if it only solves the 80% case 充分利用平台，即使仅解决了80％的情况
- Don't write a single line of code you don't have to 无需编写单行代码
- Take full advantage of .NET 3.0, SQL 2005, Windows 2003 Server, plan for- and test on Longhorn. 充分利用.NET 3.0，SQL 2005，Windows 2003 Server进行计划，并在Longhorn上进行测试。
- Don't invent new solutions to solved problems. 不要发明解决问题的新解决方案。
Buy, Not Build
购买，不建造
Limit compile time dependencies on code you don't own
将编译时间依赖性限制在您不拥有的代码上
- Everything not owned by us should be behind an interface and a factory method 我们不拥有的所有内容都应该在接口和工厂方法后面
Limit compile time dependencies on code you don't own
将编译时间依赖性限制在您不拥有的代码上
Define your data contracts in C# (think "active record")
用C＃定义数据合同(认为是“活动记录”)
- All persistent storage should be abstracted using logical interfaces 所有持久性存储都应使用逻辑接口进行抽象
Define your data contracts in C# (think "active record")
用C＃定义数据合同(认为是“活动记录”)
Fewer assemblies is better
组装越少越好
- There should be a VERY good reason for creating a new assembly 创建一个新的装配应该有一个很好的理由
- The assembly is the smallest deployable unit, so it's only worth creating a new assembly if it means NOT shipping something else 该程序集是最小的可部署单元，因此只有在不发送其他任何东西的情况下才值得创建一个新程序集
- Namespace != assembly name. Roll up many namespaces into one physical assembly if they all must be deployed together. 命名空间！=程序集名称。 如果必须将所有名称空间全部部署在一起，则将它们汇总到一个物理程序集中。
Fewer assemblies is better
组装越少越好
Only the public interface should be public
只有公共接口应该是公共的
- Only make classes and interfaces public if absolutely necessary 仅在绝对必要时才公开类和接口
- Test code should take advantage of InternalsVisibleTo attributes 测试代码应利用InternalsVisibleTo属性
- VS 2005 defaults to creating internal, not public classes for a reason 由于某种原因，VS 2005默认创建内部而不是公共类
- If it's public, you have to support it for ever如果是公开的，则必须永远支持它
Only the public interface should be public
只有公共接口应该是公共的
Windows authentication (good)
Windows身份验证(良好)
- Just say no to connection strings 对连接字符串说不
- Windows authentication should be used to talk to SQL, ADAM, the file system, etc. Windows身份验证应用于与SQL，ADAM，文件系统等进行对话。
- You can take advantage of impersonation without impersonating end users 您可以利用模拟的优势，而不必模拟最终用户
Windows authentication (good)
Windows身份验证(良好)
Tracing
追踪
- Think long and hard about trace levels 深思熟虑痕量水平
- Use formatted resource strings everywhere for localization 随处使用格式化的资源字符串进行本地化
- For critical, error, or warning, your audience is not a developer 对于严重，错误或警告，您的受众不是开发人员
Tracing
追踪
Error Handling
错误处理
- Method names are verbs 方法名称是动词
- If anything breaks the contract, throw an exception 如果有任何违约行为，请抛出异常
Error Handling
错误处理
The definition of "done" (or, how do I know when a task is ready for QA?)
“完成”的定义(或者，如何知道什么时候可以进行质量检查了？)
- Any significant design decisions have been discussed and approved by the team 团队讨论并批准了任何重要的设计决策
- For each MyClass, there is a corresponding MyClassFixture in the corresponding test assembly 对于每个MyClass，在相应的测试程序集中都有一个对应的MyClassFixture
- MyClassFixture exercises all of the functionality of MyClass (and nothing else) MyClassFixture行使MyClass的所有功能(仅此一项)
- Code coverage of MyClass is >=90%, excluding only lines you are confident are unreasonable to test MyClass的代码覆盖率> = 90％，仅排除您确信不合理测试的行
- No compiler warnings are generated by the new code 新代码不会生成任何编译器警告
- Before committing anything to source control, update to get all recent changes, and make sure all unit and integration tests pass 在将任何内容提交给源代码管理之前，请进行更新以获取所有最近的更改，并确保所有单元和集成测试都通过了
- FxCop should generate no new warnings for your new code FxCop应该不会为您的新代码生成新的警告
- Compiling with warnings as errors will flush out any place you forgot documentation comments, which must be included for any new code带有警告的错误编译将清除您忘记文档注释的任何位置，任何新代码都必须包含这些注释
The definition of "done" (or, how do I know when a task is ready for QA?)
“完成”的定义(或者，如何知道什么时候可以进行质量检查了？)
What guiding principles do you follow at your development shop?
您在开发商店遵循哪些指导原则？
翻译自: https://www.hanselman.com/blog/some-guiding-principles-for-software-development
软件开发原则
扫一扫
169
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
