简介

---

工作中经常会遇到一些问题，我尝试从个人角度给出个人见解，供大家参考。

“这个错了”，是什么意思？

• 不是针对你的观点（每个人都可以有自己的想法）
• 某部分事实错了
• 推理过程错了
• 结论无法外推（原因见2，3）

xxoo 软件有个专用的监控工具，我们应该用吗？

• 我更需要的是通用的数据接口，方便接入公司内部的监控平台。这样就可以无差别的对 xxoo 监控数据进行展示和报警。自动化的工作也成为了可能。
• 直接使用一个专用的ui工具或者界面，会让我的工作界面分裂成一个个的碎片。

A系统又出问题了，怎么搞的？

• 当我们想找出问题的原因之前，应该先搞清楚这是不是一个问题。（我们无法搞清楚一个不存在的问题）
• 如果系统A给出了一个明确的报错，通常这不是一个问题（能够被系统识别的错误，不算是系统的错误，一般是由外部环境导致的）。应该把注意力放在对系统A调用的输入和返回的信息上。
• 如果是 A系统 没有按照某种外部的规则运行，比如超出 B系统 的负载极限或者规范发出请求。这通常也不是问题。
  • 理由是，A系统 很难知道外部世界的状况，他会按自己的方式去调用外部的资源。绝大多数系统都应如此

我按官方文档做的，却得不到希望的结果，我是哪里出了问题？

• 官方文档可能确实是错的，要知道文档的维护也是很辛苦的，如果发现问题，社区需要你的帮助
• 也有可能你在什么地方出现了问题，要找出原因，参考 sarmt question

我明明 xx，却 xx，你说奇怪不奇怪？

• 计算机并不属于自然科学的范畴。在这个领域没有魔法，所有的东西都既可以证伪，也可以证明。
• 如果你真的想解决问题，请参考 sarmt question

我要做 xx，请问我该如何开始呢？

• 先创建一个文件
• 写一个起始函数，c语言中这个函数是 int main(int argc, char *argv[])
• 把你的想法填充进去
• 赶紧运行一下，看看效果。如果有问题，或者新想法，返回上一步，继续填充。

写代码有什么技巧吗？

• 小且稳定的代码片段是好的
• 不了解细节的代码，应该用测试用例保护起来（用了第三方库，或者依赖于特殊的运行环境等等）
• 尽量复用代码。预编译，宏处理等生成代码的技术，有时效果拔群。
• 多做思想实验，在脑海里想象代码的样子，并逐行执行他们，能节省大量时间
• 多写小段的代码，并立刻执行他们，减小获得反馈的时间，通常超过5秒以上的编译->执行->报错 周期，会让我烦躁不安
• 多看可以可以引发思考的代码。比如好的代码，或是自己写的代码
• 保持简单的逻辑，避免出现特例
• 利于阅读的代码风格
• 将以上原则应用到尽可能更大的尺度上