本周工作思考

• 文章中文字出现重叠问题修复的思考
  • 文章小节的展示经常性的出现一些异常情况，比如图片找不到，图片尺寸过大，文本字体颜色不对，样式不对等等问题；
  • 文章小节的实现方案是这样的：文章小节的内容输入框是富文本编辑器，展示部分首先做安全处理，然后以HTML的方式展示出来； 用户一般有两种输入方式，1 直接手工输入内容，2 从别处复制过来粘贴都这里；
  • 基于这样的实现方案，很容易出现上述举例所说的问题，如果文本和格式是从别处复制过来的，特别是内联样式， 很容易出现这类问题；这类问题不能完美的从技术侧解决，因为诊断和纠正用户的文本格式非常困难，样式带有较大的主观性和随意性，1是不知道用户是无意设置成这种样式，还是有意设置成这种样式，2是假定知道用户设置可不合适的样式，也很难把样式纠正成用户满意的样式
  • 针对这种情况如果改善呢？结合目前的经验，目前有3类方案：
  • 1 是针对问题具体解决，比如图片加载不到，图片尺寸过大的问题，这个问题是有解决过的，基本思路是通过正则找到img标签，解析出宽度和高度，判断宽度和高度是否超出我们预设的最大值，如果超出了取最大值，以此来纠正图片过大的问题；
  • 2 是基于html合法性和业务规则的校验，目前文本重叠的问题就是基于这种思路修复的，这个思路是受html validator启发而来，主要框架是把用户的输入转换成dom，通过遍历dom节点，使每个节点都接受一些规则插件的访问（vistor），规则插件可以是业务规则可以是html的w3c规则，比如转化dom失败，可以针对转化dom失败的原因，转成合法的html，比如图片节点的大小必须控制在一定的范围，比如a标签不能带有某些特定url的链接奠定。结合该解决框架，文本重叠是因为line-height不合法的，可以编写lineHeight插件，保证line-height必须大于1；
  • 3 是基于拼写检查的思路，结合上述的html validator实现，Web侧编辑时，框架实时检测用户输入的html，对于认为不合理的地方，在输入框出给出下划线或者tooltips提示，让用户根据提示修改；
  • 以上3类方案各有优缺点，方案1简单直接，缺点是不成体系，代码分散，问题解决不彻底，时间长了代码很难管理，方案2代码收敛，思路单一清晰，缺点是可能会有性能问题，方案3相对是比较完善的方案，缺单是改动较大，现有富文本编辑器实现实时拼写检查存在技术挑战和性能挑战。

最近一年大事挺多的。

俄罗斯和乌克兰打起来了，历史关系太过复杂，现实问题又太过尖锐，俄罗斯保持区域霸主地位，乌克兰想要彻底加入西方的体系，总之都想过好日子。没办法，国际关系就是这样现实主义的，用权利保证自己的安全，用实力正确最大的利益，国际关系是正儿八经的丛林法则，不是你死就是我亡。很多中国人太善良了，经常性的把博爱平等仁慈放在国际关系中，真的愚蠢至极。

俄罗斯和乌克兰打就打吧，美国带着北约，裹挟着欧洲就跟进上了，彻底的成为了代理人战争，俄罗斯到底是能源大国和军事大国，搞得欧洲能源危机，经济危机，社会政治危机一块来。

我们离战争非常之近了。

国内疫情也是此起披伏，按下葫芦浮起瓢，十一过后全国到处都有疫情出现。中国国内走的是“清零”“封城”的政策，基本上就是通过限制人员流动来控制疫情发展。很多小地方基本上是完全限制人员流动。每三天做核酸检测，看健康宝，行程码，进不去，出不来，感觉到了世界末日一样。

党的二十大胜利召开了，习总依然在任，希望能在任期内带着中国走完崛起之路，任重而道远，稍有不慎，中国就会走上日本的老路。

说了那么多大事，聊聊自己吧。

年龄越大心事越多，想的越多越迷茫，很多事不如意，很多事真糟心，工作有工作的烦恼，生活有生活的不易，孩子在哪上学搞的我全无头绪，职业目标何时实现也是找不到北。

