《程序员修炼之道》总结

注重实效的哲学

  • 提前的补救预警,把可能要做的补救选择全部做一遍,不要害怕提要求,坦然面对你的困境
  • 破窗户的蝴蝶效应,爱惜窗户会更加变得有洁癖,没有时间修窗户,就先拿木板堵起来
  • 石头汤案例,让他们瞥见未来,就能让他们聚焦在你周围,协作很好的,不能忽略小事
  • 软件足够好就行不必完美,让用户参与进来,提前制定好各种标准和范围,点到为止
  • 像投资一样对知识投资评估,因为知识会过时,咱们要避免自己的价值降低,有用的一些方法如下:定期投资,多元化,管理风险,低买高卖,重新评估和平衡,每个月读一本书,寻求一些帮助建议,还要交流学习
  • 交流前先提炼大纲,分析听众的需求、兴趣,能让你的听众明白才是交流,切记莫空谈,要选择好的时机,要让文档更好看,要让听众参与,要仔细听他们说话,并回复他人

注重实效的途经

  • 重复的危害,每一项知识应该是单一,无歧义,权威的表示,注释是会过时的请谨慎使用,用程序生成头文件,保持属性封装和更多的不用改动性,倘若现在重复代码是快了几秒,但是后面会耽搁几个小时,开发者之间也应该避免重复(建立代码中央区域,互相访问学习)
  • 正交模式开发,降低风险,提高效率,隔离第三方工具,全局变量有多线程等问题,改善结构和正交性就是重构,对测试和文档(内容和表现)都有好处
  • 要灵活要有可撤销性,如果无法彻底隔离,就用元数据自动生成技术搞
  • 曳光弹:把系统环境定死,制作大量文档,确定未知因素。具体操作采用组件式的曳光弹代码,所以这和原型是不同的
  • 用便签纸也是原型制作的一种方式,除此之外还适用于代码,新功能,架构,库,性能。
  • 实现自己的语言,提高生产力
  • 估算:来自模型,要考虑范围,分解成组件,给参数指定值。估算项目进度表增加自己的信心,每次记录下迭代的次数和时间,养成写估算日志的习惯。

基本工具

  • 纯文本力量:加密或者哈希值校验
  • shell就是工作台,GUI没有自动化
  • 精通一种编辑器,vs的模板就有宏啊
  • 版本管理很重要,bug是谁的不重要,因为都是你的事情,坏变量检查可考虑它的邻居,bug可能随环境存在,用二分法查找bug,除了修正bug还要反思之前为啥没找出来,倘若一定规模这里需不需要单元测试
  • 学习一种短小的语言比如python,perl
  • 被动和主动的代码生成器

注重实效的偏执

  • 软件模块交互要按照合约,没有完美的软件,自己都不要去相信
  • 预处理器加断言可制定合约,通过前置和后置约束来让程序早点崩溃,因为早比后崩溃好得多
  • 合约就是一些约定注释
  • 如果有一个错误,就是非常糟糕的了
  • 断言检查不了不会发生的事情,所以重构要心中有数
  • 使用异常可让代码量减少
  • 分配资源采用有始有终的原则,警惕全局变量
  • 把资源配平的方法是使用栈,在一个类里封装指针,在捕获异常的时候finally中释放资源
  • 注意动态语言无法配平资源的时候所采取的3个处理方法
  • 使用完对象置于null

弯曲或折断

  • 元程序的设计,其实就是配置表
  • 时间解耦,涉及到软件工程各个方面不仅仅编码
  • mvc
  • 黑板模式的好处(有很多解耦思想)
  • 方法调用保持低耦合的墨忒耳法则,比如一个方法最好采用如下的方式调用
    • 自身调用
    • 传入该方法的任何参数调用
    • 它创建的任何对象调用
    • 任何直接持有的组件对象调用

当编码时候

一些思考

  • 模块化让代码容易测试
  • 不要靠巧合编程
  • 考虑边界值,新bug风险
  • 为工作划分优先级
  • 算法速度的重要性(所以要估算)
  • 编程中去估算代码
  • 时间也会退化,所以不能只看这是线性算法速率就完事
  • 编程隐喻是园艺(游戏编程未必)

什么时候需要重构(原则:早重构、常重构)

  • 重复
  • 非正交的设计
  • 过时了的知识
  • 性能

如何重构

  • 要深思熟虑,而不是撕坏大片的代码
  • 确保有良好的测试
  • 不要在重构的时候添加功能

测试相关

  • 按照合约测试
  • 经常测试
  • 反射技术
  • 即兴测试代码也要放在单元测试里
  • 构建测试窗口
  • 采用自动化测试

测试的内容

  • 基本功能,错误,边界值,约定,速度

有些技术需要自己造轮子

  • 比如自动化的向导

在项目开始之前

  • 项目也不能等太久,不能分析瘫痪
  • 事物埋在了深深误解上,肯定没有考虑解决用户的商业问题,所以应该思考他所想
  • cookburn用例模板
  • 好的需求和文档应该保持抽象
  • 看远些
  • 只是再增加一个特性,对不起已经是15个了
  • 维护词汇表
  • 去解开不可能解开的谜题的思考:或许根本就不用,或者有更容易的方法
  • 是拖延还是良好判断
  • 编写要规范
  • 不要成为方法的奴隶

注重实效的项目

一些思考

  • 要交流
  • 围绕功能而不是职务
  • 项目要有项目经理和技术主管
  • 无处不在的自动化
  • 无情的测试

测试什么

  • 单元测试
  • 集成测试
  • 校验和验证
  • 资源,错误,恢复
  • 性能
  • 用户友好度

其它

  • 对测试代码去测试
  • 测试状态覆盖而不是代码覆盖
  • 代码中的英文注释是很讲究的
  • 编写文档用宏啊,你甚至可以制作出自己的文档模版
  • 期望要温和地超过
  • 给代码签自己名字
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值