简介
工作中经常会遇到一些问题,我尝试从个人角度给出个人见解,供大家参考。
“这个错了”,是什么意思?
- 不是针对你的观点(每个人都可以有自己的想法)
- 某部分事实错了
- 推理过程错了
- 结论无法外推(原因见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秒以上的编译->执行->报错 周期,会让我烦躁不安
- 多看可以可以引发思考的代码。比如好的代码,或是自己写的代码
- 保持简单的逻辑,避免出现特例
- 利于阅读的代码风格
- 将以上原则应用到尽可能更大的尺度上