谈代码规范、思想

谈起代码设计规范，人们总会说出SOLID、KISS、DRY等等专业词汇。

为了易于人们记忆，这些专业词汇都是由其英文单词首字母拼接起来的，如KEEP IT SIMPLE 、STUPID、DONT TRY YOURSELF。

我们当然也能理解这些设计规范的意思——毕竟有那么多的博客、文章。

然而有多少人能真正使用这些设计规范呢？相比于知道它们的人数，实际使用过的人数应该很少。

知易行难。知行不能统一，还是不知。

大部分人在刚入行时写的代码都“too young too simple”。很幸运的是我在刚入行时就被一位大佬告知：如果你哪天领悟了SOLID原则，就能写出好代码。

被告知之前，我有看过SOLID原则，被告知当天，我又看了一遍SOLID原则，被告知以后的以后，我也会不时的看下SOLID原则。但是我一直都没能彻底了解这个原则——我只是看懂了那些博客说的是什么，但是究竟要如何使用SOLID原则还是一头雾水。

也许这些原则就不是用来指导人们如何使用的，而是告诉人们好的代码应该是怎样的。

程序猿也是在不断进化的。

刚入行的小伙子是“鲁莽”的，他们的眼里好像只能看到“需求”，他们会飞快地将功能实现。这时候的代码没有遵循任何的设计原则，代码混乱，很容易产生bug。而且解决这些bug需要很长的时间，因为他们的代码在实现功能时没有体现业务逻辑。理清为什么这样写要耗费人不少耐心。如果这些代码被一些有强迫症的人看到，一定会给它重构一遍。

有些工作经验的开发者会学习业内比较有名的技术、思想，就像现在的中台、DDD、TDD等。当他们照猫画虎得将这些用到实际项目中时，另外一些没学过这些技术的人会对这些东西表示怀疑——这些东西似乎让代码变得更加复杂，且没看到任何收益。

经过一段时间的怀疑人生后，对技术照猫画虎的人们开始否定这些技术，认为这些技术是徒有其表。

当开发者的经验积累到一定程度后，会开始反思当前的架构是否合理，于是尝试对其进行改进。然后就会突然发现，他竟然运用到了这些设计原则、思想。

那么以后会怎样呢？