微信号:C_programming

介绍:移动互联网支付技术和解决方案...

重读程序员修炼之道

2014-11-11 19:15 JeffChen

这周末一天的时间把<<程序员修炼之道>>这本书翻了一遍. 这本书的原名是”注重实效的程序员”. 我更喜欢原来的名字, 因为平时自己都是希望追求”实效”,而不追求奇技淫巧.
程序的世界里,奇技淫巧太多,多到学不完.人的精力终究有限,遵循朴实的道理,追求效率才是程序员的“终极之道”.
其实这本书的中文版的序也是值得一看的,几位写序的作者把这本书总结得不错. 只有有经验的程序员,有多年编码经验的程序员才能真正认识到这本书的价值.

通常读这类书的都会有三种感受:
1. 作者说的有道理,应该这样
2. 作者说的有道理,我的经历告诉我确实如此
3. 作者说的有道理,为了做到这一点,我知道有这些方法,1,2,3 etc.

和程序员修炼之道类似的方法论的书,还有UNIX编程艺术,<<代码大全>>,<<编程艺匠>>等。也难怪对于N年前的我无法理解,为什么代码大全这本书排在了所有
程序员必读书的第一位.看这里 排名前2位的就是代码大全和程序员修炼之道.

比如下面这些,许多这次读来颇有感慨:

1. 我的源代码被猫吃了——-真的,去年我有段时间写的代码被同事sudo rm -rf了,都是我自己的错啊,因为服务器只有2K的下载速度,没有备份源码
2. 不要容忍破窗户 —— 真的很介意破窗户,有时候想,这个模块这次写完就再也不会更改了,于是破窗户留在那里成为了一道风景
3. 定期为你的知识资产投资 ——- 我一直在做,不过没有参加本地用户组织,因为QQ群比那个组织更靠谱. 非技术书已经好久没读了,微博算么?
4. DRY —— Don’t repeat yourself,大概每个程序员都背出来了, 通常一个项目开始的时候可以做到,随着项目进行,无耐心的重复就会出现,因为重复的话实现更容易,为了避免重复往往需要重构代码,而重构代码往往意味着回归测试,为了偷懒复制完了事. 至于强加的重复,作者提到的客户端服务器开发,这正是代码生成器,类似protocol buffer派上用场的地方. 还比如根据数据库字段,自动生成访问数据库的python代码.
5. 正交性 —— “正交性”这个词用在了太多的地方.听到有人用在语言的设计上,有人用在软件的架构上,也有人用在api的设计上.总之核心思想是,没有副作用,改变A不会影响B.正交和复用是相关联的,现在写代码会有目地性地考虑复用,在这个项目中使用,下次希望能在其他项目中继续使用.正交的好处很多,更健壮,更好测试,更容易维护更改.实现正交的方式很多,描述的时候可能是模块化,组件化,分层等.具体到技术, 应该尽量封装, 少使用全局数据,不要写相似的函数
6. 可撤销性—– 这使我想到了C++ STL.在使用C++ STL的时候尽量使用算法, 不要使用容器的特定方法.因为这样,有一天你的实现从一个容器更换为另一个容器就非常简单.
7. 曳光弹 ——其实我刚读这章的时候,以为作者讲的是prototype.后面讲述了曳光弹和prototype的区别,原来曳光弹是产品的一部分,而prototype是写完就扔的.好吧,那么原来我过去写的都是曳光弹.而按作者的说法,是为了学习而制作原型. 那么,比如我使用一个XML库,或者一个图形库,其实都是先写prototype再写到曳光弹里了.
8. 纯文本的威力—– 这一条Unix编程艺术里也提到了, 几乎每个项目都会有各种文本配置.文本配置的优点是方便阅读,易于测试,另外很多工具支持纯文本的操作,比如diff。纯文本的劣势是占内存以及解析慢. 我的这篇文章里描述的其实是纯文本的解析. 另外对于纯文本的解析,不仅仅是系统启动的时候解析,考虑在运行过程中解析纯文本.
9. shell游戏 —— shell的威力就不多说了,每一个在linux下工作的人都应该有一个自己的命令库,使用find, grep, ln, awk,sed
10. 强力编辑器 ——这一点我没有做到, 虽然一直在用vim,实际上真的不算对各种命令熟悉, 而在windows上除了各种IDE,正用着被作者鄙视的notepad。
11. 代码生成器 —— 这一点自己从来没做过,但是我看到别人把代码生成器做成项目的一部分,并且非常成功地降低了后序的工作量
12. 断言式编程 —— 这一点,如果你写过一个复杂的算法,或者写过一个中型的程序,自然会有深切的感受,断言式编程可以大大缩短debug的时间
13. 使耦合减至最少 —— 这一点很重要,解耦的重要性不用说了. 关于解耦最好的书,当然是Lakos的大规模C++软件开发,这本书里大神对逻辑设计和物理设计进行了详细的描述.惭愧,这本书我只看了小部分. 另一本C++ api设计这本书,也讲到不少关于耦合的方面,非常值得C++开发者一读.
14. 重构 —— 关于重构我可以有很多话要说,其实最近的项目经历也是个重构很好的实战经历. 有一点和作者共鸣的是,不要在重构的同时增加功能.
15. 易于单元测试 —– 单元测试的重要性就不说了,但是意识到重要性还是会习惯性地不写.其实对于小项目,单元测试写在#ifdef里是很方便的。
16. 需求之坑 —— 我的理解需求之坑,会导致后面代码不断地重构,直到有一天来了一个需求,他不太好重构,算了吧,那就做一些”没耐心”的重复把.所以项目开始前,需求越清晰越好.


 
移动开发技术 更多文章 #推荐第一篇# 你问大家答 你问我答 实际小问题答案 抵挡不住的诱惑 新百伦3折包邮
猜您喜欢 锤子和钉子 程序员的鄙视链有多长? 一款快速生成代码的Xcode插件FastStub 掌握GitHub上这100个Python repository,能让你的工资翻倍哦 Golang语言--闭包和普通函数调用区别