编程随想：密码粘贴的安全问题

图片由Google Gemini生成

就「密码输入控件是否应该允许粘贴功能」这件事情，跟同事发生了一点小的争执。

其实也没多大事。
同事觉得，既然要「安全」，那就彻底拿掉「粘贴」功能，不让进也不让出。
而我觉得，不能把控件内的文本复制出去，那是常识。但外面的文本能不能粘贴进来？这个问题还可以商量商量。

看吧，我其实是个表面上很温和的人。
实际上我想说的是：为了安全，反倒是应该允许向密码输入控件内粘贴内容才对。

---

同事的想法恐怕很朴素：功能尽量少，越少越安全。这个原则，我非常能够理解。

但是，他可能不用 1password 或者 lastpass 之类的密码管理工具，自己生活中也只在使用少量强度不够的密码。如果他像我这样一个账号独用一个密码，而且都是密码生成器生成的 32 甚至 64 字节长度的密码的话，大概就不会觉得有没有「粘贴」功能是无所谓的事情了。

若是阻止了用户进行「粘贴」，用户很大概率就只能采用比较简单的密码，而且很可能会重复使用自己别的地方也在用着的一个简单密码。那么这到底是更安全了还是更不安全了？

---

全世界可能没有哪一个国家像中国这样，醉心于所谓的「密码安全控件」。防键盘钩子，防内核驱动，私有的闭源加密算法，随机乱序软键盘，自己发明的输入法……

正常人的想法很简单：如果你的主机已经被攻破，那么谈什么安全性都是扯蛋。安全取决于最短的那块木板，所以没有必要去加码到这种程度。
但中国这边的想法更简单：我不管，我就是要「安全」。哪怕做到匪夷所思的程度。

回头想想，哪桩事情不是这样？地铁安检不也是同样的情况么？
曾经过了三年在防毒面具下的生活。然而，现今谁又不是呢？心中的防毒面具，生活在洼地的人，谁又曾拿下过？

编程随想：文档很重要

公司的文档水平一向不好，习惯也很不好。在代码中能写个注释，已经算是有好习惯了。在我看来最低限度的 ReleaseNotes，都是有人去推动后才建立起来的制度。大言不惭一下：看起来正式一点的文档，大多出自我的手笔。

前段日子，下了狠心，盯着同事们整理了一篇文档。大约三、四个月的开发内容，最后写了 82 页。我觉得不算多，但可能已经多得让不少人懒得去看了。也正常，文档不是小说，不是让你没事从头翻到尾的。有需要的时候去查上一查，还能有所收获，这就已经算是有价值的文档了。尽管离我认为的「先写文档后编码」还有不少差距，但要是能事后真真正正地补上，也是功德一件。

---

现在流行 AI，公司上上下下都在搞自己部门的 RAG。这推动了一波文档热潮。AI 没有东西吃，吐出来的东西也就质量不咋地。这样一来，文档就愈发的重要了。

对我而言，这是好事。我倒是喜欢写文档。比起写代码，写文档更接近我的舒适区。何况偶尔我也会塞点「私货」进去，甚至把文档写得像小说一样。反正是内部文档，调皮一下也无妨。将来万一有人看到，也许会有会心一笑。

而且，为了能安心退休，我倒是也愿意把自己的「毕生所学」给「贡献」出来。知识这种东西，有的人会藏私，但我觉得藏着掖着没意思。真正的能力，并不在于别人学不到的东西，而是别人学不会的东西。

---

有的时候，有些文档会让人觉得很没意思。完全是形式主义，没有什么有价值的内容。对这种文档，我个人是并不喜欢的，但偶尔也必须得去做一做，还好不是太多。

在现在的公司，基本碰不到这种事情。就算有，可能也不是我的事情。但在以前的公司，就会有不少。看起来厚厚的一叠文档，比词典还厚。有没有人看？没有。有没有用？有。你得有它。有就行。

曾经向当时的主管抱怨过，得到的回答是：这些文档的确没有意义，但规定要求必须得有它们。可能是因为如果能沉住气把这些都完成了，那这个项目的总体质量应该也不会差到哪里去。

也就是说，这是甲方的一个测试，一个考验，或者说是一个保证下限的东西。肯把这些无聊的事情搞完的，大概率也就不那么草台班子了。

