左耳听风 - 优质代码「读书打卡 day 11」

你好！我是 Java 工程师蔡姬，此蔡姬非彼菜鸡！很高兴和大家一起共读陈皓老师的《左耳听风》一书，并在这里分享自己的感悟。

我的读书打卡将会分为两部分——笔记 + 打卡。

• 笔记部分，我会整理在读书过程中感悟比较深的内容，和你一起分享。

• 打卡部分，我会就一个点阐述个人的思考。

话不多说，让我们开始吧！

笔记

整洁代码四原则

• 简单的方法

• 简单才易读，简单才易用，简单才能重用，简单才能保证质量。

• 把一件事变复杂是一件简单的事，而把一件事变简单则是一件复杂的事。

• 在设计和制作产品之初，不用考虑所有的因素。

• 维护代码的成本比创建代码的成本要高得多。

• 选择直观的变量名和方法名

• 一个好的名称应该是能“自解释的”、直观的、望文知义的。

• 只写有意义的注释

• 代码写得好就不需要注释。

• 用于生成 API 文档的注释，关键不在于说明功能如何实现，而在于告诉别人 API 能做什么以及如何使用。

• 让代码可读

• 代码不仅要供编译器“阅读”，更应该供同事和其他人阅读。

• 一定要遵守团队内部的编码规范或代码风格。

• 编码只需坚持最基本的 KISS 和 DRY（Don’t Repeat Yourself.）原则，剩下的事情顺其自然就好。

优质代码的十诫

• DRY——Don’t Repeat Yourself.

• 短小的方法——让代码更易于阅读、重用（耦合少）和测试。

• 良好的命名规范——统一的命名规范可以使程序代码更易于阅读和维护。

• 赋予每个类正确的职责——类设计的 SOLID 原则 + 正确的职责。

• 把代码组织起来——物理层组织 + 逻辑层组织。

• 创建大量的单元测试——单元测试最容易发现 Bug，此时修改 Bug 的成本也最低，单元测试决定着软件的整体质量。

• 经常重构——必须有大量的单元测试加以保障，将每次点滴式的小型重构积累起来，代替大的重构。

• 程序注释是邪恶的

• 注重接口而不是实现——接口注重的是抽象，实现注重的是细节。

• 代码审查机制——代码审查不但是发现问题最有效的机制，同时也是一种共享知识的机制。

更优的函数式编程

• 函数式编程的特点

• 不可变数据——默认情况下变量是不可变的。

• 一等公民函数——这种技术使函数可以像变量一样使用。

• 尾递归优化——在每次递归时都会重用堆栈以提高性能。

• 函数式编程的关键技术

• Map & Reduce

• Pipeline

• 递归

• Currying

• 高阶函数

• 函数式编程的优点

• 并行性——在并行环境下各个线程之间不需要同步或互斥。

• 惰性求值——表达式不会在绑定到变量之后就立即求值，而是在需要取用该值的时候求值。

• 确定性——一个函数的结果只取决于它的输入，而不取决于它的运行时状态。

打卡：在实际工作中，你遇到过“屎山”吗？当时是怎么处理的？

哈哈，相信这个打卡问题深深刺痛了大多数程序员的心。试问是谁那么幸运，还没遇到过“屎山”呢？

尤其是面对一些运行年限非常长，又缺乏重构的系统，经手的人不断更迭，每个人的能力和对代码的要求也参差不齐，在系统迭代的过程中没有将统一的标准延续下来，“屎山”就应运而生了。

而作为一个对代码有洁癖的程序员，我自然是很难与“屎山”和睦相处，总是忍不住想推倒重来。一开始也确实是这么做的，但也吃了很多亏。一方面，“屎山”之所以称为“屎山”，单元测试覆盖率就不可能高，有的甚至连一个单元测试都没有，迫切地推到重来会遇到难以克服的阻力。

当时也不得不中途放弃，转而改为分阶段重构的策略，首先，对逻辑重灾区添加单元测试，然后逐个方法重构上线，并在其中添加防腐层，将不兼容变更改为兼容性变更等等。

可见，想要打败“屎山”，不仅需要能力和勇气，还需要方法和时间。到现在，当我觉得一段代码有坏味道的时候，会第一时间进行重构，不让坏味道蔓延。好的代码质量都是迭代出来的，当然，“屎山”也是迭代出来的。

一个美好的祝愿，愿新的一年，大家都能写高质量的代码，不写“屎山”。

以上便是今日份的笔记和打卡内容。欢迎你在评论区留言，我们一起探讨，共同进步。

我是 Java 工程师蔡姬，期待和伙伴们有更多交流和思维碰撞，明天见！