正儿八经

产品1.1时，有较大需求的调整，映射到代码则意味着很多功能需要改造或者新增，此时才发现前期由于只求快，代码的可维护性太差，导致要改造模块功能太麻烦，所以就想着边改造边对代码进行重构，一步步提升性能和可维护性。

这个过程我顺便用Lighthouse跑了一下我们的页面，结果挺崩溃的。

我相当不能接受这个结果，遂列出了优化行动项

1. 深入学习React
   1. 官网再详细看一遍
   2. 极客时间上React学完
   3. medium.com上找对应的React、Redux文章
2. 尽可能少的渲染
   1. 掌握react的条件渲染规则
   2. 辨识什么情况下用Redux
   3. 父子组件、公共组件的定义和搭配
3. code review
   1. 代码逻辑
   2. 代码可维护性
   3. 渲染次数
   4. 第三方组件风险

React的条件渲染

官方的文章说的很详细，我很舒服。

https://reactjs.org/docs/reconciliation.html

这篇文章虽然老了点但是讲的通俗易懂，编于更深入的理解React的Reconciliation

https://tylermcginnis.com/react-elements-vs-react-components/

然后我们再谈怎么阻止多余的渲染

官方是这么说的：

Preventing Component from Rendering
In rare cases you might want a component to hide itself even though it was rendered by another component. To do this return null instead of its render output.

所以最简单的方式就是当不需要某个模块输出是那就return null，从而避免渲染;

因为我们是React+Redux，梳理代码后得出如下有效技巧：

1. 子组件添加state判断
2. 合理记录state用于条件判断是否需要渲染
3. 为元素设置key，选择不会动态变化得作为key，比如id之类的，杜绝使用index
4. 必要的时候设置shouldComponentUpdate
5. 卸载组件后记住重置状态
6. 利用devtool调试并提升代码性能

参考：

背景

产线当前在代码库管理遇到了如下挑战：

1. 职责权限不明确，关键操作未收口，分支管理效率不理想。
2. 多功能同时开发时，有功能之间互相Block、提测受影响、新分支建立困难的问题。
3. 无法应对后续应对多客户定制化开发场景的需要。
4. 测试团队人力紧张。

针对以上问题，本模型在旧模型的基础上进行改造，做出以下改变：

1. 分支和tag建立收口到专人负责，不用再互相等待。
2. 多feature并行开发测试，减少开发阶段的耦合。
3. 设立定制化feature机制应对后期多客户的场景。
4. 功能测试收束至develop分支进行。

实操

搬运一下我们团队的分支管理办法，大体的思路还是遵循git flow的规范

develop和release

当数个feature开发并提测后，进入多feature集成测试阶段。在develop分支进行多feature集成测试，完成后转入实验局测试。完成实验局阶段后，产品团队决定发版，这时从develop拉出release分支并根据版本号命名。此时会做最终的功能集成测试和回归测试，验证功能间是否有冲突导致的BUG和遗漏BUG，测试完成后合并至master和develop分支。

• 步骤1

  当新工程建立时，配置管理员从master分支拉出develop分支，设置保护权限，关闭develop分支所有人员提交代码权限，完成后邮件通知全体研发。

• 步骤2

  当功能提测后，研发经理将feature分支合并至develop分支。若某feature分支未成功提测，则略过该分支。当全部feature分支合并完毕后开放develop权限。

  每次测试部署时，由配置管理员建立tag，然后根据tag部署。

• 步骤3

  重复BUG修复过程直至符合发布要求。

• 步骤4

  当多feature集成测试阶段结束，配置管理员邮件通知全员即将锁定的分支，然后设置develop保护权限，建立tag进行实验局部署。

• 步骤5

  实验局阶段将对bug进行整理，非block级bug将在后续feature中进行规划和修改。

  注意事项：block级bug将视紧急程度开放权限给指定人员

• 步骤6

  当产品团队确定发版，配置管理员从develop分支拉出release分支，邮件通知全员。

• 步骤7

  集成测试部署时，配置管理员邮件通知全员即将锁定的分支，然后设置release保护权限，锁定release权限。（设置锁定的目的是防止转测阶段有人提交代码出现BUG，导致tag不可用）

