程序员如何成长？前人挖坑，后人填坑。写代码难免会出一些bug。没有人能保证自己写的代码不会出问题，那些没有被挖掘出来的bug就会成为哭笑不得的后来者。坑...这段时间，公司全面https改造涉及到域名的迁移。域名的迁移不仅仅是与nginx的映射。还有各种代码模式删除和各种组件的重定位。手术！我想最近百度主站也升级到了https。一定是期间出了问题。好像回滚过一次。他们遇到的陷阱应该不会太多。它只是www域的升级，而不是整个网络。公司最近有很多问题，有大有小。表面上看是前人挖的坑，其实是缺乏对整体架构的思考。当我们放下一个项目，转入下一个项目时，手头的东西就得交给别人处理，或者..没有人会处理，但是代码还在，说不定你会引用别人的事情，说不定哪天别人的代码爆发了大bug，当然这里的“他者”也有可能是你！我们既不想成为受害者，也不想成为加害者。一、如何挖洞挖洞不是一件简单的事情。您编写的插件、组件和代码很可能会被很多人使用。各种业务场景，你的代码乱跑，一堆测试人员测试你的代码。bug，所以给项目埋坑可不是件容易的事。那么如何埋坑呢？可以参考下面的解决方案：把一堆很长的代码放在一个文件里，不加注释，不解耦程序，把判断放在程序内部的一层深层逻辑中，临时加几个全局的Mark变量，多处改变变量的值，多处使用变量的值，不考虑多变的场景，不是实时容错，让他跑来跑去，根据你脑子的轨迹传播不同版本的代码，如果你不整理一个统一的文件，这些解决方案都不足以让你挖坑。我觉得你们组员的技术水平实在是太高了。很多时候，我们不经意间就留下了隐患。当我们写的东西被别人使用的时候，程序需要照顾的场景就会更多，就会出现更多的问题。这时候，我们就要改进我们的代码逻辑了。这样一来，逻辑耦合度高了很多，代码层次也深了很多，出错的概率也增加了很多。因此，在设计一个功能或组件时，必须明确哪些是应该考虑的，哪些是不应该考虑的。并非所有内容都适合添加到代码中。我们不是在做ExtJS的整体解决方案，也不是在编织一个底层运行库。我们只是用少量的逻辑来整合离散的、个性化的业务。逻辑越少越好，与核心逻辑无关的内容必须提取！2、在一堆庞大的文件中不容易发现“写等号作为标识”引起的bug。也许你在调试的时候输入了别人的代码域。别人的代码又长又没注释，我估计当场晕倒了。更晕的是，我还在想是不是这一堆代码的问题。在团队合作中，我们在心里默认信任我们的队友。队友出的代码，可以直接使用，没有任何问题。所以，一旦出现问题，我们更多的是怀疑自己。质疑别人是需要很大勇气的，尤其是那些成熟的框架，有多年代码的人。那么怎么踩坑呢？我们不喜欢踩坑，而有些坑一旦踩进去就跳不出来，只能选择其他方案来应对。很少有前端同学会写程序测试用例，可能还有一些同学从来没有听说过什么测试用例。在后端（比如nodejs），没有测试用例的代码就是一堆废代码，除了自己用，其他人不敢用。那么测试用例会考虑做什么呢？简单来说：写出有问题的代码，让程序按照预期的方式出错，如果没有，程序有bug写出好的代码，让程序按照正常的流程返回正确的结果，如果没有，程序就会失败有bug测试用例覆盖程序中所有的逻辑判断，比如ifelseifelse等判断逻辑必须覆盖。当我们的测试代码覆盖了100%的逻辑时，这个坑就暴露无遗了。埋葬者的致命弱点是他很少判断程序的异常。只要找出程序中的异常点，尝试换一种方式触发这个异常，就可以顺利踩坑！3、用力填坑首先，填坑是一种责任。发现问题是最难的，解决问题只是时间问题。当我们确认一个坑的时候，我们做的第一件事就是告诉别人这里有一个坑，千万不要踩。不过***又加了一句：先别踩，等我把坑填了再回来。我觉得这句话真的很暖心，程序员之间的关怀就应该如此赤裸裸。虽然，有时候，坑不是你挖的。挖坑的人还是埋坑的人。？这必然有利于增长。
