第五章 软件构建中的设计
-
设计是一个险恶（wicked）的问题(不可控部分)
险恶的问题就是那些只有通过解决或部分解决才能被明确的问题。
你必须首先把这个问题「解决」一遍才能明确的定义这个问题。
书中有一个大桥被风吹垮的例子一个很著名的工程师造好了一座大桥,这座桥经常被一股风吹刮,原本这个问题没什么大不了的,问题在于这座桥的风角度很怪,长年累月最终这座桥崩塌了,踩了这个坑,这个著名工程师才意识到,这座大桥的技术难点原来在于风的角度问题上
也就是说做一个项目的时候,很多坑都是不可预知的,不是说准备得多充分就可以避免的
//一个项目预计一周完成,你就算知道这是一个乐观的估计,在此基础上乘于二,14天,可实际上工期还是远超于这个数 -
软件的首要技术使命：管理复杂度(我们能做什么)
//用vue做一个项目,结果失败了,是vue有问题吗?肯定不是,项目的成败与技术无关
如果一个项目真的因为技术而失败，通常的原因就是技术太复杂导致失控。
将大系统分解成小系统，保持函数短小等。 -
高代价、低效率的设计源于：
- 用复杂的方法解决简单的问题
- 用简单但错误的方法解决复杂的问题
- 用不恰当的复杂方法解决复杂的问题
//如果做一个项目之前首先要做的就是降低复杂度
第25章 代码调整策略
- 一些无稽之谈
代码行数越少，性能越高——错误
//性能问题具体问题要具体分析
特定运算可能比其他的快，性能更好——错误！
//没有什么「可能」，你应该测量
开发者应该不断的优化代码——错误！
//优化着重点在于整个程序,而不是拘泥于某个函数的修改
程序的运行速度同其正确性一样重要——错误！ - 编译器的优化可能比你写得代码更好
这一章主要说的是:测试过程序之后,再去优化你的代码
第26章 代码调整技巧
逻辑
在知道答案后停止判断
按照出现频率来调整判断顺序
要做性能测试，不要盲目相信结论
用表代替复杂分支
惰性求值
循环
将不需要重复计算的逻辑外提
使用哨兵值加速循环
把最忙（循环次数多）的循环放在最内层
其他
削弱运算强度：用移位运算代替乘2或除2
将一些值初始化：如一天是 86400 秒
对每一次改进进行量化
第27章 程序规模对构建的影响
程序员的交流路径与程序员数量的关系
采用文档交流
第28张 管理构建
鼓励良好的编码实践
设定标准（编码规范、文档规范、checklist 等）
每个项目两个人（结对、师徒、支援）
Code Review
提供最佳实践给人参考
强调代码是共有财产
需求变更和设计变更
不要马上变更，累积一些再变更
成立变更委员会，系统化地控制变更
警惕官僚主义
备份所有东西：源码、工具、需求、变更、设计、文档……
如果进度落后了怎么办：
期待后期赶上——不可能
增加人手——火上浇油
砍需求——最靠谱
把程序员当人看
程序员不是机器
要有舒适的环境、要休息
个体差异
团队差异
信仰问题
管理/教育你的管理者
第32章 自说明代码
注释的种类
复述代码——无聊
解释代码——改进代码
标记——可能用的到
概述代码——有用
代码意图说明——指出要解决的问题
传达代码无法表述的信息——非常重要
