北京中科医院假 http://pf.39.net/bdfyy/zjdy/161222/5131646.html[写在之前]纸上得来终觉浅,绝知此事要躬行
本书罗列了很多tips,与其草草读之而束之高阁,却不如动手实践,一周或者一月实践个2、3条,几番下来,想来所获匪浅。
注重实效的哲学
提供选择,而非借口
如果坏事情发生,提供解决方法,而不是找蹩脚的借口。如果要辩解,请先在头脑中预演一遍,然后对着你的猫说。
不要容忍破窗户
及时修复“破窗户”-低劣的设计、错误决策或是糟糕的代码。
记住大图景并做变化的催化剂
时时留心周围的变化,并在需要的时候先拿出“石头”(石头汤)来吸引更多的资源加入。
使质量成为需求问题
快速迭代,先交付“毛边”软件,让用户参与反馈,继而迭代更新。
注重实效的途径
DRY-不要重复你自己
同一个事物只出现在一处,而不是出现在多处从而难以修改。
让复用变的容易
正交性-消除无关事物之间的影响
正交性可以提高生产率(局部改动,提高复用性与自由组合)与降低风险(容易测试,错误只影响一小部分)。
用若干技术维持正交性:让你的代码保持解耦;避免使用全局数据;避免编写相似的代码。
可撤销性-不存在最终决策
设计灵活的架构,易于更改;
不要以某种假定编程,要做好接口,抽象。
曳光弹-用曳光弹找到目标
曳光弹代码是产品代码的一部分,先端到端完成基本功能,再慢慢进行功能扩充。
曳光弹方法优点:
1.用户能够及早看到能工作的东西;开发者构建了一个他们能在其中工作的结构;你有了一个集成平台,你将每天进行集成,而不是尝试大爆炸式的集成;你有了可用于演示的东西;你将更能感觉到工作进展。
原型-为了学习而制作原型
原型代码用户即弃,而曳光弹代码虽然简约,但却是完整的,并且构成了最终系统的骨架的一部分。
估算-通过代码对进度表进行迭代
估算能力可以练习。
靠近问题领域编程
实现小型语言
基本工具
我们要乐于超越IDE所施加的各种限制,而唯一的途径是保持基本工具集的“锋利”与就绪。
用纯本文保存知识
利用shell的力量(e.g.powershell)
用好一种编辑器(e.g.VScode)
总是使用源码控制
调试
修正问题,而不是发出责难;
不要恐慌;
对着小*鸭讲代码思路;
不要假定,要证明。
文本操纵-学习一种文本操作语言(e.g.python,powershell)
编写能编写代码的代码-主动代码生成器,被动代码生成器
注重实效的偏执
没有完美的软件。我们平时要进行防御性地编程。不仅要对别人的输入进行检查,也要对自己有怀疑精神。
通过合约进行设计-语义不变项
早崩溃
断言式编程-如果它不会发生,用断言确保它不会发生
异常不应包含正常处理程序
配平资源-资源申请、释放要匹配
弯曲,或折断
保持代码灵活。编写代码时要模块化,并降低模块间的耦合度。
元程序设计
将抽象放进代码,细节放进元数据
要配置,不要集成
分析工作流,以改善并发性
用服务进行设计
创建的不是组件,而不是服务-位于定义良好的、一致的接口之后的独立、并发的对象。
用黑板协调工作流
当你编码时
编码时要有批判精神,随时准备“重构”以及“测试”。
不要靠巧合编程
不做历史的奴隶-重构阻碍的代码-早重构,常重构
估算你的算法的阶测试你的估算
不要使用你不理解的向导代码
为测试而设计-测试你的软件,否则用户就得测试
在项目开始之前
如果你发现处理的问题很棘手,可能走错了路,不妨问以下几个问题:
有更容易的方法吗?
你是在设法解决真正的问题,还是被外围的技术问题转移了注意力?
这件事情为什么是一个问题?
是什么使它如此难以解决?
它真的必须完成吗?
它必须以这种方式完成吗?
与用户一起工作,以像用户一样思考
找出用户为何要做特定事情的原因、而不是他们目前做这件事的方式
抽象比细节活得更长久
好的需求文档会保持抽象。需求不是架构,不是设计,也不是用户界面。需求是需求。
使用项目词汇表
倾听反复出现的疑虑-等你准备好再开始
若分不清是良好的判断还是拖延,那从对觉得困难的地方构建原型开始。
昂贵的工具不一定能制作出更好的设计
不要做形式方法的奴隶对有些事情“做”胜于“描述”
最后,书中提到了管理程序员的知识资产与金融资产非常相似:
定期投资-定期为知识资产投资,作为习惯
多元化以及管理风险-掌握多门技术以及单门技术的各种特性
低买高卖-在新兴的技术流行之前学习它
应周期性地重新评估和平衡资产-技术更新
未煮熟的白菜