目录
  1. 分析需求
    1. 开发为什么要分析需求
    2. 开发如何分析需求
    3. 码农的注意事项
  2. 技术设计
    1. 模型/接口设计
    2. 存储模型设计
    3. 其他
  3. 结语

  正式工作也快一年了,希望能总结一些工作方式,还有一些自己的理解。这个文章主要在讲日常生活中我是如何完成一个需求/项目的,也有很多内容其实是希望能告诉一年前的自己的,所以对于团队新人来说也许能窥探出一些避免踩坑的方式。
  本文并不会探讨“如何科学高效的进行软件开发”这种问题。我只是罗列一些现状,至于能否改进和如何改进,可能还需要我后面慢慢体会。

分析需求

  做一个需求第一步就是分析需求了,这一步也是开发流程中最重要的一步。记住,这里说的分析需求不是产品经理分析的需求,而是我们开发拿到“产品需求”之后做的二次分析,也叫需求把控。

开发为什么要分析需求

  先定基调:产品经理和用户一样不可靠,技术一定要再做一次需求分析。这里不是对产品经理能力的否认,而是对技术人员的一种自我保护。原因如下:

  以上列出的方方面面,从软件开发的角度,归根到底,就是在需求阶段认清楚需求风险,避免后面的需求变更。
  读到这里你可能有很多疑问,为什么需求变更要开发来买单呢?为什么不用敏捷开发来应对需求风险呢?这些可能和我们部门长期的开发方式有关:看似有章法,实际无章法。结果导向、业务导向的后果就是业务方先定下来发布时间,这个时间之前把这件事情搞定。在这种模式下,没有人会给你时间搞小周期迭代,更没有人会帮你挡住需求变更。大家会把赌注都压在项目一气呵成的假设上。也可以说,开发需要有能力识别出项目的全部风险。

  长期演变过来的结果,就是要求开发要有很高的业务理解能力,其实主要就是需求分析能力,甚至这种能力成为了你晋升最重要的因素之一。因为按照上面的开发模式,最理想的办法,就是在需求分析阶段指出需求缺陷,发现项目风险,使得后面的开发过程一马平川的走过来。当然这就需要我们的开发具备这项能力了。

开发如何分析需求

码农的注意事项

  千万不要因为自己想搞技术而忽略需求分析,程序员的意义在于对现实问题抽象建模,用计算机的手段来解决现实问题,也就是充当着现实和计算机之前的桥梁,因此桥梁的两边都要顾及和熟悉。尤其是身处业务部门时,业务能力要远比技术能力重要,此时不去积极参与需求讨论和分析,就是舍本逐末。

技术设计

  业务开发做技术设计的核心,在于模型、接口和数据库表结构设计,在于业务逻辑的抽象能力。少数情况下可能涉及到技术选型的问题,这一点就不在此做概括了。得益于公司大中台小前台的组织结构,前台业务并不需要关心技术问题的具体实现,包括但不限于数据的读写性能、网站的并发能力、搜索引擎的数据同步、异地多活等等技术问题,使得业务开发完全投入到业(ban)务(zhuan)中。
  设计像是一门艺术,他不一定有对与错,但是良好的设计确实可以对软件开发带来极大的积极作用,也是一个工程师综合能力的体现。

模型/接口设计

  模型是我们为了解决业务问题进行的系统建模,代表了一个模块的职责。

  除了上述,开发人员对于技术模型的设计也是有很大空间的,例如,一个业务模型是否需要拆分成多个系统模型,系统模型的设计是否具有可复用性和扩展性,模型是否清晰易懂?这样看来,模型的设计也是很讲究经验和感觉的,只有不断的尝试和总结,才能摸索出自己的方式。

存储模型设计

  系统模型设计完成之后,才可以进行存储模型的设计。相比于存储模型,系统模型才是设计的核心,因此千万不要有先设计数据库再设计领域模型的想法。对于存储模型我们指的都是关系型数据库的表结构,因为事实证明,电商的大多数情况下离不开事务,也离不开关系型数据库。
  这里要提一下现在常见的分布式数据库,现在的OLTP数据库为了实现分布式,很多采用的都是分库分表的方式。分库分表的方式缩减了数据库的查询和关联能力,从某种程度上来说变成一种弱关系型数据库。因此在进行表结构设计时,可能需要作出一些反范式的设计。
  存储模型大多由系统模型推导出,也可以认为是系统模型的持久化层实现方案。但是存储模型的设计不代表不重要,不同的存储设计带来的维护成本可能差别很大。

其他

结语

  软件开发的流程很长,但是关键的节点往往都是在前期的需求和设计阶段,毕竟这些都是在项目初期决定着项目未来方向的重要事项。工程师的价值不仅仅在于编码实现,更应该在于设计和分析。想清楚再做,往往可以避免很多无用的体力开发工作量。