tokyo对《程序员修炼之道》的笔记(9)

程序员修炼之道
  • 书名: 程序员修炼之道
  • 作者: Andrew Hunt/David Thomas
  • 副标题: 从小工到专家
  • 页数: 333
  • 出版社: 电子工业出版社
  • 出版年: 2005-1
  • 序言

    注重实效的程序员: 1. 早起的采纳者/快速的改编者 2. 好奇 3. 批判的思考者 4. 有现实感 5. 多才多艺 提示: Care About Your Craft. Think! About Your Work. 团体:我们,采集的是石头,却必须时刻展望未来的大教堂。 持续的过程:kaizen

    2011-07-11 22:05:10 回应
  • 第一章 注重实效的哲学

    在所有的弱点中,最大的就是害怕暴露弱点。 Provide options,don't make lame excuses. 破窗理论,防微杜渐。 don't live with broken windows. 抛砖引玉 Be a catalyst for change. 全局为重 Remember the big picture. Make quality a requirement issue. 知识上的投资总能得到最好的回报。 但知识是有时限的资产。 管理自己的资产: 1、定期投资。 2、多元化。 3、管理风险。 4、低买高卖。 5、重新评估和平衡。 Invest regularly in your knowledge Portfolio. 目标: 每年至少学习一门新语言。 每季度至少阅读一本专业技术书籍。 也要阅读非技术书籍。 上课 参加本地用户组织。 试验不同环境。 跟上潮流(订阅杂志) 上网。 Critically analyze what you read and hear 提问: 1、确切知道想问什么。 2、小心组织问题。 3、谦虚,求教。 被打量总比被忽略要好。 交流:内容,对象,时机,风格, it's both what you say and the way you say.

    2011-07-11 22:07:13 回应
  • 第二章 注重实效的途径

    系统中的每一项知识都具有单一、无歧义、权威的表示。 DRY don't repeat yourself 重复:强加,无意,无奈,开发者之间 Make it easy to reuse. Eliminate effects between unrelated things. Use tracer bullets to find the target. 曳光弹的优点: 用户能及早看到能工作的东西。 开发者构建了一个他们能在其中工作的结构。 有了集成平台。 有了用于演示的东西。 更能感觉到工作的进展。 如果你发现自己处在不能放弃细节的情况下,那么你要问自己,是真的在构建原型,或许曳光弹开发更适合这种情况。 制作原型的对象: 架构 已有系统中的新功能 外部数据结构或功能 第三方工具插件 性能问题 用户界面设计 原型的价值在于学到的经验教训。 Prototype to learn. 原型可以忽略“争取性”、“完整性”、“健壮性”、“风格”。 使用高级的语言构建原型,因为可以推迟实现细节。 架构原型可以解决的问题:组件责任、组件协作、耦合最小、数据、约束。 语言的界限就是一个人世界的界限---维特根斯坦 Program close to the problem domain. 估算 Estimate to avoid surprise. 根据场景选择精度(用不同的单位和数字表示不同的精度) 理解提问内容,开始前思考问题范围。 建立模型:分解组件,给参数赋值,计算。追踪估算能力, Iterate the schedule with the code. 在被要求进行估算的时候要说,“我等会儿回答你”,求精度,求更好的结果。

    2011-07-11 22:20:38 回应
  • 第三章 基本工具

    纯文本:永不过时,杠杆作用,更易于测试。 Use the power of command shells. 坚持使用一种编辑器。 Use a single editor well. 编辑器选择:可配置、可扩展,可编程。 进步远非由变化组成,而是取决于好记性。不能记住过去的人,被判重复过去。---george santayana Always use source code control. 调试就是解决问题,要借此发起进攻。 Fix the problem, not the blame. 最容易欺骗的人是自己。 调试的第一准则:don't panic. 与用户交流; 人工合成测试还不够,必须既测试边界条件,又测试现实中最终用户的使用模式。 一图胜千言,使你的数据可视化 碰到坏变量,查看周围的内存。 "Select" isn't broken.提醒自己更多的bug来自于自己的应用程序代码。 如果看到马蹄印,要想到马,而不是斑马。 Don't assume it, prove it. Learn a text manipulation language. Write code that writes code. 被动、主动代码生成器。

    2011-07-11 22:22:39 回应
  • 第四章 注重实效的偏执

    You can't write perfect software. 当每个人对你不利的时候,偏执就是一个好主意. 期望和陈述:前条件,后条件,类不变项。 如果调用者满足了例程的所有前条件,例程应该在其完成之时,所有的后条件和不变项为真。 Design with contracts. 子类必须要通过基类的借口使用,而使用者无序知道其区别。 Crash early. 死程序不说谎; 注重实效的程序员,如果有一个错误,那么非常糟糕的事情已经发生了。 尽早检测问题之一,让程序尽早崩溃。 死程序带来的危害要比有疾患的程序小得多。 断言; 在自责中有一种满足感,当我们责备自己时,会感觉没有别人有权责备我们。 If it can't happen, use assertions to ensure that it won't. 对自己认为当然不可能发生的事情,加入断言来检查。断言检查的是决不应该发生的事情。 断言可能在编译时被关闭,绝对不要把必须执行的代码放在assert中。 何时使用异常:如果移走异常还能正确运行,那么不需要异常。 Use exceptions for exceptional problems. 资源分配; Finish what you start. 嵌套分配: 以与资源分配次数相反的次序解除资源。 在代码不同地方分配同一组资源,要以同样的顺序,防止死锁。 三个选择: 顶层负责释放包含的结构 解除顶层结构的分配,其他遗弃 顶层有子结构,拒绝解除

    2011-07-11 22:27:33 回应
  • 第五章 弯曲,或折断

    编写宽松-灵活的代码。 好篱笆促成好邻居。 低耦合,降低其他地方修改代码引起本初代码的风险。 得墨忒耳法则: Minimize coupling between modules. 适应性更好,更健壮 空间、运行时代价 函数的某个方法只能调用以下方法: 自身 传入该方法的参数 他创建的对象 直接持有的组件对象 再多的天才也无法胜过对细节的关注。 把细节赶出去---让代码动态配置。 Configure, don't integrate. 用元数据描述应用的配置选项。元数据:数据的数据。 Put abstractions in code, details in metadata. 为一般情况编写程序,把具体情况放在别处。 好处: 解耦 推迟细节实现,抽象程度高 无需重新编译就可以定制 EJB:可配置,动态系统。 时间:并发,次序 Analyze workflow to improve concurrency. Design using service Always design for concurrency. Separate views from models. 黑板:无需互相知道,有共同目标。 Use blackboards to coordinate workflow.

    2011-07-11 22:30:17 回应
  • 第六章 当你编码时

    编码不是机械工作。每一分钟都要做出决策。也许很大程度上只是例行公事,但保持警觉能够很好防止灾难发生。 确保你的工作不是巧合,记录在文档中,去除多余的调用。 Don't Program by coincidence. 如何做: 总是意识到你在做什么 不要盲目编程,不要使用不熟悉或不理解的应用 按计划行事 按合约编程(建立文档) 依靠可靠的技术 测试代码,测试假定 为工作划分优先级 不要做历史的奴隶(现在的代码不要影响到未来的代码) 估算算法使用的资源:内存 CPU 时间 等。 大多数算法是亚线性,但有一些比线性要糟糕很多。 O() 上界。 简单循环:O(1) 嵌套循环:O(n²) 二分:O(ln(n)) 分而治之:O(n ln(n)) 组合:O(C) Estimate the order of your algorithm. Test your estimates. 理论结合实践。 重构:重写,重做,重新架构。 方面:重复,非正交,过时的知识,性能。 Refactor early, refactor often. 重构注意:1. 不要试图重构时增加功能。 2. 经常测试,检测重构。 3.保持短小的改变。 单元测试: 先测试子模块,再测试高层次模块。 Design to test. 测试是技术,更是文化。 Test your software, or your users will. Don't use wizard code you don't understand.

    2011-07-11 22:33:53 回应
  • 第七章 项目开始之前

    需求之坑 解开不可能解开的谜题 等你准备好 规范陷阱 圆圈与箭头

    2011-07-11 22:37:04 回应
  • 第八章 注重实效的项目

    不要留破窗户。 简单的营销:创立品牌。 Organize around functionality, not job function. 团队是由个体组成的,让每个成员都以他们自己的方式闪亮,给他们足够的空间和支持,并确保最后的交付能够符合要求,然后,像“足够好的软件”中的画家一样,抵抗不断画下去的诱惑。 don't use manual procedure. Test early, test often, test automatically. Coding aren't done, till all the test run. 单元测试 集成测试 验证和校验 资源耗尽,系统恢复。 性能测试 可用性测试 Use saboteurs to test your testing. Test state coverage, not code coverage. Find bug once. Treat English as just another language. 写文档 Build document in, don't bolt it out. Gently exceed your users' expectation. Sign your work.

    2011-07-11 22:39:21 回应