越来越想用手机填满时间，越来越觉得人生的无聊，往前走一步似乎还是长夜漫漫，往后退一步似乎也是风平浪静。

生活平虽然淡如水，但我不想看新闻，平淡才是生活本真，平凡也是人生要走的路，踏踏实实只为让生活平淡一些，小心谨慎只为让工作平稳一些，努力奋斗只为让人生平凡一些。

看着孩子越来越大，很多盆友有两个娃了，自己也挺羡慕的，可是我也没有那份 勇气再来一个，从生物学上说，孩子越多越好，这样才能让自己的基因尽最大可能不断传递下去，可是想着我小时候过的穷日子，想想算了，谁来到这个世界上都不容易，孩子到了咱家尽量给他点好的环境，兄弟姐妹他可以以后在社会上找，爸妈就不给他了。不过就一个孩子想想也挺孤单的，人都是群居动物，希望和他人在一起，年轻不在乎团聚，老了可能需要。话说回来，以后的事谁知道呢。

不管怎样，保持平常心，活出点自己的精彩也就够了。

如果对编译器或者语言编译技术感兴趣，可以研究一些JavaScript解析器。

常见的javascript解析器(JavaScript parser)列表

terser

A JavaScript mangler/compressor toolkit for ES6+.

jsep

jsep: A Tiny JavaScript Expression Parser

jsep is a simple expression parser written in JavaScript. It can parse JavaScript expressions but not operations. The difference between expressions and operations is akin to the difference between a cell in an Excel spreadsheet vs. a proper JavaScript program.

slimit

limIt is a JavaScript minifier written in Python. It compiles JavaScript into more compact code so that it downloads and runs faster.

SlimIt also provides a library that includes a JavaScript parser, lexer, pretty printer and a tree visitor.

uglify-js

相关资源:

https://github.com/mishoo

http://lisperator.net/

Esprima

相关资源:

https://ariya.io/about

https://github.com/ariya

acorn

相关资源:

https://marijnhaverbeke.nl/

https://github.com/marijnh

@babel/parser

espree

相关资源:

https://github.com/nzakas

https://humanwhocodes.com/

TypeScript

sucrase

相关资源:

https://github.com/alangpierce

swc

相关资源:

https://github.com/kdy1

https://kdy1.github.io/

esbuild

相关资源:

https://github.com/evanw

http://madebyevan.com/

recast

相关资源:

https://github.com/benjamn

https://www.quora.com/profile/Ben-Newman

jscodeshift

相关资源:

https://github.com/fkling

https://felix-kling.de/

esprit

A JavaScript parser written in Rust.

ASTExplorer

pyjsparser

Fast JavaScript parser - manual translation of esprima.js to python. Takes 1 second to parse whole angular.js library so parsing speed is about 100k characters per second which makes it the fastest and most comprehensible JavaScript parser for python out there.

其他的相关解析器

css.js

A lightweight, battle tested, fast, css parser in JavaScript

本周工作思考

• Web端Tab组件改造升级
  • Web端的Angularjs版的Tabs在实现是上复用了原来Tabs指令的API，保持API的兼容性，内部实现完成按照新Tabs的样式和布局， 这样能方便现有的老Tabs直接替换成新的，样式上直接复用umu-design的Tabs组件。这种实现方案的好处是方便现有组件的替换，都是Angularjs框架，现有的Tabs现实都能替换，即便使用React版本的也需要包装一次。Tabs本身实现就比较简单，从开发方便性上来说，反而不如直接使用Angularjs快速省事。
  • Web端Tab组件使用主要有2种形式，包括Tabs指令，HTML的
    或者
    形式。Tabs指令的形式因为新老Tabs的API是兼容的，所以直接替换指令名称即可。对于后一种形式，相当于重构，涉及到点击事件，样式布局，Tabs数据的整理等功能问题，相对复杂一些。目前涉及这类的改动大概有30多处，加上功能自测和样式Reivew，整体工作量比Button替换要大很多。
    替换范围上这次是整体提测，Button涉及面太多，查找和功能回归是占用开发时间的大头。Tab相对来说涉及面没有那么大，总共有七八十处，层级不会太深，所在的功能也比较明确，出现遗漏的情况会比较少。另外涉及部分代码的重构，避免过多的代码冲突，需要整体性的快速搞定。
    All hands上东朔老师分享了很多有价值的方法论和现身说法的案例，非常值得借鉴和学习，比如做事要提前谋划，提前准备。我最感同身受的是很多结果是由之前的很多细节和努力累积而成。今天的任何好的或者坏的结果都是之前的行为导致的，认真踏实的活在当下，才能创造更好的未来。

