本周工作思考

• 时间过着真快，有到月底了，check下工作，dailywork很满，但是一些重大的事情上看起来没有大的里程碑的进展，最近这半年我不断的在review我的工作方式，不断尝试对我来说最合适的那个节奏，拥抱变化，提升效率可能是我新的一年个人成长的重要目标：
  • 1 OKR中目标是优先级最重要的，结合公司目标，产品路线图和技术路线图严谨制定，日常工作安排必须要围绕OKR进行；
  • 2 日常工作中要确保重要的事情得到持续的有效推进，确保执行落实和执行方向的正确；
  • 3 关键目标要保证在既定时间内有关键结果的交付；
  • 4 面对实际中的问题和困难，要及时调整解决问题的思路和方法，确保以结果为导向的工作安排；
  • 5 日常工作中要善于思变，敢于想办法用创新的思路克服困难，争取目标达成；

本周工作思考

• 我有一个毛病，组件开发时，有一种安逸的方式，每个项目的组件都是按照以前习惯的思维方式写，比如参数的判断，参数的处理是否可以封装处理，日常开发中很难处理的一个事是如何在规范和创新中取舍，日常开发中我更倾向基于原则开发，规范的制定也是基于开发原则和最佳实践的总结，所以在理解规范的时候，要搞明白规范背后的故事和逻辑，规范不代表着呆板和僵化，规范是否为了更好的效率和后续的设计迭代，所以开发中要保持审慎的质疑和批判，以前的一定是好的吗？是不是有更好的设计？是不是有更好的实现，是不是hooks可以抽出一点，是不是可以安全一点，是不是可以优雅一点，是不是有更有效的办法，是不是可以做的灵活一点？人们常说，幸福指数往往和钱无关，有时候项目质量往往和时间无关，这里面有些逻辑是相同的。很多人做了十个项目，其实只成长了一次，有的项目用10天和用6天，做的效果差不多，如果有这种情况，真的该停下来想一想；
  • 我觉得Code review是一件很难的事但一定要做的事，code review如果可以度量的那会轻松很多，但这个事不容易做，如何来衡量code review本身的深度和质量，出去代码质量分析工具外，很大程度上取决于reviewer本身的能力和经验，code review本身不是轻松的事，reviewer要理解规范，要明白业务，要懂得设计，请别人review的时候，实际上再请一位老师帮助你做好一件事情，所以作为代码提交人要重视reviewer的建议，作为viewer也要认真review并且注意自身能力的提升，因为你的态度和能力也会体现再代码的review上，所以做代码审查的时候要高标准高要求，代码提交者对审查点也要认真思考敢于质疑，这种碰撞往往是最有效的集体学习和最好的集体智慧；

本周工作思考

• 本周三的工程例会上东朔老师指出Teck Leader的首要职责是给伙伴们安排好任务明确好优先级，Teck Leader要对结果负责，做好兜底的工作，这两点给了我很多的触动，从这个角度反思，我有很多做的不好的地方，很多时候我陷在自己的优先级工作里，比如改bug，比如跟线上问题，比如自己的项目，很少和其他伙伴合作的项目，我认为这是我的core job，其实我错了，我要花更多的精力专注在更重要的事情上，比如思考 对伙伴们需要我给予什么样的帮助和支持提高 项目效率和质量，我需要怎快速解决团队中的共性问题等等
  • 对工程质量负责，做好check，需要了解项目技术难度很复杂度，做好技术兜底和风险规避
  • 了解每个伙伴的优势，让大家更好的发挥最大价值
  • 加强技术预研，提高项目风险识别，关注项目质量和项目指标，引导每一位伙伴持续成长，成为更优秀的自己
  • 最最重要的是，不要自己单独做项目，一定要和其他伙伴合作项目，哪怕分很小的一个模块，也要和其他伙伴一起完成，要在项目开发过程中和协作伙伴一起并肩作战，解决遇到的工程问题，效率问题，流程问题等等项目中实实在在的小问题和大问题，最终的目的是让每位伙伴成为Teck Leader的Backup

本周工作思考