• 步骤8

  配置管理员在release上打测试tag，然后解除锁定，邮件通知全员。

  研发下载release代码，准备修改bug。

  测试经理基于测试tag，启动集成测试流程。

  研发修复BUG并提交至release分支。

  步骤7重复多次直到符合发布要求

  角色	职责	通知机制
  研发经理	feature分支向develop分支合并 release分支向master分支合并 release分支向develop分支合并	feature分支的合并需要通知配置管理和Scrum Master release分支的合并需要通知配置管理
  配置管理	develop分支的建立 release分支的建立、tag建立、锁定、删除 master分支的tag建立 feature分支的建立、tag建立、锁定、删除	develop分支建立需要邮件通知全体人员 release分支的tag建立需要通知测试，release分支的建立、锁定、解锁需要邮件通知全体人员 master分支的tag建立需要通知负责安装包的研发人员 feature分支的tag建立需要通知测试， feature分支的建立、锁定、删除需要通知相关研发人员
  研发	开发、bugfix、安装包生成
  测试经理	release分支的测试、部署 feature分支的测试、部署 develop分支的测试、部署	feature分支验收测试和多feature集成测试结果需要邮件通知对应研发和研发经理

hotfix分支场景

hotfix分支用于产品稳定版及现场问题的修正。当一线端反馈了BUG并且判定需要作为hotfix修复时，从master拉出hotfix分支。分支修复完成后，重新合并入master和develop分支。若hotfix可能影响定制化feature的场景，由ScrumMaster判断是否需要进行合入。

• 步骤1

  当master发布完成后，当有现场问题需要修正时，配置管理员从master的发布tag拉hotfix分支，邮件通知全员。

  研发从hotfix分支下载代码，修改缺陷。

  研发在实验局（建议）或专用环境验证缺陷是否修改完成。

  研发将修改提交，然后推送到hotfix。

  研发修改故障单状态，提交测试。

• 步骤2

  在hotfix整体送测日，配置管理员锁定hotfix权限。

  配置管理员在hotfix上打转测tag ，邮件通知全员。

  测试经理基于转测试tag，启动回归测试流程。

  如果回归测试不通过，配置管理员开放hotfix权限，重复步骤2直到回归测试通过。

• 步骤3

  回归测试通过，测试经理确认基于hotfix的哪个tag发布，邮件通知全员。

  执行步骤4、5、6，配置管理确定步骤完成后删除分支

• 步骤4

  研发经理基于hotfix的发布tag，向master合并，完成后通知配置管理员。

  配置管理员确认后，给master打发布tag，转升级包生成流程。

• 步骤5

  研发经理基于hotfix的发布tag向develop合并，完成后通知配置管理员。

• 步骤6

  配置管理员通知研发判断hotfix是否影响定制化分支，若影响，则通知研发经理基于hotfix的发布tag向定制化feature合并，完成后通知配置管理员和Scrum Master。

feature分支场景

feature分支用于进行新功能开发和上个阶段实验局的缺陷修复。产线管理团队需要规划好功能的相关性和相互依赖，避免把相互依赖的功能放到不同的feature中去。在feature规划完成后，需要建立分支，并在feature分支上完成工程开发、提测阶段。提测成功后，feature分支将被合并至develop分支。

多个feature分支将在develop进行合并测试，若测试前有feature不满足提测条件，为了不影响其它feature的发布，可以将这个分支延迟合并。

注意事项：common包等不参与部署过程的公共模块，在产线管理团队规划时可采用其它的分支管理策略，例如多个虚拟团队公用一个feature分支。

• 步骤1

  当需求确定时，研发经理确定feature规划。feature规划一般根据敏捷小组进行，也会受到功能关联性的影响。feature规划确定后需要邮件通知研发小组和配置管理员。

• 步骤2

  Scrum Master邮件发起feature分支建立申请，然后配置管理员从develop分支拉出feature分支，通知小组成员和研发经理。研发人员开始功能开发。

• 步骤3

  准备提测，配置管理员锁定feature分支，通知小组成员、测试经理和研发经理。研发部署锁定的feature进行提测，不论提测通过或未通过，Scrum Master都解除分支锁定，通知小组成员和研发经理。

• 步骤4

  若提测失败，配置管理员重新打开分支权限。

• 步骤5

  研发继续在feature分支进行bugfix。当bugfix完成后，配置管理员重新锁定分支。

