20200508 工作日记

今日工作，go test 检查项目单元测试的规范。问题分三类，一类ERROR，二类FAILED，三类Panic，暂时我这里就是将问题分这三类。

今天下午遇到了三个Error的问题，报错信息，切片越界。

遂定位代码片段，查看上下文语意，猜测问题的背景是这样的：输入文件路径，截取最后一部分也就是整个文件名，然后根据一定的规则再截取前半段字符串作为表格名往外发。

说白了就是个字符串处理的问题，却极好的体现了写这段代码人的不专业。各种假设，各种依赖，各种异常流程都未考虑过，上来就是一个trim，然后直接一个lastindexof找中划线的位置，那他写这段代码的时候就是依赖传入的参数是他假设的那种情况（我重新读了一遍刚刚的这句话，没错，依赖他的假设，这不就是《从小工到专家》里面描述的的那样吗？）

我只听说依赖接口编程会比较好，依赖假设编程感觉就有点可怕了。

接口比假设好的原因，从人的记忆来看我觉得可以这么理解：人的记忆遵从7+-2原则，而且遵循艾宾浩斯遗忘曲线。其实就是说，过了一段时间人就会忘记以前发生的事情，不管这件事情在当时看来是多么重要，投入了多少精力进去。

不依赖假设编程的原因，在当时看从小工到专家的时候我就想过，主要原因还是假设的不稳定，以及依赖假设的语境的易忘性。当假设的条件稍微改变时，拍拍脑袋写出来代码的人自己短时间内可能会与自己愉快地达成了共识，但这些假设的改变只发生在这个人的大脑之中，运气好一点他还会将发生的一切以注释的方式持久化存储下来。但当别人看到这段代码，并不清楚这段代码的语境是怎样的，也不清楚这段代码的上下文是如何衔接的。（顺便说一句，我见过的编程专家，能够一眼看明白某段代码的意义，依赖于他常年累月看代码的经验。当积累的语境多了，也就大概能够才得到这段代码在写什么了。）从良好的命名规范，命名内容，再到注释，一切能够提供信息的信息，都在为语境的拼凑贡献自己的力量。而接手新代码的人，需要做的第一件事就是理解当时的语境。

语境很重要。回过头来看，不依赖假设的原因，是因为假设是善变的。而没有假设，就没有语境。

不依赖假设，有需要有语境，那就需要把假设带来的语境持久化下来，从这个角度来看，接口也可以看作是持久化语境的一种。

将语境持久化下来，方便后来者理解语境。

（当然，写代码的人那天的心情，中午吃的饭，写代码当天的天气等，我理解也是一种语境。但这些信息被高度降维到了一段代码里，着实不好辨认。更何况软件工程提倡的方法论，类似于工厂大批量生产机器，应该是不依赖于人的。所以软件工程这样的工程化学科是不希望代码有人情味的，而更应该专注于生产力，或者高效能。）

再给别人描述问题的时候，也是要尽可能还原语境，让别人理解这个语境才是有效的提问。报错信息是语境的一部分，代码片段也是语境，代码上下文也是语境，甚至测试数据也可以是语境。尽可能地将这些问题整理好以后发给对方，尽可能地还原整个语境让别人知道语境从而判断问题在哪，怎么解决？

 

工作的时候，以前看过的《你的灯亮着吗？》里面的内容总是会迎面袭来。你的问题是什么？这个问题是什么？这样做对解决这个问题有没有帮助？这些直击痛楚的问题在工作中一次又一次地考验着我。每天的工作，我的大脑都在疯狂地寻找两件事之间的相关性和因果性。不得不说，这样的寻找训练真的很锻炼人，或许这就是工科的魅力吧。

从小工到专家里面也有，记得没错的话是关于问题因果性的判定。书中描述：如果一件事情改变导致了程序运行失败，那就去检查这件事情吧。大概就是这个意思。这应该也是高中生物课本里设计的那些实验想要说明的控制变量法。而工作中，一件事情的原因 可能是多因素作用的结果，因素之间还可能相互依赖，这时候就有些摸不着头脑了，但掌握一定的方法论，还是能够解决这些工程问题的。

《你的灯亮着吗？》这本书太可怕了，我现在每天每时每刻都在按照书中的规则行事：

当我遇到问题时：我的问题是什么？

当别人遇到问题时：谁遇到了问题？他的问题是什么？

当别人说话时：他说这句话的重点是什么？

当别人发朋友圈时：我应该关注他这条朋友圈的哪个部分？

当我说话时：我的重点是什么？我想要他最关注我说的哪部分内容？

 

为什么我要这么做？因为我感觉这真的很有用。

就像上学时总有学霸能抓住上课的重点，别人说话时也能抓住重点这样的能力真的很重要。 

 

今天跟hz学到的解决问题的方法很好，值得记下来。其实原理很简单，只是我用得不太熟练。这个原理就是：

这个地方有问题，那么就去找找有没有相似的地方没有问题的。看看没问题是怎么做的，有问题就解决类。

 

这个问题解决了我因为两个环境go环境变量不匹配导致的问题。

一个环境是重装系统的环境，一个环境是没问题的环境。

重装系统的环境的go环境变量的goproxy以及gosumdb两个配置与正常环境不一致，那我只要让他保持一致就可以了。

结果确实是这样的。

这种解决方法的套路，翻译过来就是：见贤思齐焉。近朱者赤。向正常的环境靠齐。

 

 

最后再记录一个开小差的想法：

亚当斯密的国富论中将一根针分为16个步骤，从而带来了极大的效率提升。每个人平均从每天能做三根，到平均几百根，具体数字我没看，但就是说明了分工对于效率提升带来的影响。

我没有看具体书中对分工为何能带来效率提升的描述，但我联想到了cpu中断。

cpu中断，通过记录函数执行上下文等一系列资源作为代价实现了进程间的切换，cpu很快快到我们感受不到，所以cpu的中断就应该是被浪费了的吗？人的动作很慢，慢到从一根针的打磨流程和穿孔流程要花费许久的时间。在两件事间切换，人的精力，人的注意力，人的记忆都会跟着切换。cpu的中断同样如此。但cpu能够做到几乎为0的切换差错率。人的精力是有限的。

早期操作系统批处理阶段cpu的利用率也很高，就像人专心做一件事一样。但如果人分心，那么就会造成整体效率的下降。从这个角度来看，社会分工带来的效率提升的原因，从技术上来看是因为不分工带来的由于忙于多件事情之中的不专心导致的精力不集中，注意力分散等原因?这么说来，从单一应用，到后来的前后端分离，再到后来的微服务架构，带来的各种职业，架构师，码农，运维，CI，也是基于不希望人们分散精力到其他领域去，从而减少切换做事领域的代价，带来生产率的提升的吧。前端不再关注后端的实现，后端不再关注项目是怎么构建起来的，测试不再关注整体的架构，各个职业各司其职，彼此之间正交性极低，耦合度极低，生产效率极高。

什么，你说你的公司后端一个顶十个？那可能是你的老板在权衡利弊以后觉得，分别请运维+测试+后端的钱加起来不如直接给你1.5个人的钱划算，然后就把这些事情全部交给了你，大家两全其美，然后你就996了。没有将工作内容细分，现在来看倒也是公司规模没有到一定程度的体现。这样好不好？我不知道。但这些事情我没记错的话两百年前里有一本书已经预言了这一切。