只有好代码的项目能成功吗?

  Simon Brown,集开发者、架构师及作家于一身,他认为成功的项目需要的不仅仅是好代码。在他的演讲《好代码是不够的》中,Brown讨论了项目成功所需的所有元素,从前期设计到操作文档。

  Brown认为好代码是一个好的开始,但要取得成功,人们需要知道要构建什么、要发布什么以及它可以运作起来。

  要知道构建什么,需要一套需求。收集完需求之后,要有一个“大局观”,软件架构代表了当前对该产品的认识。然后,大问题需要被分解成更小的解决方案,其中包含了组件、组件之间的交互以及用到的服务。随后,估计实现这个解决方案需要多少成本。据Brown说,所有这一切,从确定需求到做出估算,只要1-2天。这不是一个人的工作,应该是所有直接参与的人共同完成,这样才能群策群力。

  如果做得好,一个轻量级的软件架构能为项目引入结构——“什么是组件以及它们如何互相沟通”——与指导方针——“源自文档模式、模板和原则”,这能带来一致性——“以标准的方法来解决常见问题”——与清晰性——人们能知道自己的方向,因为他有“大局观”。作为一个反例,Brown提到一个项目,其中使用了三种持久化解决方案:Spring、EJB和Hibernate。这是因为没有人事先决定使用什么持久化框架。

  接下来的步骤是确定优先级。除非是一个小项目,否则不该试图一步到位构建并发布整个项目,而是应该确定什么是最重要的,首先完成这部分。这需要完善并挑战需求范围,决定实现需求的一个子集,它足以满足最初设想的愿景的一部分内容。

  其次是跟踪进度。跟踪进度有不同的方法,例如电子表格或看板。Brown指出,这些方法都是用来了解迭代进行到目前为止的进度完成情况的,它们并不跟踪已发布的软件。

  架构是否可以运作起来?如果作为结果的解决方案无法如预期那样运作,那一切都是徒劳的。Brown认为,对于一个可用的解决方案而言,它必须满足以下要求:

  • 它能满足架构需要:功能和非功能性需求、环境约束和所采用的原则
  • 它为代码提供了一个坚实的基础,人们可以在此之上进行构建
  • 它为解决解决方案中试图描述的初始业务问题提供了一个平台

  构建一个原型。无论架构有多伟大,代码看起来有多漂亮,没人真正知道系统是否能令人满意,是否可以扩展。原型正是人们所需要的。原型是对概念的一个验证,包含系统的垂直切片、主要需求和基础部分,刚好用于模拟实际运作,通过负载测试将整个系统至于压力之下。用于原型的代码后期可用于生产环境,也可丢弃。

  负载测试是这样实现的,“模拟典型使用场景中的多个用户,并且环境越接近生产越好”。原型和负载测试要在项目的早期阶段进行,用于验证架构。

  源码控制提供了:源代码备份、代码变更日志、恢复到不同版本的机制、经简化的并行开发方式,使用源码控制是构建解决方案中的重要一步。

  自动化测试也是必不可少的一块。刚加入的新代码会破坏什么东西吗?对项目某个部分的变更可能会对其他部分产生负面影响。为了限制变更可能造成的破坏,单元测试和集成测试是必须的,否则就要在每次变更后手动测试整个系统的功能。要做多少测试呢?Brown认为,100%的测试覆盖率是很难做到的,非常不切实际,他建议80%,覆盖代码最重要的部分。

  自动化构建。代码经过测试后,需要在目标机上进行构建和部署。但很多时候,系统在其他机器上无法进行构建,构建脚本需要保证该系统可在任意目标机上正常构建。

  Brown认为还有一个有用的步骤,即使用持续集成。持续集成服务器能自动从代码库中获取源代码、编译、测试、打包并安装,在此过程中出现任何错误它都会发出通知。这有助于确保代码的正确构建,及早发现问题。

  自动化测试和构建引入了一致性和可重复性。在多代码分支上进行并行开发时,自动化就更加有用了。

  提取配置信息。系统配置信息取决于环境,最好将它放在代码之外进行维护。

  应用程序的版本应该包含在某处:在元数据中、在诊断页面中、在日志文件中,这样人们才能知道自己正在看哪个版本的程序。

  最后就是操作文档。如果开发团队不是支持该软件的团队,那么有些操作文档是必须的,其中包含的信息涉及如何使用系统、如何监控系统、如何管理系统以及有问题时如何进行诊断。

  所有这些有助于创造一个成功产品的元素都包含在下图中了:

只有好代码的项目能成功吗?_第1张图片  查看英文原文:Is Good Code Enough for a Project to Be Successful?

你可能感兴趣的:(项目管理)