标签：需求 架构 1.2 项目 可以 系统 测试 设计 心得

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、测试再一次验收。

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

标签：需求,架构,1.2,项目,可以,系统,测试,设计,心得
来源： https://www.cnblogs.com/Leo_wl/p/16061187.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。