业务逻辑 程序逻辑_这是在您的业务逻辑之前！

我认为为软件项目制定技术清单可能是值得的–在开始编写业务逻辑本身之前，请收集所有需要回答的问题。 对于大多数这些问题，只有一个或两个可能的答案，如果您不知道哪种方法最适合您， StackOverflow可以帮助您在它们之间进行选择。

这是一个很长的清单，但是我真的相信，如果您延迟所有或全部这些，都会让您大吃一惊。

1.编程语言/框架

这是首选，因为它会影响其他所有内容。 我们所有人都有我们最喜欢的语言，并且我们对它们的熟练程度各不相同。 除了这个因素（可能会变得很大）之外，请考虑：

• 性能特点。 今天这与95％以上的软件项目无关，因为大多数语言将具有一到两个参考实现，这些参考实现将足够快 –但是不要用Ruby编写嵌入式代码（我会借此机会反驳一次）对于某些人仍然保持的所有幻想-C / C ++的速度并不比.Net或Java快 ，而是可以预测的。
• 重要的第三方图书馆。 如果您的业务应用程序仅需要具有Lucene 2.4，而Lucene到其他语言的端口就缺少功能，那么这几乎将您限制在Java范围内。 如果您正在编写针对Windows的GUI丰富的应用程序，那么.Net可能是您最安全的选择。

2.单元测试

• 这应该包括一个模拟框架，尽管我通常倾向于编写集成测试而不是单元测试。
• 考虑与您的测试运行程序集成–例如，Resharper在两年前不支持运行MSTest测试（当时我们在使用它，主要是因为我们没有更好的了解）。
• 单元测试还远远不够–集成测试是唯一使人对实际的端到端产品充满信心的东西。 对于强大的TDD倡导者：系统测试也非常有价值，因为它们是测试在整个系统上而不是在单个组件路径上流动的唯一事物。

3.依赖注入/ IOC框架

• 我直到最近才开始大量应用此技术，这是一种美。 它允许编写隔离的单元测试和简单的模拟，并有助于生命周期管理（例如，无需手动编写Singleton模式的代码）。 一个好的框架会减轻您的生活，而不是使其复杂化。
• 在实现选择的IOC框架时，请记住，将其连接进行集成测试不一定与实际生产代码的连接相同。

4.展示层

无论是Web还是桌面应用程序，大多数项目都需要一个。

5.数据层

• 您打算如何存储和访问数据？ 您的网站可以由数据库驱动吗？ 还是您需要走NO-SQL的道路 ？ 您可能需要将两者结合在一起–使用数据库存储大多数数据，但使用另一个位置存储对性能至关重要的数据。
• 对象关系映射 –您通常不希望手工制作SQL，而希望使用ORM（在此我们都是面向对象的，对吧？）。

6.通讯层

如果您的项目有几个独立的组件或服务，则应选择一种交流模型。 他们是否使用直接RPC调用或通过消息总线传递消息来通过数据库进行通信？

7.记录

• 如果我认为最好的解决方案，则将所有内容都记录到中央数据库中。 使用日志记录框架（最好选择一个具有简单错误级别方案并允许内置日志格式化的框架）。
• 确保您的日志记录不会损害您的性能（为每个日志打开与数据库的新连接是一个坏主意），但不要过早地对其进行优化。
• 不要分散您的日志-统一的日志记录方案对于分析应用程序错误至关重要，不要将某些事件记录到数据库中，而将其他事件记录到文件中。
• 我发现自动失败引发错误的单元测试很有用。 即使被测类的行为符合预期，它也可能在内部报告了错误情况，在这种情况下，您想了解它。 使用内存中的附加程序，收集所有错误/致命日志，并断言没有错误-除了专门针对错误代码输入的测试之外。

8.配置

• 确定一个明智的API以从代码访问配置。 您可以使用语言的本机配置机制，也可以自行开发。
• 确定如何维护配置文件。 谁负责更新它们？ 哪些配置是必需的，哪些是可选的？ 配置本身（不是架构）的版本受控制吗？

9.发布文档

• 发行说明/变更日志–一个简单的（源代码控制）文本文件通常就足够了，因为它提供了有关构建内容的关键信息。 应该包括新功能，错误修复，新的已知问题，以及当然的部署方法说明。
• 配置文档–特别是在大型团队中，应在一个地方记录所有必需的配置。 这使任何人都可以轻松配置和运行系统。

10.打包和部署

• 让您的构建过程将整个发行版打包到一个独立的包中。
• 对版本进行版本化–对源代码管理的每次提交都应增加版本号，并且该版本应自动集成到程序集中–这可确保您始终知道正在运行的版本。
• 根据您的IT员工以及手动部署的复杂程度，您可能需要投资部署脚本-该脚本获取发布包并完成部署所需的所有（或几乎所有）操作。 这是编写有效的系统测试的先决条件。

11.工具

• 源代码控制 ： SVN ， TFS ， Git等等。 选择一项（根据您的需求和预算），然后将您开发的所有内容都放在下面 。 一个痛苦的问题是您的分支机构管理。 一些人更喜欢在单个始终稳定的中继线上持续工作，另一些人更喜欢功能分支。 选择取决于您选择的SCM工具，团队的规模以及使用该工具的经验水平。
• 构建系统–永远不会或很少运行的单元测试几乎没有效果。 使用TeamCity来确保您的代码始终经过良好的测试（至少与您认为的一样良好）。
• IDE -有些编程语言只有一个显著IDE ，其他有一个数 。
• （注–我真的不认为Visual Studio是没有Resharper的IDE）
• 错误跟踪–在一个简单的地方可以收集和处理错误。
• 功能和待办事项管理–易于访问的位置，向您和整个团队展示：您当前正在处理哪些功能，为完成功能而要做的任务，待办事项上的优先功能是什么–至关重要，可帮助您选择下一步（我更喜欢基于sprint的方法 ）
• 文档标准。 它可以是Wiki，共享文件夹，Google Docs或（ugh）SharePoint，但是您应该决定采用哪种组织方案。 我强烈建议您不要将文档作为附件发送，因为这样您就无法确定它们何时更改。
• 基础IT –备份，共享存储，VPN，电子邮件等

您是否同意此清单？ 我错过了什么？ 在项目的后期阶段可以延迟什么？

参考： 这是在您的业务逻辑之前！ 来自我们的JCG合作伙伴 罗恩•格罗斯 （ Ron Gross）在“量子不朽”中的报道 。

• 使用FindBugs产生更少的错误代码
• 测量代码复杂度
• 为什么自动化测试可以提高您的开发速度
• 不执行代码审查？ 你的借口是什么
• Java工具：源代码优化和分析
• 您的代码中有几个错误？