奇迹之流WonderfloW

Nothing Replaces Hard Work!

《程序员修炼之道》的笔记

| Comments

老样子:印象笔记链接

责任:Provide Options, Don’t Make Lame Excuses.

什么是负责?就是在出了问题时,要提供各种选择,而不是找借口。不要说事情做不到;要说明能够做什么来挽回局面。

软件的熵:Don’t Live with Broken Windows. 不要留着“破窗户”(低劣的设计、错误的决策、糟糕的代码)不修。发现一个修一个,如果没有时间整理,就把出问题的代码放在注释里或者显示未实现。

足够好的软件:Make Quality a Requirements Issue 让用户参与权衡质量的需求

知识资产:Invest Regularly in Your Knowledge Portfolio 1. 经营你的知识资产: * 定期投资:尽管每次投资量小,但是要保持习惯 * 多元化:你知道的不同的事情越多,你就越有价值。你掌握的技术越多,你就越能更好地进行调整,赶上变化。 * 管理风险:不要把所有的技术鸡蛋放在一个篮子里 * 低买高卖:在新兴技术流行之前学习它,尽管很困难,但是收益巨大。 * 重新评估和平衡:这是一个非常动荡的行业,也许上个月才开始研究的热门技术现在已经像石头一样冰冷。 2. 目标: * 每年至少学习一种新语言 * 每季度阅读一本技术书籍 * 也要阅读非技术书籍 * 上课、参加本地用户组织:meetup * 试验不同的环境:windows、linux * 跟上潮流:订阅期刊杂志 * 上网:博客、新闻订阅等等 3. 批判的思考

交流

> > 我相信,被打量比被忽略要好。 ——Made West,Belle of the Nineties,1934 > >

知道你想要说什么;了解你的听众;选择时机;选择风格让其适应听众;让文档美观;让听众参与;做倾听者;回复别人,注重邮件礼仪。

重复的危害:DRY - Don’t Repeat Yourself

糟糕的代码才需要注释,注释也是一种重复

正交系统:又叫模块化、基于组件、分层、松耦合。 对于正交设计,有一种简单的测试方法。一旦设计好组件,问问自己:如果我显著地改变某个特定功能背后的需求,有多少模块会受影响?在正交系统中,答案应该是“一个”。 1. 让你的代码保持解耦。 2. 避免使用全局数据 3. 避免编写相似的函数

可撤销性:There Are No Final Decisions. 需求是随时会变的,保持代码的灵活性,还需要维持架构、部署及供应商集成等领域的灵活性。

曳光弹:Use Tracer Bullets to Find the Target 在黑暗中用枪射击时,曳光弹与常规弹药交错着装在弹药带上。发射时,曳光弹会留下一条烟火般的踪迹。如果曳光弹击中目标,那么常规子弹也会击中目标。 曳光代码类似一个简单的原型,其好处是: 1. 用户能够及早看到能工作的东西 2. 开发者构建了一个他们能在其中工作的结构 3. 你有了一个集成平台 4. 你有了可用于演示的东西 5. 你将能够感觉到工作进展

估算 1. 理解提问内容 2. 建立系统模型 3. 把模型分解为组件 4. 给每个参数指定值 5. 计算答案 6. 追踪你的估算能力 7. 估算项目进度

调试:Fix the Problem,Not the Blame bug是你的过错还是别人的过错,并不是真的很有关系,它仍然是你的问题。

配平资源:Finish What You Start 配平资源的意思就是当你分配一个资源,用完后,要记得解除。

动态配置:Configure,Don’t Integrate 把抽象编写到程序,把细节放到元数据中,让元数据变得可配置。什么是元数据?即关于数据的数据,如数据库建表语句。 时间耦合:Always Design for Concurrency 平时我们很容易忽视软件架构中的时间。减少时间耦合,即增加并发。 1. Analyze Workflow to Improve Concurrency.分析用户的工作流,把可以并发的内容并发处理。 2. 使用饥饿消费者模型的架构。用一些独立的消费者任务和一个集中式工作队列取代中央调度器。各个消费者任务从工作队列中抓取一项分别处理。完成后接着按自己的步伐前进。每个组件都在时间上解除了与其他组件的耦合。 3. 为并发进行设计,时刻考虑到别的进程也会调用你的内容。必须对任何全局变量或静态变量加以保护。在调用时,测试调用对象的有效性等等。 4. 对并发和时序依赖进行思考还能够引导你设计更整洁的接口。

Model-View-Controller 基于消息订阅/发布的架构模式: sub/pub 从发布和订阅这种架构我们可以得到很多启示,比如MVC架构,视图与控制的分离。

怎样深思熟虑地编程: Don’t Program by Coincidence * 总是意识到你在做什么 * 不要盲目的编程 * 按照计划形式,不管计划是在你脑海中还是写下来。 * 依靠可靠的事物 * 为你的假定建立文档 * 不仅要测试你的代码,还要测试你的假定 * 为你的工作划分优先级 * 不要做历史的奴隶。不要让已有的代码支配将来的代码。

估算你的算法效率 注重算法效率有助于避免盲目编程,但是考虑效率也不要忘了注重实效,最快的算法对你的工作并非总是最好的。小数据的插入排序,其编码和调试时间明显优于快速排序,但效率是一样的。

重构 你应该在何时重构? 1. 重复的代码 2. 非正交的设计 3. 过时的知识/需求 4. 需要改善性能

怎样进行重构? 1. 不要试图在重构时增加新的功能 2. 在开始重构前确保有足够的测试 3. 采取短小、深思熟虑的步骤:把某个字段从一个类移到另一个,把两个类似的方法融合进超类中。