正儿八经 - 资深Java/React工程师

发篇文章感慨一下，从去年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（延后）

部署方案推敲以及评审，最好有PlanB。

确认部署方案，相关人员和部门配合，进行演练

记录部署问题，优化部署方案。

现场部署，做好问题记录，拿回公司做分析和优化。

一定要考虑客户的生产环境，公司做好随时支援现场的准备。

公司组织了一次敏捷得自动化测试，先做个课堂笔记，不久后公司会推自动化测试，到时候根据实践，再具体聊聊。

塔克曼模型

需求很多时候其实是在抢占资源。

持续集成平台搭建

• Jenkins 服务器搭建
• Gitlab 平台搭建并且与 Jenkins 整合
• 用 Git 进行版本控制的策略
• 自动化单元测试

团队压力大-解决方法

• 需求整流
• 团队从止血到造血
• 形成业务版本节奏、和团队交付节奏

代码质量保证手段的建立

• Sonar Qube 平台搭建与培训
• 代码评审制度建立

实例化需求

• 用户故事和验收条件的编写规范
• 采用实例化需求的方式来梳理需求
• 采用 Cucumber 编写自动化验收测试
• 采用 Selenium 驱动用户界面测试

实际迭代工作中的团队协作

• 度量
• 测试用例可追溯性
• 缺陷周期时间
• 缺陷泄漏率
• 测试覆盖率
• 绩效考评

单元测试

Robot Framework

工具

现公司推的工具是Katalon，写Xpath可以用java等语言写。

前端自动化测试：

1. 用ID这类唯一性的属性标识元素，使测试用例能更少的维护，只要id在元素结构不发生大的变化都能继续用。
2. 业务代码加ID，通用组件加ID，根据唯一标识写Xpath

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

1.以用户为中心
2.玩者之心
3.”瘦身运动”

优秀程序员四大修为

1.坚韧不拔
2.知识全面
3.完美主义
4.团结协作