很多人在思考问题时，有一个根本问题没有搞清楚，那就是自己的立场。如果一个人的思考范围是一个圆，立场就是这个圆的圆心，思考工具、思考材料、思考方法、个人经验都是圆心之外的辅助。

立场是一定存在的。在生活工作中，你做的任何事情的背后都有立场的存在，有些立场藏得很深，七转八绕才能看见真正的立场，有的立场很明确，一眼就能被看透。当我们在争论一个技术方案，讨论一个社会问题时，所有论点的背后那个不动的东西就是立场。比如现在俄乌战争，很多人的言论是支持或者同情俄罗斯，很多人是支持或者同情乌克兰，也有很多人的是中国如何在这场冲突中的选择，各种观点都有，但是所有这些言论的立场基本上都是这场战争对我们个人意味着什么，趋利避害是在关于战争话题讨论中最根本的立场。立场丰富多样，其实是有限的，可以被识别的。这个世界复杂多变，很难理解。确立正确的立场才能更好的生存。没有立场的灵魂是苍白的。

本周工作思考

• Web端Tab组件开发和替换
  • 这个项目比我预想的要复杂一些，整体来说技术复杂度较低，业务复杂度一般，涉及到的面太多，有些tabs是统一组件，有一些统一组件，对于改动频次非常少的tabs使用暂时使用样式上优化。二级Tabs和三级Tabs使用量比较大，组件替换1是要处理样式和布局问题，比如原来的布局或者布局不合适；2是要验证逻辑的正确性，tab的点击处理存在不一致的情况，所以所有需要替换的地方都要验证到；3是要走UI review，对部分页面整体效果做一些微调；目前web端大概有70处二级Tabs和三级Tabs。
  • CEO talk上东朔老师提到了做事的思想对我触动很大：把重复的事提炼成流程，而流程则需要持续的改进，这是概括了6sigma里很多的理念，像我们开发中的很多事情其实是存在大量的重复，小到文案样式，大到页面设计，有很多技术是解决重复这类问题，比如组件化技术，动态化技术，跨端技术，脚本化技术等，但是开发过程也有很多的小的重复，比如代码拉取合并、发布部署等等，这类动作日常做的多了，就习以为常了，恰恰是这类事情最需要做成流程化的，另外对开发组织来说，能流程化的才能真正的固化下来，形成组织能力的一部分。以后的工作中增强这种意识把重复的事情尽可能以流程的形式固化下来，提升研发效率。

利用假期好好学习一下《赢在中国》里面的很多观点和思考。摘录了马云的一些点评和观点，有些可以理解，有些还需要继续琢磨。使用“把书读厚”的方式来读。

少做就是多做，不要贪多，做精做透很重要，碰到一个强大的对手事，不要去挑战它，而应该去补充它，做它做不到的，服务好它，先求生存，再求战略，这是所有商家的基本规律。

主题20问：
1，商业的基本规律是什么？包括哪些内容？
2，怎么理解“少做就是多做”？
3，少做为什么就是多做？
4，在一个范围和程度内，如何评估是多做了还是少做了？
5，“少做”的付出是什么？结果是什么？副产品是什么？
6，“多做”的付出是什么？结果是什么？有何不好的影响，有何好的影响？
7，如何统筹理解“少做”和“多做”的现实关系和取舍，
8，从发展的角度，如何动态的调整“少做”和“多做”
9，少做和多做的关系，背后的根本原因是什么
10，举一个例子说明，少做 比 多做 更好或者更坏？
11，举一个例子说明，多做 比 少做更好 或者更坏？？
12，做精做透的内涵是指啥？
13，如何找到强大对手没有做好的的地方？
14，如何界定“挑战”和“补充”？
15，如何低调的发展，不让对手所有防范？
16，生存和战略是企业中始终要思考的问题
17，商业的本质是什么？
18，如何看待和竞争对手的关系？
19，从18的思考开始，这一点往深里思考，涉及到了一个人的商业价值观？本质上我们如何做生意？做生意为了什么？
20，“少做就是多做，不要贪多，做精做透很重要，碰到一个强大的对手事，不要去挑战它，而应该去补充它，做它做不到的，服务好它，先求生存，再求战略，这是所有商家的基本规律。”这就话到底该如何理解？

