编码前3000问


TIP

当我们接到产品的需求的时候,别着急马上投入开发,先要了解需求的来龙去脉,多思考,尽可能将里面潜在的坑挖出来,这样上线后才会更好的满足需求,代码的扩展性、代码生命周期才会更长。


下面简单列了一些应该思考的问题:

  • 多去了解业务功能背后的想法,也许产品只是口渴了而不是真的想喝牛奶,技术同学可以从技术角度给产品同学一些启发,最终大家达成新的业务共识。

    一名优秀的工程师至少可以抵半个产品经理!

  • 新功能会不会对历史业务产生影响?如果会的话,要把影响的范围尽可能全的罗列出来,产品和技术共同探讨老业务的兼容问题

  • 如果涉及底层老的数据库表重构,要考虑新、老数据如何平稳迁移,不影响线上用户的正常访问

  • 是否存在并发,如何保证数据质量?要采用什么锁机制?

  • 做好概要设计方案、详情设计方案,并组织所有相关人员参加评审,如果涉及数据库变动,最好叫上DBA。做方案尽量多想一想,如果担心老业务吃不透,可以叫上一些老员工,先整体再细节再整体,做到有点有面,一定要以全局性视野对待项目,否则很容易陷入误区。

  • 容量规划。新功能上线后,数据量有多大?后续每日预估新增多少数据?采用什么形式的存储?是关系型数据库(如mysql)? 要不要分库分表?还是采用Nosql存储?

  • 数据是否存在冷数据、热数据之分(例如微博),是否要分开存储?

  • 尽可能采用服务化形式,但是抽象到何种程度,要视具体的业务而定,尽量朝着高内聚、低耦合设计原则。

    • 集中式调用改为HSF分布式远程调用,走的网络调用。为了提高性能,封装client二方包,通过xml bean配置控制逻辑,先从tair中查询,然后再走远程调用。
    • 如果有多处地方代码用到同样的模型数据,最好能过上下文的方式传递,避免每次用到都走接口查询
  • 模块化、组件化,具备乐高积木的特性

  • 多使用一些设计模式,提升系统的可扩展性

  • 尽量往平台方向思考,但要注意控制成本,即便一期做不到大而全,但一定要留好扩展,便于后续的不断迭代。

  • 如果是新应用,另起炉灶,要做好技术选型,最好选一些主流技术框架,切勿凭个人喜好,最后搞成百花齐放,后面的维护成本极高

    统一、标准化是一个亘古不变的话题,这一点非常重要

  • 如果是跨部门跨团队合作,需要提前约定好交互方式,联调时间,并要想一想,如果一方挂了,另一方如何做才能将影响降到最小。

  • 对于很多技术改造,可能会配置开关,做好开关两面的测试工作,必要时可以紧急切换开关降低影响

  • 接口响应时间。是否需要引入缓存,缓存的数据如何维护?数据预热、数据有效期,空间不足、缓存的命中率怎么样?

  • 接口的最大并发量,需要做性能压测,了解系统能支撑的上限,便于大促活动时机器扩容

  • 接口的容错性,如果出现意外情况时,尽量保住核心业务,不受边缘业务或非核心接口的影响

  • 有条件的话,做好接口的流量控制,配置阈值,超过预设值能自我保护,并有对应的业务提示。

  • 做好单元测试、项目代码 code review

  • 发布时,要提前准备发布计划,以及回滚计划