正如书中所说,许多人都会跳过第一章的内容,但是我还是读了下来,并在读完后决定写一个关于这本书的章节总结,以此来巩固我对这本书的学习,当然如果当你不经意间看到这东西并且对你有帮助的话,对于我来说是最大的开心。
1.1什么是软件架构
1. 软件架构描述的是关于软件的组织性。
2. 而软件架构是有好与坏的,糟糕的软件架构会让我们剔除它以结束自己的痛苦,而好的软件架构则是意味着我们总能进行很少的调用就可以完成我们自己的需求,同时也不需要担心有副作用。
3. 我们总会去修改代码,但是在修改之前,我们需要先花上很大一部分的时间去学习现有的代码与组织,随后便可轻松的完成编码。
4. 整个修改过程便是:遇到问题->学习代码->解决方案->解决问题,如此循环。
5. 当然,在解决了问题后,我们仍需要对我们写的代码进行清理,让他更好的融入组织中,以便于方便后面的人去理解或修改你的代码。
6. 解耦的好处便是让你在改变一块代码时,只需要学习少量的代码便可以进行更改。同时也可以认为在改变一块代码时,不必更改另外一块代码。
7. 耦合越低,更改所波及的范围就会越小。
1.2有什么代价
1. 良好的架构需要很大的努力及一些列准则。每当你做出一个改变或者实现一个功能时,你必须很优雅地将它们融入到程序的其余部分。你必须非常谨慎地组织代码并保证其在开发周期中经过数以千计的小变化之后仍然具有良好的组织性。
2. 不要轻易的添加一个抽象层或者支持可扩展的地方,因为这需要花费你的时间去开发、调试与维护。但是这个扩展可能并不会出现。
3. 解耦意味着在你进行扩展时仅需理解少量代码,然而抽象却增加了理解代码的难度。
4. 不要一味的追求可扩展性,时刻意识到引擎是用来做游戏的。
1.3性能和速度
1. 软件架构使你的程序变得更加灵活,同时也会因此导致性能的降低。
2. 性能优化总是在某些假设下进行的。优化的方法在特定的条件下进行更好。
3. 将你的程序做得更具有灵活性,以便能够更快速的进行原型编写,但这会带来一些性能损失。同样地,对你的代码进行优化会降低它的灵活性。
4. 保持代码的灵活性,直到设计稳定下来,然后去除一些抽象,以提高游戏的性能。
1.4坏代码中的好代码
1. 编写架构良好的代码需要仔细的思考,这是需要时间的。所以如果是一些一次性的代码,则不需要过多的考虑,只需要去尽快实现功能就行。当你要长期与这份代码打交道时,是需要进行良好的架构的。
2. 原型是一个完全正确的编程实践,但是一定要确保它是一次性,用后一定要扔掉,否则你将会看到一团糟的代码组织。
1.5寻求平衡
在开发中我们总是会去考虑
1. 获得一个良好的架构以便于更好的理解代码。
2. 获得快速的运行时的性能。
3. 快速完成今天的功能。
但是它们是相互矛盾的,良好的架构需要花费更多的时间去完成今天的功能,而更好的性能则会使程序僵化失去灵活性,快速完成今天的功能总是伴随这糟糕的组织与一堆Bug,所以这需要我们自己去寻找其中的平衡点。
1.6简单性
简单性即为在保持数据结构与算法的正确性,努力尝试着编写最干净最直接的函数来解决问题。
1.7作者的建议