Closed cuixiaorui closed 4 years ago
本参考指南汇总了书中的提示与检查清单
受益一生的原则,需要定期的复习
如果你不在乎能否漂亮地开发出软件,你又为何要耗费生命去开发软件呢?
关掉自动驾驶仪,接管操作。不断地批评和评估你的工作
要提供各种选择,而不是找接口。不要说事情做不到:说明能够做什么
当你看到糟糕的设计、错误的决策和糟糕的代码时,修正它们。
你不能强迫人们改变。相反,要向他们展示未来可能会怎样,并帮助他们参与对未来的创造。
不要太过专注于细节,一致忘了查看你周围正在发生什么。
让你的用户参与确定项目真正的质量需求。
让学习成为习惯
不要被供应商、媒体操作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行分析。
如果你不能有效的向他人传达你的了不起的想法,这些想法就毫无用处。
系统中的每一项知识都必须具有单一、无歧义、权威的表示。
如果复用很容易,人们就回去复用。创造一个支持复用的环境。
设计自足、独立、并具有单一、良好定义的目的的组件
没有决策是浇筑在石头上的。相反,要把每项决策都视为是写在沙滩上的,并为变化做好计划。
曳光弹能通过试验各种事物并检查它们离目标有多远来让你追踪目标。
原型制作是一种学习经验。其价值并不在于所产生的代码,而在于所学到的经验教训。
用你的用户的语言进行设计和编码。
在着手之前先进行估算。你将提前发现潜在的问题。
用你在进行实现时获得的经验提炼项目的时间表度。
纯文本不会过时。它能够帮助你有效利用你的工作,并简化调试和测试。
当图形用户界面无能为力时使用shell。
编辑器应该是你的手的延伸;确保你的编辑器是可配置、可扩展和可编程的。
源码控制是你的工作的时间机器——你能够回到过去。
bug是你的过错还是别人的过错,并不是真的很有关系——它仍然是你的问题,它仍然需要解决。
做一次深呼吸,思考什么可能是bug 的原因
在OS或编译器、甚或是第三方产品或库中很少发现bug。bug很可能在应用中。
在实际环境中——使用真正的数据和边界条件——证明你的假定。
你用每天的很大一部分时间处理文本,为什么不让计算机替你完成部分工作呢?
代码生成器能提高你的生产率,并有助于避免重复。
软件不可能完美。保护你的代码和用户,使它们免于能够预见的错误。
通过合约建立文档,并检查代码所做的事情正好是它声明要做的。
死程序造成的危害通常比有问题的程序要小得多。
断言验证你的各种假定。在一个不确定的世界里,用断言保护你的代码。
异常可能会遭受经典的意大利面条式的代码的所有可读性和可维护性问题的折磨。将异常保留给异常的事物。
只要可能,分配某些资源的例程或对象也应该负责解除其分配。
通过编写“羞怯”代码并应用得墨忒耳法则来避免耦合。应该直接要求提供你所需要的东西,而不是自行“挖通”调用层次。
要将应用的各种技术选择实现为配置选项,而不是通过集成或工程方法实现。
为一般情况编程,将细节放在被编译的代码库之外。
利用你的用户的工作流中的并发性。
根据服务——独立的、在良好定义、一致的接口之后的并发对象——进行设计。
容许并发,你将会设计出更整洁、具有更少假定的接口。
要根据模型和视图设计你的应用,从而以低廉的代码获取灵活性。
用黑板协调完全不同的事实和因素,同时又使各参与方保持独立和隔离。
只依靠可靠的事物。注意偶尔的复杂性,不要把幸运的巧合与有目的的计划混为一谈。
在编写代码之前,先大致估算事情需要多长时间。
对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中测定它的速度。
就和你会在花园里除草、并重新布置一样,在需要时对代码进行重写、重做和重新架构。要铲除问题的根源。
在你还没有编写代码时就开始思考测试问题。
无情的测试。不要让你的用户为你查找bug。
向导可以生成大量代码。在你把它们合并进你的项目之前,确保你理解全部这些代码。
需求很少存在于表面上。他们深深地埋葬在层层假定、误解和政治手段的下面。
要了解系统实际上将如何被使用,这是最好的方法。
“投资”于抽象,而不是实现。抽象能在来自不同的实现和新技术的变化的“攻击”之下存活下去。
创建并维护项目中的使用的专用术语和词汇的单一信息。
在遇到不可能解决的问题时,要确定真正的约束。问问你自己:“它必须以这种方式完成吗?它真的必须完成吗?”
你的一生都在积累经验。不要忽视反复出现的疑虑。
不要掉进规范的螺旋——在某个时刻,你需要开始编码。
如果你没有把某项技术放进你的开发实践和能力的语境中,不要盲目的采用它。
小心供应商的炒作,行业教条,以及价格标签的诱惑。要根据工具的价值判断它们。
不要把设计师和编码分开,也不要把测试员与数据建模员分开。按照你构建代码的方式构建团队。
shell脚本或批文件会一次次地以同一顺序执行同样的指令
与呆在书架上的测试计划相比,每次构建时运行的测试要有效得多。
就是这样
在单独的软件副本上故意引入bug,以检验测试能够抓住它们。
确定并测试重要的程序状态。只是测试代码行是不够的。
一旦测试员找到一个bug,这应该是测试员最后一次找到它。此后自动测试应该对其进行检查。
像你编写代码一样编写文档:遵守DRY原则、使用元数据、MVC自动生成,等等。
与代码分离的文档不太可能被修正和更新。
要理解你的用户的期望,然后给他们的东西要多那么一点。
过去时代的手艺人为能在他们的作品上签名而自豪。你也应该如此。
厌倦了 C、C++ 和 JAVA?试试 CLOS、Dylan、Eiffel、Objective C、Prolog、Smalltalk 或 TOM。他们每一种都有不同的能力和不同的“风味”。用其中的一种或多种语言在家里开发一个小项目。
你想让他们学到什么? 他们对你讲的什么感兴趣? 他们有多富有经验? 他们想要多少细节? 你想要让谁拥有这些信息? 你如何促使他们听你说话?
设计独立、良好定义的组件。 使你的代码保持解耦。 避免使用全局数据。 重构相似的数据。
架构 已有系统中的新功能 外部数据的结构或内容 第三方工具或组件 性能问题 用户界面设计
责任是否得到了良好定义? 协作是否得到了良好定义? 耦合是否得以最小化? 你能否确定潜在的重复? 接口定义和各项约束是否可接受? 模块能否在需要时访问所需数据?
正在报告的问题是底层 BUG 的直接结果,还是只是症状? BUG 真的在编译器里?在 OS 里?或者是在你的代码里? 如果你向同事详细解释这个问题,你会说什么? 如果可疑代码通过了单元测试,测试是否足够完整?如果你用该数据运行单元测试,会发生什么? 造成这个 BUG 的条件是否存在于系统中的其他任何地方?
某个对象的方法应该只调用属于以下情形的方法: 他自身 传入的任何参数 他创建的对象 组件对象
总是意识到你在做什么。 不要盲目地编程。 按照计划行事。 依靠可靠的事物。 为你的假定建立文档。 不要只是测试你的代码,还要测试你的假定。 为你的工作划分优先级。 不要做历史的奴隶。
你发现了对 DRY 原则的违反。 你发现事物可以更为正交。 你的知识扩展了。 需求演变了。 你需要改善性能。
在解决不可能解决的问题时,问问你自己: 有更容易的方法么? 我是在解决正确的问题么? 这件事情为什么是一个问题? 是什么使它如此难以解决? 他必须以这种方式完成吗? 他真的必须完成吗?
单元测试 集成测试 验证和校验 资源耗尽、错误及恢复 性能测试 可用性测试 对测试自身进行测试
目录拆分