本月的功能在踉跄中勉强上线了，这个月有实验的味道，有摸索的代价，有分工和衔接上的问题，有技术储备方面的不足，有业务梳理方面的欠缺，也有我的能力和意识上的不足，梳理整个开发流程，目前存在的几大问题：
1、代码质量问题：
描述分析
1.性能层面：css
从综合维度看，代码质量好坏取决于开发人员总体的编程经验：好比操做系统，设计模式，数据结构和算法，网络原理，数据库，前端等等因素。前端
就目前系统总体上看，性能可能会出现的地方，从优先级权重来排列，主要集中在：算法
- 不看执行计划
- 对索引的理解比较浅，没用好索引
- SQL优化经验薄弱
- 数据库查询和脚本问题。
- 减小接口对数据库请求
- 减小前端图片请求
- 减小前端css/js请求
2.规范层面数据库
有些规范是能够文档化的。好比全局变量所有大写，局部变量驼峰命名，文件先后缀命名等等比较容易约定俗成；编程
有些规范没法约定的。好比做业调度有些人命名jobs，有些人命名schedule。若是要想规范必须把业务考虑进来。若是只是想表达定时做业，属于技术术语job可能比较合适；若是是业务层面的任务调度可能schedule比较合适。也就是说若是碰到模棱两可的命名的时候，须要增长考虑因子，经过扩大“视野”来更精确的命名它。设计模式
若是碰到一个问题始终不清楚要如何命名的时候，首先应该要检讨的是本身对业务熟悉不熟悉，对系统总体熟悉不熟悉。若是实在没法确认，最好请教和沟通，通常都能作好命名。说不定能发现一些本身无知的内容。缓存
若是真的以为用名字没法描述清楚，言不尽意，模棱两可，那就增长代码注释。代码注释的前提是自解释，实在没法达意才去作注释，由于注释太多也是有成本的。安全
一致性优先，也就是说一致性是可读性的基础，不然数据库一种命名，业务代码一种命名就是错乱了。好比公司叫Company，可是业务命名叫Supplier，会员叫Member。这里会出现这种不一致的命名，主要缘由仍是对业务领域不清楚致使的。网络
因此在底层命名很是关键，好比数据模型的表和字段的命名，若是底层命名错误，从上下往上只能将错就错，让人改也不是，不改也不是。数据结构
总之，代码命名和给孩子取名字同样，其实都是须要慎之又慎，不可随意叫个阿猫阿狗什么的。这里有个原则就是要遵循：简单，可读，统一和优雅的原则，固然优雅是最高的要求。
规范仅仅写个规范文档是很不够的，写好并持续完善规范文档只是万里长征第一步。只有规范文档，没有落地检查，文档也会变成一纸空文。
定个原则是比较容易和简单的，若是细细追究，里面有不少坑。
首先你们对简单，可读，统一的理解各不相同，最后生成的代码必然是千人前面，理论上须要对业务的深刻了解，须要有很好的英文功底，同时在总体上要作常常性的检查和复盘。
可是引入代码审查又须要成本，假设一个月审查一次，那么对每一个成员编写的一个月的代码，从月初到月底进行一番梳理和纠正，没有1-2天是没法完成的。
因此审查是有成本的，要不要审查呢？
权衡利弊，必需要审查，并且要按照规范，引入严苛的代码审查机制，每月作一次代码规范和代码质量的检查和考核。
为何要严苛来作代码审核呢？由于代码质量反应了咱们的产品质量，代码的好坏决定了将来运维的成本，技术债务的危害怎么形容都不为过，轻则系统局部异常，中等的会致使修改困难，严重的推翻重来。
若是由于进度一时妥协，回头又忘记了修改，中间又出现人员变更，那么这份代码的后患是无穷的，由于没有规范的代码，对交接人来讲从心态上是本能反抗的，可是又不得不改，因而就一通乱改，能贴膏药就贴膏药，能运行就能够，管他规范不规范。这样致使的结果是对规范来讲，只能从不规范走向更加不规范，最后走向没法维护。
落地解决：
1.性能层面：
磨刀不负砍柴功，开发以前进行技术评估，识别出其中技术复杂度和难度，及早发现性能方面可能会产生的问题。
把评估的内容逐条分解罗列并作文档化，对容易的功能尽可能不要有心态上的藐视。
遇到没有把握的技术问题，及时的拿出来讨论，不要以为很差意思。
- 数据库层面：
- 经过我的持续学习和提升数据库优化技能：
- 学会查看执行计划
- 了解索引的底层原理
- 深刻理解关联查询的底层原理
- 主站须要生成静态页面进行缓存。
- 多研究学习和参考别人写的代码，作好底层的技术沉淀，平时多练练内功。
- 经过针对性内部培训来提升我的薄弱环节，让技术均衡发展，又各有特长。
2.规范层面：
- 编写规范的文档，并持续更新和完善
- 严格遵循规范来写代码，若是规范当中没有的，须要适当讨论并作迭代规范。
- 按照规范进行代码审查，每一个开发人员都参与其中，每隔两周轮流进行代码的检查和盘点。直到团队造成默契，能够在后期适当的减小审查频率。
- 基本的规范审查并不难，好比命名，函数的长度等，只要遵循文档来作就能够了。
- 难的是对没有接触过的技术应该如何作？好比单点登陆，路由规则等。
- 参与前期的需求分析，若是没有则后期自行了解，好比以询问的方式进行了解。
- 了解技术评估和技术原理。
- 查看当事人的源代码。
2、测试发布问题
描述分析：
- 周期：每月集中到最后一周进行测试和发布时间太紧迫，若是中间缺乏交互和确认，很难保证结果不偏离方向。
- 人设：测试人员对业务和测试流程缺乏前置准备，包括业务的烂熟于心，测试工具和测试数据的知识储备，致使测试时候不知道如何测试，在原本时间不足的状况下，增长沟通成本。同时测试水平只停留在简单浅层的黑盒测试层面，对于深层次的问题，好比压力测试，DDos攻击，安全层面的每每就测试不到了。
- 功能测试：测试力度远远不足。缘由有以下几种：
- 边测试边修改边上线，修改速度不及测试速度，致使开发紊乱。
- 前期测试重视不够，部分业务理解异常，等到测试出来，修改的周期可能会很长，这样其余积累下来的BUG处理起来就只能长时间等待了……
- 集成测试
- 功能分工致使的我的只测试和本身相关的功能，可是系统是一个总体，在测试边界处是须要双方集成测试的，好比Message的来往功能。
落地解决：
- 周期：改进交付时间，每隔两周就交付测试，增长交付频率，尽早发现和解决问题。
- 人设：
- 增长测试人员May和Kaka的前期业务培训和接受业务熟练度的考核，减小测试的遗漏。
- 增长对测试人员包括开发测试的测试技能培训，提高测试人员的测试水平。好比对测试人员来讲，须要学习产品经理的思惟和设计原理，增长测试人员的主动性，让测试人员能站在用户的角度来进行测试，而不是简单的鼠标点点。
- 从心态上重视测试，测试是闭环的最后一个环节，缺一不可。对测试要有敬畏感，测试并非简单的点一点鼠标的问题，测试的水可深可浅。测试人员须要的是综合能力，测试技能怎么强调都是不为过的。
- 编写测试用例文档。测试既要有心态上的重视，也要有可落地的操做方法，而测试用例文档能够很好的指导每一个测试人员进行统一测试，避免测试的遗漏和不足。
- 文档内容涵盖测试的各个维度，该文档编写人员尽可能对产品的理解要达到设计人员的水平，对每一个角落的测试用例要尽量详尽。该测试用例模板必需要规范，用来指导开发和测试人员进行完整详尽的测试。
- 开发人员内测：
- 功能测试：执行交换角色测试
- 集成测试：交换角色测试，负责人集中测试。
3、开发效率问题
描述分析：
1.业务层面
- 业务理解不透彻致使的代码BUG，好比Message系统模块，收发人员流程没法打通；
- 对数据库模型理解误差致使的功能BUG，例子同上；
- 开发任务分工和配合不足；
- 开发交付频率不足，致使的过程脱节和问题集中积压，最后处理缓慢和延迟；
2.技术层面
- 前端技术积累薄弱，遇到复杂一点的前端作起来比较耗时；
- 技术复杂度预估不足，致使的开发延迟。
- 分工致使的集成薄弱，好比集成测试，需求和开发沟通成本。
落地解决：
1.业务层面
- 业务培训：产品需求文档须要提早发布预热，培训后须要作业务复述，复杂的须要作详细的设计文档，直到产品经理以为正确后再进行开发设计。
- 对于复杂功能的业务，采用专题会议的方式，反复讨论，进行头脑风暴，把业务掰开揉碎讲清楚，直到当事人能复述经过为止。针对个别复杂的业务，好比公共询盘功能，须要出详细的需求文档。
2.技术层面
- 前端技术难点：自研解决，实在没法解决再去考虑外包和招聘。
- 开发前须要作任务分解，识别出技术复杂度，对没有把握的技术要及早提出疑问，经过团队的力量拿出合理的解决方案。
- 功能层面，进行角色互换测试。好比Arvin测试Ive的Message模块，Ive测试Arvin的机械表单模块。
4、开发意识问题：
如下从三个方面总结一下成员开发过程当中的意识问题。
对开发来讲，各个环节要持有严谨和一丝不苟的态度，树立简单并不简单的意识。对于完成的功能，若是时间上容许，须要反复回头检查可能出现的问题，不要满目乐观，或者以为某个功能很简单，要站在可能出现问题的立场上来看待正常的功能。由于咱们要打造的是产品，而不是项目，不是小孩过家家的功能。
好的代码是不断重构出来的，由于业务和需求是不断叠加的，不可能写出一成不变的代码。当业务倍增，需求变革的时候，再好的代码都会出现生锈，腐蚀和坏味道。因此在不忙的时候，须要常常性的整理本身的代码。
重构解决的是长远的质量和可维护，可扩展的根本问题。技术债务，若是不及时解决，随着时间的推动和人员变更，后续花费的成本会逐渐叠加甚至没法解决，比如盖房子，在有问题的基础上盖房子，盖得越高危险越大，到了晚期可能就只能推倒重建。
三个臭皮匠胜过诸葛亮，技术越讨论越进步，业务越讨论越明白。对于模棱两可或者彻底不懂的问题，尽可能多请教和讨论。
讨论的印象是最深入的，对我的的成长和帮助也是最大的。好比对Vue的学习和上手，对数据库脚本的编写，对ES的学习和讨论等等……
树立不懂不丢人，不懂装懂才丢人的意识。不要忌讳或者很差意思讨论。
讨论讲究效率和默契。要集中时间，充分准备。 有些开发人员常常问些没头没脑的问题，既没有背景铺垫，也没有上下文，而后想一出一个问题，频繁的打断别人的思路而不自知。这种沟通是很浪费时间和成本的。
