注重实效的哲学
- 提前的补救预警,把可能要做的补救选择全部做一遍,不要害怕提要求,坦然面对你的困境
- 破窗户的蝴蝶效应,爱惜窗户会更加变得有洁癖,没有时间修窗户,就先拿木板堵起来
- 石头汤案例,让他们瞥见未来,就能让他们聚焦在你周围,协作很好的,不能忽略小事
- 软件足够好就行不必完美,让用户参与进来,提前制定好各种标准和范围,点到为止
- 像投资一样对知识投资评估,因为知识会过时,咱们要避免自己的价值降低,有用的一些方法如下:定期投资,多元化,管理风险,低买高卖,重新评估和平衡,每个月读一本书,寻求一些帮助建议,还要交流学习
- 交流前先提炼大纲,分析听众的需求、兴趣,能让你的听众明白才是交流,切记莫空谈,要选择好的时机,要让文档更好看,要让听众参与,要仔细听他们说话,并回复他人
注重实效的途经
- 重复的危害,每一项知识应该是单一,无歧义,权威的表示,注释是会过时的请谨慎使用,用程序生成头文件,保持属性封装和更多的不用改动性,倘若现在重复代码是快了几秒,但是后面会耽搁几个小时,开发者之间也应该避免重复(建立代码中央区域,互相访问学习)
- 正交模式开发,降低风险,提高效率,隔离第三方工具,全局变量有多线程等问题,改善结构和正交性就是重构,对测试和文档(内容和表现)都有好处
- 要灵活要有可撤销性,如果无法彻底隔离,就用元数据自动生成技术搞
- 曳光弹:把系统环境定死,制作大量文档,确定未知因素。具体操作采用组件式的曳光弹代码,所以这和原型是不同的
- 用便签纸也是原型制作的一种方式,除此之外还适用于代码,新功能,架构,库,性能。
- 实现自己的语言,提高生产力
- 估算:来自模型,要考虑范围,分解成组件,给参数指定值。估算项目进度表增加自己的信心,每次记录下迭代的次数和时间,养成写估算日志的习惯。
基本工具
- 纯文本力量:加密或者哈希值校验
- shell就是工作台,GUI没有自动化
- 精通一种编辑器,vs的模板就有宏啊
- 版本管理很重要,bug是谁的不重要,因为都是你的事情,坏变量检查可考虑它的邻居,bug可能随环境存在,用二分法查找bug,除了修正bug还要反思之前为啥没找出来,倘若一定规模这里需不需要单元测试
- 学习一种短小的语言比如python,perl
- 被动和主动的代码生成器
注重实效的偏执
- 软件模块交互要按照合约,没有完美的软件,自己都不要去相信
- 预处理器加断言可制定合约,通过前置和后置约束来让程序早点崩溃,因为早比后崩溃好得多
- 合约就是一些约定注释
- 如果有一个错误,就是非常糟糕的了
- 断言检查不了不会发生的事情,所以重构要心中有数
- 使用异常可让代码量减少
- 分配资源采用有始有终的原则,警惕全局变量
- 把资源配平的方法是使用栈,在一个类里封装指针,在捕获异常的时候finally中释放资源
- 注意动态语言无法配平资源的时候所采取的3个处理方法
- 使用完对象置于null
弯曲或折断
- 元程序的设计,其实就是配置表
- 时间解耦,涉及到软件工程各个方面不仅仅编码
- mvc
- 黑板模式的好处(有很多解耦思想)
- 方法调用保持低耦合的墨忒耳法则,比如一个方法最好采用如下的方式调用
- 自身调用
- 传入该方法的任何参数调用
- 它创建的任何对象调用
- 任何直接持有的组件对象调用
当编码时候
一些思考
- 模块化让代码容易测试
- 不要靠巧合编程
- 考虑边界值,新bug风险
- 为工作划分优先级
- 算法速度的重要性(所以要估算)
- 编程中去估算代码
- 时间也会退化,所以不能只看这是线性算法速率就完事
- 编程隐喻是园艺(游戏编程未必)
什么时候需要重构(原则:早重构、常重构)
- 重复
- 非正交的设计
- 过时了的知识
- 性能
如何重构
- 要深思熟虑,而不是撕坏大片的代码
- 确保有良好的测试
- 不要在重构的时候添加功能
测试相关
- 按照合约测试
- 经常测试
- 反射技术
- 即兴测试代码也要放在单元测试里
- 构建测试窗口
- 采用自动化测试
测试的内容
- 基本功能,错误,边界值,约定,速度
有些技术需要自己造轮子
- 比如自动化的向导
在项目开始之前
- 项目也不能等太久,不能分析瘫痪
- 事物埋在了深深误解上,肯定没有考虑解决用户的商业问题,所以应该思考他所想
- cookburn用例模板
- 好的需求和文档应该保持抽象
- 看远些
- 只是再增加一个特性,对不起已经是15个了
- 维护词汇表
- 去解开不可能解开的谜题的思考:或许根本就不用,或者有更容易的方法
- 是拖延还是良好判断
- 编写要规范
- 不要成为方法的奴隶
注重实效的项目
一些思考
- 要交流
- 围绕功能而不是职务
- 项目要有项目经理和技术主管
- 无处不在的自动化
- 无情的测试
测试什么
- 单元测试
- 集成测试
- 校验和验证
- 资源,错误,恢复
- 性能
- 用户友好度
其它
- 对测试代码去测试
- 测试状态覆盖而不是代码覆盖
- 代码中的英文注释是很讲究的
- 编写文档用宏啊,你甚至可以制作出自己的文档模版
- 期望要温和地超过
- 给代码签自己名字