或许有几分道理，也或许其实是歪理。但不管怎么说，总之当时的我是被说服了，埋下头继续写。

---

又有的时候，有些文档，真的是必不可少的。

记得以前说过这个观点，可能是在 Google+ 上。我认为如果要自杀，一定要写遗书。悄咪咪地去死也就算了，别给后人留悬案。如果有遗书，家人或许还可以帮你讨个公道，没有遗书的话，很多时候就白死了。反正都是要死了，干嘛不把后事办好一点呢？

图片来自网络

反正车费你都拿不回来。

编程随想：可以 delete this 吗？

在 C++ 中能不能 delete this，去问 AI，它能给你一个基本上算是标准答案的回答。面面俱到，滴水不漏。

在C++中，从技术上讲，你可以在类的成员函数中调用 delete this。然而，强烈不推荐这样做，因为它非常危险，并且会带来很多潜在的问题。……

看起来是不太好的，至少是不推荐。
但是如果你改一个问法，去问可不可以「对堆上 new 出来的非模态对话框在 PostNcDestroy 中做 delete this 操作」，那它又会改口了。

在MFC中，当你在堆上new了一个窗口类，并且它是一个非模态对话框，那么在PostNcDestroy中调用delete this是完全安全且合理的。这是一种标准的MFC编程模式，专门用于解决你所描述的生命周期管理问题。……

所以，事情都得分场合来看。有些情况下「坏事」也可以变成「好事」，至少会是合理的。反过来也一样。大多数情况下，对具有某个「标签」的事物并不应该有唯一的判断结论，因为它可能还有别的标签（不知道 3D 人士看不看得懂）。

---

上述资讯，其实算是 C++ 开发的基本功。MFC 开发如果入了门，也不应该有此疑惑。不过呢，世间的事情很多都比较复杂，并不像示例或教科书上那样简单、清晰、明了。夹杂了别的东西之后，情况就又发生了变化。

最近在查一个问题，就遇到了一个案例。
有个小弟，在 PostNcDestroy 里面，去上了一把锁。std::mutex，成员变量，用 std::unique_lock 辅助管理。
然后程序就 Crash 了。调试起来倒也容易，因为这个虽然看起来跟多线程有关，但也并不是真正的多线程问题，还是很容易复现的。

我也不多啰嗦。到了这把年纪，很多抖擞精神去查的问题，结论出来以后都失望无比，最后写都懒得去写，何况世上还有 AI。有经验的程序员应该一眼就看出问题了：std::unique_lock 在 PostNcDestroy 函数退出时，才会把自己管理的 std::mutex 给解锁，但那个时候这把锁的主人已经把自己给毙了。这就相当于访问了无主内存。

所以，「自毙」这种事情，虽然不是不可以，但后事还是要先安排好。

---

图片由 Google Gemini 生成

比如，「禁诉令」这件事就做得很好。否则法院可能哪天就得直接关门了。

编程随想：招投标那些事

图片来自网络，与本文无关

说起来，我们公司最近也投了个标，也中了。

这个项目跟了好几年，从疫情期间就开始跟。开头的时候有 120 万的预算，最后招标的时候砍得只剩 45 万。然后甲方还提出来要「分期付款」，4:3:3。作为一个开发人员，我参与的招投标项目不算多，有点孤陋寡闻，这回算是头一次听到这种事情，也算是长了见识。

后来到实施的时候又出了问题。甲方提出来服务器能不能不买，用租用公有云服务器的方式来代替。这事也听得我一愣。要知道公有云基本上「三年」是一个大致的盈亏平衡点。只租一年或者两年，一般是比自己买服务器要省钱的。如果租到了第三年，对于租用者而言大概率就不合算了。

不过最后听说甲方还是掏钱买了服务器，据说配置还挺高的。闹得我现在也琢磨不清楚这甲方到底是有钱还是没钱？或许端看花的是谁的钱吧？对了，这个甲方也是个大专院校。

在这个项目里面，我只是顾问身份，基本没怎么参与，个中曲直我也懒得去理清楚，各位权且当个故事听着吧。

---

然后我还想起一个事。同样地，没有立场，没有观点，只是一个事情，讲出来供大家参考一下。

