随想
文章平均质量分 83
研究是为了理解
要想学会一件事,就不能什么都学。
展开
-
随想012:断言
主流编程语言不约而同的在语言层面上提供了 `断言` 机制;编程专家们不约而同的提倡使用 `断言`;优秀的代码不约而同的已经使用了 `断言` 。即使是第一次听说断言,你也应该意识到,这个东西应该挺重要。那么接下来的问题是,什么是断言(**assert**)?原创 2023-06-29 11:06:27 · 379 阅读 · 0 评论 -
随想011:关于编程
软件工程的最基本经验是:保持简洁。软件设计有两种方式:一种是设计得极为简洁,明显没有缺陷;另一种是设计得极为复杂,没有明显的缺陷。第一种方式要难得多。原创 2023-05-25 11:23:43 · 1182 阅读 · 1 评论 -
随想010:该在哪里花费时间
当一个复杂的软件产品刚开始的时候,它还没有吸引众多用户。这意味着开发人员不必考虑多许多人造成不便或者“破坏”使用该产品的程序,因此可以快速地对产品进行修改。的前 5 个主要版本(X1 ~ X103)在 2 年内发布,但自从1987 年 9 月 发布版本。这是软件设计的一个重要的长远原则,当你开发一个重要的产品而且希望它能持续很长一段时间时,至今几乎仍是 UNIX/Linux 所有 GUI 的基础。一个灵活的、深思熟虑的设计可以使产品的生命力持久。以来,经过了将近 36 年,这描述了一个有趣的现象。原创 2023-05-18 16:24:52 · 721 阅读 · 0 评论 -
随想009:读书
小时候写题目,写到不会的,从来不解决,错了就错了,也不更正。导致错误永远都在,你写 1 张,10 张,100 张卷子看起来好像很努力,其实都一个样,你只是把会做的做了,不会做的,错的永远还在那里,没有解决。我们天生喜欢享受,谁不想轻松些呢,所以遇到困难的事情,我们会下意识想逃避,然后我们就会烦躁、就会想睡觉。这是读书的目的,也是读书的本质所在。读书就是要选对书籍,克服难点,理解作者表达的内容,提升自己的理解力。等到对细节了解到一定程度后,就会有豁然开朗的一刻,而此时你醍醐灌顶,见识也上升到新的高度。原创 2023-03-22 11:57:57 · 555 阅读 · 0 评论 -
随想008:烂摊子
我看到过很多离谱的现象。比如:程序 代码重复、命名随意、逻辑混乱、甚至对齐都不一致,当我询问代码为什么这样写时,他们告诉我:我接手时就是这样!原理图参数错误、器件老旧,甚至原理都不合理,当我询问电路为什么这样设计时,他们告诉我:我接手时就是这样!PCB 布局不合理、CPU 引脚扇出不合理、布线不合理、甚至在 PCB 上硬连线(原理图上没有这些器件),当我询问 PCB 为什么这样画的时候,他们告诉我:我接手时就是这样!我知道他们接手了一个烂摊子。原创 2023-03-17 18:20:33 · 742 阅读 · 2 评论 -
随想007:模块化代码
你一定不止一次的听说过模块化代码。理想的模块化代码高内聚低耦合、逻辑清晰、经过严格测试,易于复用它被描述的像是无所不能,仿佛只要使用了模块化代码,你就可以节省大把开发时间,项目就能化腐朽为神奇。以至于有些人了解模块化代码的优点后,惊喜的发现找到了一个可以无视人员素质又节省开发时间的终极方法:强制所有开发人员使用模块化代码原创 2023-02-07 20:15:50 · 1348 阅读 · 0 评论 -
随想006:帮忙的时机
于是我暂停当前的问题,告诉他们这里存在代码重复,为了引起他们的注意,我会告诉他们重复的危害,以及改正方法。就像我进行的代码审查,因为他们不能理解其中的重要性,所以不愿做,最后变成了我指出一个地方,新人修改这个地方,就这么软抗拒。在审查的过程中,如果我发现了BUG,他们会很积极的修改,但如果是提升代码质量的重构,比如要求用宏来替换魔法数、用函数封装重复代码等,他们就会开始找理由、找困难,他们开始抗拒。当我过几天查看他们的代码时,在不同的时候,不同的人身上,而担心时,跟他谈代码质量,他们不需要,也不关心。原创 2022-08-30 14:34:14 · 443 阅读 · 3 评论 -
随想005:调试的思考
任何的 BUG,都可以用以下步骤来解决:很多 BUG 很难解决,在第一步时就撞了个头破血流。总有人试图走些捷径,选择跳过这一步。无源之水、无本之木、万丈高楼浮空起结果自然是反反复复、来来回回,“攻关”之后接着“攻关”,然后公关。................................................................................................原创 2022-07-14 08:43:02 · 570 阅读 · 0 评论 -
随想004:交流的思考
一次系统联调,你正在看实时打印的日志信息。突然,你发现一个疑点,于是对联调的同事说:给传感器断下电。同事去另一个房间操作了一下然后返回。你发现程序的运行和预期不符,于是向同事确认:确定给传感器断电了?同事回答:断过电了!“是不是我的程序哪里错了?”你这么想,并仔细地检查了程序逻辑。然而你越发相信程序没有错,因为它清晰而简洁。你连接到设备后台,开始查看实时运行信息,发现这台传感器仍在线。“不是断过电了吗,传感器怎么还在线?”于是你指着运行信息把疑问反馈给了同事。同事觉得你的这原创 2020-11-15 21:06:22 · 1351 阅读 · 1 评论 -
随想003:问题是如何解决的
隔壁办公室的空调制冷效果变差,室外三十六七度,室内三十一二度。最热的那段时间,我去过他们办公室几次,每次都是汗呼呼的出来。这个办公室空调不但是今年有问题,去年也是这样,一年过去没什么改变。但是有天研发管理部的负责人突然带着电工查看空调制冷情况,从他与同事的交谈中我得知:今天总经理在隔壁办公室坐了半天,热的满身汗,然后要在这个办公室再增加一台空调,同时要求管理部排查所有办公室空调制冷情况。......原创 2019-09-05 21:38:46 · 2181 阅读 · 4 评论 -
随想002:设计规范
经理们大都喜欢成文的规范。嵌入式程序设计规范、原理图设计规范、PCB设计规范...但是试图用规范来消除重复错误的尝试可能是徒劳的!规范能够起到多大作用,取决于研发人员的执行程度和理解程度。问题往往出现在对规范的理解上,规范制定者表述的内容与规范使用者理解的内容会产生偏差。出现这个现象的原因是知识层面的不对等。不理解规范会带来问题。如果对一个事物理解的不够透彻,看到的只是......原创 2019-01-25 10:50:54 · 2761 阅读 · 5 评论 -
随想001:速度与质量
“突击一下,明天我就要看到项目结果。” 一些经理常常下达这样的命令。 很多研发人员选择忽略胸中翻腾的哀怨,对经理强颜笑道:“好的!” 而有责任的研发人员会问经理: “那你愿意牺牲什么?” 就像不能要求一个处理器功耗最低的同时性能又最高一样:提升一方面,就要牺牲另一方面! 提升速度,会牺牲掉什么? 如果经理掌握着话语权,决......原创 2018-12-07 10:07:53 · 2526 阅读 · 1 评论