你这个帖子很有特点，好像很少有什么帖子，是因为看了别人的帖子有个想法，然后另发的。

实际上我觉得这挺好，因为在大多数时候我是不太喜欢爬楼看东西的。

如果感觉某个点重要，应该引起更多人的重视，那么单独弄帖子，真的挺不错。

@good1uck #1
对于这种复杂问题来说，「那得看情况」基本上是不会有什么错误的，「实践是检验真理的唯一标准」。

有些人非要在这种经验上和别人争执，其实没有什么必要，「上司 CTO 」可能是个见多识广的人，在这行混久了已经懂了。

因为情况太多太复杂，没有什么「银弹」。

这是个底层认知，是个常识，如果简单的提问，这么回答是完全没有问题的，这提醒大家不要忽略这个问题的复杂程度。

但如果你是很较真的去想这个问题，那么这个层次就有点太低了，这个回答是没有办法直接指导实践的。

如果要想得到结论，就要去做实证研究。

这方面社会科学和医学的研究方法可以借鉴下，因为这些经验都与人的行为有很大的关系，绝对不是理化生这样的基础学科研究的范畴，应该也不是工程类研究的范畴。


不过有这些学科背景的程序员可能并不多吧，所以大多数人可能不太理解。

@Orenoid
这个观点来自另一本讲代码质量的书，叫做《修改代码的艺术》，主要内容就是处理遗留代码，你说的那个场景正好是这本书讲述的范围。

它里面对遗留代码做了重新定义，认为只要是没有被单元测试覆盖的代码，都算是遗留代码。

当时我对单元测试还有测试驱动开发都不熟，所以最近就没有继续看下去，正在学这方面的内容(《 C++程序设计实践与技巧 测试驱动开发》)，感觉还是挺不错的。

@Orenoid #14
谢谢你的经验分享，我也有这种感觉，自从看了这本书之后，写代码基本上就不用注释了，因为那些名字，一看就基本上能想起来。

遇到比较重要的函数，就会单独拎出来写个文档。

最近在学「测试驱动开发」(单元测试)，如果要很强调可读性，测试驱动开发会不会是很好的选择？

如果稍微重要点的函数都有很多的单元测试来进行覆盖，那么顶多跑测试就能够知道大概的作用，不需要阅读内部实现了。

这样就解决了变量名鸿沟问题，当你运行测试之后，你的理解水平就更接近于写代码的人，那样的话就不会有很大问题了。

@ikeepall #11
你是怎么知道图上小程序的供应商？
是不是在一些角落中留下了供应商的痕迹？

@dobelee #5
公司已有

@imn1 #7
谢谢你补充的这些规则
@rostov
谢谢提供说明摘录
@oneoyn
请问你是这方面的从业者吗？

你所指的那种书的确存在，如果看过《代码整洁之道》(豆瓣评分 8.6)，就应该理解类似的说法，短函数是非常重要的，作者欣赏的函数是那种只有 2~5 行的，最多不超过 20 行。

> 函数的第一规则是要短小。第二条规则是还要更短小。我无法证明这个断言。我给不出任何证实了小函数更好的研究结果。我能说的是，近 40 年来，我写过各种不同大小的函数。我写过令人憎恶的长达 3000 行的厌物，也写过许多 100 行到 300 行的函数，我还写过 20 行到 30 行的。经过漫长的试错，经验告诉我，函数就该小。(第 3 章 函数 - 3.1 短小)
> ...
> 这个程序中每个函数都只有两行、三行或四行长。每个函数都一目了然。每个函数都只说一件事。而且，每个函数都依序把你带到下一个函数。这就是函数应该达到的短小程度！(第 3 章 函数 - 3.1 短小)

当然你也能轻松找到很多反例，这只是经验之谈，这个经验既不清晰也不严格，但这的确是部分人的想法，而且还写在书里了。我很欣赏的是这个人能很清楚的看到这一点，不清楚后续有没有实证研究。

@herozzm #3
主要是方便，微信群里的迁移过去基本上是无缝的，传播起来也方便很多，大部分人主要的应用就是微信。
我也不喜欢微信小程序，但是感觉很多人喜欢。

@gouflv #1
纯属谣言，社区常常见到，例如下图。
你说这话给我的感觉就是从上世纪穿越过来的，根本就没用过微信。
https://i.loli.net/2020/09/27/p4cNK6LQuyGs8zn.jpg

从点击数来说，大家对此问题还是有点兴趣的。

@a719031256 #218
举出反例总是轻而易举，在软件开发这个行当，积累了些经验并写在了书里，除了那些算法什么的，或者其他的用数学证明的，大多数的经验都没有用科学手段去验证，这是个很大的问题。我只零零星星的听别人提到过引用实证研究的事情，但从来没在这些出名的书中见到过。

