36 lines
4.0 KiB
Markdown
36 lines
4.0 KiB
Markdown
|
# 第三季回归 | 我们一起来写好代码!
|
|||
|
|
|||
|
你好,我是郑晔,我又回来了!
|
|||
|
|
|||
|
在《[10x 程序员工作法](https://time.geekbang.org/column/intro/100022301)》中,我们讲了工作原则,在《[软件设计之美](https://time.geekbang.org/column/intro/100052601)》,我们讲了设计原则。有不少同学通过各种途径和我表示,这两个专栏让他们受益匪浅。但也有人和我提出,虽然觉得有收获,但还不过瘾。
|
|||
|
|
|||
|
这些原则虽然很好,但怎么应用到自己的实际工作中,完全取决于个人的理解,经验丰富的人或许可以直接改变自己的行为,而经验少的人,从中的获得就完全取决于个人的悟性了。
|
|||
|
|
|||
|
比如,我在两个专栏中都讲到了单一职责原则,最终得出的结论都是要把代码写短小。但什么叫写短小,不同的人理解起来就是有差异的。
|
|||
|
|
|||
|
有一次,我在一些人面前演示了如何将一段代码重构成小函数,然后,我问听众,你们可以接受一个函数代码行数的上限是多少?一个听众很认真地说,100 行。我默默地看了看被我重构掉的那个“不好”的函数,好像也没有 100 行,按照他的标准,那个函数根本不需要改。
|
|||
|
|
|||
|
还有一次,一个颇有经验的前辈在我面前说自己写代码的要求很高,函数要求写得很短。我不明就里地问了一句,你要求一个函数不得超过多少呢?他说 50 行。
|
|||
|
|
|||
|
50 行也好,100 行也罢,在我看来,这简直是一个天文数字。我通常对自己的要求是,像 Java 语言这种表达能力一般的语言尽可能 10 行之内搞定,而像 Python、Ruby 这类动态语言,5 行代码就可以解决大多数问题,而且很多代码一行就够了。
|
|||
|
|
|||
|
在自己实际的项目中,考虑到团队的协作,我在静态检查中配置的参数是 20 行。换言之,一个函数超过 20 行,连构建都是无法通过的。
|
|||
|
|
|||
|
从这些例子中你可以看到,虽然大家都遵循了同样的原则,但具体体现在代码上,却是千差万别的。
|
|||
|
|
|||
|
也正是因为理解的差异,造成的结果是,虽然许多人懂得了很多道理,依然不能很好地完成自己的本职工作。许多人日夜辛苦地调试的代码,其实在写出来的那一刻就已经漏洞百出了。
|
|||
|
|
|||
|
如果能够知道这些代码是有问题的,在写代码之初就把这些问题消灭在萌芽中,日后的辛苦就可以节省出不少。
|
|||
|
|
|||
|
Martin Fowler 在《[重构](https://book.douban.com/subject/30468597/)》这本书里给这种有问题的代码起了一个很有特点的名字:代码的坏味道。
|
|||
|
|
|||
|
有追求的程序员都希望自己能够写出整洁的代码,而这一切的出发点就是坏味道。只有拥有对于坏味道的嗅觉,才有机会对代码进行重构,也才有机会写出整洁的代码。
|
|||
|
|
|||
|
所以我做了第三个专栏,在这个专栏里,我们就从代码的坏味道出发。我会给你提供一些非常直观的坏味道,让你看一眼就知道代码有问题。在这些坏味道中,有一些是你已经深恶痛绝的,比如,长函数和大类;有一些则是在挑战你的编程习惯,比如,else 语句和循环语句。这些坏味道的知识即学即用,对照你的代码,你立刻就能发现很多问题。
|
|||
|
|
|||
|
按照我们专栏一贯的风格,我不仅仅会告诉你一段代码是坏味道,也会告诉你这些坏味道之所以为坏味道背后的道理,还会和你讨论如何去重构这段代码。
|
|||
|
|
|||
|
有了《[10x 程序员工作法](https://time.geekbang.org/column/intro/100022301)》或《[软件设计之美](https://time.geekbang.org/column/intro/100052601)》这两个专栏的积淀,当你再去学习新专栏的时候,之前学习的这些原则就实打实地体现在对于代码的改进上,让你修炼的内功有了更好的用武之地。
|
|||
|
|
|||
|
来吧,欢迎加入《[代码之丑](https://time.geekbang.org/column/intro/100068401)》!请再次和我一起踏上程序员精进之路,我们一起修炼,不断打磨自己编写代码的手艺!
|
|||
|
|