read_books/程序员修炼之道_ascii.txt at master · dizuo/read_books · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
# chinese page(english page)

1.1 我的源码让猫给吃了	2
1.2 软件的熵	4
	破窗理论，整个过程的心态变化，”随便“，“无所谓” 开始。。。
1.3 石头汤与煮青蛙	7
	跨部门合作，要让其他部门出人，得先出一个demo，眼见为实了才能调动他们的积极性。
1.4 足够好的软件	9
1.5 你的知识资产	12
	知识是无形的资产，具有时效性，需要不管更新迭代。
	增加对知识读书的投入
	充电增长见识，同时批判地思考，对所看到的、听到的进行二次过滤。
1.6 交流	18
	I believe that it is better to be looked over than it is to be overlooked.被打量比被忽略重要。
	Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people. A good idea is an orphan without effective communication.
	除非你能够与他人交流，否则就算你拥有最好的主意，最漂亮的代码，或是最注重实效的想法，最终也会毫无结果，没有有效的交流一个好想法就只是一个无人关心的孤儿。

	·知道想要说什么：写大纲，熟练掌握
	·掌握听众的需求
	·选择时机
	·选择风格，面谈、QQ、Email。。。
	·让文档美观，不能只注重内容。
	·让听众参与，互动~
	·做倾听者：让大家听你说话，必须使用一种方法：听别人说话。
	·回复他人：任何形式的讨论，回复他人。。
	It is both what you say and the way you say it.

2.1 重复的危害性	26
	需求不断在变化，代码、模块的复制十分容易，梦魇地开始。
	DRY Don't repeat yourself. 最重要的工具！
	DRY替代方案是多个地方有相同的内容，
		It isn't a question of whether you'll remember: it's a question of when you'll forget
		不是你能否记住的问题，而是你何时忘记的问题。

	·强加的重复
		信息多重表示：客户端、服务器可能基于不同语言开发，某些数据结构不可避免重复，方案：开发代码生成工具。
		代码注释。
			Bad code requires lots of comments.
			代码和注释某种意义下也是重复，每个修改都要同时修改code和comment，注释会不可避免地过时。有注释还不如没有。
		代码和文档
			写代码，同步文档。但是当最后期限逼近，客户抱怨，We trend to defer the updating of documentation.(我们一般倾向于延迟更新文档）。
		语言问题
			C/C++ .h,.cpp文件中函数申明等重复，没办法克服！避免在头文件和源文件中重复注释。
	·无意的重复，有时候重复是错误设计的结果。
		C++, Java, Always use a accessor functions to read and write the attributes of objects. It will make it easier to add functionality, such as caching in the future. The trick is to localize the impact(影响局部化).
	·不耐烦的重复
		项目紧任务重，怎么快怎么着。。
		欲速则不达，shortcuts make for long delays.前期的不耐烦后期可能付出代价。
	·开发者之间的重复
		这种重复最难检测。
		相互之间多交流，论坛、svn，codereview，相互学习！

2.2 正交性	34
	STL是正交性设计的典范！	正交性：模块之间耦合度为0，两个向量正交：一个在另一个上面投影为0。	Eliminate effects between unrelated things.

	·提高生产率	35
		改动局部化，开发、测试时间最低。
		正交能够促进复用
		正交组件组合，M*N结果
	·设计	37(56)
		Orthogonal systems: modular, component-based, layered，模块化、组件化、分层！
		组件按层次组织，每层提供一级抽象，每层只使用其下面的层次提供的抽象，改动底层实现，不影响其他代码方面，有极大的灵活性。参见Android层次化组件。
	·工具箱与库	39(57)
		ME：stl中容器和迭代器，适配器正交性，更换数据结构只需要修改数据结构类型，代码基本上不需要修改。
	·编码	40(59)
		Keep your code decoupled.
		Avoid全局变量：依赖于全局变量，升级到多线程可能会潜在风险，OO做法是：一般context通过构造函数参数传入模块。单例设计模式。
		避免编写想相似的函数：Strategy策略模式
			Refactor: Get into the habit of being constantly critical of your code. Look for any opportunities to reorganize it to improve its structure and orthogonality.
			养成批判对待自己代码的习惯，寻找任何机会，重新进行组织优化数据结构和正交性。
	·测试	41(60)
		为每个模块写内在的单元测试。
	·文档	42(60)
		正交性也应该应用到文档中，两个维度坐标轴是内容和形式。显著改变形式并不会影响到内容。
	·认同正交性
		正交性跟DRY很类似，DRY降低系统内重复度，正交性是降低系统模块之间的依赖性。

系统不正交，每处改动都会造成其他地方出错，噩梦开始，It is time to refactor！

2.3 可撤销性	44(62)
	·可撤销性	45(63)
		要把决策视为写在沙滩山的，而不要把他们刻在石头上。大浪随时可能到来把他们抹去。
		There are no final decisions.
	·灵活的架构	46(64)
		不同语言（java、C++、）不同平台（win32、unix、linux、android等），随时可能要支持，把第三方产品隐藏在定义良好的抽象接口 或者使用元数据。
		可撤销性：如果某些东西是自动添加的，它也可以自动撤销。
		没人知道将来会怎样，尤其是我们，要让代码学会“摇滚”：可以摇就摇，必须滚就滚。

2.4 曳光弹 	48(66)
	曳光弹与常规子弹交错在一起，运行环境和约束与真实子弹完全一致（这点区别于原型），并且反馈是及时的。
	·在黑暗中发光的代码	49
		用户能够及早看到能工作的东西
		开发者构建了一个能在其中工作的结构
		你有了一个集成平台
		你有了可用于演示的东西
		你将更能够感觉到工作进展
	·曳光弹并非总能击中目标	51(69)
	·曳光代码 vs 原型开发	/ 	Tracer Code versus Prototyping	51(69)
		原型开发为了试验，结束后丢掉所有所有东西，使用已经获得的经验进行重新编码。例如使用高级语言实现xx功能，结果理想的话，然后用C/C++实现算法细节。
		原型制造生成用过就扔的代码，曳光弹代码虽然简约，但却是完整的，并且构成了最终系统的骨架的一部分。原型制造可以视为在第一发曳光弹发射之前进行的侦查和情报搜集工作。

2.5 原型与便签	53(70)
	·应制作原型的事物
		架构、已有系统中新功能、外部数据结构内容、第三方工具组件、性能问题、用户界面设计
		Prototype to Learn
	·怎么样使用原型 54(72)
		可以忽略正确性、完整性、健壮性、风格。使用高级脚本语言快速构建原型，获取经验以后使用低级语言重写！
	·制作架构原型 55(73)
		追求架构整体性，延迟考虑细节。
	·怎么样不使用原型 56(73)
		别人很容易被原型的完整性所误导。如果所在的环境或文化不允许，则最好还是采用曳光弹方法，你最后将得到一个坚实的框架，为将来开发奠定基础。

2.6 领域语言
2.7 估算