20本专业书计划，之前看过某个视频分享，要想成为这个领域的专家，至少20本这个领域的专业书走起。小时候学习书法的时候，老师教过王羲之的练习方法， 当你写完18缸的水，书法水平才算凑合。每读一本专业书都算是一个大型的project, 因为要耗费至少完整10-20个小时才能完成，且分散到好几天到1-2个月。而且读专业书不像读故事书那样轻松，一般还要边阅读边思考。内化功力是重要的，学习不能只是学不用，我也渐渐意识到，只有在工作中，运用过程中，边做边学习边思考才是有效学习。所以，摒弃学生时代那种学习方式，读完整本课本，再去用，或者读完整本课本，根本没有实战机会去用，这是比较低效的学习，随着时间久了，从书本里学到的东西也就淡忘了。
我读了啥？
最近我完结的一本专业书阅读是：Clean Code: A Handbook of Agile Software Craftsmanship （代码整洁之道），原版链接放在文末参考处。
大师级作者 Uncle Bob 分享：
写代码如写文章
把系统当故事来讲，而不是当作程序来写
计算机业内知名的Uncle Bob (Robert C. Martin)的书，这本书，会给你提供很多思路，整洁你的代码。对我而言，这本书对我最大的帮助是教我如何做好一次Code Review (CR), 以及在自己写代码的时候如何优化自己的代码。 在我进入一家成熟的科技公司 （Tech Company）之前，我根本不太知道CR是什么东西，之前实习的时候的创业公司也不需要做Code Review. 诚如在领英上很多创业公司的人分享的一样，一个创业公司，只要代码能跑，就赶紧先上线再说。然而，这个方式，在成熟的科技公司里，是不允许的，因为你的代码，可能随时破坏Production的稳定性，带来爆炸范围 (Blast Radius)很广的客户影响 (Customer Impact), 进而来带几百万几千万美金的业务损失。隐形的危害是，可能现在看不出来，长久地会越来越难维护，并且变得越来越糟糕且越难越铲除，花费工程师越来越多的时间进行运维 （Ops），而时间就是金钱。
在我工作第一年内，那时候我还是不太懂如何做好一次Code Review, 当有同事叫我帮忙review 一个Code Logic, 那时候的我大概是这样：
- 看了半天，不知道该从哪里入手？从哪里看起？
- 对于这个Code Logic 我该问什么问题？
- 不知道问什么问题，于是就去模仿别人如何回复？ 想参考一下别人该从哪开始看。
- 查遍内外网的WIKI， 关于”How to do a code review?”
- 那时候的我，甚至花费很多时间，挤尽脑汁，都问不出一个问题。
- 最后，花费很多时间，却还是没有信心自己是否做好一次Code Review。
- 最后不确定因素仍然很大，大脑里没有一个标准，我到底该不该Approve? 不Approve 又不想卡着同事进度。
这本书是组内Tech Lead 推荐给我们的，我花了一个月时间看完，带着做笔记那种方式阅读，同时在工作中进行运用。这本书让我受益的是：
- 任何technique 都是可以进行训练的，包括如何做好Code Review 也是，没有人生来就懂做任何事，所以对于刚毕业的New Grad 不知道怎么做CR也是很正常的。但是假以时日，以正确的策略进行训练，是可以掌握的。
- 这本书提供了好几个方面，带给你思路，一个整洁的代码该是什么样的，什么是不好的代码，根据不同的情况，该怎么往整洁的代码进行改进。
- 一个BAD CODE 的后果：带来无穷无尽的 Ops, 增加后期维护负担 （例如，半夜被page , 没法睡觉起来修某个Bug），不如从创立开始就优化它，让它用尽量优美的方式存留。
- 诚然，写一份代码，能跑通并上传，是很快的，于是有的人怀疑，到底该不该从一开始花费时间去优化？但是从长远的眼光去看待，一份不好的代码，长远会消耗你越来越多的时间和精力去修复，最后变成历史遗留问题， 该留该删都无从下手，不删又源源不断带来维护痛苦。
- 不仅是写作，写书，创作的时候我们才是作者，当我们在写一份Code Logic的时候，我们就是这份Code的作者。以作者的角度去思考，你要让你的读者知道你在写什么，你写的代码不是写日记，不是只写给自己看。
- 一份优美的Code，就像一首优美的诗，一篇优美的散文，读起来让人赏心悦目，读者会感激你为他们省下了很多难以理解的琢磨时间，并且还能从你的CODE里面获得启发共鸣。
书里面的精华在于，会从这几方面带给你启发：
- 命名原来很重要，好的命名让你一眼就知道这块逻辑在做什么，怎么样给方法变量命名？
- 规范代码格式的重要性
- 边界设置，如何优化边界条件，如何优化条件设置？
- 每块逻辑该放在什么地方最合适？依赖（包/服务）该放在什么位置？
- 什么是冗余内容，如何化繁为简？
- 什么才是好的注释？什么是不必要的注释
- 异常处理的优化
- 测试规范，如何优化提高测试速度，如何提高测试的安全度？
- 如何规范化多线程多进程，如何减轻并发带来的难以发现的问题？
结语
在我工作第二年的时候，随着工作实战经验的积累，搭配理论的补充，读完这本书后，我工作第一年内的那些疑惑都解开了，并且享受这个过程，Code Review 是一个很好的机会，有一些资深的工程师会给予你反馈，如何进一步优化。
如果你也读过这本书，有什么共鸣的，欢迎在下方留言~
参考
美国亚马逊 英文原版 Clean Code: A Handbook of Agile Software Craftsmanship
亚马逊中国 中文版：代码整洁之道
5 赞 Likes
小伙真帅