这世界上没有优秀的理念，只有脚踏实地的结果。
主题20问：
1，‘理念’到底是一种什么东西？
2，‘理念’是如何形成的？
3，‘理念’是如何影响我们的思考和行为的？
4，如何定义的结果？
5，要用哪些维度来定义结果？比如 时间、金钱，情感，情绪，认同，心理，享受，体验等等
6，你能举例说明，影响你自己的理念有哪些？
7，如何定义“优秀”？
8，如何定义“优秀的理念”？
9，尽可能多的举例你所知道的“理念”？
10，从上面列举的“理念”中，你认为“优秀的理念”有哪些，说明你的理由？
11，“脚踏实地”用来形容怎样的一种行动？
12，“脚踏实地的结果” 和 不“脚踏实地的结果”有何区别？
13，如何理解 “没有…., 只有…” 这种句式？
14，如何理解“这世界上没有优秀的理念，只有脚踏实地的结果。”的积极意义？
15，如何理解“这世界上没有优秀的理念，只有脚踏实地的结果。”的消极意义？
16，如何创造/发明一个‘理念’？
17，从“理念”到“结果”，中间到底要经历什么？
18，”结果“如何达成？
19，说说你的“理念”和“结果”的辩证关系？
20，从因果论的角度，简述【9】中的一个理念，在你的工作生活中形成了怎样的结果？

永远不要让资本说话，要让资本赚钱。
主题20问：
1，资本永远是贪婪的
2，资本不是万能的，他可能不会说话，很可能说的不对
3，资本的目的是赚钱，让他说话，他也会嫌累，不在其位不谋其政
4，契约很重要，明确企业的目标和责任义务，约束资本的目标和责任义务
5，坚定自己的立场，明确自己的存在的价值，资本要是说话了，就没你啥事了
6，资本也是脆弱和敏感的，资本其实非常脆弱，抗压力是最弱的，最值得保护的
7，说的好听点的，资本想是企业的爹娘，能给你企业温暖和基础的生命力，但是企业不能遇到啥事都找爹娘，但是爹娘对企业的啥事有都爱操心
8，说的不好听的，资本是苍蝇，不管是臭味的蛋，还是香味的蛋，只要让它看见缝，它都想盯一下

我觉得一个好东西往往是说不清楚的，说的清楚的往往不是好东西。
主题20问：
1，哲学思辨色彩浓厚，背后是丰厚的经验和敏锐的洞察，这种能力很难轻易获得
2，这个论断的一个背景思考是，分类思维。“东西”很多种类，这里的“东西”应该是“创意”，“观点”，“方案”，“战略方向”，“思路”，“思想”等
3，我想起了一句老话，只可意会不可言传。
4，当然很多“好东西”是说的清楚的，说不清楚不是好事
5，这里的说不清楚的意思应该是指，没有更多的基于事实的数据，现象或者现有的理论让别人相信或者理解你所说的内容（如2所列举的那些），经过若干时间后，这些内容直接或间接造成的后果被证实是符合预想的
6，说的清楚的往往不是好东西，这句话其实很有深意。试想我们身边什么东西是你说不清楚的呢？或者说的清楚呢？每个人很难对身边的所有的现象能用现存知识说清楚，即便是再博学的人
7，说不清楚 意味着可能2个事，1是你的本身的知识太少，不足以说清楚，2是内容本身足够复杂，你说不清楚
8，作为工程师，不管是好东西还是坏东西，都要有说清楚的能力，这是非常基础和重要的能力，说清楚的东西才能成为一种现实，才能作为技术决策的因素

