从一本 Java 书说起工程
最近看了一本工具书,是 Effective Java 中文版(第2版)
我用时两个多星期,分别在早起、晚上和周末的时候把这本书细细过了一遍。觉得很有意思。在我的感觉来看,这个是Java语言的《原则》的书。同样的这就说明我看的工具书很少哈哈哈。
这本书不适合入门的时候看,而是使用了Java半年以上、较为熟悉Java生态了之后,去翻看比较合适。我觉得里面提到的很多原则在编程时都应该尽可能遵守。
很多Java规则,读这书之前并不知道的,但可能你一直就是这么做了,也许你会惊讶。
其实这些都是IDE(集成开发环境,Java常用的是IEDA)在无形的帮助我们养成良好的习惯而努力。因为他会通过各种警告提示我们。如果你有很好的信任IDE的话,你将养成了不少好习惯。
对于书中的 78 条规则,这里就不细讲了,因为这里是读书笔记而不是技术分享。
今天想说的是根据这些Java开发规则而想到的一些七七八八的个人的想法。
首先,使用 Java 的人,绝大多数都是程序员,就是所谓的软件工程师。我们在公司里,从事的是代码生产工作,也就是说,我们做的是一项非常严谨的工程,这里的严谨的工程,我们首先是工程师。我的意思是相对的,是相对于科学研究和所谓极客精神。科学研究是不太考虑成本的,是可以试错的。而极客精神,是带有个人主义色彩的,是探究到底的精神。而在我认为的工作中,这些都不是最重要的,最重要的是严谨和规范的工程。
基于这个指导思想,在《Effective Java》里,反复唠叨的是要严格规范写法,要写文档、能够不用复杂的东西就不用。
这里有几个词,严谨和规范就意味着约束和要求,「没有规矩不成方圆」,我们生产的是商业代码,是要经过多人之手的。在这种约束下,个人必须遵从集体,组织的约定是首要的,个人的代码风格必须遵从组织的代码风格,代码注释、命名、通用写法都必须有强一致性。因为只有这样,这项工程的可维护性才高,生命力才够顽强。
还有「工程」一词,这个意味着稳定和成本。什么意思呢?就是在工程里,不允许出现比较激进的东西,必须是被广泛使用了的,有使用基础和较为广泛的使用生态的技术,才能够被引进到工程里面来,因为这意味着维护这个工程的成本比较低,我们不做研究,因为大多数时候的工程代码,都是效率优先。因此常常有「拿来主义」。这个再正常不过了,国内的Java生态,常常就是阿里巴巴有什么开源了什么,其他中小型厂商就看一看能不能为己所用,如果有用、成本不高、能够解决问题的,就直接用起来了。不少厂商也会开源各种各样的组件,然后相互抄袭和借鉴,其实是蛮好的事情。
甚至我觉得,对于一个五年工作经验以下的开发者,都不太需要考虑创新,一板一眼地学习,根据规范来就好了。
二八定律在哪里都可以套用。这个感觉也有点奇怪,这二八定律难道是万精油?到哪都可以扯上两句,容易形成诡辩了。
这一点是在工作过程中感受的,和书中所看到的也类似吧。大概就是20%的技术可以解决80%的需求,因为对于同一类的工程,需求都是类似的,则20%的技术积累就可以了。这样常常导致一个开发者容易陷入自我满足的状态,感觉没有成长性了,大部分事情都可以解决,没有自我学习的动力了。那没办法噢。学习这种事情,就是靠自己的。
这本书的确是一本工具书,不是Java开发者的话也是看不懂。而后面引申出来的想法,大概是可以在工程领域通用的。书翻来翻去都是那样,甚至越学越窄,而思想则越思考越多,并且还挺通用的。这个真是有意思的事情。