刚入职某大厂，面对之前遗留的大量糟糕的前端代码，该怎么办？

自然是摆正态度，坦然接受。

大多数时候，我们面对其他人写的代码时，都会觉得写得烂，写得糟糕。有时候就算是面对自己一年前写的代码，也会觉得这是写的什么鬼，然后一看注释，发现是自己写的。

所以，只要之前的代码运行起来没有问题，也就不需要去管它。如果是遇到刚好需要去修改这部分代码，那就是需要改哪里就优化一下哪里就行了，也没有必要看不惯就全部重新弄，浪费时间，说不定还会产生其他的问题。

曾几何时，我也属于这种看不惯别人写的代码的程序员，在接手一个模块时，干的第一件事情就是把整个模块代码全部重构了。由于不能耽误项目进度，完全就是靠着自己加班去整的，结果后来还是出了一些小bug。但事后想想，这些投入的必要性并不强，因为在随后的迭代中，我当时重构的这个模块又经历了很多次的迭代，一些大版本的迭代时，本来就涉及到整体代码的改动，完全没有必要在当时做这件事。

所以，现在当我看到别人写的代码时，更多的是去读其中的逻辑，然后理解，在适当的时候优化其中的一部分。反正随着项目的不断进行，大部分的代码最终都会被新的代码所替代的，不用急于一时。

我会花一些时间把页面整理干净、整齐，受不了没有层次和段落的页面，哪怕注释少些都可以忍受，但是没缩进的不能忍受。

后端程序员写前端时感觉非常的耗时耗力，且代码质量不高该怎么办？

首先搞明白什么是前端？用大白话来说前端就是精装修公寓，它作的主要工作是把毛坯变成精装修。

1、前端要做什么？

把UI设计用代码实现

2、前端的主要工作？

交互逻辑实现，数据接入处理实现，样式实现。

3、为什么后端写的前端有一种无力感？

因为后端做的更多的是数据处理相关方法，更多的是底层数据交互；前端呢？前端要做的是搭建UI层和数据层并做交互；

后端对于前端最大的困难是UI搭建，UI搭建首先需要要有空间感，如同cad制图一样，同时前端UI搭建的基础知识也必须的清楚，流式布局、弹性布局、定位布局、块状元素、行内元素、文档流、伪类、BOM、DOM等等。

那就用webassembly技术吧，不用写js

有些人写一天代码要找半天BUG，大家觉得是编程能力的哪一方面出了问题？

写一天代码，找半天bug？那还用说，肯定是你编程能力出了问题。

代码产生代码类型的bug，一般是自己编码不够规范，或者不够严谨导致的。要不怎么说良好的代码书写习惯，是判定一个程序员是否优秀的呢。

这类bug的出现，绝对是最头疼的，而且往往出现的bug非常奇葩。想要猜出这类bug，需要结合更多的信息，不如log、场景、时机、数据等等，还需要一点经验。

产生这种bug，真的非常头疼，绝大部分情况下写“写一天代码，找半天bug”就是源于此。所以，优化一下自己的编程习惯吧。

策略有一种类型的bug，就是自己的策略出了问题，自身代码设计有缺陷。这说明你的代码局部，或者全局构造能力出了问题。

这类bug，功能映射到的代码设计有缺陷，猜这类bug也不简单。要找这类bug，要回想自己整体的设计似乎，或者根据bug发生的场景、时机，推算可能存在错误的设计思路。

悲催的是，如果存在很大的错误，那基本上就要重新调整了，会很痛苦。

以上两种情况，就是我们说的，程序员的编程能力出现了问题。另外还有一种原因：

业务对业务流程、需求逻辑的理解，或者业务代码设计出现偏差，都会导致出现业务类型的bug。

这类bug，相对而言比较好解决，要么就是文案错误、信息空缺、要么就是集合元素缺失等等。重新理解业务逻辑，比较好猜出问题所在。

所以，要想不出现“写一天代码，改半天bug”的情况，就尽量不要出现代码类型的bug，少出现策略类型的bug，业务类型的稍微多些。当然bug还是越少越好……

建立自己的bug库要想快速找到bug，必须建立自己的bug库，这里所说的库，不是说做做笔记什么的，而是对各种bug理解认知之后的集合。

你要明白，一个人在开发过程中，遇到bug很局限的，所以，你最好和你的同事组队。当同事出现bug，如果你不是非常忙，最好帮他参谋参谋，这是扩大自己bug库的好时机。

除了自己的bug和同事的bug外， 还有很多bug是我们不熟悉的。 当自己的bug库有了一定的积累， 定位bug有了一定的经验和心得后，可以去逛逛论坛、交流群、博客等，见识见识别人的疑难杂症和解决方案， 这会有助于提高自己bug定位能力和解决能力。

如果能有上述或类似的一些习惯，我相信用不了多久， 你们代码中的bug会越来越少，定位bug也将会轻车熟路， 个人能力会得到很大的提升。

这款可视化神器查找Bug更容易——Anteater追踪程序执行过程，让Bug定位更迅速