• 今天问题排查的反思
  • 在跟进Edge页面白屏的问题时，因为本地没法复现，约了用户去复现排查问题，感谢我们可爱的日本用户，他们非常配合；
  • 排查过程中约了2次会议，现在总结来看其实第一次就可以解决这问题，第一次在看用户浏览器的报错信息时，看到了一些报错，目前来看有三种报错，1 js兼容问题，2 https和http混用问题，3 QRcode.js加载的问题，第一次会议只看到前两个问题，第三个问题没有注意，原因就是经验性的忽视了，自以为第三个问题和第二个问题是一个问题，就没有认真的分析错误的原因
  • 我觉得这是一种低效的做法，如果我在第一次会议时再认真一些，再细致一些，再考虑周全一些， 就没有第二次约会了，这不仅节省了我和洪宝的时间，也节省了日本用户的时间，还会建立更加专业的公司形象，这类事后诸葛，其实挺沮丧的；
  • 快就是慢，慢就是快，如果把工作和生活中的每件事做到极致，其实总的来看是快的，就是高效的，令人愉悦的。什么算极致呢，我理解的极致就是这个事在事前想到了最好的结果和计划，事中高效愉快的完成了计划并达成了想要的结果，其实要享受过程，事后反思总结没有明显的纰漏和现有能力下的提升空间。最近一段时间我的很多事做完了，总结发现有很多可以做的更好的地方，其实对自己来说挺遗憾的，我的一个感受是处理很多零碎的事情会无形降低自己做事的标准，现在看沉浸式的工作方式可能是最有效的方式

本周工作思考

• 对web端技术设计及评审的一些简单思考
  • 项目开始前的技术设计及评审已经成为研发流程中的重要一环，从我们自身发展的角度，技术设计及评审的过程都是很重要，也是非常必要的。其实在研发过程中，我们或多或少受到CMMI，敏捷开发，面向对象开发，领域驱动等各类软件开发方法或者开发流程思想的综合影响，所以大家在写技术文档时思路和角度也不太相同，就目前的总体流程而言我们一直在持续改进，就是敏捷开发与持续交付 -> 总结反思改进 -> 敏捷开发与持续交付 这样的一个迭代式的开发到交付的闭环;
  • 持续改进，提高过程效能的这个大的发展原则下，需要持续优化和细化核心流程，同时持续精简繁冗非必要流程，当前这个识别过程随着业务和组织的发展，长期看是动态的，阶段性上是稳定的，因为根本目标是通过优化过程，提高开发效能，在不同的发展阶段，公司的发展目标所有侧重，也会直接体现在研发过程的设计和优化上；
  • 敏捷交付是一个大过程，它由很多的小流程和微流程组成，设计环节就是其中很重要的一环， 我们目前没有规范约束设计方面的的所有过程，只是在设计阶段做了一个里程碑的的环节，从内容上看，它可以包括需求确定之后的所有需要设计的内容，甚至可以包括关键需求分析和领域建模的内容，从实践角度来说，也推荐设计文档里可以包括需求分析，领域建模，对象分析，架构设计，功能设计，项目管理分析及安排等一系列需要在开发阶段前置的内容；因为项目的情况不同，所涉及的设计粒度和范围也是不同的，所以现阶段不太可能就设计内容和设计过程做太具体点的规范，但是我们需要持续的优化和丰富，以期形成可裁剪的标准化模板；同时我也知道在园艺设计上，有一种路线设计方法，在公园的路线规划上，期初先设计几条主干道，然后开放公园，后面根据人们走出来的路，规划建设其他辅路和游园路线，这方式是主干道规划 + 通幽小径自决的方式，这种方式有一定的优势，但不一定适合所有的公园；
  • 目前的从我的角度观察，web端的技术设计文档存在有几个需要优化的问题
  • 项目实现后的设计变更无法反应到最初的设计文档上
  • 设计文档对新伙伴和Code Reviewer的说明作用不大
  • 设计文档缺乏对工程能力沉淀的指导作用
    现在的重点项目代码量一般比较大，涉及到大量css和html，实现细节繁博，从Code Review和后续迭代来看，技术文档有要努力达成3个重要目标：
    1 作为未来业务和框架迭代的技术基础和指导，可以包含一些关键需求的分析及对未来可迭代方向的思考，以及当前设计的描述及其背后的逻辑推演过程等等
    2 成为工程建设的素材来源和思考根基，可以包含一些工程上思考，是否有组件化的功能，需要提取哪些可复用的功能，可以使用哪些方法提升开发效率，测试效率等等；
    3 成为个人和团队的技术产物的沉淀，可以包含一些该项目在技术选型上思考，以及同类项目，或者同Pod类似项目上的技术思考，或者业界同类功能的实现分析；
  • 技术评审不是设计的结束，设计伴随着项目的过程甚至是后续的迭代，开发过程中可能要随时更新或者修整之前的设计并尽可能的补充到技术文档上，现阶段我们项目类的技术文档，我建议追求精深简洁一些，数量上不必繁冗，对于长期的项目，比如i18n开发，搜索类，OTJ甚至可以用一篇文档持续更新，这样可以较好的保证设计思路的连贯性和完整性；
  • 另外，技术文档不比代码，文档不是给机器看的，技术文档是纯给人看的，我们的目的是让别人更快的看懂，所以多考虑下别人的阅读体验和不同层次的技术理解能力及技术感受力

