鲍勃大叔《Clean Code》书籍反对意见的收集


这是各种读者对罗伯特·C·马丁(Robert C. Martin)2008年的著作《清洁代码》评论,点击标题见英文
 
我写这篇文章是因为我一直看到人们推荐Clean Code。我觉得有必要提出反对意见。最初我是在公司组织的阅读小组中阅读“清洁代码”的。我们每周阅读一章,共十三周。(这本书有十七章,由于已经提到的原因,我们跳过了一些章节。)
我会推荐这本书吗?不。我是否建议将它作为初学者使用?否。
 
Clean Code
的主要问题是书中的许多示例代码简直令人恐惧。“清洁法规”将强大而永恒的建议与非常可疑或过时的建议两者混淆在一起了。
这本书的大部分内容不再有用,基本上有几章就是为填充而填充,有整整一章介绍了JUnit的内部结构。这本书来自2008年。关于代码格式化有一整章内容,如今已简化为一句话:“选择明智的标准代码格式化,配置自动工具以实施它“,然后再也不要考虑这个主题。
其余内容几乎完全专注于面向对象的代码,并赞扬SOLID的优点,以排除其他编程范例。面向对象的程序设计在发布之时非常流行,但是那时是缺少函数性程序设计技术。
近年来,拥护SOLID观点的人数也一直在稳步下降。该书着重于Java代码,排除了其他编程语言,甚至其他面向对象的编程语言。Java当时很流行,Java可能是正确的选择,但是如今有更好的选择。最后,本书对Java的整体使用非常过时。即使对于2008年,本书所提供的许多java代码也不是很好的。
 
该书向我们展示了TDD循环:
第一定律除非单元测试失败,否则您不得编写生产代码。
第二定律您编写的单元测试可能不会超过失败的总数,并且编译不会失败。
第三定律您编写的生产代码数量可能不足以通过当前失败的测试。
这三个定律将您锁定在一个可能长达三十秒的循环中。测试和生产代码是一起编写的,而测试仅比生产代码提前几秒钟。
但是这本书并没有承认这个过程中缺少的第零步:弄清楚如何分解摆在您面前的编程任务。
 
鲍勃大叔写道:

这两个示例说明了对象和数据结构之间的区别。对象将其数据隐藏在抽象之后,并公开对该数据进行操作的函数。数据结构公开其数据,并且没有有意义的功能。返回并再次阅读。注意这两个定义的互补性质。他们是对立的。这种差异看似微不足道,但却具有深远的意义。
鲍勃大叔对“数据结构”的定义与其他人所使用的定义不同!尽管Martin确实明确定义了他的用语,但这是一种非常奇怪的定义。(banq注:认为鲍勃大爷这样的定义很奇怪?是不是自己也很奇怪?反正奇怪人的看别人觉得奇怪。很多人之前接受的OO认知是空白,他们主要从数据角度理解一切,而不是从行为职责去看问题,所以,这种颠覆对于他们是措不及防的,被怀疑成很奇怪的的定义)
 
最近,我看到了许多反对Clean Code的强烈反对。作为软件新手,这对我来说是具有变革性的,向我介绍了可测试性和可读性之类的概念,而这些概念在大学中他们并未告诉我们。它给了我一个讨论程序设计的词汇。它简短易懂,没有一些繁琐的例子。因此,直到有人提出了一种无懈可击的替代方案之前,我将继续向新手推荐它,但要告诫他们应该保留一些个人意见,并跳过无聊的部分。只要您有更多经验丰富的开发人员向您展示实际上良好的编程,就不会对你造成太大的伤害。
 
John Ousterhaut的软件设计哲学。这是一本简短易读的书,深入探讨了有关软件开发的真相。我读过关于如何编写软件的最好的一本书。
 
两本书绝对是垃圾书:分别是Code Complete和The Clean Architecture书。我完全不会推荐他们。
 
John Ousterhout的“软件设计哲学”是一个很好的选择。简洁,精巧的书,其中包含许多实现细节,这些细节经过透彻思考并智能呈现。
 
《简洁代码》是一本非常有用的书,它将对99%的初级开发人员有所帮助。您想证明它的某些部分(或代码示例)不那么好,那就去做,但是如果您希望100%同意400页的材料来将一本书归类为“好”或“有用”,那您就被误导了。我们是开发人员,而不是蹒跚学步的小动物,请阅读并使用批判性思维来决定要保留什么和丢弃什么。
 
