很多时候，做软件开发，和做其他事情，道理都是相同的：
即使是临时文件，也要清晰的命名，避免后续可能的，潜在的错误发生，并且还可以帮助我们快速分析，调试出现的错误。
或者是快速恢复思路：自己之前做过的开发，即使过了相对较长的时间之后，比如3,5天，3,5个月，甚至3，5年，自己回头再看自己的软件或代码，仍旧可以看懂，并且明白自己当时的意图。
举例：
之前看到这个新手玩python偶遇坑爹错误，求开导
中的我的回复：
不论错误的原因是否是由于测试文件名和模块同名。但是这样的做事情的方式，都是偷懒的做法，不好的做法，都属于很不好的习惯。
而针对该特定问题：其由于第一次，刚开始就没有给临时文件一个清晰的名字，而导致了后续的问题。
而正常的思路，好的做法，应该是：
去测试该requests模块，需要写个测试文件，目的是用来测试此模块，
那么该测试文件的命名，就不应该很随意的、轻易的去起个无意义的名字，比如：
a.py或abc.py1.py或123.pytest.py或demo.py
而是应该要保持思路清晰，起个见名知意的名字，比如：
requestsDemo.py或requests_demo.pyrequestsTest.py或requests_test.py
如此，才可以达到写代码的目的：
- 不论是，别人看你的文件名，看你的代码
- 还是，过了很长时间之后，你回来看你自己的代码
都可以快速的看懂你所写的代码，能读懂你的每个文件所要实现的功能。
否则就很容易变成，很多人所遇到的情况：
- 不论是，自己写完代码，没过多长时间
- 还是，别人过来看你的代码
都是：
- 单独看文件名，不知道该文件的作用
- 再去看代码，也是逻辑不够清晰，逻辑混乱，无法快速准确的明白你的代码的含义，所要实现是什么功能
如此：
就变成了典型的：
- 坏的软件开发的习惯
- 坏的写代码的风格
这就和之前的软件开发的重中之重的要注意的那一点写代码是给别人看的所冲突了。
看到这里，估计有人会问：
不就是简单的给测试文件命个名，写点测试代码吗？
又不是真正的去搞软件开发，写详细实现功能的代码，用得着这么严谨，甚至说死板吗？
对此，我的回答是：需要这么严谨。
因为：
- 第一次就做对的事情
把这个问题，上升到做事情的态度来看，那么你需要明白一个做事情原则中，很重要的一条：第一次，就做对的事情
因为，如果第一次就马虎，尤其而带来的以后的潜在的错误，以及解决该问题的错误所需要花费的精力和成本，
远大于你为了第一次做对的事情，仅仅比你随意的就下手做了，而多思考了几秒，几十秒，甚至几十分钟
这个逻辑，也非常类似于：
解决软件的bug的时间，永远是越早越好，最好是想办法找到合理的机制去预防软件的bug。
因为随着时间往后推移，软件的bug所导致的问题会越严重。
- 只有好的习惯，才会产生更好的结果
只有严谨的，认真的态度，养成好的习惯，才能从好的习惯中获益：减少后续发生问题的概率
最终实现我们的终极目的：更加高效的做事情，更加高效的搞软件开发。
而高质量的软件，和低质量的差距，也就是从第一天的做事情、搞软件开发的态度上，就决定了。
 |  |  |
| 第 2 章 通用软件开发之态度和想法 |  | 2.2. 软件开发的效率、成本和投资 |