我没有关系，也没有钱，我是一点点起来， 我相信关系非凡不可靠，做生意不能凭关系，做生 意不能凭小聪明，做生意最重要的是你明白客户需 要什么，实实在在创造价值，坚持下去。这世界最 不可靠的东西就是关系。

关于【关系】20问：

• 1，为什么说关系不可靠？
• 2，这个“关系”本质上什么呢？
• 3，关系有哪些分类？
• 4，何时需要关系？
• 5，何时需要主动的稳定关系？
• 6，何时需要增强关系？
• 7，何时需要减弱关系？
• 8，何时需要主动断绝关系？
• 9，我们需要什么什么样的关系？
• 10，形成关系的因素是
• 11，可靠的关系是什么样子的？
• 12，做生意为什么要凭关系?
• 13，关系对于生意人意味什么？
• 14，关系的生命周期是怎样？
• 15，如何从无到有的创建一个关系？
• 16，如何处理多个关系之间的关系？
• 17，关系怎么产生利益？
• 18，关系会对目标达成产生什么样的影响？
• 19，关系的的负反馈是什么？
• 20，关系管理的原则是什么？

本周工作思考

• 关于软件价值\设计价值\代码价值\时间价值的简单思考
  • 优化点或者bug改的多了很容易让开发者进入“就事论事”的思考方式，认为这个有bug了，就改这个地方，软件从构成上来说是一行行代码，一个个组件或者模块，实际上软件一个极其的复杂的系统，规避复杂的思路不应该是不动其他地方，不往深里改，正确的思路在理解软件系统运行方式的基础上找到最正确的方法，这个最正确是从整个系统来说的，对系统的长期运行、扩展、性能来说最合适的， 而不能站在某个优化点或者某个bug上来说。以我的经验，从任何单个优化点或bug问题本身来说，稍有经验的开发人员都能给出至少5种不同的修改方法，但是如果从维护整个系统健康的角度来说，正确的方法比较有限，一般能够想到2种就很不错了，再加上时间、成本、研发能力之类的约束，对一个问题能找到一个完全正确方法并且能执行，其实是不太容易的。所以有时候我们会陷入一种技术决策纠结，对待一个bug，我是用简单的不太正确的方法改呢，还是用正确但是有些困难的方法改呢？我相信每开发人员每天都会都会碰到这类问题，我也是一样，有时候在这个上面花的时间比实际写代码的时候多。我也在不断思考这类问题到底该如何回答，到目前为止，我也没有思考清楚这个问题该如何解答，如果从代码修改上的“政治正确”上来说，那肯定要选择最后一个，要困难但是正确的，实际如果要细细思考，答案远没有那么简单，不过以我的思考和实践来说，要回到系统设计本身来说，这个出问题的背后的设计到底是解决了什么问题，针对这个问题，现在解决方式能不能促进这个问题的解决呢？如果能促进这个问题解决，那能不能推进这个设计的优化呢？如果能促进这个设计的优化，那能不能改善这块代码的质量呢？如何能改善这块代码的质量，那能不能花更少的时间呢？这个思考模型是从大到小的逐层深入的思考，依次是软件价值，设计价值，代码价值，时间价值，从这四个价值上判断修改思路是否合适。
  • 软件价值，设计价值，代码价值，时间价值构成了我对一个技术决策的价值观的判断，软件价值代表了给用户解决的问题，可以一定程度上体现商业价值，设计价值是对软件运行的保证和守护，代码价值则代表了技术本身的价值，时间价值则代码完成这件是要花费的实实在在的成本，在公司里我们所在的一切首先是指向商业价值，如果一件事情从各个角度看都没有直接的或者间接的关系，或者价值传导链很长，那这件事存在的合理性就很值得质疑了。同样的当一个系统具有软件价值，但是不太有设计价值时，那么这个软件的运行，扩展，迭代，维护都会面临巨大的挑战和负向的风险，这种情况会非常影响软件价值的实现，甚至会反噬软件价值，代码价值的实现则会增强设计价值，不合适的代码会影响架构的实现，进行影响到设计价值。
  • 很多bug和优化点的实现方式主要在代码价值这，如果实现方式是可以实现设计增值，那种方式才是最正确的方式，可以简单概括成一个有意思的公式
    修改一个bug的方法的收益价值 = （软件价值＾3 * 设计价值＾2 * 代码价值）/ 时间价值＾2, 如果有伙伴真的碰到了一个纠结的技术问题，难于决策，可以尝试这种思路，假设每个价值单位 都是正整数，按照这个公式算就会发现，很多看起来“政治正确”的方法，因为增加了时间价值，所以收益价值小于正常改的情况，因为时间价值2次方的关系，但是如果对软件价值有增加的话，会极大的增加整个收益价值，当时时间价值是否要二次方关系，要看开发者所在岗位的成本价值。

