上一页 1 2 3 4 5 6 7 ··· 11 下一页
摘要: 任何你不知道的时候,要明确表示你不知道,同时要给出一个获取信息的计划,并设定反馈的最后期限。不管怎样,这是问问题的人真正想要的:你来提供答案。 阅读全文
posted @ 2020-01-09 15:38 peida 阅读(1342) 评论(0) 推荐(1) 编辑
摘要: 软件系统的设计和开发过程中,增加系统复杂性的12中危险信号。 阅读全文
posted @ 2020-01-04 10:08 peida 阅读(865) 评论(0) 推荐(0) 编辑
摘要: 良好的设计是软件工程的一个重要目标,这本书中的思想应该会使编程变得更加有趣。 阅读全文
posted @ 2020-01-02 09:41 peida 阅读(625) 评论(0) 推荐(0) 编辑
摘要: 大道至简:干净的设计和高性能是兼容的,复杂的代码往往很慢,因为它做的是无关的或冗余的工作。 阅读全文
posted @ 2019-12-31 14:40 peida 阅读(2132) 评论(1) 推荐(1) 编辑
摘要: 软件设计为易于阅读,而不是易于编写。设计和代码的可阅读性是好的设计和编码一个指标,面向阅读和维护编程。 阅读全文
posted @ 2019-12-30 11:47 peida 阅读(920) 评论(0) 推荐(3) 编辑
摘要: 确保一致性需要一些工作:决定约定的工作、创建自动检查器的工作、寻找类似的情况以在新代码中模拟的工作,以及在代码评审中培训团队的工作。 这种投资的回报是您的代码将更加明显。 阅读全文
posted @ 2019-12-28 07:17 peida 阅读(1257) 评论(0) 推荐(0) 编辑
摘要: 破窗效应:如果每次都增加一点复杂性,时间一长就会发现各种临时妥协的处理越来越多,直到系统不可维护为止。避免破窗效应出现,每个开发组织都应该计划将其全部工作的一小部分用于清理和重构,这项工作从长远来看是值得的。 阅读全文
posted @ 2019-12-27 13:40 peida 阅读(902) 评论(0) 推荐(1) 编辑
摘要: 编写注释的最佳时间是在过程的开始,即编写代码的时候。原因如下: 首先,编写注释使文档成为设计过程的一部分,其次,这不仅产生了更好的文档,而且还产生了更好的设计,第三,这会使的编写文档的过程更加愉快。 阅读全文
posted @ 2019-12-26 10:04 peida 阅读(876) 评论(1) 推荐(2) 编辑
摘要: 为变量、方法和其他实体选择名称是软件设计中最被低估的方面之一。好的名称是文档的一种形式:它们使代码更容易理解。它们减少了对其他文档的需要,并使错误检测变得更容易。相反,糟糕的名称选择会增加代码的复杂性,产生可能导致bug的歧义和误解。 阅读全文
posted @ 2019-12-25 10:01 peida 阅读(778) 评论(2) 推荐(4) 编辑
摘要: 注释的目标是确保系统的结构和行为对读者来说是显而易见的,这样他们就可以快速地找到他们需要的信息,并有信心地对系统进行修改。 ​ 有些信息可以在代码中以一种读者已经很容易理解的方式表示,但是有大量的信息不容易从代码中推断出来。 阅读全文
posted @ 2019-12-24 09:50 peida 阅读(1055) 评论(0) 推荐(1) 编辑
摘要: 好的注释可以使软件的整体质量有很大的不同;写出好的注释并不难;而且(这可能很难相信)写注释其实很有趣。 阅读全文
posted @ 2019-12-23 13:40 peida 阅读(1164) 评论(0) 推荐(1) 编辑
摘要: 两次设计的方法不仅提高了你的设计,也提高了你的设计能力。设计和比较多种方法的过程将教会您使设计更好或更差的因素。随着时间的推移,这将使你更容易排除糟糕的设计,并专注于真正伟大的设计。 阅读全文
posted @ 2019-12-22 07:25 peida 阅读(702) 评论(0) 推荐(2) 编辑
摘要: 异常处理是软件系统中最糟糕的复杂性来源之一。任何形式的特殊情况都会使代码更难理解,并增加bug的可能性。最好的方法是重新定义语义来消除错误条件。对于无法定义的异常,您应该寻找机会在较低的层次上屏蔽它们,这样它们的影响就有限了。 阅读全文
posted @ 2019-12-21 07:13 peida 阅读(1027) 评论(0) 推荐(1) 编辑
摘要: 拆分或联接模块的决策应该基于复杂性。选择能够隐藏最佳信息、最少依赖和最深接口的结构。 阅读全文
posted @ 2019-12-20 08:00 peida 阅读(1503) 评论(1) 推荐(1) 编辑
摘要: 在开发模块时,寻找机会让自己承担一些额外的痛苦,以减少用户的痛苦。把复杂留给自己,简单留给用户。 阅读全文
posted @ 2019-12-19 07:51 peida 阅读(1181) 评论(0) 推荐(2) 编辑
摘要: 软件设计的哲学,解决软件复杂性的原则,中文翻译抢先体验版,持续更新中。 阅读全文
posted @ 2019-12-18 18:47 peida 阅读(3426) 评论(0) 推荐(1) 编辑
摘要: 软件系统是分层组成的,其中较高层使用较低层提供的功能。在一个设计良好的系统中,每一层都提供了不同于其上下层的抽象;如果您通过调用方法跟随单个操作在层中上下移动,那么抽象会随着每个方法调用而变化。 阅读全文
posted @ 2019-12-18 15:48 peida 阅读(908) 评论(0) 推荐(1) 编辑
摘要: 与专用接口相比,通用接口有许多优点。它们往往更简单,包含更少的方法。它们还提供了类之间更清晰的分离,而特殊用途的接口往往会泄漏类之间的信息。使您的模块具有一定的通用功能是降低整个系统复杂性的最佳方法之一。 阅读全文
posted @ 2019-12-18 15:42 peida 阅读(1309) 评论(2) 推荐(2) 编辑
摘要: 信息隐藏与深度模块密切相关。如果一个模块隐藏了很多信息,就会增加模块提供的功能,同时也减少了它的接口。这使得模块更深入。相反,如果一个模块没有隐藏很多信息,那么要么它没有太多的功能,要么它有一个复杂的接口;不管怎样,这个模块都是浅层的。 阅读全文
posted @ 2019-12-17 19:39 peida 阅读(1230) 评论(0) 推荐(0) 编辑
摘要: 通过将模块的接口与其实现分离,我们可以向系统的其他部分隐藏实现的复杂性。模块的用户只需要理解其接口提供的抽象。在设计类和其他模块时,最重要的问题是使它们更深入,这样它们就有了公共用例的简单接口,同时还提供了重要的功能。这最大化了隐藏的复杂性。 阅读全文
posted @ 2019-12-17 19:36 peida 阅读(1519) 评论(0) 推荐(0) 编辑
摘要: 好的设计不是免费的。它必须是你不断投资的东西,这样小问题就不会积累成大问题。 幸运的是,好的设计最终会收回成本,而且比你想象的要快。 阅读全文
posted @ 2019-12-16 15:09 peida 阅读(1553) 评论(0) 推荐(1) 编辑
摘要: 如果一个软件系统难以理解和修改,那么它就是复杂的;如果它容易理解和修改,那么它就是简单的。复杂性来自于依赖和模糊的积累。随着复杂性的增加,它会导致变化的扩大、高的认知负荷和未知的未知。 阅读全文
posted @ 2019-12-16 15:05 peida 阅读(1989) 评论(0) 推荐(0) 编辑
摘要: 更简单的设计允许我们在复杂性变得不可抗拒之前构建更大、更强大的系统。有两种对付复杂性的一般方法:第一种方法是通过使代码更简单、更明显来消除复杂性。处理复杂性的第二种方法是封装它,这样程序员就可以在一个系统上工作,而不必一次暴露系统的所有复杂性。这种方法称为模块化设计。 阅读全文
posted @ 2019-12-16 14:47 peida 阅读(1778) 评论(0) 推荐(0) 编辑
摘要: 计算机科学中最基本的问题是问题分解:如何把一个复杂的问题分解成可以独立解决的几个部分。问题分解是程序员每天都要面对的核心设计任务。 阅读全文
posted @ 2019-12-16 14:37 peida 阅读(1838) 评论(1) 推荐(1) 编辑
摘要: 2020年必读书籍推荐:软件设计的哲学(A Philosophy of Software Design),本书190多页,豆瓣的点评分在9分以上,目前只有英文版本,中文版还未上市,英文好的同学建议去直接阅读原版。 阅读全文
posted @ 2019-12-16 14:35 peida 阅读(3231) 评论(0) 推荐(2) 编辑
上一页 1 2 3 4 5 6 7 ··· 11 下一页