代码调试一直是让广大程序员头疼不已的工作，新人尤其容易中招。最让程序员们抓狂的情况莫过于程序没有报错，输出的结果却不符合预期，如果面对的是一个冗长复杂的程序，则更是无从下手。

程序调试的一种常见做法是手动检测程序，收集可疑变量x（下图第一行）并打印出x的值，通过观察x值来发现bug，但这种方法本身很容易出错；另一种常见的做法是设断点调试（下图第二行），使用调试器自动停止程序执行，并单独查看x每次的赋值，但断点调试往往只能逐次提供一个小的值视图，不方便观察分析。

已有的大部分可视化调试工具都有一个明显的缺点：缺少变量和表达式的全局值视图，而Anteater这个用于跟踪和探索程序执行的交互式可视化系统则克服了这个困难。Anteater能够自动检测源代码，捕获程序执行的行为以及用户指定的变量和表达式，然后通过交互式可视化呈现程序执行的信息。

Antater能自动插入代码，跟踪变量及其执行结构的上下文。它向程序员提供了交互式可视化功能，并提供了值的全局视图，从而可以轻松地检测错误值并进行交互；缩小可视化范围，从而可以检查特定的值，更容易发现bug。

下图展示了Anteater系统的工作流程。首先，用户使用Anteater接口选择要跟踪的变量，定义跟踪规范。这个跟踪规范与源代码一起，通过Web接口发送到Python后端。然后，Anteater跟踪程序，检测源代码，以收集执行信息以及指定的值。下图右侧显示了该系统的简化版本，在对代码进行检测之后，使用python来创建程序跟踪。这个跟踪通过Web界面传回到Anteater前端，进行可视化并呈现给用户。

Anteater可提供跟踪变量的接口。比如，在下面的Python代码中，用户可以选择想进行跟踪的变量和表达式，右键单击，进行跟踪。用户还可以选择函数调用和库导入，将它们从跟踪中排除。

为了展示Anteater在变量跟踪中的强大功能，用Anteater来分析一下六种梯度下降算法的效果。观察的六种方法依次是Vanilla, Momentum, Nesterov, Adagrad, Rmsprop, 和Adam。交叉点的数量（变量num_intersections）以及最小交叉角度（变量min_angle）这两个变量在梯度下降算法的每次迭代中都会改变，通过观察这两个变量值的变化来判断几种算法的效果。

下图展示了通过观察变量num_intersections的变化来选择梯度下降算法的过程。（目标：最小化num_intersections） （A）图概述了6种梯度下降法的行为，观察散点图可知，最后三种方法（Adagrad, Rmsprop, 和Adam）会立刻卡住。因此，下一步只需比较Vanilla, Momentum和Nesterov这三种方法的效果。（B）图中的Vanilla梯度最初朝着一个较差的值（一个大的值）移动，但在最后下降到了一个较好的值（一个小的值）。（C）图显示了在Momentum法中，每次num_intersections下降到一个较好的小数值时，又会重新跳到一个较差的大数值上，而（D）图中的Nesterov方法也有这样的特点。因此，从优化num_intersections值的角度考虑，Vanilla梯度下降法效果最好。

下图则展示了通过观察变量min_angle的变化来选择梯度下降算法的过程。（目标：最大化min_angle）（A）图概述了6种梯度下降法的行为，观察散点图可知，最后三种方法（Adagrad, Rmsprop, 和Adam）要么立即卡住，要么只是略有增加。（B）图中的Vanilla梯度一开始表现较差，但经过一段时间的迭代，最终达到了一个较好的大数值。（C）图所示的Momentum法，每当min_angle达到一个较好的大数值时，就会迅速开始下降。（D）图中的Nesterov也表现出类似的规律。因此，从优化min_angle值的角度考虑，仍然是Vanilla梯度下降法效果最好。

Anteater的开发者还在TE问题（Tennessee Eastman）上进行了挑战，提出了一个化工厂的开放基准，考虑了真实世界中的各种复杂因素，以此来展示Anteater在工业应用中的可行性。

（F,G,H表示三种产物，NaN值代表装置爆炸的设定值，即当反应堆压力超过3000kPa时,会发生爆炸。）

上图是使用Anteater系统进行的展示。（A）图表明成本（Cost）和总产量（Total Production）相关，可以找到低成本且高产量的解决方案。 黑点表示在优化的最后一次迭代中达到的解决方案。 在（B）图中，反应器温度（Reactor Temperature）参数中较高的值对应更高的总产量（Total Production），爆炸可能性较小。 （C）图表明在优化过程中，H和G是相互竞争的关系，高G值对应低H值。 在（D）图中，反应器水平（Reactor Level）值影响产物F的产生，低反应器水平对应于高F产量，并且在更高的反应水平下，发生的爆炸更少。

上面这两个案例展示了Anteater可视化程序运行和发现程序问题方面独有的优势。至于如何更充分地利用这个神器，各位程序猿可参考：Anteater: Interactive Visualization for Program Understanding，用好bug查找神器，让代码调试更高效！

更多科技知识可关注 @人民邮电出版社 头条号，我们会持续推出优质的计算机知识和图书资源！