本周工作思考

• Web 按钮组件升级及UI规范化优化升级
  • 目前按钮替换涉及到部分样式的修改和调整，在开发过程中遵守一些开发原则：
  • 样式上新增，不减，适当修改
  • 代码上保留原来的按钮代码实现，方便出现问题快速定位，等到过2,3个月后再删除
  • 风险较大的修改，首先考虑不出bug，宁可不替换原有按钮实现，但必须使用规范的button style，保证样式一致性
  • 但凡有修改，必须见到按钮看样式，看点击事件
  • 深度隐藏的按钮，同步UI和QA
  • 分批修改，分批提测
  • 按钮涉及到很多功能的实现，也意味这一定风险，可能出bug的点主要是一些条件控制的功能上，比如在特定小节的按钮，国际化的语言的展示问题，受时间或者自测覆盖的限制可能会有遗漏，不过严格按照 【但凡有修改，必须见到按钮看样式，看点击事件】的原则，出功能问题的概率比较小。
  • 按钮替换十一前会完成web页面的一级页面和二级页面的替换，点多面广，工作量比较大，web端的代码从6年前到现在代码都有涉及，按钮写法也不太一致，主要考验耐心认真和代码与功能的映射的熟悉程度，需要对每个修改点都要自测覆盖，仍然会有可能的遗漏，比如按钮再不同条件下class会有不同，动态生成的button等涉及逻辑问题都是需要重点关注的
  • 关于小节排序拖动异常的bug排查过程总结
  • 小节排序的拖拽排序有一个bug排查前前后后花费了1天多的时间，排查和过程过程让我印象深刻值得思考。
  • 场景是这样的，在章节内，反复快速拖拽排序，持续2分钟左后，会出现被拖拽的小节存在两个，原位置有一个，目标位置有一个，持续大概2，3秒后，原位置的消失，恢复正常。
  • 刚看到这个问题时，我是觉得有点不可思议，我的第一反应是渲染那出的问题，但是不至于这么慢，这是让我疑惑的点。所以我需要找出渲染在哪慢的。
  • 首先是从实现路径上排查，拖拽排序在实现上有三个过程：1 数据的处理，就是数据在数组中的移动，2是拖拽效果的实现，3 是dom的渲染，这个主要是依赖angularjs中ng-repeat指令的渲染，从逻辑上来说这三个点都有可能出现，这种情况下要么依次排查，要么盲猜一个可能性最大的，这种情况下，我相信直觉一些，选择直觉最大的一个可能，就是ng-repeat那慢了，于是我仔细排查了ng-repeat的使用，我发现没有使用track by，这会导致整个小节列表的渲染是全量的，于是我加上track by，修改之中发现问题已久另外还引起了Unique ID重复的问题，由于我还是认为track by可以解决这个问题，但是现在没有生效，有点让我困惑，于是我深入查看了ng-repeat的实现，考察它是如何实现dom渲染的，如何利用track by，它的实现如何受脏检查影响，是否技能存在性能瓶颈，看完之后我的结论是ng-repeat看起来没有性能瓶颈，即便不使用track by。此时陷入僵局，直觉不管用了，只能在看其他的过程。
  • 数据处理比较好排查，在删减数据的过程中，分别打上性能log，观察执行时间即可确认是否有问题，通过分析日志发现，数组的变化都是在拖拽动作完成后即时完成的，我反复试了多次，数据都是正常的。从这个结果上看，排除了数据变化和拖拽两个阶段，因为在发生bug的场景下，拖拽完立即有数据变化，拖拽过程和数组变化都是正常的。那么bug就出渲染上了，但是ng-repeat的排查没有发现问题，于是我又想到是不是可能从脏检查入手可以发现点蛛丝马迹，把触发脏检查点，以及脏检查的使用是否合适都检查了一遍，并且在脏检查处打了log观察其执行，发现数组变化会立即触发脏检查，进而执行相应的watcher，这块也没有认为可疑的点。这个bug看起来是没法解决了。这时我突然想到一个关键的点，就是究竟是谁触发了dom的删除操作？通过对dom操作的调试发现，dom的操作竟然在动画服务里，可是我在代码里没有使用动画，这个是啥原因？于是顺着堆栈一行一行代码往前倒腾，终于在茫茫anguarljs源码里找到了一个我熟悉的代码，ng-repeat的实现代码。原来ng-repeat的代码里使用了动画，删除动作会被放入动画队列，因为小节删除的的整个交互和实现比较复杂，影响了动画的性能，所以排在动画队列最后的小节dom删除就会2,3秒之后执行。
  • 原因找到了，一般修改基本上很容易了，不过这个原因的层次比较深，出问题的代码再anguarjs里面，所以如何优雅的禁用此处的动画就成了解决的问题关键，在使用上ng-repeat没有关于任何动画的使用的API，只能另寻他途，在深入研究了动画的源码后发现，动画服务里面有个一个customfilter可禁用动画，到此问题也就解决了。
  • 通过这个排查过程，我觉得反推法结合第一性原理的应用会比较快的找到问题所在，简单来说直接从病灶出发，其实这个bug的解决的转折点在通过dom删除的代码入手，回到场景上上看要被删除的小节2,3秒后才被删除，这个现象的背后就是dom删除被推迟了或者dom删了渲染慢了，通过现象可以直接排除渲染慢了，因为如果渲染有问题，拖拽过程会很卡顿，实际情况是拖拽很流畅，所以问题在dom删除慢了，以第一性原理的思路，反推为什么dom删除慢了的本质原因，也就找到了了这个问题的修复思路。

