关于盘点和总结的那点事儿

本月的功能在踉跄中勉强上线了，这个月有实验的味道，有摸索的代价，有分工和衔接上的问题，有技术储备方面的不足，有业务梳理方面的欠缺，也有个人能力和意识上的不足，梳理整个开发流程，目前存在的几大问题：

一、代码质量问题：

描述分析

1.性能层面：

　　从综合维度看，代码质量好坏取决于开发人员整体的编程经验：比如操作系统，设计模式，数据结构和算法，网络原理，数据库，前端等等因素。

　　就目前系统整体上看，性能可能会出现的地方，从优先级权重来排列，主要集中在：

• 数据库优化技术偏弱。

• 不看执行计划
• 对索引的理解比较浅，没用好索引
• SQL优化经验薄弱
• 数据库查询和脚本问题。
  • 关联查询
  • 索引缺失
  • 请求频率

• 减少请求次数。

• 减少接口对数据库请求
• 减少前端图片请求
• 减少前端css/js请求

• 善用缓存

• 静态文件CDN缓存
• 基础数据共享缓存

• 内容压缩

• 图片压缩
• 请求文件压缩
• 富文本内容压缩

• 主站可能出现的高并发查询。
• 网络带宽延迟。

　　2.规范层面

• 命名随意性

　　有些规范是可以文档化的。比如全局变量全部大写，局部变量驼峰命名，文件前后缀命名等等比较容易约定俗成；

　　有些规范无法约定的。比如作业调度有些人命名jobs，有些人命名schedule。如果要想规范必须把业务考虑进来。如果只是想表达定时作业，属于技术术语job可能比较合适；如果是业务层面的任务调度可能schedule比较合适。也就是说如果碰到模棱两可的命名的时候，需要增加考虑因子，通过扩大“视野”来更精确的命名它。

　　如果碰到一个问题始终不清楚要如何命名的时候，首先应该要反省的是自己对业务熟悉不熟悉，对系统整体熟悉不熟悉。如果实在无法确认，最好请教和沟通，一般都能做好命名。说不定能发现一些自己无知的内容。

　　如果真的觉得用名字无法描述清楚，言不尽意，模棱两可，那就增加代码注释。代码注释的前提是自解释，实在无法达意才去做注释，因为注释太多也是有成本的。

一致性优先，也就是说一致性是可读性的基础，否则数据库一种命名，业务代码一种命名就是错乱了。比如公司叫Company，但是业务命名叫Supplier，会员叫Member。这里会出现这种不一致的命名，主要原因还是对业务领域不清楚导致的。

　　所以在底层命名非常关键，比如数据模型的表和字段的命名，如果底层命名错误，从上下往上只能将错就错，让人改也不是，不改也不是。

　　总之，代码命名和给孩子取名字一样，其实都是需要慎之又慎，不可随意叫个阿猫阿狗什么的。这里有个原则就是要遵循：简单，可读，统一和优雅的原则，当然优雅是最高的要求。

• 规范不是万能

　　规范仅仅写个规范文档是很不够的，写好并持续完善规范文档只是万里长征第一步。只有规范文档，没有落地检查，文档也会变成一纸空文。

　　定个原则是比较容易和简单的，如果细细追究，里面有很多坑。

　　首先大家对简单，可读，统一的理解各不相同，最后生成的代码必然是千人前面，理论上需要对业务的深入了解，需要有很好的英文功底，同时在整体上要做经常性的检查和复盘。

　　但是引入代码审查又需要成本，假设一个月审查一次，那么对每个成员编写的一个月的代码，从月初到月底进行一番梳理和纠正，没有1-2天是无法完成的。

　　所以审查是有成本的，要不要审查呢？

　　权衡利弊，必须要审查，而且要按照规范，引入严苛的代码审查机制，每个月做一次代码规范和代码质量的检查和考核。

