1.1 项目设计心得

1.1.1 不要过分设计

项目因为只有一个人，所以我秉承着简单的原则，没有过多的拆分服务（紧紧只有两个），这两个服务也是根据了自己的承受能力，以及结合业务后综合得出的结论（还有很多模块，没有拿出来，比如：Id获取，用户管理等）。这样设计很好了保证后来工作不会因为模块过多带来工作混乱。

1.1.2 持续优化

在项目初，为了保证快速上线项目，代码很多都是大差不差写的，保证了业务功能的实现。但随着从开发到维护阶段，时间逐渐有一些空闲，随着新的需求到来，和原来有冲突的地方，或者涉及到新需求改动的地方就开始优化起来。比如：采用合适的设计模式，采用更优雅的设计。方法、类、参数等名称也可以修改的更优雅。注释，修改日期也可以慢慢补上，给别人看代码留下思路（防止别人骂你，哈哈）。

除了在代码层面优化，架构也是可以改进的，因为没有过分设计，涉及到的外部东西不多，我们可以根据一定的需求来调整架构。如：我在高峰压测时，调整了项目的调用方式，缩短调用链路。

随着持续优化，项目现在保证了可读性，可扩展（这个可扩展仅仅是从技术层面哈，业务层面的可扩展需要在项目设计之初就需要有考虑，虽然可以通过持续调优优化来改造，但是还是有些麻烦的）。

1.2 系统owner意识

对待系统，要有owner意识，这个不管是自己负责，还是他人负责。当然，自己负责可能就会涉及的更深。也会从以下几个方面总结一下

1.2.1 架构相关

熟悉自己系统架构和业务架构，系统架构包括部署情况，如：线上的机器数，机器类型，采用的容器等，用户从前端到后台处理完成所经历的节点。业务架构则主要体现在：业务领域，关键的职责等。熟悉这些才方便和其他系统沟通，以及业务划分等（扯皮，哈哈）。

1.2.2 系统相关

除了对自己的系统部署，架构有了解外，还需要对自己的系统能力有一定的了解，其中主要包括：上下游链路（这个关键，涉及接口或其他变动，需要通知到，否则引发一系列问题），关键接口的能力（高峰压测，防止业务量增加引发系统崩溃），中间件，配置开发等。此外，还需要对自己的系统缺陷有一定了解，在出现问题时可以有应急方案。

1.2.3 系统保障

在日常，需要对自己的系统进行巡检，可以从CPU、网络、内存、日志等多方面查看，对系统出现的问题及时进行诊断、修复，谨防在问题在客户端报出时才进行解决。除此之外，还需要对系统监控报警及时响应，查明问题原因，修复。

1.3 研发流程

有一个规范的研发流程可以省很多事，提高大家的工作效率。另外，还可以减少因需求不规范、提测延期、测试时间不够、需求增加等带来问题。

我举个例子哈。如下：

在需求确认阶段：筛选出可以做的需求，然后要求产品给出合规的原型图、并且要求团队成员与产品对需求理解达到一致。

研发前准备：确定投入资源，识别需求难点并技术选型，UI评审、测试用例评审、接口评审等。

研发阶段：代码风格统一、前后端联调，冒烟测试用例通过，CodeReview代码实现等，然后转测

SIT测试：提测后，拒绝开发环境测试、执行全量的测试用例。并且把bug提给对应的开发人员，对问题修复时间点追踪。UI可以在此阶段验收。

UAT测试：确定发布所需要的资源，准备是否充分。产品、业务、UI、测试再一次验收。

上线：日志观察，产品再次确认。可以结合灰度策略来进行线上测试。完成上线后，通知团队成员。