看了吐槽同事代码风格的帖子来的，我的一点感想

我虽然只有 6 个月的工作经验你们不用听我
我看完帖子的评论后发现工龄越高的越能理解某种比较俗气的风格
但如果同样的问题问我之前的上司 CTO 兼股东的话，他大概率会说“那得看情况”

*那种

业务代码，和高质量有点冲突，很多时候可读性，健壮性，可维护性这些比性能要重要许多，单纯炫技肯定是不行的。

（我写 Python ）
打开 Django 源码

和

打开基于 Django 实现的电商网站源码

...

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

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

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

很多其实和写作文一样，有的人喜欢用这种方式表达，不可能做到大家的表达都一样，只能做到相近吧，通俗易懂最好。

写功能要短小，好测试，好重用。 写业务要放在一起，好修改。

做事情 A 。
做事情 B 。
做事情 C 。
做事情 D 。
...
这是一个函数，可能有 400 行。
你把每个相对独立的逻辑抽出去就是 4 个函数每个函数 100 行。
读代码的时候，思路就是
做了事情 A 。
做了事情 B 。
做了事情 C 。
做了事情 D 。
完了插一脚，改一脚，都很好插很好改。
可以不炫技，平平淡淡，一读就懂才是最高境界。

鱼与熊掌不可兼得。
理论上要可读性高，可维护性好，实际上，今天加需求，明天改需求

@Mindjet 我工作几年，好多地方还是按照这本书的，但没必要完全照搬

整洁、美观、优雅
这并不是工程追求的东西
当然工程并不排斥这些东西
工程只是不追求
如果追求这些会导致工程中其他的关键部分受阻
那这些追求就会靠边站
软件工程本质上甚至都不算是是在制造工具
因为工具已经在那儿了：能计算的机器
软件工程只是人在教工具怎么做事
也就是指挥而已
指挥就是讲话
讲话是技术也是艺术但归根结底还是技术
把话说清楚的情况下
尽可能提高讲话效率
所以让话变得简洁优雅当然是有意义的
但很多时候为了把一件事情说明白
最好的办法就是不厌其烦地从多个角度进行详细描述
这个时候如果强行格式化
倒不是说这话就没法讲了
但是无论是讲的人还是旁听的人都得遭罪

俗与雅相辅相成，喝着咖啡就大蒜，秋水长天一色。

@good1uck #1 有追求是好事的，能保证自己的追求也是好事。不过我很不喜欢把别人贬的一文不值。在那个帖子中，大部分人都表达的是没有那么不堪，而不是他同事写的很好。

@Mindjet #5
短函数这个实践，我觉得有个两个前提是，要保证命名的可读性（或者要有足够的文档和注释），还有低耦合，否则反而可能会比较坑。
最近维护前同事的旧代码，他就很喜欢封装大量的函数，实现功能的时候一层一层构造一条很长的调用链。总的来讲，代码重复率确实很低，但那个代码真的维护得想死，他的很多命名根本说不清楚这个函数干了什么（因为是自己实现的，所以他可能觉得命名已经说得够清楚了），为了搞明白这一点，不得不进去函数读具体实现，进去又是一堆不明不白的函数调用。这样导致在阅读的时候，到处跳转，逻辑割裂严重，为了搞明白一个业务，甚至不得不深入到非常低层级的代码中去。如果是这种，我宁愿他写一些长点的函数，好歹有一个连贯可读的逻辑。
当然这个问题本质上不是短函数造成的，只是说在这个情境下，受代码上其他问题的拖累，反而降低了可读性和可维护性。

我觉得更多是逻辑拆分的清晰，而不是单纯追求代码短。如果把一个完整的逻辑愣是拆成若干个短函数，反而可能更麻烦。

@Orenoid
确实，函数名是最重要的东西，体现的是结构，函数的具体实现反而是细枝末节的东西，很多时候不值得讨论

不写业务代码的时候，感觉卧槽我代码写的真好真优雅。加上了业务之后，感觉代码就是一坨屎。。。 很多地方不得不妥协。如果不想妥协，还想继续优雅，可能时间翻倍，架构推翻。为了一种小概率或者不发生概率，去把主要部分都重写一遍。。

而且有时候，过渡追求代码优美，带来的后果就是。可读性变差，东一坨西一坨，并不容易阅读。还不如写成面条式。

重复的东西写烦了或觉得将来很可能会写烦才做优化，否则怎么快乐怎么来

其实说白了就是开发过程中懒得写注释。自己开发的工具类写上注释，别人可能看不懂的写上注释，所有业务逻辑相关的地方也写上注释。

就算别人不知道你这段代码的操作多么花里胡哨，那他也根据注释去重新实现业务逻辑。

只要你的注释与文档足够清晰的描述了你自己定义的类或方法的逻辑，那么别人还看不懂可能就真的是水平问题了。

@Mindjet 划分到无限小，划分的意义我感觉就不大了。我感觉，别喷

我就很烦那种 if 后面不跟{ } 和换行，直接写代码的 不管你 if 里的代码只有一行 return 或者其他什么 就是烦

非业务代码,可以封装,抽象 => 让写业务的人调用简单(最好无感,例如 aop,拦截器等)
业务代码,按照人类理解的流程去写就行了

我以前的领导经常给我强调，代码是给人看的，保证正常执行外，“活人理解”是最重要的。

@good1uck 经验多了就学会妥协了。代码写的好，leader 又看不到。有时候，在面向晋升编程的公司里，你还必须得有把简单事情复杂化的能力。不然评委只觉得你的工作好简单，你的水平也好低

如无必要，勿增实体

我最烦的事就是我封装好的东西被猪队友破坏性更新，那时候真的很烦。

那个帖子，一开始我是持代码能跑就行，逻辑越简单越好的态度。

然后我试着按楼主的需求去添加，发现那个代码真的写的屎一样，就算是从自己以后维护的角度来说，也应该写简洁一点，而不是复制粘贴就往上堆

可以看我在#280 的回复。。

老工程师们因为看的多知道什么是真的有害，什么只是锦上添花。

这就是一个老鸟和菜鸡的区别线。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

@MrStark 确实，但是耐心地看完别人的封装也很难吧，相当于要去学习一遍别人的思维

@Mindjet 哈哈，那个帖子比较有热度，有感想的人应该挺多的，我就拓展一个话题出来。相当于蹭了热度，也能和更多人讨论。