目录
关于架构部分
设计包括以下活动:
(1)定义满足需求的软件架构(architecture)；
（2)具体说明架构中的各个软件组件的算法。
架构包括:
软件中所有模块的定义，它们之间如何提供接口，它们之间如何组装，组件的拷贝如何实例化(即在内存中创建并执行的组件拷贝)和销毁。设计的最终产出是设计规格说明 ( Design Specification）
介绍一下实例化
实例化是面向对象编程中的一个概念，指的是创建一个类的具体实例。当你定义一个类时，实际上是定义了一个对象的模板，而实例化则是基于这个模板创建一个具体的对象。
在许多编程语言中，实例化一个类通常通过使用关键字"new"来完成。下面是一个简单的示例，展示如何实例化一个名为"Person"的类：
class Person:
def __init__(self, name, age):
self.name = name
self.age = age
person1 = Person("Alice", 25)
在这个示例中，我们定义了一个名为"Person"的类，它有两个属性：name（姓名）和age（年龄）。然后，通过将参数传递给类的构造函数__init__()，我们实例化了一个名为"person1"的对象，其姓名为"Alice"，年龄为25。
通过实例化，我们可以通过对象访问类中定义的属性和方法。例如，我们可以通过person1.name来访问对象的姓名属性，通过person1.age来访问对象的年龄属性。
实例化允许我们基于类创建多个对象，并且每个对象都可以具有自己独立的属性值。这样，我们可以有效地使用类的特性和行为来组织和处理数据。
需要注意的是，不同的编程语言可能会在实例化过程中有些差异，但基本概念是相通的。希望这个简单的解释对你有帮助。如果有任何进一步的问题，请随时提问。
真正的项目当中，我们一直在指定标准和做定义和统一，其实这个事情真的还是蛮难和繁琐的。
从需求到设计的转换并不容易
一些方法声称，将需求规格说明中的“架构”作为软件架构样转换就会很容易。
这个也是不现实的呀，因为说实在，都还是处在拍脑袋想的阶段
感觉我们国人的像是有一个特点，就是游记打多了，不知道怎么正规地弄。
将设计追溯至需求
软件架构，要求所有需求都能够被覆盖
软件部署时，检测到故障，快速分离出最有可能故障的组件
维护期间，当一个组件被修复，要想到哪些其他组件会受到影响
最好做一个大的二维吧表格来维护
评估备选方案
在需求达成一致后，你须充分考虑各种架构和算法。
在需求规格说明选择中，这种架构是为了优化系统外部行为的可理解性。
架构的选择通常是为了优化吞吐量、响应时间、可变更性可移植性、互操作性、安全性或者可用性，同时满足功能需求。
没有文档的设计不是设计
我经常听到软件工程师说，“我已经完成了设计，剩下的工作就是写文档了”。这种做法毫无道理。你能想象一个建筑设计师说，“我已经完成了你新家的设计，剩下的工作就是把它画出来”，或者一个小说家说，“我已经完成了这部小说，剩下的工作就是把它写下来”?设计，是在纸或其他媒介上，对恰当的体系结构和算法的选择、抽象和记录。
哈哈哈，头要笑掉了
封装
信息隐蔽
使软件更加容易测试和维护
有助于隔离错误，当其出错之后，只有隐藏该信息的软件需要被检查或是更改
封装通常指的是在每个对象中隐藏属性和方法。
不要重复造轮子
有的话，直接拿来用，不要干啥都是自己写，没有啥用和意义
保持简单
构建软件设计有两种方法，
一种方法是使它简单到没有明显的缺陷，
另一种为使它复杂到没有明显的缺陷。
但是核心都是，让用户看不出缺陷
避免大量的特殊案例
如果一个系统有太多特殊案例，那么就要重新思考设计新算法
缩小智力差距
现实问题和对此的计算机解决方案之间的距离，为智力距离
智力距离越小，维护软件越容易
但是实际上，不同人审视这个世界的时候，都是不一样的
将设计置于知识控制之下
保持概念一致
当设计完成后，设计应该看起来像是一个人做的，尽管其实它是很多参与者的产出。
概念一致比自我满足更重要
概念性错误比语法错误更严重
不管你多优秀，都会犯概念性错误
低耦合，高内聚
但是今天我们已经不太需要它了
因为我们的库中有大量完善的组件，它们都拥有这样的特点，我们不太需要考量了。
为变化而设计
为了适应变化，设计需要做到:
·模块化，即产品应该由独立的部分组成，每一部分可以很容易地被升级或替换，以对其他部分造成最小的影响(见原则65、70、73、80 。
·可移植性，即产品应该很容易修改以适应新的硬件和操作系统。
·可塑性，即产品可以灵活地适应预期外的新需求。
·保证最小智力距离( 见原则 69 )
·在知识可控范围内(见原则70)
·这样它就能表现出概念一致( 见原则 71
为维护而设计
从可维护性的影响来说，架构选择比算法或代码更加重要
为防止出现错误而设计
1.不引入错误。
2.引入的错误容易被检测。
3.部署后软件中遗留的错误要么是不危险的，要么在执行时有补偿措施，这样错误不会造成灾难。
在软件中植入通用性
一个软件组件的通用性体现在，它在不同的场景下不做任何修改就可以实现预期功能。
要尽可能植入通用性，以便日后扩展
在软件中植入灵活性
使用高效的算法
“算法分析”理论让我们知道，如何区分本来速度就慢的算法
模块规格说明只提供用户需要的所有信息
设计过程中的一个关键部分，是对系统中每个软件组件的精确定义
设计是多维的
一份完幕软件设计至少需要包括:
看上方
打包方案
依赖层次
调用关系
进程组织
优秀的设计出自优秀的设计师
优秀设计的特征是:简洁(Clean )简单(Simple )、优雅( Elegant ）、快速( Fast )、可维护( Maintainable )、易于实现(Easy to lmplement )。
对于最好的设计者要重点支持。他们才是未来。
（架构师还是大佬呀）
理解你的应用场景
无须太多投资，即可实现复用
你认为你干的事情跟其他人会有多大不同吗？其实并咩有。
“错进错出”是不正确的
提示为什么这样输入是错误的，给其返回一个错误码
这样更加容易定位
Windows就做了，我觉得还不错
软件可靠性可以通过冗余来实现
避免使用特殊技巧
Allen macro 指出他们“通常只是愚蠢地使用了高智商”
避免使用全局变量
如果大家都可以用，你还知道是谁犯的错吗？
编写可自上而下阅读的程序
避免副作用
这些操作对程序外部可见
很多细微错误的来源，潜伏最深，很难排查
你会drama的
为什么说权力和金钱，是高度的集聚效应？
权力和金钱都具有高度的集聚效应，这是因为它们都具有“强者更强”的特点。一方面，权力和金钱都能帮助个人获取更多的资源和机会，从而实现更大的成功和影响力，进而获取更多的权力和金钱；另一方面，成功和影响力也会让个人更容易获得更多的权力和金钱。这种集聚效应会逐渐形成一个“强者俱强，弱者俱弱”的局面。
在现代社会中，权力和金钱往往是相互关联的。权力能够带来更多的金钱，而金钱也能够带来更多的权力。在一些不公平的社会中，这种集聚效应会导致少数人拥有绝大部分的权力和金钱，而大多数人则处于弱势地位。这种现象也被称为“贫富分化”或“权力集中”。
LLVM是什么？
LLVM（Low Level Virtual Machine）是一个编译器基础设施项目，包括了一组 modulized 的编译器前端和后端，提供了以程序分析为基础的优化和代码生成等功能，同时具有很高的可扩展性、模块化和重用性。除了作为编译器基础设施，LLVM 也可以用于构建其他应用程序，如静态分析器、JIT 编译器、符号执行器等。LLVM 项目在开源社区拥有广泛的影响力，也被广泛应用于各种领域。
2572
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
