Work Experience To Record

• 对于不相关知识，要果断舍弃。学习需要投入成本，选择重点，注重收益。
• 学会明确地、全局地、追根究底地识别问题，深入问题发生的本质，且高效地寻找问题接口人。
• 思路上的变化
  • 视野，考虑问题的高度：流程上的考虑，团队的考虑，不要陷在个人项目中，关注更大的范围
  • 技术方案：可维护性，可扩展性，用户体验，安全，性能
  • 人源：即资源，即支持。开展工作的润滑剂，事业道路上的助手
  • 规划：有判断，立目标，做计划，分阶段，任务分解（比如大项目排期）
• 产品线为首要因素、兼顾个人发展、不要陷入项目中
• 对自己无益有害的工作，及时转交给别人。爱惜自己
• 对知识的系统回归，梳理和总结。搭建知识网络，并为每个细分内容丰富细节
• 对细碎知识的管理能力，也是一种有用的技能。
• 要有时间管理，晚上要有总结回顾，日常要有记录才能有效进行阶段回顾
• 在leader不信任的情况下，不要做黑活，吃力不讨好的事情。理解和信任是工作的基础
• 我眼中的高T
  • 知识体系化，全面且深入，高度的技术钻研能力
  • 对系统的健壮性，有独到的认知，对系统的架构设计能力
  • 团队协作能力
  • 自我管理能力
  • 高效解决问题能力，follow through
  • 工作思路和具体方法
  • 耐心和恒心
  • 个人影响力
• 按功能点排期，开发量和联调量。对于前端来说，静态页面和用户交互的开发量。首先关注风险点，确定风险点为高优先任务。
• 排查和解决问题的路径：定位问题，查看文档或规范，研究源码或原理，编写最小化demo进行测试，修复问题，问题总结和记录。
• 编写邮件时，要突出负责人，如以 @某某 并高亮方式来标识，负责人必须在收件人一栏中。邮件中的重要内容（或结论）可以背景描黄来突出，并对每件事情提供后续计划或建议。
• Learning comes in different styles. I learn best by：
  • Reading a book (a real one with actual paper pages)
  • Typing in code examples and seeing results
  • Having a mentor I can ask questions from

---

1、一个系统，从无到有，从小到大，是个循序渐进，不断迭代的过程。无法一口气吃成胖子，要稳扎稳打，宁愿多花时间，多做准备，也不要匆匆开始，回头自食其果。调研就是确保深入思考和方案权衡的有效方法，并能对风险点进行确认，调研不仅仅要关注方案的优点，也需关注方案的局限性。

2、今天虽然干了些事情，但被事情淹没，没有合理作息。这是忌讳，合理休息是高效工作的基础，抬头看看自己需要干什么，不能总是被生活推着走。

3、自己的事情是可以专注的，高效的且可控的。所以如果无法正确排期，是因为1、无法正确预估工作量（跨团队合作是难以预估的），2、无法合理的管理时间（在有可能被打断的时间中，就不应该着手做需要专注的事情）。同时，提高沟通效率，以 完成一个目标为前提（，提出解决方案并落实后续行动）进行沟通，而不是沟通毫无成果或无后期跟进。

4、有额外需求加入时，首先需要预估解决方案（无调研不预估），无法确认实现方案前避免提供排期。若排期时间较长，影响正常项目进度，要权衡情况（确认优先级，是新需求延迟还是正常需求延迟）。理论上，新需求应该加入下一轮迭代（或下一轮提测），而不是无限制地扩大一个项目的需求（而导致项目失控）。这不仅仅是开发上的问题，也是项目的认知同步问题。新需求的增加，需要让相关人员都知会到，这是一个浪费，也增加项目管理难度。

5、调研很重要，而且需要完整的调研。浅层的调研，会使得自己从一个坑掉入另外一个坑中，多关注局限性！