• 步骤6

  提测通过，研发经理merge分支至develop。确定merge成功后，删除feature分支，通知小组成员和配置管理员。

• 步骤7

  当第二个feature或者后续feature需要提测时，需要先从develop反向合并然后进行检查，该步骤是为了防止代码冲突或者功能被覆盖。

注意事项：若合并分支时发现基础代码有冲突，研发需要给测试团队提供冲突列表，帮助测试团队着重验证冲突功能。

定制化feature分支场景

当存在定制化需求时，需要建立定制化feature分支。该分支用于定制化客户的功能开发、测试、打包等。在定制化开发过程中，若有影响该分支的release和hotfix出现，则需要合入定制化feature分支。

• 步骤1

  定制化需求确定，配置管理员决定从哪个tag创建定制化feature分支。

• 步骤2

  配置管理员从develop分支拉出定制化feature分支，通知相关小组成员和研发经理。

• 步骤3

  当有release分支发布时，配置管理员决定是否合并至定制化feature分支，然后通知研发经理。

  研发经理从release分支合并代码至定制化feature分支。

• 步骤4

  当有hotfix分支发布时，配置管理员决定是否合并至定制化feature分支，然后通知研发经理。

  研发经理从hotfix分支发布tag合并代码至定制化feature分支。

• 步骤5

  准备提测，配置管理员锁定定制化feature分支，通知小组成员和测试经理。

• 步骤6

  研发部署锁定的定制化feature进行提测，提测未通过，配置管理员解除分支锁定，通知小组成员。

• 步骤7

  研发继续在定制化feature分支进行bugfix。当bugfix完成后，配置管理员重新锁定分支并且提测，通知小组成员、测试经理。

• 步骤6

  提测通过，配置管理员对定制化feature分支建立tag，转安装包流程。

​

感谢：

前几天，组织上让我参加了一下咱们产品系统架构评估方面的一个会议，虽然内容较少但是我受益颇多。主持人是刚进入没多久的架构师，议题是现系统架构中一个很大的问题：现有架构（没做集群，因为大多数情况下客户现场只会给到2台服务器）吃不下每秒15000条syslog（网络交易日志），问题在于我们加的中间件kafka。

所以最终议题为：什么时候需要中间件—即为什么我们要拿掉kafka。

架构师抛了这几个问题：

1. 解耦 怎么解？

   比如 redis 用于做数据的交换，这个数据是不能丢的。

   比如kafka，不保证时间，不保证顺序性。。。

2. 如果去掉这个中间层（件）会怎样？

特别是第二个问题，要随时问自己，如果去掉了会怎样？别盲目解读在我们领域，不是什么是加一层不能解决的这句话。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

发篇文章感慨一下，从去年4、5月份开始，产品线正式成立（刨去mvp时间），到现在10个多月，从0到1，经历了太多。两地跑，累计飞了8万多公里，150多个小时。经济舱你懂的，真的是坐飞机都坐吐那种…..

从0开始建立产品线团队，现在产品线大大小小五个团队：产线组、平台组、测试组、产品组、架构组以及管理团队。团队已经相对完善。

从0开始确立产品目标、产品受众、产品价值，产品版本从0.1=>0.2=>0.3=>0.3.3=>1.0=>1.1。产品的roadmap已经清晰。

当然这段过程走过来，发现了一些需要提升的地方，为了让产线更加阳光灿烂。

年前大家做了下总结，确定了一下2019年的节奏。

1. 严格按照产品roadmap进行产品的迭代。力保核心功能。
2. 产品需求定义需更加清晰和严谨，必须有功能优先级，如果遇到无法自圆其说或者技术投入和产出存在较大差距的，应根据评估情况，决定做不做（由于产品上线的客户不是很多，对于某些需求不是很确定其价值，所以确立了这条规则）。功能不是越多越好。
3. 技术选型的出口人只能是平台组负责人，平台负责人对技术选型负全责。
4. 现有技术架构的优化、技术团队的工作流程优化、文档管理等由架构组负责，负责人为业务架构师。
5. 产线组、平台组、测试组三个组合并进行重新（虚拟）划分，划分为虚拟团队的形式（业务功能小组，非功能需求小组、现场支持和研发目标承接小组）。每个组暂由Scrum Master负责日常工作管理。

