摘要：前端开发，有一项很重要的基本功，就是在大型项目中，比如几万行代码中，迅速找到新增功能或调试的切入点。猜测输入框大小跟这个字号有关系。通过观察分析和断点技巧，我们很容易地就从一个大型项目几万行代码中迅速定位到我们要修改的地方。
前端开发，有一项很重要的基本功，就是在大型项目中，比如几万行js代码中，迅速找到新增功能或调试bug的切入点。特别是你只是接手这个项目，并不了解其中每一个功能点所在的位置，也没有时间一行行读代码的情况，这个基本功显得尤其重要。
这项能力除了娴熟的调试工具使用技巧，更重要的还是对变化的观察力和总结归纳的能力。本文用一个讲一个功能案例的实现。
功能背景一款大型canvas应用。我们使用了一些开源库实现canvas上的文字与html文字的互转。使我们可以在一个输入框中输入文字然后绘制到canvas上去。也可以点击canvas上的文字然后通过开源库进行文字编辑。
要实现功能我们的canvas应用有整体放大缩小的功能。但是文本输入与我们的canvas应用是两个不同的体系，现在我们要对这个文本输入相关的库进行对应的放大缩小的调整。在canvas应用处于放大缩小的场景，text输入框对应放大缩小。并且在放大缩小的场景下对输入框中的字体的放大缩小，在回归到正常大小的时候。显示与100%时设置的字体大小相同。
目前的情况是应用处于放大状态时，输入内容以及转化到canvas上的大小依然是画布100%时的大小。然后当画布变回正常大小，之前绘制到canvas上的的文本就小的没法看了。
canvas应用放到大300%时文本组件的情况：
canvas应用放到大300%时绘制到canvas上的文本：
canvas应用回到正常100%时绘制到canvas上的文本情况：
首先观察输入框的大小什么决定。要先观察输入框的组成结构。查看elements，发现它是dom结构，没有在iframe中，也不是canvas绘制，先松一口气，看来仅仅是dom上的变换。
然后我们在输入框中输入，同时观察右边dom结构有什么变化。发现输入到第二个字符的时候多了一个带内联属性的font-size的span，我们输入的内定到这个span标签中。
然后通过输入组件的工具栏把输入的字体调整到其他字号。发现内联的font-size有变化。字体变大。输入框变大。
猜测输入框大小跟这个字号有关系。
在不同的缩放比例下，按照我们的缩放比例乘以100%状态下的的字体大小。就是在该比例下的大小了。
首先看span是怎么加入进去的，监听p的子节点变化。加一个dom断点。
监听到了appendChild。然后查看调用栈。
定位到这个位置，看到是在这里给span设置了14px的默认大小，修改它：
var scaleValue = $("#zoomIn-container").attr("data-float")||1;
me.mark("fontsize", 14*scaleValue);
刷新，发现打开输入框，输入框大小跟之前一样，输入第一个字时还跟之前一样，输入第二个字母，span出来之后，字体和输入框就变成当前比例下我们想要的大小了。
另外，发现那句代码有一句注释 16 to 14。
猜测之前有一次默认字体大小从16到14的整体改动。如果我们全局搜索一下16 to 14这个改动，也许会有意想不到的发现。
那么第一个字母的大小由什么决定？用chrome一看，由css决定。父元素的font-size决定。所以现在我们父元素的css要动态修改。在初始化输入框的时候就要设置好内联的css。如何知道在哪里初始化的文本dom，哪里改？
观察，发现输入框消失之后，整个输入框相关的节点都消失了。猜测整个输入相关的节点由js动态生成。于是全局搜索class名。
果然搜到，然后在dom初始化之后的代码中加入以下代码，设置字体大小。
// ls20180523 把传入的字体大小。根据当前比例做一个缩放。
var scaleValue = $("#zoomIn-container").attr("data-float") || 1;
$container.find(id).css("font-size",14*scaleValue);
刷新。初始框变大。第一个字母变大。继续输入字体依然变大。
然而输入第一个字母，点出去，发现绘制到canvas上的依然是100%状态下的14px。而输入多个字符的时候，字体是该比例下的大小。因为上面的观察我们知道只有一个字母的时候是没有span生成的，所以可能对产生的canvas字体有影响。 那么我们txt转canvas的函数可能也需要修改。
这个函数在哪里？是不是有这样一个函数？有什么办法知道？由前面的观察我们发现点出去的时候文本组件相关dom是会消失的。于是，断点它。
在调用栈里发现这样一个函数。果断进去看一看。
然后在这个函数里设置断点。重新操作，在里面一步步走一下。
很容易地，我们找到这个函数，并最终定位到这行代码。修改之。
//ls20180524 根据缩放比例调整。
var scaleValue = $("#zoomIn-container").attr("data-float")||1;
result = "" + matchTarget[1] + "
";
再测试。发现只输入一个字。到canvas上大小正确。
然而出现了新的问题。如图。这个字号设置的地方。显示变成了我们实际的大小值。实际应该显示的是我们dom上设置的大小值除以当前页面比例的值，才是我们100%比例时候的值。我们要找到它在哪里修改的。观察这个节点是何时从14变成这个值的。然后设置断点观察节点变动。到这个赋值的地方给值进行一个换算就可以了。
然后剩下最后一个功能。修改字号。修改字号后我们框里的字体大小应该是缩放后的比例下的这个字号的大小。只要监测相关节点的变动，然后切换一下字号，就可以找到设置span大小的节点。都很好修改了。
到这里这个功能就基本完成，哪怕是一个刚接手的项目，整个功能修改过程也不超过2小时。当然，后续还有问题要考虑，比如高分屏设备像素比的问题。
修改后，canvas应用放大300%时的字体组件：
到这我们就基本实现了我们的功能，代码量很小。要注意修改其他人代码的时候，要考虑修改的地方的方法的作用，使用范围等。尽量保证自已写的东西不会影响到其他可能的逻辑，要从代码编写者的角度进行多方面的思考。对于第三方库的使用，我们首先要考虑库原有接口的组合使用，在原有接口不足的情况下才考虑修改源码。
通过观察分析和断点技巧，我们很容易地就从一个大型项目几万行代码中迅速定位到我们要修改的地方。
github地址：https://github.com/liusaint/l...
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/95265.html
摘要：而测试驱动开发技术并不只是单纯的测试工作。需求向来就是软件开发过程中感觉最不好明确描述易变的东西。这里说的需求不只是指用户的需求，还包括对代码 可能很多人和我一样, 首次听到前端架构这个词, 第一反应是: 前端还有架构这一说呢? 在后端开发领域, 系统规划和可扩展性非常关键, 因此架构师备受重视, 早在开发工作启动之前, 他们就被邀请加入到项目中, 而且他们会跟客户讨论即将建成的平台的...
摘要：而测试驱动开发技术并不只是单纯的测试工作。需求向来就是软件开发过程中感觉最不好明确描述易变的东西。这里说的需求不只是指用户的需求，还包括对代码 可能很多人和我一样, 首次听到前端架构这个词, 第一反应是: 前端还有架构这一说呢? 在后端开发领域, 系统规划和可扩展性非常关键, 因此架构师备受重视, 早在开发工作启动之前, 他们就被邀请加入到项目中, 而且他们会跟客户讨论即将建成的平台的...
摘要：自动化接入和升级方案通过命令行工具提供一键接入升级能力，同时集成到团队脚手架中，大大降低了工程接入和维护的成本。原始代码经过解析器的解析，在管道中逐一经过所有规则的检查，最终检测出所有不符合规范的代码，并输出为报告。 引言 代码规范是软件开发领域经久不衰的话题，几乎所有工程师在开发过程中都会遇到，并或多或少会思考过这一问题。随着前端应用的大型化和复杂化，越来越多的前端工程师和团队开始重...
摘要：例如其中的为，但是数组中没有元素，是稀疏数组而每个位置都是有元素的，虽然每个元素都为，为密集数组。那稀疏数组和密集数组有什么区别呢在中最主要考虑的是两者在迭代器中的表现。截取并返回新数组为新数组容器。 卑鄙是卑鄙者的通行证，高尚是高尚者的墓志铭。 ——北岛《回答》 看北岛就是从这两句诗开始的，高尚者已死，只剩卑鄙者在世间横行。 本文为读 lodash 源码的第一篇，后续文章会更新到...
阅读 3803·2021-09-27 13:56
阅读 860·2021-09-08 09:36
阅读 746·2019-08-30 15:54
阅读 578·2019-08-29 17:29
阅读 913·2019-08-29 17:21
阅读 1662·2019-08-29 16:59
阅读 2725·2019-08-29 13:03
阅读 2945·2019-08-29 12:47
