只有好代码的项目能成功吗？
Simon Brown，集开发者、架构师及作家于一身，他认为成功的项目需要的不仅仅是好代码。在他的演讲《好代码是不够的》中，Brown讨论了项目成功所需的所有元素，从前期设计到操作文档。
Brown认为好代码是一个好的开始，但要取得成功，人们需要知道要构建什么、要发布什么以及它可以运作起来。
要知道构建什么，需要一套需求。收集完需求之后，要有一个“大局观”，软件架构代表了当前对该产品的认识。然后，大问题需要被分解成更小的解决方案，其中包含了组件、组件之间的交互以及用到的服务。随后，估计实现这个解决方案需要多少成本。据Brown说，所有这一切，从确定需求到做出估算，只要1-2天。这不是一个人的工作，应该是所有直接参与的人共同完成，这样才能群策群力。
如果做得好，一个轻量级的软件架构能为项目引入结构——“什么是组件以及它们如何互相沟通”——与指导方针——“源自文档模式、模板和原则”，这能带来一致性——“以标准的方法来解决常见问题”——与清晰性——人们能知道自己的方向，因为他有“大局观”。作为一个反例，Brown提到一个项目，其中使用了三种持久化解决方案：Spring、EJB和Hibernate。这是因为没有人事先决定使用什么持久化框架。
接下来的步骤是确定优先级。除非是一个小项目，否则不该试图一步到位构建并发布整个项目，而是应该确定什么是最重要的，首先完成这部分。这需要完善并挑战需求范围，决定实现需求的一个子集，它足以满足最初设想的愿景的一部分内容。
其次是跟踪进度。跟踪进度有不同的方法，例如电子表格或看板。Brown指出，这些方法都是用来了解迭代进行到目前为止的进度完成情况的，它们并不跟踪已发布的软件。
架构是否可以运作起来？如果作为结果的解决方案无法如预期那样运作，那一切都是徒劳的。Brown认为，对于一个可用的解决方案而言，它必须满足以下要求：
- 它能满足架构需要：功能和非功能性需求、环境约束和所采用的原则
- 它为代码提供了一个坚实的基础，人们可以在此之上进行构建
- 它为解决解决方案中试图描述的初始业务问题提供了一个平台
构建一个原型。无论架构有多伟大，代码看起来有多漂亮，没人真正知道系统是否能令人满意，是否可以扩展。原型正是人们所需要的。原型是对概念的一个验证，包含系统的垂直切片、主要需求和基础部分，刚好用于模拟实际运作，通过负载测试将整个系统至于压力之下。用于原型的代码后期可用于生产环境，也可丢弃。
负载测试是这样实现的，“模拟典型使用场景中的多个用户，并且环境越接近生产越好”。原型和负载测试要在项目的早期阶段进行，用于验证架构。
源码控制提供了：源代码备份、代码变更日志、恢复到不同版本的机制、经简化的并行开发方式，使用源码控制是构建解决方案中的重要一步。
自动化测试也是必不可少的一块。刚加入的新代码会破坏什么东西吗？对项目某个部分的变更可能会对其他部分产生负面影响。为了限制变更可能造成的破坏，单元测试和集成测试是必须的，否则就要在每次变更后手动测试整个系统的功能。要做多少测试呢？Brown认为，100%的测试覆盖率是很难做到的，非常不切实际，他建议80%，覆盖代码最重要的部分。
自动化构建。代码经过测试后，需要在目标机上进行构建和部署。但很多时候，系统在其他机器上无法进行构建，构建脚本需要保证该系统可在任意目标机上正常构建。
Brown认为还有一个有用的步骤，即使用持续集成。持续集成服务器能自动从代码库中获取源代码、编译、测试、打包并安装，在此过程中出现任何错误它都会发出通知。这有助于确保代码的正确构建，及早发现问题。
自动化测试和构建引入了一致性和可重复性。在多代码分支上进行并行开发时，自动化就更加有用了。
提取配置信息。系统配置信息取决于环境，最好将它放在代码之外进行维护。
应用程序的版本应该包含在某处：在元数据中、在诊断页面中、在日志文件中，这样人们才能知道自己正在看哪个版本的程序。
最后就是操作文档。如果开发团队不是支持该软件的团队，那么有些操作文档是必须的，其中包含的信息涉及如何使用系统、如何监控系统、如何管理系统以及有问题时如何进行诊断。
所有这些有助于创造一个成功产品的元素都包含在下图中了：
查看英文原文：