领导说了团队一直在用敏捷的方式再跑，但是还不够特别敏捷，今年会邀请Scrum中文网的创建人来继续对团队进行敏捷训练。找到适合团队的小步快跑方式。

一个团队是否有活力或者是否有能力，我觉得就是看团队目标是否对齐、管理团队是否足够开放、看团队是不是能自省、是否能自驱动、是否有立规矩。

2019 会怎样谁知道呢？

特别说明

虚拟团队为了解决什么问题？

1. 运转效率提升。围绕不同的目标，把相关的各职能的人员放到一个团队，解决大家之前反馈的沟通决策链过长效率低，团队优化跨组织推动麻烦等问题。
   

2. 保障非功能需求等长期目标。按照目标拆分团队，保障纳入产线规划的技术规划，持续有人去做。
   

虚拟团队的拆分原则是什么？

根据产线规划目标，按照目标的耦合程度，把目标做拆分，由不同的小组去承接这些目标。根据各组的目标和个人发展诉求相结合，把不同的同事放在不同的小组。不同的周期，小组的组成会有适度调整

都说了虚拟团队的设立是为了提升运转效率和更加敏捷的自优化，那么哪些事情我们可以自己做决定？

一句话：不涉及约定目标定义调整、目标优先级调整、周目标是否能达成的事项，团队都可以先决定，再做向上和左右的同步。

上周五产线领导派了一个活，合并前端和后端rest服务的代码，release合到develop。其实是一个很简单很日常的工作，但是因为种种原因，现在的版本周期过长，导致新增和修改的代码很多（特别是前端一堆的css、less、jsx、js….）。所以你知道我心中有多少只草泥马了。

这个时候需要的是冷静，蛋定。找个本子合一支笔，列清楚怎么做这件事情，一定要花时间考虑清楚再下手。

行动清单

1. 摸清楚分支情况，看看改动到底有多大，根据摸排的情况，判断是否需要上升到领导，因为如果动作太大势必会对团队的一些代码方面的操作有影响，需要领导提供协助，让团队配合合理解。

2. 把涉及到修改人都和其确认一下，代码改动的分支以及模块，看是否与自己的理解存在误差，及时修正误差。

3. 借助命令（git log、git diff、git show…）以及工具（meld）对代码进行比对合并，设计面广最好不要直接往develop上合，先拉一个本地分支往上合，合完之后，验证通过再往develop合并。

4. 合并之前，明确通知合并开始的时间点，并告知团队此时间段内不要再往分支上提交代码。

5. 合并代码的时候手别抖，心别慌，扎稳马步，看清楚再合并，其实也不怕，因为你是单独拉的分支，哪怕整坏了也无所谓。所以就跟开车一样，胆大心细。

6. 合并完之后，本地测试是否功能有问题，一定要测。

合并代码有个坑，在于自动合并，它往往会给人错觉表示这块代码或者这几个文件时没问题的，但是很多时候往往是有问题，因为git并不知道这几个文件是否存在因果联系，这样就往往容易漏掉。我就遇到了这个问题，合并代码之后哪儿都ok就是一直提示license有问题，几个人轮番查了几波，排除了可能的原因，最终就落到了代码合并上，猜测是代码合并造成的，所以就查代码，最后发现确实是权限过滤的url那儿没有添加上license相关的url，导致license的url每次都被拦截了。

小结

干越复杂越麻烦的事，越不能心慌，理清思路，列出行动项，一个个啃掉。

最近前后端都在写，而且相对来说前端写的多一些，因为领导说了，咱们这条产线实行前后端分离策略，但是团队里不再招专业前端，那xxx你先上，你不是常说你是一块砖吗，哪里需要哪里搬。是的，xxx就是我，所以朋友们在公司切记谨言慎行。当然主要还是我觉得了解下前端还是可以的（但是打死不写css）。

所以我就从一个后端干到了前端，当然团队里肯定是有专业得前端的，不过因为咱们事业部有几条产线，所以资源稍有紧张，给到咱们产线就两个前端，有一个只会css，css肯定得有得，不然你想想啊，就算领导放心让你写css，你也肝颤啊。so，我就从产品mvp开始到正式产品立项，就主要精力在前端。

一入前端深似海啊