我认为干净代码的想法很荒谬。代码应该简单明了。一个普遍的陷阱是过度设计,使代码变得比需要复杂。但是我在编程的各个方面都看到了这一点,人们花了数小时来创建构建文件(Cmake等),创建UML图,预定义API,还创建了不必要的函数和类(“以后可能需要”) )等。坦白地说,这只是浪费时间。(banq注:过度设计有时是扩展自己理解新业务领域的廉价方式,对未知业务领域通过各种零成本的折腾踩坑是为了避免使用大量琐碎代码踩坑,代码是最昂贵,当然除非你愿意无限制加班,用代码替代思考)
 
让我对Martin的方法感到绝对疯狂的是他几乎出于宗教的坚持,即在编写代码之前不要“选择数据库”。关系代数是20世纪最重要的算法之一,但是Martin希望您使用自己编写的代码来编写和管理自己的关系。对我来说,已经拥有完善的强执行机制时却自己编写管理关系的代码,这是程序流程的错误。我发现令人恼火的另一件事是,我还会遇到那些坚持“没有框架”的人。鲍勃大叔说您的代码不应该与Javabeans或Django有关,而应该与它的含义有关:如果您要编写工资核算应用程序,则该应用程序的存储库应显示“工资核对!”。这是很好的建议。但是,每次查看以“干净代码”标准编写的应用程序时,我都会看到标有“领域”,“服务”,“ use_cases”,“网关”,“适配器”的文件夹。我称其为“编写干净代码框架”,因为这就是事实。
 
我从观看SICP讲座视频时记得的一件事是,您应该将代码视为定义一种新语言,并使用函数(语言中最有用的术语)来分解代码。我认为这是非常基本的建议,但与马丁在本书中所讨论的内容:如果将代码分解为最少但必需的函数,则可以通过有意义的概念/动作的结构和显式命名来使代码更清晰。马丁似乎已经相当大地扭曲了SICP想法。他的零注释代码理念:您不必将注释写在每行的旁边,而是将其放入一个与该注释相同的函数中,这是一种自我记录代码的奇怪方法。(零注释代码:代码即是注释,无需过多自然语言)
 
 感谢您对马丁的观点的强烈反驳。我看过太多的人拿着这本书作为有关如何编写代码的最新参考。对我来说,我所见到的主要问题是他对零注释代码的痴迷。我觉得这很疯狂,因为它导致您描述了无数怪异的命名方法,最终使代码变得绝对不可读。但是好处是它使人们意识到编写代码的方式很重要。
 
这对我来说是一本具有革命性意义的书,读起来很难。
 
鲍勃大叔说数据库是事后才考虑的且不重要的。在那之后,我失去了对他的尊重。(banq注:这是一位可爱的数据库宗教虔诚者)
 
在过去几年里阅读了近一百本有关编程的书籍之后,我仍然建议“ Clean Code”作为我的最爱。作为一个新的开发人员,我在学校没有学过保持方法简单和名称易读。这本书对这两件事的强调是值得的。
 
我认为OO和FP思维之间存在冲突。关于FP的所有内容都与OO概念相反:1)关注数据及其转换(而不是对象之间的消息)。2)不要变异(变化状态,对象只是函数的袋子)。3)传递您需要的所有内容(如上面的评论者所述,这违反了对象属性的全部目的)。我认为这两个阵营是不兼容的,尽管一些面向对象的想法似乎倾向于FP的想法。OO损坏了我的大脑,FP似乎正在恢复它:)
 
FP和OOP是完全兼容。这大约是我们在工作时所采用的方式:FP适用于所有小规模事务:数据是纯数据,并由纯方法操纵。不变的数据结构,返回而不是引用,重新创建而不是修改。这里没有OOP。然后,应用程序代码将责任区分开;有些地方是可以保留状态并通过业务级方法对其进行改变状态的类:每组数据仅在一个类中存储和变化。可以改变的任何状态数据都是私有的,不会对外分发任何对其的可变引用。 大多数情况下,OOP仅用于分离代码库不同区域之间的接口和实现,并使用依赖性注入以避免依赖性循环。代码重用主要通过组合而不是继承来实现。