2019 年成立子公司的时候，IT 运营和成本核算也是独立进行。总公司那边买办公电脑，都是买 Dell 品牌机。已经 2019 年了，买到的还是 HDD 的配置。我反正是看不上眼，后来都加装/换装了 SSD。

到了 2023 年，我自己的办公电脑要汰换，也是去买了配件自己来组装了一台新的电脑。旧电脑是 2015 年申请的，8 年时间用下来，已经没有升级潜力了。

当时买了一堆东西，CPU / 散热器 / 主板 / 内存 / 机箱 / 电源 / SSD。我发单子申请，采购让行政人员负责。全部流程走下来都很顺畅。组装过程也很顺利，毕竟我和另一位 IT 同事都是二十几年经验的 DIYer 了。这台电脑现在用得也很趁手，价格不足四千，整体性能远超公司那些同事的所谓 13 / 14 代 i7 的 Dell 品牌机。花自己的钱，办自己的事，就是这样，又好又省。

后来搬回来，总公司来交接固定资产。我看到资产表上没有我这台电脑，倒是有登记一个 CPU，就是我这台电脑用的型号。
资产登记不是我负责的，行政人员是个小姑娘，不是太聪明的样子。我当时让她采购的这一大堆东西，我怀疑她就只看懂了 CPU，然后写了上去。

前来交接的人员，也不太聪明的样子。来过至少两拨，可能还不止两拨，每一拨我都费了不少口舌跟他们说明这个事情。看他们眼神，还是没懂的样子，一副「算了我也懒得管了就这样吧」的表情。搞得我一度有点怀疑是不是自己的沟通能力出了问题。

现下愈发觉得各方面都懂的「通才」甚是难得。有幸遇见过几位，不是丁克就是少子，不由得对人类的未来愈发地「看好」。

话说回来，一个 CPU，当然也值不了 75万，不然发姐的 AMD 股票肯定得涨到天上去。

编程随想：给点好药吧

图片来自 DALL-E，纯属虚构

公司的测试主管最近很忙，我春节前有个事要找她，却一直约不到时间。

午休时终于碰到了她，于是闲聊之下顺便打听最近在忙些啥，咋整得这么愁眉苦脸哩。

这一句话可就把装满苦水的话匣子给打翻了，抱怨和吐槽犹如滔滔江水连绵不绝。原来近期客户要求写「说明」的情况越来越多，都是有人投诉到工信部、证监局，然后红头文件一层层压下来，最后结果就是我们公司需要写一份说明，再一层层发还回去。

若是我们公司犯的错误，所以才需要写「说明」，也就罢了。可是这些越来越多的投诉，偏偏又并不是。大部分都是客户亏了钱，又啥都不懂，然后就开始瞎投诉。
最离谱的一件事情就是：

客户下了一个卖单，限价单。交易所帮他以高于委托价的价格撮合成交了。结果他去投诉，说没按他设定的价格成交，是软件有 Bug，要向我们索赔。

我和她一起骂：这不是脑子有病吗？投诉的人脑子有病，收下投诉的人脑子同样有病。没炒过股票还没卖过东西吗？

算了，人家脑子有病，那也是一种病，有病就得吃药。听说印度的仿制药，吃了得抱着脑袋坐在高速公路边上想去挡车。这乱投诉，算是症状轻的了。
这药要是不好呢，那真是害人又害己啊！真的，给点 好药 吧。

编程随想：还会有下一次的

图片来自网络，与本文无关

昨天，有同事收到测试部门反馈的一个 Bug。

他的第一反应，是下了一个判断：「这个 Bu g可能是因为 XXX 导致的。」
随后他就动手去改了。

作为同一个办公室的同事，我听到了他说的话，出了一身冷汗。
当然，也许是因为我经验比他多一些。不过，或许更因为我比他更为谨慎一些。
我问他：「你能确定这个 Bug 的原因吗？有没有重现过？」
他说不能确定，没有去重现过。
我又问他：「你确定你改了以后这个 Bug 就没有了吗？」
他说也许吧，先改了试试看。

那我觉得这个 Bug 就还会有下一次的。

正确的做事方法，我当然告诉了他，看他听不听了。
然后，我也去跟测试部门打了个招呼，让他们留神一点。
放任不管的话，养老金说不定就没了。

对了，我真的只是在说编程而已。
另外，无论我还是这位同事，婚姻状况都还没 出问题。