前段的东西太多，而且层出不穷。抵御诱惑的最好办法是什么？我觉得是先仔细想想需不需它，当不确定时，先放着不着急做决定，只要坚定自己所要的东西，什么诱惑对你都是过眼云烟。

脚手架的选择就出现了两派，一派以我为首，崇尚拿来即用避免重复造轮子，一派以专业前端同学为首，崇尚自己搭一套脚手架。具体就不细说，反正双方谁也说服不了谁。最终领导说了，谁是主要负责人谁说了算，当然专业前端是主要负责人，所以最终就决定自己搭建脚手架。当然这个过程是很痛苦的，时间也很长…曾今一度放弃这个方案，但是想着已经花了那么多精力了，就咬咬牙继续整了。最终大概前前后后花了3-4个月时间才算稳定了，当然这个过程编码还是断断继续在进行的。

所以这块主要说下webpack，现在的前端打包工具我估计没谁说不用webpack吧，webpack教程我就不恬不知耻的讲了，网上一堆。不过我还是觉得大家尽量系统的看教程，别东一块西一块凑。

脚手架

对于webpack打包工具，涉及到性能，我认为的三个关注点：

1. 包大小

   主要是从压缩、去重（注意依赖公共部分单独打包）方面考虑，能从现有的配置解决的就不要引入新的插件，用了插件需要在官方了解每个数的意义。

   项目中：js压缩用的UglifyJsPlugin，第三方库处理我们用的是CommonsChunkPlugin（有人说DllPlugin更好用），后面会抽时间试下。

2. 包拆分

   打包时，注意包的拆分，按模块按页面，可以分得细一些，让页面按需加载…，别都打到一个包里，一开始我们就遇到这个问题，打开一个页面光渲染所需的内容就要下载半天。

3. 打包速度

   能用缓存的用缓存，不需要转译的就别转译，Happypack能多进程执行打包，会快点

   有两个很漂亮的可视化插件，*JARVIS、webpack-bundle-analyzer ，对于优化打包很有用。*

小结

• 前端选型一定要适合团队和自己业务发展的。其它人觉得好用，你得看看其它人的场景和公司的体量。

• 没有特别与众不同的要求或者很多的个性化，避免重复造轮子。

• 当资源有限的时候，先保证功能性，再保证性能，但是性能优化一定是一个长期的非功能需求。

技术栈

没什么好说的……，都是主流的

嗯…..19年过了两个月了是时候开始做个19的规划了，为什么一开始没做，因为我相当不专业的忘了…看斗自己都老火，这就体现了我和专业人士的区别，还是比较业余，谁叫我放荡不羁爱浪，需要自我克制一下，所以19规划还是得做。

ok 2019年我需要这么规划一下

知识丰富

时间分布：地铁上、睡前半小时、上班的午间休息、周末每天2-3小时

1. 一个季度看2-3本书，根据书的厚薄进行动态调整，内容：技术类（谁叫我时程序员呢）、提升认知类（说起高大上，就是看一些扫盲的）、自个儿国家人文类（你会发现中国人的牛气冲天以及中国文化的博大精深，绝对时认真的）、心理学类（看看自己内心到底有多么黑暗）

2. 几个知识付费的课程学完，花钱买教训（知识）。

3. 国外的几个网站多逛逛，看英文文档。好歹对得起自己高中唯一一次英文及格的辉煌（而且是在高考）。

提升影响力

1. 用心经营自己的社交圈，别让自己太独孤求败。

2. 让领导清楚自己在干什么，多和领导进行沟通。

3. 把团队内分享这事做得更好

继续坚持

目标笔记小程序：

1. 小目标定好，每天上班路上做好目标规划以及时间规划。下班回家睡觉前想一想然后回顾一下。

2. 大目标（按月、年）定好，每天看一遍，为其调整为其努力。

番茄土豆APP：

按照番茄土豆的时间节奏进行，注意身体，保持高效。

变得完美

1. 为成为完美的男人而努力，经常对着镜子反思自己的缺点，把缺点改的不那么缺。

2. 养成早起早睡的习惯，嗯 现在已经比之前提前了一个小时起床，赞一个。要继续加油。

3. 雾霾散去，锻炼身体，一周2-3次，一次20-30分钟，根据自己老的程度，动态调整。

4. 治理拖延症（指生活上的，工作上我从不拖延！！！），想到事情了马上做，听到指令后马上做（这条主要是针对媳妇儿的教导）