　　为什么要严苛来做代码审核呢？因为代码质量反应了我们的产品质量，代码的好坏决定了未来运维的成本，技术债务的危害怎么形容都不为过，轻则系统局部异常，中等的会导致修改困难，严重的推翻重来。

　　如果因为进度一时妥协，回头又忘记了修改，中间又出现人员变动，那么这份代码的后患是无穷的，因为没有规范的代码，对交接人来说从心态上是本能反抗的，但是又不得不改，于是就一通乱改，能贴膏药就贴膏药，能运行就可以，管他规范不规范。这样导致的结果是对规范来说，只能从不规范走向更加不规范，最后走向无法维护。

落地解决：

　　1.性能层面：

• 任务分解和文档化

磨刀不负砍柴功，开发之前进行技术评估，识别出其中技术复杂度和难度，及早发现性能方面可能会产生的问题。

把评估的内容逐条分解罗列并做文档化，对容易的功能尽量不要有心态上的藐视。

遇到没有把握的技术问题，及时的拿出来讨论，不要觉得不好意思。

• 数据库层面：
• 通过个人持续学习和提高数据库优化技能：
• 学会查看执行计划
• 了解索引的底层原理
• 深入理解关联查询的底层原理
• 主站需要生成静态页面进行缓存。
• 增加页面静态缓存技术
• 增加CDN技术
• 多研究学习和参考别人写的代码，做好底层的技术沉淀，平时多练练内功。
• 通过针对性内部培训来提高个人薄弱环节，让技术均衡发展，又各有特长。

　　2.规范层面：

• 编写规范的文档，并持续更新和完善
• 严格遵循规范来写代码，如果规范当中没有的，需要适当讨论并做迭代规范。
• 按照规范进行代码审查，每个开发人员都参与其中，每隔两周轮流进行代码的检查和盘点。直到团队形成默契，可以在后期适当的减少审查频率。
• 基本的规范审查并不难，比如命名，函数的长度等，只要遵循文档来做就可以了。
• 难的是对没有接触过的技术应该如何做？比如单点登录，路由规则等。
• 参与前期的需求分析，如果没有则后期自行了解，比如以询问的方式进行了解。
• 了解技术评估和技术原理。
• 查看当事人的源代码。

二、测试发布问题

描述分析：

• 周期：每个月集中到最后一周进行测试和发布时间太紧迫，如果中间缺少交互和确认，很难保证结果不偏离方向。
• 人设：测试人员对业务和测试流程缺少前置准备，包括业务的烂熟于心，测试工具和测试数据的知识储备，导致测试时候不知道如何测试，在本来时间不足的情况下，增加沟通成本。同时测试水平只停留在简单浅层的黑盒测试层面，对于深层次的问题，比如压力测试，DDos攻击，安全层面的往往就测试不到了。
• 功能测试：测试力度远远不足。原因有如下几种：
• 边测试边修改边上线，修改速度不及测试速度，导致开发紊乱。
• 前期测试重视不够，部分业务理解异常，等到测试出来，修改的周期可能会很长，这样其他积累下来的BUG处理起来就只能长时间等待了……
• 集成测试
• 功能分工导致的个人只测试和自己相关的功能，但是系统是一个整体，在测试边界处是需要双方集成测试的，比如Message的来往功能。

落地解决：

• 周期：改进交付时间，每隔两周就交付测试，增加交付频率，尽早发现和解决问题。
• 人设：
• 增加测试人员May和Kaka的前期业务培训和接受业务熟练度的考核，减少测试的遗漏。
• 增加对测试人员包括开发测试的测试技能培训，提升测试人员的测试水平。比如对测试人员来说，需要学习产品经理的思维和设计原理，增加测试人员的主动性，让测试人员能站在用户的角度来进行测试，而不是简单的鼠标点点。
• 从心态上重视测试，测试是闭环的最后一个环节，缺一不可。对测试要有敬畏感，测试并不是简单的点一点鼠标的问题，测试的水可深可浅。测试人员需要的是综合能力，测试技能怎么强调都是不为过的。
• 编写测试用例文档。测试既要有心态上的重视，也要有可落地的操作方法，而测试用例文档可以很好的指导每个测试人员进行统一测试，避免测试的遗漏和不足。
• 文档内容涵盖测试的各个维度，该文档编写人员尽量对产品的理解要达到设计人员的水平，对每个角落的测试用例要尽可能详尽。该测试用例模板必须要规范，用来指导开发和测试人员进行完整详尽的测试。
• 开发人员内测：
• 功能测试：执行交换角色测试
• 集成测试：交换角色测试，负责人集中测试。