本周工作思考

• iPhone6s语音微课卡顿问题排查
  • 这个问题存在很长时间了，综合各种情况其优先级没有得到优先处理，随着web组的整体产能的扩充，现在可以把一些疑难问题花时间处理也跟进处理
  • 本来计划这个排查需要一下午的时间，实际上断断续续用了近1天多的时间，排查的方法是还是通过打log的方式看是否有报错或者性能瓶颈，通过排查和排除发现，
  • 只有iPhone 6s上的app录制的语音微课在iPhone 6s的app或者Safari上存在问题
  • 在 Android app 或者 PC Chrome 上播放均无卡顿的情况发生
  • 使用 Android app 或者 PC Chrome 录制的微课均无卡顿的情况
  • iPhone 6s上使用的编解码器是LAME3.99，而Android app 或者 PC Chrome使用的是LAME3.100
  • 单独播放iPhone 6s上录制的音频无卡顿的情况
  • 通过性能日志发现，发生卡顿时video的onTimeUpdate的的事件执行事件过长，去掉onTimeUpdate的事件，则无或者轻微卡顿发生，确定是直接原因和onTimeUpdate有关，但是无法确定是否是因果关系
  • onTimeUpdate事件中涉及到播放时间控制，slides更新，播放进度展示等业务逻辑
  • 通过以上排查发现，卡顿和react setState性能有明显正相关，目前初步推测造成性能问题的原因是有2个，1是音频文件解码性能，2 khtml内核和react在渲染上性能损耗；目前暂未发现特别消耗性能的业务操作，因为通过日志发现，播放卡顿时，业务逻辑展示的性能消耗无明显规律，在统计各处都有发现较大的性能消耗，也都有无明显性能消耗的地方
  • 目前还未想到特别有效可落地的办法，onTimeUpdate控制slides的更新，必须保证音画同步，所以不能使用异步的方式，但是mp3文件的解码比较费时间但是涉及浏览器内部，没法触及优化；目前在验证的方法是重新编码LAME3.99的mp3文件，周四在通过FFmpeg做转换试验，暂时没有较大的进展；
  • 1

本周工作思考

• Code review的思考
  • 目前最大感受是时间不够用，在google的工程实践中建议，代码审核要尽快完成，但是实际工作中特别像是私信和测评2.2这样业务复杂的较大项目，2个小时完全review完，确实很有难度，我有着这样的想法，较大项目的代码提测时，详情代码提交的伙伴用半个小时以内串讲一下整个实现思路和功能，然后再具体的做cr，这样做的好处是在做好cr和花费时间之间做一个折中，让code review对代码深入的理解，这样才能保证cr更有效，保证代码库中代码质量是持续改进的，而不是越来越来糟糕；
  • 在代码质量和设计守护是上我们必须秉持长期主义，一开始就把代码的设计和实现做的足够好，在代码扩展中，保证必要的重构，从编写代码的一开始就消除本可以避免的重构；
  • 随着业务的深化迭代，我越来越觉得前端代码的可扩展性，易理解性及稳定性是最重要的三个开发原则，并且它们的权重是，可扩 展性 > 易理解性 >稳定性, 可扩展性和稳定性两者之前在开发过程中有时候会纠结，该以倾向那个，在review私信的代码时，我看到兴旺在私信列表实现时，我想到一些我自己的实现，但是我比较了一下，似乎兴旺的实现在当前更合适一些，因为当前的实现比较简洁，用常规的做法，比较容易理解和实现，也覆盖住了当前需求，就没必要为了追求高性能的原则做其他的设计，这里不是说性能不重要，当我们没有找到一个既有较好性能又有较好的扩展性的方法，就先放弃为追求性能而造成扩展性差的方案，基于长期主义，可以持续优化的方式才是正确的，不要从一开始就减少了可持续优化的可能性， 我们在设计时应该优先考虑这三个原则，如果有些设计很富有巧思构想，却和这三条原则相违背，建议大家再想一想，再讨论一下；

本周工作思考

