ACM通信
Kode恶性
山核桃Dickory医生
信贷:形象
亲爱的KV,
在检查我们产品中的一些加密代码时，我遇到了一个允许空加密的选项。这意味着可以打开加密，但数据永远不会被加密或解密。它将永远被储存在“透明的”地方。我从最新的源代码树中删除了这个选项，因为我认为我们不希望一个不知情的用户打开加密，但仍然将数据存储在明文中。我的团队中的另一个程序员审查了潜在的更改，并阻止我提交它，说空代码可以用于测试。我不同意她的观点，因为我认为不小心使用代码的风险比简单的测试更重要。我们谁是对的?
零的零
亲爱的空,
我希望你听到我说她阻止你的行为是对的时不会感到惊讶。我已经写了相当多关于测试的重要性的文章，我相信加密系统足够关键，需要额外的关注。事实上，空加密选项在测试加密系统时可以发挥重要作用。
大多数使用加密技术的系统不是单个程序，而是在构建或运行时可以放置不同加密算法的框架。众所周知，加密算法还需要大量的处理器资源，以至于专门的芯片和CPU指令已经产生，以提高加密操作的速度。如果您有一个加密框架，它没有一个null操作，一个只需要很少或没有时间就可以完成的操作，您如何衡量框架本身带来的开销?我明白，在绩效分析中，建立一个基准衡量标准并不是常见的做法，这是我在用拳头敲桌子、大声说脏话时得出的结论。我经常认为程序员不应该只被赋予办公室而不是小隔间，而应该被赋予填充单元。想想看，如果每个人都有一堵软垫墙让他们的头去撞，而不是那些便宜的、容易破裂的纸板办公桌，公司会在医疗账单上省下多少钱。
使用一组空加密方法可以让您和您的团队近乎隔离地测试系统的两个部分。对框架进行更改，您就可以确定这是加快了还是降低了框架的总体速度。添加一组实际的加密操作，然后您就能够测量更改对最终用户的影响。您可能会惊讶地发现，对框架的更改并没有从总体上加快系统的速度，因为由框架引起的开销可能非常小。但是如果删除空加密算法，就无法找到这个问题。
更广泛地说，任何框架都需要在没有嵌入其中的操作的情况下尽可能多地进行测试。在专用的环回接口上比较网络套接字的性能(消除了所有不可预测的硬件)，可以帮助建立显示网络协议代码本身开销的基线。空磁盘可以显示文件系统代码中的开销。用简单的函数替换数据库调用，以丢弃数据并返回查询的静态答案，可以看出Web和数据库框架中的开销有多大。
我们常常试图优化系统，而没有充分分解它们或将它们分离出来。复杂的系统会产生复杂的测量，如果你不能推断出组成部分，你肯定不能推断出整体，任何声称他们可以的人，都是在对你撒谎。
KV
亲爱的KV,
您如何看待像Doxygen这样从代码生成文档的系统?它们能取代项目中的手写文档吗?
明明白白的现实与文档
亲爱的明明白白的现实,
我不太清楚你说的“手写”文件是什么意思。除非你的电脑有某种我还没听说过的奇特的心理接口，否则任何文档，无论是代码还是其他地方的，都是手写的，或者至少是手写的。我相信您实际上想问的是，能够解析代码和提取文档的系统是否有用，对此我的回答是:“是的，但是……”
任何类型的文档提取系统在开始时都必须有一些东西。如果您认为从一段代码中提取所有的函数调用和参数就足以称为文档，那么您就大错特错了，但不幸的是，持这种观点的不止您一个人。唉，与他人有共同的信仰并不会使这些信仰正确。从Doxygen获得的典型的、未注释的代码库甚至不值得使用“API指南”这个术语，它实际上相当于在代码上运行一个花哨的grep，并将其管道输送到文本格式化系统(如TeX或troff)。
为了使代码被认为是文档化的，必须有一组与之相关的说明性词汇。
为了使代码被认为是文档化的，必须有一组与之相关的说明性词汇。函数和变量名虽然具有描述性，但很少解释隐藏在代码中的重要概念，例如，“这该死的东西实际上是做什么的?”许多程序员声称他们的代码是自我记录的，但事实上，自我记录的代码是如此罕见，以至于我更希望在去酒吧的路上看到独角兽载着蝎头兽。声称代码是自文档化的，这只是对懒惰的一种掩饰。在这一点上，大多数程序员都有漂亮的键盘，应该能够以每分钟4060个单词的速度输入，其中一些单词可以很容易地用于实际的文档。它不像我们在古老的行打印终端上打字。
Doxygen这样的系统的优势在于，它提供了一个一致的框架，可以在其中编写文档。从代码中提取说明性文本是简单而容易的，这有助于鼓励人们注释他们的代码。下一步是说服人们确保他们的代码与注释匹配。陈旧的注释有时比没有注释更糟糕，因为当您在代码中寻找错误时，它们会误导您。“但它说它能做X!”，并不是您在数小时盯着一段代码及其附带的注释之后所希望听到的尖叫。
即使使用半自动文档提取系统，您仍然需要编写文档，因为API指南不是手册，即使对于最低级别的软件也是如此。API文档是如何组合在一起形成一个完整的系统的，以及它应该如何使用和不应该如何使用是优秀文档中的两个重要特性，也是较差的文档中所缺乏的东西。曾经我工作过的一家公司的产品水平和技术含量都相对较低。我们有自动文档提取，这是很好的第一步，但我们也有一个优秀的文档团队。该团队从代码中提取原材料，然后从公司开发人员那里提取必要的信息，有时很温和，有时不那么温和，这样他们不仅可以编辑API指南，还可以编写相关的高级文档，使产品对那些没有编写API的人实际可用。
是的，自动文档提取是一个优点，但它不是问题的全部解决方案。良好的文档需要严格遵循的工具和过程，以便产生对生产它的人和必须使用它的人都有价值的东西。
KV
相关文章
在queue.acm.org
API:设计问题
Michi亨宁
http://queue.acm.org/detail.cfm?id=1255422
微软协议文档计划:大规模互操作性测试
与Nico Kicillof、Wolfgang Grieskamp和Bob Binder的讨论
http://queue.acm.org/detail.cfm?id=1996412
科德·维瑟斯对战摩斯拉!
乔治Neville-Neil
http://queue.acm.org/detail.cfm?id=1066061
数字图书馆是由计算机协会出版的。版权所有©2015 ACM股份有限公司
没有发现记录