三、开发效率问题

描述分析：

　　1.业务层面

• 业务理解不透彻导致的代码BUG，比如Message系统模块，收发人员流程无法打通；
• 对数据库模型理解偏差导致的功能BUG，例子同上；
• 开发任务分工和配合不足；
• 开发交付频率不足，导致的过程脱节和问题集中积压，最后处理缓慢和延迟；

　　2.技术层面

• 前端技术积累薄弱，遇到复杂一点的前端做起来比较耗时；
• 技术复杂度预估不足，导致的开发延迟。
• 分工导致的集成薄弱，比如集成测试，需求和开发沟通成本。

落地解决：

　　1.业务层面

• 业务培训：产品需求文档需要提前发布预热，培训后需要做业务复述，复杂的需要做详细的设计文档，直到产品经理觉得正确后再进行开发设计。
• 对于复杂功能的业务，采用专题会议的方式，反复讨论，进行头脑风暴，把业务掰开揉碎讲清楚，直到当事人能复述通过为止。针对个别复杂的业务，比如公共询盘功能，需要出详细的需求文档。

　　2.技术层面

• 前端技术难点：自研解决，实在无法解决再去考虑外包和招聘。
• 开发前需要做任务分解，识别出技术复杂度，对没有把握的技术要及早提出疑问，通过团队的力量拿出合理的解决方案。
• 功能层面，进行角色互换测试。比如Arvin测试Ive的Message模块，Ive测试Arvin的机械表单模块。

四、开发意识问题：

以下从三个方面总结一下成员开发过程中的意识问题。

• 树立严谨心态

　　对开发来说，各个环节要持有严谨和一丝不苟的态度，树立简单并不简单的意识。对于完成的功能，如果时间上允许，需要反复回头检查可能出现的问题，不要满目乐观，或者觉得某个功能很简单，要站在可能出现问题的立场上来看待正常的功能。因为我们要打造的是产品，而不是项目，不是小孩过家家的功能。

• 重构意识

　　好的代码是不断重构出来的，因为业务和需求是不断叠加的，不可能写出一成不变的代码。当业务倍增，需求变革的时候，再好的代码都会出现生锈，腐蚀和坏味道。所以在不忙的时候，需要经常性的整理自己的代码。

重构解决的是长远的质量和可维护，可扩展的根本问题。技术债务，如果不及时解决，随着时间的推进和人员变动，后续花费的成本会逐渐叠加甚至无法解决，好比盖房子，在有问题的基础上盖房子，盖得越高危险越大，到了晚期可能就只能推倒重建。

• 重视讨论

　　三个臭皮匠赛过诸葛亮，技术越讨论越进步，业务越讨论越明白。对于模棱两可或者完全不懂的问题，尽量多请教和讨论。

　　讨论的印象是最深刻的，对个人的成长和帮助也是最大的。比如对Vue的学习和上手，对数据库脚本的编写，对ES的学习和讨论等等……

　　树立不懂不丢人，不懂装懂才丢人的意识。不要忌讳或者不好意思讨论。

　　讨论讲究效率和默契。要集中时间，充分准备。 有些开发人员经常问些没头没脑的问题，既没有背景铺垫，也没有上下文，然后想一出一个问题，频繁的打断别人的思路而不自知。这种沟通是很浪费时间和成本的。