《‪软件困局：为什么聪明的程序员会写出糟糕的代码》，好像说的就是这个事情，当然我没有把这本书看完，只是看完前言(序章)后有这种感觉。

> 软件工程其实并没有多少“工程”的成分，这已经是公开的秘密了。
> ...
> 自计算机诞生以来，特别是 20 世纪 60 年代大批软件问世之后，围绕软件的种种问题一直伴随且困扰着从事软件生产和研究的人们。... 在大学里，学生并没有学到在团队中如何编写便于后续维护的软件，他们在大学里完成的软件作业仅达到了课程项目的要求，却与业内软件开发的实际规模和真实复杂度完全脱节 ；另一方面，在工业界，靠自学成长起来的一代聪明的程序员习惯于凭自己的直觉和经验来解决问题，他们相信软件必然会包含 bug，但这些包含了 bug 的软件照样可以带来巨大财富，这些根深蒂固的观念导致工业界缺乏改进软件工程的动力。
> ...
> 但是，编写软件却不是这样的。虽然软件被称为工程学科，但它几乎没有工程的特征，即随着时间的推移，在严格的实验基础上建立起一个知识体系。人们自然会问关于工程产品的那些问题：它有多坚固？可以使用多久？什么情况下可能失败？对于软件来说，无论是针对程序的一个部分还是整个软件，这些问题都无法得到可靠的答案。专业许可是大多数工程学科的标志，但这却被软件行业视为潜在的诉讼来源，而不是制定标准的机会。
> ...
> 早在 1990 年 11 月，卡内基–梅隆大学的玛丽·肖（ Mary Shaw ）为《 IEEE 软件》杂志撰写了一篇题为《软件工程学科的前景》的文章，她解释说：“工程依赖于有关技术问题领域的、以实践者可以直接使用的方式编纂的科学知识，从而为实践中常见的问题提供答案。普通的工程师可以用这些知识来更快地解决问题。这样一来，工程部门就可以共享先前的解决方案，而不是总依赖于某个行家的问题解决方案。”
> ...
> 她将软件工程与土木工程进行了比较，并指出，“尽管大型土木结构在有历史记载之前就已经建成，但在过去的几个世纪里，它们的设计和建造都是基于理论知识，而不是凭直觉和积累的经验 。”1 我翻阅了美国土木工程师协会的出版物目录，其中尽是有趣的标题，如《水管情况评估》和《寒冷地区路面工程》，我很欣赏在其他工程学科中有这么多的理论知识。

我感觉之所以会出现这种现象，就是因为软件「工程」太想成为「工程」了，这个领域的很多经验都直接和人相关，而不是跟什么物理化学研究的对象相关，那么研究的方法就应该参考社会科学，而不是工程学甚至是数学。

@jackrelative #220
看到你说的那种情况，我猜测有部分人会将读不懂他人的代码，归结到「他人写的烂」上头，实际上阅读他人的代码本来就是个很难的事情。当然，如果遗留代码有文档有测试，风格良好可能会有助于阅读，但不能忽略处理遗留代码本身的难度就很大。

感觉大部分人都没有指出「房间里的大象」。

如果看过《代码整洁之道》(豆瓣评分 8.6)，就应该理解类似的说法，短函数是非常重要的，作者欣赏的函数是那种只有 2~5 行的，最多不超过 20 行。

> 函数的第一规则是要短小。第二条规则是还要更短小。我无法证明这个断言。我给不出任何证实了小函数更好的研究结果。我能说的是，近 40 年来，我写过各种不同大小的函数。我写过令人憎恶的长达 3000 行的厌物，也写过许多 100 行到 300 行的函数，我还写过 20 行到 30 行的。经过漫长的试错，经验告诉我，函数就该小。(第 3 章 函数 - 3.1 短小)
> ...
> 这个程序中每个函数都只有两行、三行或四行长。每个函数都一目了然。每个函数都只说一件事。而且，每个函数都依序把你带到下一个函数。这就是函数应该达到的短小程度！(第 3 章 函数 - 3.1 短小)

当然你也能轻松找到很多反例，这只是经验之谈，这个经验既不清晰也不严格，但这的确是部分人的想法，而且还写在书里了。我很欣赏的是这个人能很清楚的看到这一点，不清楚后续有没有实证研究。



PS：前提就是那个代码是人写的，而不是生成的，如果是的话，那可能是个很「好」的代码。

感觉还是「独立」，这个词有点太模糊，如果不说清楚是什么独立，可能大家谈的都不是一回事。

GUI 的信息展示是实时的，CLI 做不到，当然可以加装插件，部分替代 GUI 的功能。