编程 实质上是一门手艺活，既然是手艺，外面就会有很多集体技巧和教训。

“破窗实践”，DRY（Don’t repeat yourself），曳光弹，正交性，这些词的意思是什么你还记得么？

《程序员修炼之道》这本书在我看来就是一本 徒弟写给师傅的开发哲学指南。

外面既讲了一些软件开发的哲学，比方破窗实践，它解释了你的代码为什么很快就会变成“屎山”。也讲了一些有用的技巧和工具，比方如何利用好 shell，晋升你的编程效率。

这本书没有简单的代码，没有艰涩难懂的原理，你齐全能够当作一本闲书来看。

这本书里提到的看似人人都懂的情理，恰好是很多码农们平时工作中最不器重，却应该去恪守的理念。

我提炼了一些书中 我感觉至今依然没有过期的观点 （毕竟本书有肯定的年头了，读起来很有年代感），和大家分享下， 这两头也夹杂着一些我的认识和思考。

一、开发的哲学

1. 作为开发，你须要对本人说的话负责。对于不可能做到，危险太大的事件，你有权不去为之负责。
2. 不要给做不到找借口，在你说做不到的时候，要提供你的想法，通知大家，做不到的起因是须要重构，还是须要工夫做原型，还是须要额定的资源反对。

3. 破窗实践：一扇破窗户，只有有那么一段时间不修理，就会慢慢给修建的居民带来废除感。于是窗户就会一个个破碎，人们开始乱丢垃圾，乱涂乱画。所以不要容忍你的代码有“破窗户”。

   这一点大家必定也深有感触，在你写代码的我的项目里一旦看到了一些乌七八糟的构造和设计，你也会不盲目地开始往上面写凑活的代码，缓缓就变成屎山了。

4. 温水煮青蛙，代码是会缓缓腐烂而不被觉察的。要继续一直的察看你我的项目的变动，而不要只是专一于本人的那一块代码。
5. 器重你的”常识“，这是你的资产。既然是资产，就要定期投资（一直学习），多元化地学习。并且要定期的评估你的技术方向，毕竟开发是个动荡的行业，当初吃香的技术过几年就会过期。要一直地调整你的方向。
6. 在做需要时，要像用户一样去思考需要的合理性，而不是一味实现产品下发的需要。
7. 做的软件，要温和的超出用户的冀望。给他们的货色要比他们的冀望多一点，给零碎减少个性时，多做一些额定的致力，能够给你带来很大的美誉。
8. 当你在的开发团队人员宏大时，能够指定每个人负责工作的各个方面。围绕性能，而不是工作职务进行工作的调配。比方有人要探讨日期解决，就去找 Mary，有人要探讨数据存储，就去找 Fred。

二、开发的准则

9. 不要反复你本人：DRY（Don’t repeat yourself）零碎中的每一个组件都要繁多，没有歧义，并且权威的示意进去。
10. 放弃我的项目的零碎正交性：不要让零碎间相互耦合，非正交的零碎意味着你批改这边的零碎，会影响到其余的零碎。

非正交的一个典型体现是前端的 CSS，网上有很多调侃 CSS 的段子，CSS 的一个批改常常会影响到别的中央，这也是 CSS 很让人苦楚的一个中央。在后端开发里，咱们要尽量让零碎间不要相互影响，这对系统的挫伤是很大的，并且在排查问题时十分苦楚。

11. 保障代码设计的可撤销性：如果你的想法是这个问题的惟一解，那么这会是一个很危险的事件。用户的需要变动的很快，你的决策很可能只在当下是正确的，不存在最终的决策，或者说，时刻要留神和反思，如果当初这个办法行不通，是不是就没法挽回了。
12. 做好资源的估算：这里的资源指的是很多代码相干的资源，比方数据库，存储，性能等。在开发前，肯定要做好估算，在设计良好的代码构造，保障再将来可能应酬变动。
13. 把文档尽量多的做在代码里，而不是游离于代码之外。否则，过了一段时间后，你这些文档就没有什么作用了。
14. 你不可能写出完满的软件：作为一个开发，你要有这种盲目，本人也不要置信。所以要对本人可能犯的谬误，做防御性的编程。
15. 异样解决：如果我删掉所有的异样解决代码，这些代码是不是还能运行？如果你的答复是”不能“，那么阐明你的异样代码正在被用在非异样的情景中。这样不好。
16. 利用好元数据：这里的元数据能够了解为配置文件。将形象放进代码，将细节放进元数据。

咱们日常开发中常常应用配置文件和分布式配置核心，把可能放入配置文件的数据尽量放入，这样不仅不便保护和批改，也可能实现不重启利用批改利用行为的性能。代码中应该只有咱们对业务的形象。

17. 思考好零碎并发：要为并发做好周全的思考。

这个要求是不是看起来很稀松平时，大家都会？其实很多大型零碎，尤其是老的零碎，都没有思考并发问题（去问问传统软件企业做的软件，你就晓得了）。并发其实能够算作是互联网公司最常遇到的问题，也是各种技术面试会问的很深的问题，要好好把握。

18. 不要靠偶合编程，要弄清楚程序为何可能运行。

咱们接触变成初期，常常会有些代码调着调着就跑通了，然而连本人也不晓得为什么。这种代码真正用于线上危险很大。毕竟，他兴许不是真的能工作，他兴许只是看起来能工作！

19. 什么时候该重构：当你发现这四个事件呈现的时候，就是你该重构的时候。

• 代码违反了 DRY 法令
• 有非正交的设计
• 需要变动后代码过期了
• 性能有很大问题

20. 重构时的准则：

• 不要试图在重构的时候同时减少性能。
• 在开始重构前，确保你领有良好的测试，这样你才敢放开手脚改变。
• 采取短小，三思而行的步骤。

21. 在测试的时候，要去做状态笼罩，而不是谋求代码覆盖率。
22. 好好学习 shell：通常咱们喜爱用各种带界面的软件，他们的特点是所见即所得。然而也带来了毛病，所见即全副所得（what you see is all you see）。这对于效率的晋升是一个瓶颈，有很多 GUI 下面须要很多操作的事件，在 shell 上只须要一行代码。所以只管它有点难入门，然而学好了，会大幅度提高效率。

关注我

我是一名奋斗在互联网一线的后端开发工程师。

平时次要关注后端开发，数据安全，欢送交换。

• 微信公众号：后端技术漫谈
• Github：@qqxx6661
• CSDN：@蛮三刀把刀
• 知乎：@后端技术漫谈
• 掘金：@蛮三刀把刀
• 腾讯云 + 社区：@后端技术漫谈
• 博客园：@后端技术漫谈
• BiliBili：@蛮三刀把刀

原创文章次要内容：

• 开发实战
• 技术面试
• 算法题解 / 数据结构 / 设计模式
• 程序人生

集体公众号：后端技术漫谈

如果文章对你有帮忙，请各位同学 点赞 转发 珍藏 三连，你的反对是对我莫大的激励~