休闲清单

时间分布：晚上9点半之前、周末3-4小时

1. 除了学习和工作时间外的休息时间（作为凡人，需要偷懒放松），可供选择的休闲方式：

2. 看电影（嗯，一个月怎么滴也得一场）

3. 网络视频（Running Man、圆桌派、这就是街舞）

4. 听音乐（各种直击灵魂和耳朵的音乐）

5. 偶然性看小说（如果阴差阳错发现有喜欢的，就看一部，下班地铁上会看）

心愿清单

1. 至少给媳妇儿准备一个惊喜，希望她每天都高高兴兴的。

2. 带老婆孩子去海边玩几天（国外）。

3. 双方父母做一个全面体检，根据身体情况配置上对应的保险。

4. 2-3次自驾游。

最近报了一个课程-告别低效，人人必备的聪明工作法,少数派出品。

其实很早以前就接触了相关的内容，还买了几本书，买了几个工具，其中有本书对我还是比较有用的，这本书更多强调的是工具，是术的方面，让我学会了用工具做时间管理。比如番茄钟、滴答清单等。

之所以再报这门课程是为因为，之前的时间管理训练做的不是很好，没有坚持下来，国外传来的四象限法、GTD、SMART、精力管理…这些很多地方出现的词语，主要还是讲思路方面的问题，对于我来说现在可能能真正落地的更合适，而这门课程里面的某些内容就是我需要的，同时想要通过这门课程让自己能更加重视提升工作效率的重要性，能提升一点也是好的。

文件管理

这个应该是我做的最差的，文件都是摆满桌面，一通找，不过后来我找到了两个工具，超级超级超级好用，Everything+Wox 这两个东西真的是帮了我的大忙，让我不至于老是风中凌乱。我是觉得这两个就已经基本上解决了我的诉求，让我能快速的找到我的文件，不过稍有遗憾的是你的大概记得住你的文件名或者文件夹名才能有用，所以做好文件的管理是基础。课程中讲了一个工具Droplt，亲测好用，能根据我的规则帮我进行文件的分门别类。你也能设置自动分类。

高效获取信息

• 信息源的质量
  • 信息源的半衰期（信息的有效时间）、信息源的稀缺程度（价值高低），通常是半衰期越长，稀缺程度越高。

• 掌握信息获取的主动权
  • 获取信息尽量是通过pull而不是push（推送，通常不是有价值的信息），pull就表示是自己主动去寻找的信息
  • 避免回声效应，即老是停留在自己的认知层面，屏蔽了外面的信息。

浪起来的我-效率提升工具

我这儿就笼统的分享一下我为了提升效率而使用的一套工具，有些花钱有些用的免费的，这儿说的提升效率包括工作、学习、生活上的。

工作节奏：滴答清单付费版、ToDoist、番茄土豆

文件搜索：Everything、Wox

学习：记录、收藏：印象笔记付费版，Pocket（稍后阅读）

回顾：目标笔记

适合自己的才是最好的，你觉得用的爽然后确实有改善那就行了。

学习提升方法论

在学习记忆中始终保持必要难度是必要的，这样才能训练自己的记忆能力。

提升知识记忆的内化效果方法

1.复述意识=>复述学习的内容，比如用康奈尔笔记法做知识回顾

2.间隔学习，知识交叉，不能长时间一直学习某个知识，因为这样就没有保证记忆的难度。

3.费曼学习法=>把学到的知识讲给非专业人士听，用于检测自身是否对知识理解不到位，然后再反过头来深化

记忆方法-记忆宫殿

即把需要记忆的内容，抽象成图画，最终转化为情景式的关联记忆，因为人的空间记忆能力是超强的，所以用大脑的这块区域来记忆，坚持训练，肯定对记忆力有提升。我小试了几天，发现通过想象画面来记忆真的比死记硬背更有效且更有劲。

课程还提到了一个工具：anki，加强记忆力的工具。

实操

1. 邮件FAST法则

   

2. 邮件ABC法则

2. 思维导图做会议记录

名词解释

任务管理LTF体系：List（列表，行动项） Tag（标签，标识） Filter（过滤器，搜索）
邮件FAST法则：Fliter（过滤） Archive（归档） Transfer（流转） Snooze（延后）