6、维护性，提升维护性的本质在于对 需求的正确理解，不使用技巧编程，单一职责的函数，规范的编码。编码规范能帮助你 快速定位 问题，且避免遗漏。单一职责提升函数间的独立性，减少代码修改量，较少错误概率。不使用技巧使得项目开发减少后顾之忧，避免埋下地雷。最后，正确理解需求，拆分需求，是一切程序开发的根源。

7、代码中的统一管理，有些像中介者模式。复杂逻辑应减少统一管理，由中介者转型为基础服务（基础服务可以增加反向监听能力，以梳理哪些依赖该基础服务），减少耦合，提升扩展能力。相互之间通过接口来通信。

8、早睡早起不加班，空余时间要放松心情和充电。加班不是解决之道，一定要有时间来思考和规划未来，并渐渐实现。

9、热水泡脚，热水洗澡，生活幸福

10、改变个人观念（要谦逊），不要认为别人啥都不懂，也不要觉得自己啥都懂。劝说别人时少用否定，要委婉。

11、说话要 条理清晰有逻辑，不啰嗦。

12、各自排各自的排期，即使是正确的，也不要给其他人排期，这是相互尊重的问题。排期中，留有 20%—30% 的缓冲时间很有必要，这能保证项目的质量，这个缓冲时间以开发和联调总时间的基础上计算。

13、项目流程：

• 立项
• 调研（或设计，交互、视觉设计）
• 评审（需求评审或是详设方案评审，后者偏技术方案，确认方案可行性 和 方案完备）
• 排期（要留有缓冲时间，结合各自排期后给出总排期，具体到每人给出自己排期）
• 开发 + 联调
• Code Review（什么时机呢？ 走到你的同事座位跟前，像请师父一样请他坐到你的电脑面前，然后，花5分钟给他讲讲你的代码，给他另外一个5分钟让他给你的代码提提意见，这比什么都好。）
• 提测（文档更新，确保代码的质量和维护性）
• 项目上线

14、对 知识系统且正确地认识 非常重要，将知识应用到实际生产中，带来收益也非常重要，相得益彰。

15、跨部门合作，重要事情（任务、行动）一定要有邮件做确认，这样容易跟踪问题，同时区分责任，并能推动双方各自的进度 （邮件有监督压力的效应）。

16、无风险的代码尽量先上，不要拖着在下个项目中。你永远预测不到这中间会发生什么，而导致下个项目延期。

17、项目要小而快。有大项目（长时间）的时候避免并行，否则中间会有各种各样的代码 merge，无形中增加许多不必要的风险。比如性能优化项目中间上线了许多其他项目，每天要合并5个左右的版本，即耽误时间也增加风险（以后一次性合代码哈，而且开发前要考虑这个因素），即使上线后，其他人也需要合并我的代码，增加第二层风险。

18、如果是难得一次的问题或缺陷，应该相互忍让。如果是长期而频繁的问题，那应该与向他人沟通，提升效率。

19、要婉拒，给别人其它路径来完成任务（提出解决方案）。有些事不能开先例，一旦如此不可阻挡，不要跟自己的事情过不去。

20、不是抱怨，而是寻找解决方法。不是拒绝，而是思考解决方法。

21、流程扩大是最为糟糕的事情，使得大家互相推卸责任，同时无法寻求他人帮助。而且如果是跨团队，有时还无法追究责任。跨团队合作一定要有邮件，而且要CC到有关负责人。免得有苦自己吃，别人还冤枉了你。

22、没必要时就不要扮演黑脸，把得罪人的事情自己拦过来，换个思路，拉一个多人会话，事情就会方便很多。

23、不要去保证一个项目的进度，尤其是一个对流程一知半解的项目 ，特别是对外合作项目。只要保证自己的工作及时完成，前面的 与 后续的时间、流程都不要去保证。

24、学习需要用心观察和总结（很多知识书上是学习不到的），没有人有义务教你的。对于教你的人，要由衷地感谢！