新手程序员应该学会这3个原则

一、背景

和一些新同事相处一段时间后，发现他们经常犯一些低级的错误。
今天，我将工作五年总结出来的一些原则分享给你们，这篇文章先说最容易理解的三点。
通过遵循这些原则，你们可以做事效率更高，犯错的概率也更低。

二、信息敲错了

在帮忙新人处理线上问题的时候，经常发生最终是配置文件的信息填错了，或者程序里的字符串敲错了等等。
后来进行问题复盘的时候，发现很大比例都是因为对应的信息是自己手敲的，结果敲错了。

对于这个问题，我早在八年前在大学首次参加ACM比赛的时候，就学会解决方法。

参加过ACM比赛的朋友应该都遇到过，对于一些题，会要求按照指定格式输出一些字符串。
新手经常发生这样的事情：你明明算法都正确，但是最终就是过不了，一直WA。
最后找大牛来看，发现输出的字符串不符合要求。
比如有次，题目要求输出字符串 main,很多人敲为mian。

这里给你们的第一个原则就是：不要手敲，请复制一切信息。 这些低级错误，通过这个简单的原则就可以避免。

三、不是一个东西

这两周，周围的一个新人连续犯了两个错误。

第一个是测试环境程序不符合预期。
比较MD5时，发现编译机程序的MD5和测试机一样，但是看日志时，发现代码和测试机的日志对不上。
后来发现这个程序有两份代码，一份代码已经编译出了程序（和测试机一样，MD5在这份看的），另一份代码一直在修改开发（代码和日志在这里看）。

PS：MD5是根据文件内容计算出的一串值，冲突的概率很小，所以一般MD5一样就认为文件一样。

第二个是线上的程序出现了问题，测试环境原先也有这个问题，但是程序重新编译后就不能重现了。
这个怎么看代码都找不到问题，只好先发布恢复线上问题。

后来同事无意间发现发不错代码了，复制的其中一份代码开发了一半，被发布到线上去了。
我问为什么会发生这样的问题时，得知他的代码复制了三四份（震惊）。

再细问他经历了什么事情？
原来这个项目有多个独立的功能，在一个目录下。
开发每个功能时，都单独复制一份代码。
在开发的过程中，他自己也经历过很多次开发了一半，发现开发错位置了，然后把开发的那些代码复制到其他位置。如果还错了，就再复制，直到正确为止。

面对这种做事方法，我是不能接受的（这么容易犯错为啥还用这个方法？）。

这里给你们的第二个原则是：一个项目的代码只有一份，可以避免很多开发机与测试机对不上的问题。

PS1：这里的只有一份不是说备份问题，大家应该使用版本控制系统去备份管理代码。
对于处于开发的代码，我会使用同步工具从开发机实时同步到编译机。如果开发机挂了编译机还有一份实时备份。

PS2：当然，现在已经9102年了，我们却还在收到管理这些系统。自从去年没有梦想火爆后，听说今天已经要引进CICD了。

通过CICD也可以避免这两个例子里的问题。
但是保持一份这个原则确实通用的。
比如代码里的函数实现保持一份、公共库保持一份等等，不然都会遇到类似的问题。

四、正确的反馈问题

我负责的是一个通用的资料服务，用于接入各种类型的业务数据。
业务数据出问题的时候，使用方首先找的就是我。

但是大多数人问问题的方法都有问题。

面对资料性系统，发现资料不对时，大多数人一直在说你的系统有问题哇，但是迟迟不说具体是什么问题。
此时正确的姿势应该提供具体资料的请求参数，以及预期和现在是什么。

面对储存也一样，比如redis异常问题，应该提供具体的redis路由发现的信息，以及具体问题（延时变高还是数据不一致）。
提供路由发现信息，对应的负责人才能去看具体是哪个业务以及具体哪个redis实例有问题。

之所以需要这样做，是因为很多人不会换位思考，或者自己想当然的认为对方知道一切。
比如你反馈资料系统的图片不对了，你要说具体是哪个图片，具体到对应的名字。毕竟后面有几十个规格的图片，只有你知道你用的是哪个图片。
比如你反馈redis有问题，以直播为例，在你看来你只用了一个redis，但是对redis的负责人来说，你们直播业务接入了几十个REDIS。只有你知道你用的具体是哪个REDIS。

另外有时候提供了相关信息，但是你是通过截图提供的。
这就很容易引出第一个错误：信息敲错了。

因为这个，也经常会发生一件很有趣的事情：你反馈一个问题，对方敲错了查不到有啥问题。你们两个争论不休，最后发现你们两个说的不是一个数据。
截图没问题，但是对于关键的参数信息也最好在发完截图之后，提供一下文本参数。

五、最后

这里先给大家了三个建议原则：不要手敲数据、数据维持一份、反馈问题提供详细文本参数。

你有遇到没遵守这三个建议而产生的问题吗？
或者你有其他的什么好的建议，可以说来听听，一起学习一下。

-EOF-