程序员修炼之道

时间:2023-02-12 08:35:57

  身为一名程序员,当一本叫做《程序员修炼之道》的书出现在面前,又怎能忍住不去看呢?于是,出现了下边的读书笔记。
 该书确实博大精深,包含了很多内容,但很多都是点到为止。那种心中有剑的感觉,跃然纸上,或许高手都是如此吧。根据多年武侠观摩经验,一定要把不懂的记下来,以后肯定大有用处。那就记。
 第一章:注重实效的哲学(A Pragmatic Philosophy)
 说实话,第一遍看完这章,我只记住了“破窗户理论”和两个寓言--石头汤和煮青蛙,却不知道注重实现的哲学到底长什么样-_-!,没办法,天生愚钝,再找一遍吧,找到如下关键字:
 一. 负责,也就是咱们所说的干一行爱一行,也就是职业素养;
 二. 变化,就是所谓的大局观;
 三. 合理,就是做“做够好的软件”。完美,只存在于梦里,或许梦里也没有完美;
 四. 学习,不断的提供自己;
 五. 交流,这里说的不是和计算机交流;
 爱岗敬业,注重实效,注意方法,积极进取,以人为本,这是做事的基本准则吧?这一章充分体现了哲学的普适性。

 第二章:注重实效的途径(A Pragmatic Approach)
 这章的内容涵盖了软件开发的各个方面,包括编码、架构、项目管理、开发方式、估算等。
 这章的实质,是介绍软件开发的公理。
 公理一. DRY原则
 话说一天,一个叫Rails的小孩来到世界最牛的武馆--java武馆,用DRY(Don't Repeat Yourself)和CoC(Convention over Configuration)技压群雄后,他的两大绝技,便为世人所追捧。
 那么,何为DRY?就是拒绝重复,可重复真的那么好决绝吗?那还得先看看重复的伎俩。
 强加的重复(imposed duplication)。包括信息的多种表示,注释,文档,语言问题。
 无意的重复(inadvertent duplication)。
 无奈性重复(impatient duplication)。
 开发者之间的重复(interdeveloper duplication)。
 公理二. 正交性
 降低各模块的耦合性(解耦性),也就是spring的本质,具体表现为面向接口编程,AOP。
 减少团队组织的重叠。
 公理三. 可撤销性
 有容乃大。具体表现为灵活的架构。
 领域语言(DSL?)

 第三章:基本工具(The Basic Tools)
 工欲善其事,必先利其器,没什么好说的。文本编辑器,shell,源码管理,文本操作,代码生成。。。总之,人之所以为人,是因为人懂得创造工具,使用工具。

 第四章:注重实效的偏执(Pragmatic Paranoia)
 按合约编程。于DDD有何联系?这应该就是rails和grails里领域类的约束吧?有一个叫contract4j的DBC项目,由于不太喜欢annotation的contract方式,也没有时间过多研究。看来这块东西需要好好补充下。
 断言式编程--如果它不可能发生,用断言确保它不会发生。
 正确使用异常。
 配平资源。程序的因果报应说,为了来世(程序上线后)的美好,一定要确保写程序时有始有终。所幸,我们的世界已经不那么原始了,spring里的模板类,动态语言(ruby/groovy)里的文件操作闭包,都可以帮助我们往升彼岸。

 第五章:弯曲,或折断(Bend,or Break)
 解耦与得墨忒耳法则(google了下Demeter,介绍如下:德墨忒耳是希腊奥林珀斯十二主神之一,罗马名字刻瑞斯(Ceres)。她是宙斯的姐姐,掌管农业的女神,给予大地生机,教授人类耕种,她也是正义女神,感觉这里说的不是这个人。。。)
 函数的得墨忒耳法则:某个对象的任何方法都应该只调用属于一下情形的方法:
  它自身
  传入该方法的任何参数
  它创建的任何对象
  任何直接持有的组建对象

 元程序设计,一个古老而又时髦的词,很多内容,暂且不表。
 时间耦合--关于程序的时间--并发和次序。

 第六章:当你编码时(While You Are Coding)
 这章主要介绍了一些编码时的经验,包括:算法速率(big O),重构,测试,对向导的警惕。可以看作是对最新的编程方法的一个选择和总结。

 第七章:在项目开始之前(Before The Project)
 挖掘需求,挖掘,说明需求分析的复杂。需求文档是对需要完成的某些事情的陈述(会保持抽象),它不是和用户的聊天记录。商业政策经常会改变,所以我们并不想把它们硬性的写入需求。那么怎么办呢?把需求文档和策略文档分开,并用超链接吧两者连接起来。需求应该深入到商业逻辑的本质,而不能知其然,不知其所以然。也就是确定DDD里的模型。
 当遇到不可能解开的谜题时,考虑它是否是真正的约束。
 构建原型比空谈更有实效。
 作为注重实效的程序员,应该倾向于把需求搜集、设计、以及实现视为用一个过程--交付高质量系统--的不同方面。
 不要做任何形式的奴隶。

 第八章:注重实效的项目(Pragmatic Projects)
 注重实效的团队,再次祭出了第一章的那几个原则。
 足够好的软件。
 无处不在的自动化。
  项目编译(生成代码,回归测试);
  构建自动化;
  自动化管理(网站生成,批准流程);
 无情的测试

 该书没有太多的代码,应该作者是在一个哲学的高度来教授自己的经验。可以归类为到软件方法学,只是他的方法没有明确的定义,只有一个原则:实效。