《代码大全》读书笔记-第5章软件构建的设计

我是菜鸟0713号

已于 2024-08-02 07:05:33 修改

阅读量292

点赞数 5

分类专栏：笔记文章标签：软件构建

于 2024-07-31 08:38:12 首次发布

本文链接：https://blog.csdn.net/weixin_43988887/article/details/140807452

版权

笔记专栏收录该内容

5 篇文章 0 订阅

订阅专栏

有人会说，设计不是真正的构建活动。但在小项目中，包括设计在内的许多活动都被认为是构建。有些设计更关注系统级问题，许多设计工作留给构建。有些大型项目设计非常详细，导致编码成为一项机械性劳动。小型项目的设计更多的是程序员坐在电脑前完成的，不管是小项目还是大项目都会在精心的设计中获益的。

1.设计的挑战

设计是一个棘手问题，定义为只有通过解决它或解决它的一部分才能明确定义的问题。这个悖论意味着，必须“解决”一次问题才能清晰地定义它，然后再解决一次才能创建有效的解决方案。塔科马海峡吊桥问题就是典型的棘手问题，这艘桥在设计时主要考虑的是有足够的强度来支持设计的负载，在建成使用时，因为大风产生的侧向谐波导致的大桥梁坍塌。
在这里插入图片描述
设计没有章法，设计之所以没有章法，是因为你会采取很多不恰当的步骤，走入死胡同，会犯很多错，越早意识到错误并且修正错误是很重要的；另外就是很难知道自己的设计是不是“足够好”，由于设计永无止境，最常见的衡量办法就是“当你时间不够的时候”。
设计关乎取舍，设计工作的关键是权衡相互竞争的设计特性，并从中取得平衡。什么样的目标决定什么样的设计。
设计是不确定的和启发式的，不同的人设计相同的程序，方案都是不同的。由于设计师不确定的，所以设计技术都是启发式的，需要用到“经验法则”或者“试行”的策略。
设计是水到渠成的，设计是一个自然浮现，需要通过设计评审、讨论、写代码和修改代码的过程中逐渐完善和改进的。

2.关键设计概念

2.1 管理复杂性

软件项目常见的失败原因是需求不到位、计划不周或管理不善。软件如此复杂，以至于没人知道它在做什么。一旦没人完全理解一个区域的代码变化对其它区域的影响，项目就无法进一步发展了。软件开发人员应该用一种安全的、一次只专注于其中一部分的方法来组织程序，目标是尽量减少需要考虑程序的数量。在架构方面，通过划分为子系统来降低复杂度，子系统越独立，就能使其安全地专注于解决一个复杂的点。

2.2 理想的设计特征：

最小化复杂性 要做简单的、易于理解的设计，不要做“聪明的”、难以理解的设计
易于维护 程序是写给人看的，而不是机器。写代码时不断想象别人使用软件时会提出什么样的问题，把系统设计得不言而喻。
松散耦合 松散耦合是指在设计师，将不同程序的关联控制在最小范围内。通过遵循良好的接口规则、信息分装来设计相互关联尽可能少的类。
可拓展性 在不破化底层的前提下对系统进行增强。进程间调用、rpc、消息队列等技术都很值得借鉴。
精简性 精简性意味着没有多余的设计，在软件中，只要写入了代码，就要花时间区阅读、理解、审查、编译、测试这些代码。这些都会对项目的质量造成影响，借助git等版本管理工具，可以安心地删除多于代码。
层次性 尽量保持分层地层次，一般在控制软件中，将软件分为通讯层、设备层、指令层，上层调用下层，可以使程序更容易理解。
标准技术 多借助标准技术，因为大家都很熟悉。