第1页 全书
- 章节名:全书
- 页码:第1页
关心你的技艺 思考你的工作 不要依靠自动驾驶仪,不间断的思考,实时地批判你的工作。 在一个项目的总体结构中,总有个性和技艺的位置。一百年之后,我们的工程看起来或许已很古老,就像是中世纪的大教堂建造者所使用的技术在今天的土木工程师看来很古老一样,但我们的技艺却仍将受到尊重。 在所有的弱点中,最大的弱点就是害怕暴露弱点。 提供各种选择,不要找蹩脚的借口。不要说事情做不到,要说明能够做什么来挽回局面。 不要害怕提出要求,也不要害怕承认你需要帮助 一扇破窗户,只要有那么一段时间不修理,就会渐渐给建筑的居民带来一种废弃感。于是又一扇窗户破了,人们开始乱扔垃圾。出现了乱涂乱画。严重的结构损坏开始了。 不要容忍破窗户 但更重要的是,士兵充当催化剂,把村民团结起来,和他们一起做到了他们自己本来做不到的事情——项目协作的成果。每个人最后都是赢家。 做变化的催化剂。 知识上的投资,总能得到最好的回报。 1. 严肃的投资者定期投资——作为习惯。 2. 多元化是长期成功的关键——你知道的不同的事情越多,你就越有价值。 3. 管理风险 4. 低买高卖。在新兴的技术流行之前学习它可能和找到被低估的股票一样困难,但所得到的就和那样的股票带来的收益一样。 5.重新评估和平衡 最重要的是定期为你的知识资产投资。 你说什么和你怎么说同样重要。 第二章 注重实效的途径 不要重复你自己(DRY) 系统中的每一项知识都必须具有单一、无歧义、权威的表示。 代码中的文档:把注释保留给其他的高级说明,否则,我们就是在重复知识。用头文件记载接口问题,用实现文件记载代码的使用者无需了解的实际细节。 无耐性的重复:如果你觉得受到诱惑,想一想古老的格言:”欲速则不达“ 正交性:不相依赖性或者是解耦性 消除无关事物之间的影响 可撤销性 没有什么永远不变——而如果你严重依赖某一事实,你几乎可以确定它将会发生变化。 通过DRY原则、解耦以及元数据的使用 在黑暗中发光的代码——快速清晰的获取用户需求。 在背要求进行估算时说什么——”我等会告诉你“。 第三章 基本工具 * 用纯文本保存知识 * 利用shell 的力量 find . -name '*.c' -newer Makefile -print find . -name '*.jave' -mtime +7 -print * 使用单一的编辑器 选一种强大的编辑器,然后学好他 调试心理学 要修正问题,而不是发出指责 不要恐慌 代码生成器 编写能够编写代码的代码 第四章 注重实效的偏执 你不可能写出完美的软件 俺合约进行设计——用文档记载并约定软件模块的权利与责任,以确保程序的正确性。 早崩溃,要崩溃,不要破坏 断言式编程:如果它不可能发生,用断言确保它不会发生 异常留给意外事件,“如果我移走所有的异常处理,这些代码是否仍能正常运行?” 如果答案是否,那么异常也许就用到了非异常的情形中。 错误处理器是另外一种选择 怎样配平资源:分配某项资源的例程或对象应该负责解除该资源的分配。 以与资源分配次序相反的次序解除资源的分配 在不同的地方分配同一套资源时总是使用相同的顺序分配他们,以减少死锁的可能性。 第五章 弯曲,或折断 解耦与得墨忒耳法则 编写遵守得墨忒耳法则的“羞怯”的代码 函数的得墨忒耳法则: 某个对象的任何方法都应该只调用属于以下情形的方法: 1. 他自身的方法 2. 传入该方法的任何参数; 3. 它创建的任何对象; 4. 任何直接持有的组件对象 缩小调用类中的响应集的规模 元程序设计 要配置,不要集成 元数据:关于数据的数据,如调谐参数,用户偏好,安装目录等。元数据在运行时而不是编译时被访问和使用 将抽象放进代码,将细节放进元数据。 以声明的方式思考(规定要做什么,而不是怎么做):为一般情况编写程序,把具体情况放在别处——在编译的代码库之外。 时间耦合:分析工作流,以改善并发性 为并发进行设计 用黑板协调工作流 第六章 当你编码时 靠巧合编程: 1. 实现的偶然; 2. 语境的偶然;——你的模块必须依赖GUI?是否依靠说英语的用户?你还依靠别的什么没保证的东西? 3. 隐含的假定; 怎样深思熟虑的编程: 1. 总是意识到你在做什么 2. 不要盲目的编程; 3. 按照计划行事; 4. 依靠可靠的事物; 5. 为你的假定建立文档; 6. 不要只是测试你的代码,还要测试你的假定; 7. 为你的工作划分优先级 8. 不要做历史的奴隶 最好的算法并非总是最好的 重构: 1. 重复 2. 非正交的设计; 3. 过时的知识; 4. 性能 早重构,常重构 1. 不要在重构的时候加入新的功能; 2. 在开始重构之前,确保你拥有良好的测试。 3. 采取短小、深思熟虑的步骤:如果使你的步骤保持短小,并在每个步骤之后进行测试,你将能够避免长时间的调试。 确保对模块做出的剧烈改动,会破坏构建。 易于测试的代码:为测试而设计。 第七章 在项目开始之前 你是否曾经有过你的项目注定要失败的感觉,甚至是在项目开始之前?有时它也许会这样,除非你先建立某些基本准则。 不要搜集需求——挖掘他们 找出用户维护要做特定事情的原因,而不是他们目前做这件事情的方式。 用文档记载需求背后的原因将在每天进行实现决策时给你的团队带来无价的信息。 与用户一同工作,以像用户一样思考。 倾听反复出现的疑虑,等你准备好再开始。你可能无法准确地指出问题所在,但给它时间,你的疑虑很可能就会结晶成某种更坚实的东西,某种你可以处理的东西。 对于某些事情,“做”胜于“描述“ 注重实效的程序员批评的看待科学方法,并从各种方法学中提取精华,融合成每个月都在变得更好的一套工作习惯。这至关重要。你应该不断努力提炼和改善你的开发过程。绝不要把方法学的呆板限制当作你的世界的边界。 第八章 注重实效的项目 不要留破窗户 煮青蛙 交流 不要重复你自己 正交性 无处不在的自动化 文明通过增加我们不加思索就能完成的重要的操作的数目而取得进步。 一切都要自动化。 在现实中,项目的成功是由它在多大程度上满足了用户的期望来衡量的。 温和的超出用户的期望。 交流期望 额外的一公里。 注重实效的程序员不会逃避责任。相反,我们乐于接受挑战,乐于使我们的专业知识广为人知。如果我们在负责一项设计,或是一段代码,我们是在做可以引以为豪的工作。 Sign Your Work 在你的作品上签名。 过去时代的手艺人为能在他们的作品上签名而自豪,你也应该如此。
说明 · · · · · ·
表示其中内容是对原文的摘抄