游戏设计模式阅读笔记0——序

中文版链接：致谢 · 游戏设计模式

目录

一、序——笔记反思

二、架构，性能和反思

1.什么是好的软件架构/p>

2.如何处理改动/p>

3.解耦帮了什么忙/p>

4.性能和速度

5.保持平衡

6.简单

 7.就快完了

一、序——笔记反思

1.

反思：在是实习生的时候，就明显感觉到了主程在编码能力上对我的压制力。具体体现在，同样的功能，他的思路更清晰，实现明显更优美，模块更分明，但当时的我只能尽量依葫芦画瓢，也不明白这是哪方面的知识的缺失，只能全归在经验缺失上。在正式工作后，感觉到自己的代码复用性很低，平时写代码很没有规范，对接口设计意识薄弱，维护困难。对性能也一知半解。

2.

 3.

二、架构，性能和反思

1.什么是好的软件架构/h3>

第一个关键点是架构是关于改动的。评价架构设计的好坏就是评价它应对改动有多么轻松。 

2.如何处理改动/h3>

反思：在实际工作中，经常拿起功能就开始做。是觉得任务多，时间赶，先实现了再说。现在要摒弃这个坏习惯。注重细节！

3.解耦帮了什么忙/h3>

  将代码载入到神经元太过缓慢，找些策略减少载入的总量是件很值得做的事。

 反思：解耦会给后期维护的带来便利，解决我当下的一部分问题。最小化在编写代码前需要了解的信息。

需要注意：

反思：不执着于扩展和抽象。在项目中，做适合项目的事。

4.性能和速度

1.

反思：这个问题在实习的时候困扰我很久，因为之前有打ACM，所以对算法性能有一定的洁癖。但是工作后，发现事情变得很复杂。我面对的是一个对编程可能都不了解的人，在实现功能。他充满了不确定性，以及我的经验缺失，导致我很纠结。我常常因为之前的代码不适用于后来的改变（修改起来很多，后期使用麻烦），而去改掉之前的逻辑。工作后，没时间想那么多，也有了一些经验，改掉了一些“锱铢必较”的小毛病后，编码也变得简单起来，也更随意了。害。

2.

 3.

        严格要求自己的代码！如果它并不好就不要爱它！

（hhh好狠）

5.保持平衡

 没有正确的答案，只有不同的错误。hhh

6.简单

1.

反思：之前在这里有些困惑，和主程聊了聊，他给我看了些实例。茅塞顿开。异而同，提炼不同的数据，不同的处理，最后再汇聚到一个相同的处理中。大受裨益。

 7.就快完了