• 基于rxjs+web component的组件开发
  • camera侦测组件和mic侦测组件实现逻辑上相对简单，把它们抽到umu_media_lib中，使用web component做了实现，主要考虑点：
  • 封装性好，html，style可以封装在组件内，可以独立使用；
  • 不依赖第三方库，chrome本身很好的支持；
  • 使用方便，如
  • 在状态和流程管理上目前尝试使用了rxjs + react + hooks作为数据流和订阅通知的管理器，在录制项目的界面上涉及多个步骤的数据转换，比如从开始页到录制页，另外是录制页面的各种状态rxjs的响应式可以录制时的状态通过observeable传递给其他关注的组件；这样会比较方便的避免过多的状态通知的情况；
  • 努力向身边优秀的伙伴们学习
  • 有一次和@元峰吃饭，我就问@元峰是怎样做到高中清华的，@元峰说了一个细节让我获益匪浅，他告诉我他高中做数学试卷的时候，往往是从后往前做的，也就是是先从所谓的压轴题开始做起，我听完有点震惊，毕业后我就没有关注过考试技巧的话题了，但我隐约记得十多年我上高中的时候，我的老师告诉我们不会的题目先跳过去，先易后难，这成了我的定式思维，而@元峰的做法是先难而后易，我倒是不觉得这个方法本身很惊奇，而是用这个方法背后该是怎样的思考，真的有大开大合的开阔思维方式；我记得我也曾请教过@熊瑛Candice认为什么样的学习方法最有效？@Candice说，专注最重要，专注学习了，很多内容就搞明白了，那一刻，我对专注有更多的理解；今天通过周报又和彤烨一起复习了下如何写邮件<IF规范-邮件沟通>，其实身边的很多伙伴都在有意无意间成了我的良师益友，身边有这么多优秀的伙伴有时候感觉很幸福，有时候也感觉特别有压力，但是更多的时候是动力，是学习和成长的动力。

本周工作思考

• 排查log问题的简单总结
  • 最近每天会抽点时间关注线上log问题，坦白来说，近一年来，log采集的及展示的基础设施建设上我们已经越过了0的阶段，现在正在往1的方向上奔
  • 目前最大的痛点是对线上问题来说，用户反馈比我们自己发现比例大， 如何前置bug的发现，就是如何缩短发版后到线上bug被发现的时间是我们需要解决的问题；
  • 我们现有已经拥有了sentry和kibana的能力，对web端来说，如何利用好这两个能力，可能是未来半年内我们要解决的问题；
  • 稳定的服务质量对我们来说非常重要，随着客户使用的持续扩大和深入，需要更深入的思考质量建设，从设计开发到上线后持续跟进，都要纳入整个质量建设体系的考虑；
  • 在日常的log跟进中，有一些关键log确实存在欠缺的情况，对于发现有欠缺的业务，可以随时补充，另外也要多想办法规避log不足带来的问题，最近在排查log的时候也有一些感触；kibana的监控里经常报BJ_report未定义的问题，其实在代码里是找不到直接引用BJ_report对象的情况，但是有if(BJ_report)的类似使用，虽然在chrome上没有报错，但是在一些低版本的浏览器里，对全局变量的使用可能会有差异，我们觉得大部分的时间都使用chrome，所有对兼容性的认识并不深刻，基于这些例子，我总结基本思路是大胆假设，认真推导和求证，log里总会有一些蛛丝马迹供我们参考和旁证，另外一个感触就是，自己的知识和经验还是太欠缺了，知识的欠缺就会导致推导和分析过程是错误的，还需要更加的深入学习，思考和沉淀；

打车回家，扫完健康码，司机大叔问，这个点儿回家，明个还上班吗？我笑了笑，晚去点没关系的。够累的，司机随口回了句。过了一会，估计是看我在刷手机，大叔说了句，咱们30分钟到，你先眯瞪会吧……对这个莫名的关心我竟有种莫名的感动。成年人的世界眼泪最不值钱，这种感动却也弥足珍贵。

闭着眼睛，思绪纷飞，我想起我的父母在我这个年纪已经独立抚养4个孩子，没有自己的房子，挣钱无非种地，种菜，养猪，5分钱的鸡蛋都要攒着卖，经常要凌晨三四点起床载着一二百斤的青菜骑车三四十公里去隔壁镇上卖菜，生活困苦，足够艰难。对比我的现在，虽然我的生活也不理想，但是没有4个孩子要抚养，将心比心，他们才是生活的强者。