本周工作思考

• 按钮替换这周把课程的替换完了，涉及到react的替换了一部分，主要碰到问题主要是按钮组件不太符合规范，比如置灰状态，动画状态等，另外一个常见问题是直接是HTML插入Dom的情况，这种没法使用组件，目前直接应用的按钮样式。另外在button渲染上目前是直接用的angularjs的实现，下周会改写成react组件render的情况，外面使用适配器的形式包裹起来。
  • 组件依赖管理一直是比较费时的问题，往往修改一个样式需要从几级的依赖npm中找到对应的修改点，这个问题非常影响前端的开发效率，这种问题在优化点和bug修复，文案调整上比较明显，所以九十月份我们会集中一部分精力完成npm包依赖的改造和优化，提升小问题的修改效率，进而提升前端工程能力；目前的前端的技术体系已经不是创业型公司的那种常见工程架构，整个前端技术和工程体系及对应的流程是按照二十人左右的工程团队适配和设计的，所以在当下阶段我们要适时变化，适应发展，优秀的团队是能够适应发展和变化的团队，就像云端计算能力能够实现自由伸缩，工程团队所采用的方法和机制也应该是这样的。在质量和性能这两个核心要求不变的条件下，项目开发流程，代码交付过程，bug修复过程，技术选型过程，团队建设都需要适时变化顺应公司发展战略。
  • 东朔老师在CEO Talk上对优化点和重点项目安排上背后的思考我个人觉得用意深远，也是非常务实的设计，从研发角度来说，20年和21年的快速发展给我们工程上带来了很多新东西，包括技术，理念，机制，流程等等，这些东西能否真正适合我们的可持续发展和我们企业的特点，能否化为我们自己的血肉和力量，我觉得真的需要一个阶段来沉淀和总结以及批判式的吸收，这样才能内化为我们的自己的可以成长的能力，对工程能力来说，可以成长的能力我理解为工程能力，否则可以称之为生产能力，工程能力转化为生产能力需要一个过程，最近我也在看我能接触到一些SaaS企业的工程发展史，比如Salefore，微软，用友，纷享销客等，以我的浅陋思考，我发现她们的发展路径都是螺旋式，我觉得这对我是一个很好的启发。