程序员修炼之道阅读笔记4

第五章 弯曲或折断

 

26 解耦与得墨忒耳法则

尽可能写羞怯的代码，意思是不要让代码轻易暴露自己，不与太多人打交道。

得墨忒耳法则：方法只能调用（1）它自身 （2）传入的参数 （3）方法内创建的对象 （4）直接持有的类的对象。

 

27 元程序设计(metadata)

metadata的意思是关联数据，也就是一些细节数据。比如一些配置信息，调节参数，用户偏好之类的数据。使用Metadata的设计可以极大的增强设计的灵活性。

把抽象放进代码，细节放进元数据，要配置，不要集成在代码中。

 

28 时间耦合

程序应该为并发做好准备。分析工作流，改善并发性。

在编程的时候，要容许并发，考虑任何时间和次序上的依赖。分析出完成合理的工作流有助于规避时间耦合。

 

29 它只是视图

发布订阅模式：发布者持续发布数据，订阅者只订阅自己感兴趣的发布者，并遵循发布者的协议聆听数据。

MVC：不用多说了吧。

 

30 黑板

黑板方式的编程之前没有听说过。我的理解感觉这个模式很像redis之类的缓存系统，并且被多个client以同一的接口(键值对的读写)的形式访问。

黑板上有形形色色的各式各样的信息，但是是能以一种方式来获得，就是『看黑板』（单一接口）。

第六章 当你编码时

 

31 靠巧合编程

当你写代码时，首先明确你懂得你要写的东西，而不要『写写试试』。有可能你写出的程序只在某些场景下运行正确，但是在一些corner case中会失败，这就是靠巧合编程了。写代码难就难在对付corner case，有时不得不做出一些妥协。

32 算法速率

 

这里介绍很少，仅仅只是算法世界的沧海一粟。首先要会衡量程序的算法复杂度O，懂得几种常用算法的O是多少，懂得O(N2), O(log n), O(n)等等算法速率的区别。

 

33 重构

读Martin Fowler的《重构》吧。重构应该是随时随刻的。

 

34 易于测试的代码

别废话，多写测试。写测试也是一个程序自省的过程，不容易写测试的程序往往是设计很差的程序。

 

35 邪恶的向导

知其然，知其所以然。

第七章 在项目开始前

 

36 需求之坑

挖掘需求，建立需求文档，需求文档不能太细致，要保留合理程度的抽象

 

37 解开不可能解开的迷题

有时候问题的解决需要跳出常规的思维。或者简单一点，用另外一种方法，而不是钻牛角尖。

 

38 等你准备好

不打无准备的仗。没什么好说的。

 

39 规范陷阱

不要等万事具备才开始，因为不可能万事具备，用户总是在变。这一点契合敏捷的思想，快速做一个圆形，然后分期快速迭代。

 

40 圆圈与箭头

工具是拿来帮助加快开发，而不是束缚开发的。不需要被各式各样的UML规则搞得束手束脚，只需要画简单易懂即可。

第八章 注重实效的项目

 

41 注重实效的团队

软件的熵：对团队来说，保持一致的高质量十分重要，因为如果没有质量约定，软件的熵会持续膨胀，破窗户会到处都是。

煮青蛙：团队都是由一个不好的习惯而一点一点腐烂的，由于大家身处居中，很难察觉。

交流：敏捷的核心就是交流，just do the talking!

不要重复你自己：换言之，注意在碰到问题的时候看看文档，看看是不是已经有人记录过类似的坑。

正交性：按照合约，解耦，正交性的软件开发原则来分配团队职责。

 

42 无处不在的自动化

凡是有人参与的过程，肯定会产生错误。为了省事，也是为了减少错误发生的几率。单元测试，自动构建，集成测试，自动化测试

 

43 无情的测试

测试是为了保障代码的质量。所以越是仔细，全面的测试，越是有助于系统的健壮，不负责任的程序员或者测试，总是拿着可以正常运行的数据来进行着测试。有条件还是需要专职的测试，合格的测试，而不是那种连代码都看不懂的刚毕业的小姑娘。

 

44 全都是写

文档和注释。没什么好说的，我一直认为写作能力是程序员的第二能力。

 

45 极大的期望

达到客户的期望，才是软件真正的成功。问题是怎么抓住客户的期望。除了多交流以外，能在保证基本功能实现后，添加一些用户友好的功能，会很加分。比如快捷键，漂亮的UI，自动化安装等等。

 

46 傲慢与偏激

以傲慢的名义，留下自己的足迹。换言之，自己的锅自己扛。