-
闭环思维
做事情要有始有终，体现在： 1、测试闭环，测试流程要形成一个开始和结束的范围。比如数据从录入，到中间到修改、删除，到操作后数据到回显 2、开发闭环，开发流程闭环。比如通过mock数据，减少开发、联调等阶段前后端彼此到依赖。开发阶段应该重视自测流程 3、任务分配闭环，任务下发，应量化需求，需求的结果，要有时间限制。尽量避免有任务分配，无任务反馈的情况。对任务要有反馈机制。 4、排查问题形成闭环，比如针对问题排查后，应该形成最终解决方案（以文档形式体现）。对于问题流转至后端的，要持续跟踪，记录原因、解决的方案、 解决人、解决的时间点等 -
复盘思维
培养总结的习惯。 总结经验，收获，idea等 比如，针对线上遇到等问题，进行反思： 1、基本项：什么时间出现的问题；问题的影响范围；问题出现的原因；排查的过程；如何解决的；解决人；解决时间点； 2、扩展项：是不是共性问题，有哪些时可以被其他项目借鉴的；如何避免类似情况的发生；有没有更好的解决方案； -
系统思维
学习应该，形成体系，将知识结构化。 零散的知识点，不方便记忆。应该找到规律，结构化，标准化，系统化。 对于第三方库的学习，不能只停留在对api对应用级别： 1、了解底层原理 2、社区配置（文档）；社区更新力度；问题支持力度 3、应用场景，解决的问题 4、有何利弊 5、可扩展性； 6、落地的复杂度，学习成本 -
创新思维
保持好奇心，了解行业技术最新动态，尝试在实际项目中应用。 一个问题，多套方案，养成思考最优解对思维 -
问题思维
问题无关大小，都应重视。问题小的，发生在体量大的系统上，也会产生不良的影响。 问题的出现，意味着机会，解决问题才能体现价值。 -
观察思维
了解行业的业务经营模式，分析背后盈利模式； 通过简历招聘，了解行业的需求。 1、性能； 2、可视化 3、组件化 4、技术栈 通过面试题，了解行业的关注点，技术方面应该优先掌握的技术点 参加活动分享，了解行业的趋势、体系建设等 -
故事思维
如何将自己的价值，更好的展示给别人。 只会闷头做事的人，就是个苦力。 -
任何一个有一定复杂度、会持续增长的应用最重视的，其实并不是开发速度，而是可维护性和可扩展性。
[](https://mp.weixin.qq.com/s?__biz=MzIyMDkwODczNw==&mid=2247484581&idx=1&sn=d8cd6d87e71c0f31db2ad6e3e665dbf6&chksm=97c5990ba0b2101d26cccf583608b5ad556c193123f9e30001000c809a8f368ba69e122968c1&scene=21#wechat_redirect)
跟对老板比做对事情重要：好的老板愿意去培养下属，指出问题。有能力的老板才能给下属更高的成长空间。
不用试图耍心机或者邀功、抢功：这些伎俩只能欺骗你自己，老板视角看的一清二楚。
认真记下老板的建议，多多反思：几乎所有人接受到批评，第一反应都是去反驳。但在职场上，老板一般是不会害你的（因为有晋升等利益相关）。
这可能就是老板比你更懂你的地方，他能从一个更有经验的外部视角来看你的方案你做的事情。
遇到“不公”先想想自己：机会是有限的，为什么老板会把晋升机会、好的工作机会给某个人而不是你？先不要抱怨不公，想想为什么。
抓住机会多跟老板交流：基本上每周周会上，我都会提出来一些手头上一些比较棘手的问题或者对团队未来新动向的疑问，
来学习下老板是什么样的解决思路。
不要经常换工作，做一份工作通常 3-4 年才会有所沉淀，对这个领域非常了解。 换工作的原因一定是追求更高的目标，而不是工作中遇到了困难想要逃避或者追求涨薪。
越是遇到困难越要解决困难才可能有成长，逃避困难，换了工作仍然会遇到。技术的深度会跟薪资挂钩正比，即便是通过跳槽涨薪，没有技术实力压住泡沫还是会破。
在 IT 行业，工作和兴趣要尽可能贴合，可以发挥最大效果。 假如工作内容是一条线，兴趣是是一条线，这两条线的夹角越小，干活又轻松成果又多。
如果这两条线是直角，两边可能都很痛苦，建议调整。
牛逼的架构师一定是业务、前后端各种技术栈全部有很深的理解。 不懂业务或者不懂前端只懂后端，
都很难站在一个更高的视角来整体看问题和设计架构。因为系统是一个整体，有一部分不懂或者不关心，就可能成为系统的短板。
如何能评估比较准的工期呢？一个很简单的公式送给大家：
需求非常明确而且经常这样做：自己评估时间 * 1.5
需求不够清晰，有可能变，但是代码和技术方案熟悉：自己评估的时间 * 2
需求不够清晰，代码和技术方案也是新的，需要探索：自己评估的时间 * 2.5 or 3
ICE 最初就是基于 React 的一堆基础组件 + 业务组件 + 脚手架 + 前端教学文档 + 前端答疑群。我们的卖点就是：
你系统里的复杂组件如果可以被其他系统复用，那么我们来开发；我们提供前端技能培训和答疑，在我们答疑群里问的任何前端问题都可以被我们解答，复杂问题我们提供上门服务
怎么提高你的单位时间价值呢？
提升你的技术能力，把时间花在解决别人解决不了的难题上。
提升自己的责任感，主动去承担责任，责任往往伴随着权利，让自己成为项目组的核心。
培养自己批量解决问题的能力。过去你可能可以解决任何业务方提出的需求。但是现在需要在这基础上沉淀和总结规律，提炼出一套解决该类问题的通用解决思路和方法。
原来你只能接一个项目，现在你可以同时接多个同类的项目，也没问题了。此时你会说，我自己做不完啊！为什么要自己做？如果你完全知道怎么做，
那就跟你的老板申请加个实习生或者外包的同学来帮你写代码。关键在于，你有一套方法，可以保证质量。
提高效率。作为一个前端工程师，你需要开始写工具了。只要能让你更快完成开发任务的工具和方法，都可以提高你的单位时间价值。
复制你的时间。花一份时间完成某个事情，然后让他持续复制下去。每复制一份就能带来一份收益。知识付费了解一下。
明确你身上哪些东西是别人需要的
这个世界上只有两种商业模式，一个产品生意，一个是流量生意。一种人拿着产品寻找用户，叫产品生意，还有一种是拿着用户寻找产品的，这种叫做流量生意。
你身上有什么东西是可以卖的吗？
你的经验。把你的经验打包成产品，交付给他们。收点钱不过分。这就类似于，很多人都想去挖金子，而你以自己的经验，总结出一套方法，可以让他挖的更快，
那你的这套方法就值钱了，有多少人想淘金，你就有多少用户。
你的技能。你能解决别人解决不了的问题，这就是你的价值，这个价值只要加上简单的运营就可以换来财富。比如现在的技术咨询行业。给一个创业公司搭建一套
DevOps 平台，你觉得难吗？但是确是很多创业公司非常需要的。你可以帮他们解决他们软件架构的性能问题，这也是你的价值。
你的不同。每个人都是不同的，你需要走出去，让更多的人认识你，提升自己的影响力，积累一部分脑残粉，让他们来供养你吧。试试去做一个 YouTuber ，
分享你自己。
-
(已整理)前端项目如何管理
一般会从下面几点来考证一个项目是否管理得很好： 可扩展性：能够很方便、清晰的扩展一个页面、组件、模块 组件化：多个页面之间共用的大块代码可以独立成组件，多个页面、组件之间共用的小块代码可以独立成公共模块 可阅读性：阅读性良好（包括目录文件结构、代码结构），能够很快捷的找到某个页面、组件的文件，也能快捷的看出项目有哪些页面、组件 可移植性：能够轻松的对项目架构进行升级，或移植某些页面、组件、模块到其他项目 可重构性：对某个页面、组件、模块进行重构时，能够保证在重构之后功能不会改变、不会产生新 bug 开发友好：开发者在开发某一个功能时，能够有比较好的体验（不好的体验比如：多个文件相隔很远） 协作性：多人协作时，很少产生代码冲突、文件覆盖等问题 可交接性：当有人要离开项目时，交接给其他人是很方便的 .editorconfig: 统一每个开发人员的编辑器配置 eslint: 检查 js 语法（包括 jsx 语法），然后最大程度的矫正不符合规范的代码 stylelint: 检查 css 语法（包括 less, scss 语法），然后最大程度的矫正不符合规范的代码 prettier: 代码格式优化 husky + lint-staged: 强制开发人员对代码进行检查、自动矫正与优化 测试： js 模块：jest / mocha / tape / ava React 组件：enzyme + jest，另外可以使用 react-testing-library 代替 react-dom/test-utils Vue 组件：vue-test-utils + jest / mocha / tape / ava 一般会从下面几点来考证多个项目之间是否管理得很好： 组件化：多个项目共用的代码应当独立出来，成为一个单独的组件项目 版本化：组件项目与应用项目都应当版本化管理，特别是组件项目的版本应当符合 semver 语义化版本规范 版本格式：主版本号.次版本号.修订号，版本号递增规则如下： 主版本号：当你做了不兼容的 API 修改， 次版本号：当你做了向下兼容的功能性新增， 修订号：当你做了向下兼容的问题修正。 先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。 统一性：多个项目之间应当使用相同的技术选型、UI 框架、脚手架、开发工具、构建工具、测试库、目录规范、代码规范等，相同功能应指定使用固定某一个库 文档化：组件项目一定需要相关的文档，应用项目在必要的时候也要形成相应的文档 -
规范化 - 建立代码规范与Code Review制度 风格规范 - 缩进、换行、大小写等风格问题 实践规范 - 规避一些常见的隐患，或者针对特定问题的最佳实践 业务规范 - 与业务有关的特殊要求，比如文案中的关键词 自动化 - 使用工具自动检查代码质量 代码规范检查 - 包括风格规范、实践规范、业务规范 重复率 - 重复出现的代码区块占比，通常要求在5%以下 复杂度 - 总行数，模块大小，循环复杂度等 检查覆盖度 - 经过检查的行数占代码库总行数的比例 流程化 - 将代码质量检查与代码流动过程绑定 执行自动化代码质量检查的时机： 编辑时 - 使用编辑器插件，实时运行质量检查 构建时 - 在本地或者开发机的构建脚本中运行质量检查 提交时 - 利用Git Hooks，提交代码或者生成Pull Request时运行质量检查 发布时 - 在发布脚本中再做一次质量检查，通常与自动化测试放在一起 中心化 - 以团队整体为视角，集中管理代码规范，并实现质量状况透明化 当团队规模越来越大，项目越来越多时，代码质量管控就会面临以下问题： 不同项目使用的代码规范不一样 部分项目由于放松要求，没有接入质量检查，或者存在大量未修复的缺陷 无法从团队整体层面上体现各个项目的质量状况对比 为了应对以上问题，需要建设中心化的代码质量管控体系，要点包括： 代码规范统一管理。使用Git或者NPM包管理自动化代码质量检查的规则集，自动安装，不在本地写规则。一个团队、 一类项目、一套规则。 使用统一的持续集成服务。质量检查不通过的项目不能上线。 建立代码质量评分制度。让项目与项目之间能够横向对比，项目自身能够纵向对比，并且进行汇总反馈。 -
- TODO 干货
选择合适的目标 可能目标一 ：技术大佬 应该说能够开发维护一个开源框架，或者造出一个还不错的开源轮子，都算是行业内的技术大佬了。比如vue作者：尤大；elementui的饿了么团队等。 如果要做到这点，需要很强的技术执念，很好的技术基础，耐得住技术本身的枯燥，看得到技术本身优化带来的未来价值，能够在最后的升级、技术产品中找到 自我定位、人生成就感、自我的快感。 如果说是想成为这样的人，但对于还不确定是否自己就是这样人，那看下首先： 1 自己是否持续关注了一些最新技术的特性，比如deno,vue3，webpack4,关注了代表你是有兴趣的，而你关注的时间如果是下班或者休息时间就更证明你是这类人。 2 分析已经在用的技术究竟好在哪里，为什么这么用，我们的用法合理么。比如面试题里会问es6，会问react和vue的对比，但实际上，难道不面试、没人问我们， 我们真的不去思考么？当数组的find、includes语法出来之后，为什么不去分析下他的性能、合理性、简洁在哪里，为什么不去思考下我如果用了vue用的是否够好， 是否理解了vue的核心思想，去更好的实践，而不是vue的高级api使用者。因为在很多时候，我会看到大部分的号称中级甚至高级前端，在写vue页面代码的时候， 对于class,style的部分的理解和使用还是用原来jq还有原生的套路，去找这个元素，然后去改的样式，如果有看到element的源码，应该很容易看到， 组件是把这部分用data或者方法去承载的吧。 3 自己是否是技术兴奋型的。当我听到尤大在讲vue3.0在进行升级，优化了运行时、体积、内存之后，以及是通过什么样的思路优化这些时，很赞有没有， 我们也可以看到他在分享时的那种享受，对自己成就的自我肯定。但现实，我们的公司或者技术团队是否能采用，是另外一回事。如果从这点考虑， 也许很多人会对新技术本身是失望的，因为不能解决自己工作中、业务中的棘手问题。很明显的，我感觉到当尤大讲到会不会支持ie时，大家是关注这个点的， 因为业务就是业务，我们需要关注刚需。所以是否自己或者团队能找到业务和技术兴奋度的平衡感是很重要的。因为有些公司的技术栈可能还是jq的， 对于可能近几年都不能转型为新技术的前端来讲，这里的技术福利是香而不可食的。 4 自己是否有期望有可能成为引领技术变革的人，公司是否会给你这样的机会。如果说注定是要想成为技术大佬的人，那么按捺不住的你一定会选择去创造新技术， 去技术栈好的公司，去为现在的公司做技术架构调整。这是一名技术执着的大佬会有的魄力。而有些虽然挂着技术经理、技术总监头衔，却职业定位完全是 项目经理、业务经理的人，重心是不在这个领域的。而实际来讲，对于公司，不同阶段，这两种人都是需要的。 番外篇： 关于技术人员定位或者cto定位的问题，发现很多ceo对技术是有一定偏见的，尤其是对底层的程序员，对他们的定位完全是业务实现者，而对他们的专业能力、 专业瓶颈完全不考虑，也不会说考虑技术本身的更新性。 当然，更不用提技术反推业务了。在业务方或者ceo或者其他职能的眼中，管你是什么技术，我的需求是最紧要的，至于因为技术迭代换新导致的问题， 需要技术自己完全买单。而技术给自己买单的过程，却全程不给机会，没有合作的平台。大部分小公司都是这么干的，在他们发现问题的时候怎么操作呢？ 把这批技术人员下线，重新招聘高能力人员。但仔细对比就会发现，在一些独角兽或者bat的大厂，技术是可以承载更多价值，可以引导吧需求做的更好， 可以反推需求，可以利用技术成品去大量的降低成本，这种模式是很成功的。而小公司不这样做，核心原因是耗不起、容不得不成熟的技术团队去试错的成本， 另外一个核心原因就是看实际情况，我们目前不需要那样。不管怎么操作，都完全没有问题的，只是希望都能看长远一点，不要仅仅做了当前那些事。 这个现象不仅仅是程序员的，也是后端、产品经理、大数据还有等其他专业性职能都有的问题。 可能目标二 ：高级前端 在互联网快速发展的今天，前后端分离的今天，除了后端、产品当项目经理外，对于前端来讲，当一名高级前端也未尝不可。 我们就是成不了大佬但是能完美精确的完成需求的那批人，我们就是制定团队规范、组织好团队指导团队完成业务攻坚的人。技术不一定是行业最好的， 也不一定要很牛逼的东西，但工作范围内足够用，当偶尔超出业务范围、技术范围，我们也能解决。 与上面的技术大佬不同的是，这样定位的前端已经对技术本身没有那么狂热，而是对公司业务、实现产品价值更有兴趣。也许在3-5年里， 技术提升也只有那么一两次在必要的时候精进。事实上，有很多中小公司的技术总监都是这样承载下来的。不要唯技术论，而要唯业务论，业务为主心骨， 技术只是必要时、严重欠债时才会考虑。 番外篇：即使作为高级前端，也要有一点点的技术敏感性。不要完全为业务需求所累，因为即使这样，当新需求苛求新技术时，自己如果不会，那就尴尬了。 可能目标三 ：项目经理 在互联网快速发展的今天，前后端分离的今天，除了后端、产品当项目经理外，对于前端来讲，当项目经理也没有很严重的壁垒，尤其在中小公司。 我们都知道项目经理的角色基本是确定需求，跟踪进度，协调资源，风险控制，项目测试以及交付，后续运营辅助。 那么，其实在整个开发链中，发现前端是整个业务感知最细腻的，尤其对用户交付是直接负责的。而且前后端分离之后，前端对于数据的敏感性、 操作性会进一步加强，能力稍强的可以整理出整个业务的数据流，业务逻辑等。所以前端对整个开发进度是有一定能力去把控的。 也许有人讲到肯定是后端能力把控更合理，因为数据是核心，因为后端的问题前端解决不了。那我也想说，前端的问题后端就能解决么？在我经历的项目团队中， 也许大多数的前端代码看起来都非常简单，但只能说明那些页面需求很简单，需要前端专业能力的，后端也是一片空白。然后作为一个开发团队， 不要指望项目经理要有能力解决专业问题才可以当。如果这个逻辑的话，那产品经理当项目经理不是更不合理。在组建团队的时候，对于每个职能， 就应该有对应的预期和风险评估，每个职能是否有能力完成自己的任务。如果后端或者前端能力不行，应该是换能力强的人上或者找职能主管辅助解决。 可能目标四 ： 一份工作 && 一份生活 与后端的性质不同，前端是一名入门门槛很低的职业，而且薪资也还可以，工作性质属于代码可见，最短链路的一个工种。所以，必然的会带来很多非本专业的同学， 很多女性同学。比如女的java,女前端，比例非常高。 不是很多人都有强烈的职业目标，有很多人只是作为一份工作。就和行政、人事一样，很多可能做三五年，也并没有太大的职业能力变化和职业规划的变化。 我对它没有那么的热爱，也不想变成自己的事业。 对于小公司的大多数的前端需求，尤其简单重复需求，其实本身就不需要招资深的前端去完成。这是一项工作，一个并不需要挑战最新技术、严谨逻辑的工作。 比如我们知道的，登录注册页、列表详情页，点击一个按钮页面跳转，实际上很多基本操作因为我们的用户规模、期望的体验都没要要求，所以都很简单。 如果把前端当做一份普通的工作，其实就可以拥有一份生活。在阿里的文化里，大家都强调很拼，为了理想可以996，甚至906。但还是有很多人也有理想， 却不是阿里那种。可能是我们在中小公司也有自己的价值和快乐，可以承载自己的业务。可能是我们可以收获兴趣和爱好，收获家人。 干工作确实要努力一点，尤其是年轻的时候，但也可以稍微不那么拼，用一生去积累。多体验一些生活，多去设计，多去实践。不只是工作里才有成长， 你的工作也不是全部的可能，也许下一份职业就在你收获其他，灵感其他时而变成自己的事业。 可能目标五 ：人生充满可能 我想大家在当前端时，一定没有想过自己能做多久，自己的瓶颈会是什么，自己是喜欢前端的什么，又什么时候会失去对他的兴趣。当你不喜欢它的时候， 也许工作本身就会变的乏味。当你喜欢时，就是一直坐在那里做自己喜欢的事情。 大家一定不会怀疑像尤大，阿里大佬勾三股四，大漠这些人会不会对技术有什么疑惑，还能干多久。因为在技术的生涯里，他们已经走了那么久，找到了对技术的热爱， 所以技术不是工作，而是事务，而是做下去会开心的事情。包括大家都知道的阮一峰老师，人家写了那么多博客，在没有任何酬劳，可能没有预想过自己会进军阿里、 成为带队人时。 而对于我们来说，如果你还没有做那么久，也还没有达到对前端的一定的积淀或者沉淀。一定要好好想想这个问题。 技术是做一件事的一种技能，你是否喜欢做这件事。能做这件事是因为技术本身还是因为事情本身。在很多阿里的p89出来创业的时候，大家会明显的发现， 他们这时候重点在做事上。我们要用技术这个能力去做一件我想做的业务，我想做的产品，而不是关注此时我的技术还差多少没提升，自己要不要搞最新的技术， 我的技术带来的薪资是怎么样的。 如果你决定你做事为核心了，那么其实我们每个人都有无限的可能，前端只是一种最小的选择。我们可以选择从前端入手，了解互联网产品的开发流程， 可以了解医疗行业背景，可以了解大数据，可以了解与人沟通的能力，可以了解区块链，可以了解一个产品背后的逻辑与商业模式。当变成这些时，你还有很多职业选择。 大会能给我们带来什么 技术动态 在上面讲到，作为技术，只要还是在做前端，我们需要关注技术动态。不管是不是能用到，不管我们是不是技术大佬还是管业务的经理， 或者我们就是想不要丢了自己的饭碗。那么来参加一些技术行业的知名会议，对于我们更好的关注一些重要技术的状态是很有帮助的， 因为大会虽然分享的少，但一定会列举的是比较里程碑性质或者编程思想角度的大问题。 从这个目的触发，了解下就好的角度，大会是平时我们关注动态少，关注不到重点的一种弥补。这个是倾听学习了解的角度。 编程思维 && 涨见识 在一个固定的公司里，我们的技术栈一般不会大的变革，我们的一些编程思想也比较固定了。 那么这里看一些知名的团队在做些什么，有那么一两个问题是自己也在关注，看下他们怎么做的，没有干货，也能湿润下自己。 再不济，也比我们大多数时候看网络上良莠不齐的文章，来的高效。作为大多数非资深前端来讲，其实很多问题、很多技术上都是迷茫的， 而大厂在这方面的内容输出少的可怜。所以大家在看到阮一峰教程时才会觉得眼睛放光，除了通俗易懂，更大的特点是， 能通过他的教程得到了从入门到进阶的一个阶段。 另外一个特点，就是目前的90、00后都不喜欢看书，也不喜欢研究源码。所以可以看到很多社区随便分享下布局知识、高阶编程的知识， 前端社群就炸锅一样的，甚至每个人都发一遍自己的版本。 而大会上，肯定讲的是一个不一样的版本，有过实践的，很涨见识对不对。 前端同行 对于前端来讲，其实和大多数技术社群是一样的，大家都会进很多群，却很少交流。大会上能看到同行，这么多，应该是很大的一种欣慰。 那么对于一场大会，我个人觉得非常有价值的部分是diss，尤其针对主题性质的有价值的Q&A. 比如这次有提问到为什么要对比antd vue 仿照antd react,怎么支持阿拉伯语，至少从我的角度看，这两个问题都很好。其实参加会议的每个人平时积累下来， 都会有不少于十个以下的精华问题，而这些问题很多时候都是被零散的解决或者妥协了。而大厂或者一些技术大佬似乎能很好地解决问题，那么他们是如何解决这个问题的， 这个是大家最想听到的一部分，最想diss的一部分。 团队思考 && 业务思考 在分享之中，我们也能看到每个分享人基于自己或者团队的立场，去分享一个事情的时候的核心点是什么，分享的水平如何，其基本的思路是什么， 出于什么样的场景去解释这个问题，以什么样的方法论、技术方案去解决。 我们更多的时候会发现，我们之所以没有台上的嘉宾做得好，除了公司的原因，还有运作方式不一样、团队思考不一样。他们有更多的角度去让技术产出、 技术驱动变得可能，而我们更多的是技术让需求变得可能，除此很少去思考出其他的可能。 我记得之前校宝有次邀请到了蚂蚁的一个资深技术，后面转型管理的分享。她讲到很重要的一点，其实开始也是做技术啦，不过到后面发现， 产品还有业务方有些细节设置的不合理，有些地方没有考虑的更好，到这里还是和我们一样的。但后面他们变成了什么呢？他们的技术加班加点， 在技术考虑到位的基础上，吧需求更严谨的描述一遍，用严谨的数据模型、数据报表分析给产品、业务方，然后让他们看到技术带来的影响。在拿到话语权之后， 他们针对需求有越来越多的控制权、分析的能力，在解决基本需求完全没问题的情况下，他们又做了技术的产品，去承载团队内部技术需求、额外的业务需求、 创造用户需求。当在看到部门的产品矩阵时，可以看到好几个技术产品。 虽然以上的过程不可复制，但值得参考，尤其阿里或者腾讯在几乎任何需求的情况下，都不是直接完成，而是分析需求特点进行归类工具化方案解决，这种点很好。 把简单重复的解耦出去，解放开发者能力，把剩下的再根据业务进行封装。 -
用于解决这些问题的一个“框架”叫做 5W2H分析法，也叫做七何分析法，用于企业管理和技术活动。用来提高沟通问题效率，弥补考虑问题疏漏。 发明者用五个W开头的英语单词和两个H开头的单词进行设问。以此来发现问题，寻找解决思路，描述问题等。具体介绍下： WHAT – 是什么？目的是什么？做什么工作？条件是什么？哪一部分工作要做？重点是什么？与什么有关系？功能是什么？规范是什么？工作对象是什么？ WHY – 为什么要做？可不可以不做？有没有替代方案？ WHO – 谁？由谁来做？ WHEN – 何时？什么时间做？什么时机最适宜？ WHERE – 何处？在哪里做？ HOW – 怎么做？如何提高效率？如何实施？方法是什么？ HOW MUCH – 多少？做到什么程度？数量如何？质量水平如何？费用产出如何？ 以上的分析法适用于各种场景，当leader给你新任务时，从以上几个方面提问，丰富这个需求的内容。开会的时候根据此方法总结会议主题，达到会后明确会议思想。给下级部署任务时，需要从以上几个角度描述你的任务，并让其记录下来，使得任务发布更明确。你还可以结合我们前面介绍的5why来扩充这个体系，实现一套完整的问题分析、归纳、整理、描述结构。 合适的员工： 1.发现问题 2.解决问题 能够主动的去解决一些问题，提出解决方案，提高开发效率，提高部署效率等等。代码写出来除了给用户看之外，能帮助团队做一些提高。 3.不断提高 一个团队中，只有不停的学习，才能带动团队越来越棒。你提高了，团队没提高，需要你做分享，想办法提高整体水平。团队回报给你的是技术领导力的提升，会有机会让你去做leader涉及到管理的范畴，锻炼你的管理能力。反之团队提高了，个人没提高，当这个差距足够大的时候，团队会选择淘汰掉你。一个团队的管理要做好两件事，招合适的人，开除合适的人。所以，当下最重要的事情就是提高自己，要成为领头羊，而不是拖团队后腿。 4.不断优化 工作是不停地重复简单的工作，我们经常需要开发不计其数的导流页，落地页，着陆页。需要开发H5，活动页。项目精简版，缩略版。有这么一句话：简单的事情重复做，你就是专家。 重复的事情用心做，你就是赢家。重复工作交给别人，有的人会抱怨，有的人会产出一套规则，让这些重复的事情变得简单。几十万行的js交给别人，有的人会抱怨，有的人会整理一套规则，模块化，工具类，让开发变得容易。不断优化你的工作，优化重复繁琐的点 5.态度积极 杜绝一切负面的态度出现在工作环境中。能力强不强无所谓，态度一定要正确，能理性的看清PM和RD的关系，能处理好自己的情绪。西方有句话，意思是招聘那些态度好的人，培养他们的能力。 -
(已整理)一个思维习惯，让你成为架构师
-
(已整理)如何成为一位优秀的前端工程师？
TODO：图片 做不同的事情，内心感受是不同的。当你觉得无感时，说明你对技术细节的认知还不够，只是简单的重复。需要通过学习其中所有的技术点来提高技巧。同时，需要不断深入理解，感受实践中用到的技术和工具所发挥的作用。形象的说就是知识的“分辨率”怎么样，是模模糊糊的，还是"精度"很高，了解每一个细微的技术点。你会发现，有太多东西值得探索。只有在具体实践中才有体感，脱离应用场景啃一本书没有用的。进一步，你才能准确定义和抽象出开发中的普便问题。这是提高纵轴挑战水平的方式。所以，不必刻意寻找有挑战、有难度的工作做。重要的是，你能不能潜的更深，积累下更多的有价值的感受。 如果你正在做一件本身挑战很大的事，这时无须再增加挑战水平（纵轴）而是通过发现和学习已知的未知（对应问题域的知识域）技术来解决问题（横轴）。这时候需要拆解目标，降低挑战，耐心从基础开始学习。内心需要克服浮躁和自我怀疑的情绪。没有银弹能解决所有问题。关注前端技术发展，保持学习是十分重要的。 任何一种心理状态都不是一成不变的。比如一些能力不错的同学，对于常规需求，处于完全“掌控”的状态。但干的久了，一直做类似的事情挑战水平自然会衰减，通常会进入“无聊”的状态。然后常常会说工作太无聊，缺乏挑战，一成不变。其实是你主观意识上没有加深工作的感受，只是被动的被支配做一些事。经常反省自己所处的状态，每一件事努力做到心流（同时提高纵轴和横轴）。 -
1、对输入的不信任 （1）对空指针的检查 （2）对数据长度的检查 （3）对数据内容的检查 2、对输出（变更）的不信任 （1）修改代码时，采用不信任编码，正确的不一定是“对”的，再小的修改也应确认其对后续逻辑的影响，有些修正可能改变原来错误时的输出，而输出的改变，就会影响到依赖该改变字段的业务。 （2）发布前，应该对涉及到的场景进行测试和验证，测试可以有效的发现潜在的问题，这是众所周知的。 （3）发布过程，应该采用灰度发布策略，因为测试并非总是能发现问题，灰度发布，可以减少事故影响的范围。常见灰度发布的策略有机器灰度、IP灰度、用户灰度、按比例灰度等，各有优缺点， （4）发布后，全面监控是有效发现问题的一种方法。因为测试环境和正式环境可能存在不一致的地方，也可能测试不够完整，导致上线后有问题，所以需采取措施补救 A：如使用Monitor监控请求量、成功量、失败量、关键节点等 B：使用DLP告警监控成功率 C：发布完，在正式环境测试一遍 二、服务 一般的系统，都会有上下游的存在,而上下游的整个链路中，每个点都是不能保证绝对可靠的，任何一个点都可能随时发生故障，让你措手不及。 因此，不能信任整个链路中的任何一个点，需进行设防。 1、对服务本身的不信任 （1）服务监控 前面所述的请求量、成功量、失败量、关键节点、成功率的监控，都是对服务环节的单点监控。 在此基础上，可以加上自动化测试，自动化测试可以模拟应用场景，实现对于流程的监控。 （2）进程秒起 人可能在程序世界里是不可靠的因素（大牛除外），前面的措施，多是依赖人来保证的；所以，coredump还是有可能发生的，这时，进程秒起的实现，就可以有效减少coredump的影响，继续对外提供服务。 2、对依赖系统的不信任 可采用柔性可用策略，对于根据模块的不可或缺性，区分关键路径和非关键路径，并采取不同的策略 （1）对于非关键路径，采用柔性放过策略 当访问非关键路径超时时，简单的可采取有限制（一定数量、一定比重）的重试，结果超时则跳过该逻辑，进行下一步；复杂一点的统计一下超时的比例，当比例过高时，则跳过该逻辑，进行下一步 （2）对于关键路径，提供弱化服务的柔性策略 关键路径是不可或缺的服务，不能跳过；某些场景，可以根据目的，在关键路径严重不可用时，提供弱化版的服务。举例如派票系统访问票据存储信息严重不可用时， 可提供不依赖于存储的纯算法票据，为弥补安全性的确实，可采取缩短票据有效期等措施。 3、对请求的不信任 （1）对请求来源的不信任 有利可图的地方，就会有黑产时刻盯着，伪造各种请求，对此，可采取如下措施 A：权限控制 如ip鉴权、模块鉴权、白名单、用户登录态校验等 B：安全审计 权限控制仅能打击一下非正常流程的请求，但坏人经常能够成功模拟用户正常使用的场景；所以，对于一些重要场景，需要加入安全策略，打击如IP、号码等信息聚集，频率过快等机器行为，请求重放、劫持等请求） （2）对请求量的不信任 前端的请求，不总是平稳的；有活动时，会暴涨；前端业务故障恢复后，也可能暴涨；前端遭到恶意攻击时，也可能暴涨；一旦请求量超过系统负载，将会发生雪崩，最终导致整个服务不可用，对此种种突发情况，后端服务需要有应对措施 A：频率限制，控制各个业务的最大请求量（业务根据正常请求峰值的2-3倍申请，该值可修改），避免因一个业务暴涨影响所有业务的情况发生。 B：过载保护，虽然有频率限制，但业务过多时，依然有可能某个时间点，所有的请求超过了系统负载，或者到某个IDC，某台机器的请求超过负载，为避免这种情况下发生雪崩，将超过一定时间的请求丢弃，仅处理部分有效的请求，使得系统对外表现为部分可用，而非完全不可用。 三、运营 1、对机器的不信任 机器故障时有发生，如果服务存在单点问题，故障时，则服务将完全不可用，而依赖人工的恢复是不可预期的，对此，可通过以下措施解决 （1）容灾部署 即至少有两台以上的机器可以随时对外提供服务。 （2）心跳探测 用于监控机器是否可用，当机器不可用时，若涉及到主备机器的，应做好主备机器的自动切换；若不涉及到主备的，禁用故障机器对外提供服务即可。 2、对机房的不信任 现实生活中，整个机房不可用也是有发生过的，如2015年的天津滨海新区爆炸事故，导致腾讯在天津的多个机房不能对外提供正常服务，对此采取的措施有： （1）异地部署 不同IDC、不同城市、不同国家等部署，可用避免整个机房不可用时，有其他机房的机器可以对外提供服务 （2）容量冗余 对于类似QQ登陆这种入口型的系统，必须保持两倍以上的冗余；如此，可以保证当有一个机房故障时，所有请求迁移到其他机房不会引发系统过载。 3、对电力的不信任 虽然我们越来越离不开电力，但电力却不能保证一直在为我们提供服务。断电时，其影响和机器故障、机房故障类似，机器会关机，数据会丢失，所以，需要对数据进行备份。 （1）磁盘备份 来电后，机器重启，可以从磁盘中恢复数据，但可能会有部分数据丢失。 （2）远程备份 机器磁盘坏了，磁盘的数据会丢失，使用对于重要系统，相关数据应当考虑采用远程备份。 4、对网络的不信任 （1）不同地方，网络时延不一样 一般来说，本地就近的机器，时延要好于异地的机器, 所以，比较简单的做法就是近寻址，如CMLB。 也有部分情况，是异地服务的时延要好于本地服务的时延，所以，如果要做到较好的最优路径寻址，就需要先做网络探测，如Q调 （2）常有网络有波动或不可用情况 和机器故障一样处理，应当做到自动禁用；但网络故障和机器故障又不一样，经常存在某台机器不可用，但别的机器可以访问的情况，这时就不能在服务端禁用机器了，而应当采用本地回包统计策略，自动禁用服务差机器；同时需配合定时探测禁用机器策略，自动恢复可正常提供服务机器。 5、对人的不信任 人的因素在运营的世界里其实是不稳定的因素，所以，不能对人的操作有过多的信任。 （1）操作备份 每一步操作都有记录，便于发生问题时的回溯,重要的操作需要review，避免个人考虑不周导致事故。 （2）效果确认 实际环境往往和测试环境是存在一些差异，所有在正式环境做变更后，应通过视图review和验证来确认是否符合预期。 （3）变更可回滚 操作前需对旧程序、旧配置等做好备份，以便发生故障时，及时恢复服务。 （4）自动化部署 机器的部署，可能有一堆复杂的流程，如各种权限申请，各种客户端安装等，仅靠文档流程操作加上测试验证时不够的，可能某次部署漏了某个步骤而测试又没测到，上线后就可能发生事故若能所有流程实现自动化，则可有效避免这类问题。 （5）一致性检查 现网的发布可能因某个节点没同步导致漏发，也就是不同的机器服务不一样；对此，有版本号的，可通过版本号监控发现；没版本号的，则需借助进程、配置等的一致性检查来发现问题。 备注：以上提到的不信任策略，有的不能简单的单条使用，需要结合其他的措施一起使用的。 -
向下管理 不去写重复的应用代码，去做新的或者更低层的代码研究。 去关注产品。 与其他部门，例如pm提出的需求，采用yes，but模式去回答。而不是以工程师思维来思考，遇到需求先考虑资源是否充足，技术难度等，习惯性的说no。 一定要让那些让你满意的人满意，不让你满意的人可以选择性的放弃。 赋能你的team staff，看到每个人的优缺点，扬长避短。 向上多表现，向下多关心，平级多帮助，把荣誉给下属。 如果能招到一个比你级别高的人，他还心甘情愿在你手下工作，这相当于变相提升了自己的级别。 在一家高速发展中的公司，做一个技术leader最重要的事是招聘，其次是人员管理和技术提升。 对下属要严格，认真帮助他分析自己的优缺点，并帮助他提升优点，规避缺点，让他做能够发挥他长处的事情。 管理team有一个非常重要的关键点，就是人员的架构。 关注PM，QA，后端RD的感受，让他们爽，你就会爽，领导总是会从侧面了解你的团队。 两周做一次staff谈话，了解工作状态和诉求，让他多说，自己多听。 把对staff的反馈放在平时，不要积怨，不要将误会加深。 向上管理 1.与领导有冲突，事前要理智的分析。要反思。 太快下判断，以为领导要搞你，其实他是为了帮助你。 不要单向控制，向领导隐瞒你工作的过程。 从自己的角度出发，看不全面，一定去跟领导沟通，但是之前要把自己站在老板的角度把细节想明白。 2.跟领导谈的时候要注意。 利益要一致。 澄清问题，我的意思是什么，而不是什么。 尊重，尊重对方的情绪。就事论事，行为和人分开。 信赖对方。 3.了解你的老板，知道他们在意什么，了解他们的性格和习惯，是阅读型还是倾听型的。 4.让老板知道你在做什么。（但不要太细节） 5.了解自己的不可替代性，在恰当的时候，跟老板提要求。 6.真诚的为公司和老板考虑。 左右管理 1.让跟你合作的人舒服，尊重他们。 2.做利益交换，达到共赢。 做一个技术leader 跟我一起冲。 发展员工。 给予team成绩，让团队每个人成功。 沟通和协作，增加staff参与感。 赢得他人的信任，让别人乐于分享他的问题。 倾向性，给别人确定的答案。 把自己的team当做一家公司，你应该做什么能够让team自给自足，并能赚到更多的钱。 扩大团队影响力，有两个思路 找到自己团队工作中的痛点，解决它并把他推广到其他team，甚至打造成一个产品，向社会交付。（比如性能监控平台） 找到跟你合作的人或者team的痛点，开发技术工具来解决，提供合作效率。（比如UI切图重命名工具，雪碧图生成器） 当你成为一个20人以上团队的leader，技术会变得不重要，找到懂技术的人，做技术创新和业务创新，变得更重要。 自我修养 做的更多一点，做的比你的主管安排给你的任务更多一点。 熟悉更多业务和代码，不管是不是你写的。 熟悉端到端，各端的架构和业务。 自学更多基础和底层的原理性的知识。 做的更好一点，针对系统和业务里面的不合理的地方，提出并修改他。（向领导展现自己，同时增强自己对业务和代码的熟悉性。） 通过看书系统性的学习，通过看文章查找疑问点，找寻一些方法。 将所学的东西真正实践，自己模拟环境写demo。 讲给别人听。 工程师成长 高级工程师 多做一点，尤其是测试。 交付一个完整产品。 别人可以继承你的代码，不要有坑。 提供一个可扩展的系统。 P6可以自己解决问题。 p6可以独立解决一件复杂问题。 专家 （团队） 规范制定 树榜样，你怎么做，他怎么做。（一级一级的学习，分治和递归） 拆分复杂问题成小问题的能力。 P7可以将自己的技术影响力拓展到整个Team。 P7可以批量解决复杂问题。 大厂对各个级别能力的要求