2012年的经验总结

最近工作非常忙，忙到一直把这件事搁置脑后，先占座 ==================分割线====================== 这一年经历没有太多，感触不少。项目一直大修大改，需求变更比翻脸快，也让我学到不少东西。 一、要写出无bug的程序 程序无bug？也许很多人觉得是在开玩笑，或者吹牛B。如飞舟所说，如果首先你就坚信程序是一定会有bug的，那么你写出来的程序一定有bug。那么我们应该相信程序是可以写出无bug的，而我们要做的就是不断向这一目标靠近，最终接近零bug。 “为什么要这么做？我写出的程序跑的也很稳定嘛～～有bug马上改掉就好了嘛。”我以前就是这么样一个观点。但你这么做的后果是，你的程序永远得不到别人的信任，你也无法得到别人的信任。就如我曾经跟一个同事交流时说，如果两个操作系统（特意选了这种很重要的软件）摆在你面前，一个功能很强大，但是时不时就来个bug崩溃。另一个功能相对简单，但是运行很稳定，你会选择用哪个？再换到人，2个人，一个人写代码可能很快，但他的程序总是时不时就出个bug。另一个可能写代码比较慢，可能效率也不高，但是他写出的代码几乎很少出bug。问：如果你现在需要开发一个很重要的软件，你会选择谁？对现在的我来说，我都会毫不犹豫的选择后者，借用一句话说，稳定压倒一切。 如何做到程序无bug？遵循一些最基本的原则即可做到很好。

1 每个函数都拥有返回值，所有调用该函数的地方均对返回值进行检查。 2 多用断言，对自己的程序苛刻一点。 3 函数尽可能短小，保证一件函数只做一件事，做到单输入单输出，可进行单元测试。 4 尽量避免深层次的if嵌套，尽量避免else的出现。 5 对于复杂的逻辑，要分析清楚，找出最小操作集，用正交组合的方式去实现复杂的逻辑事务。 6 每一行代码在写完之后都要用单步调试走一遍（主要针对一些平时跑不到的条件分支） 以上大概就是我目前阶段对于无bug程序编写的一些会记到心里的，也是在努力的去做到的（看似简单，其实很难，比如第6条目前做的就不好，总是有时候贪图快会忘记） 二、如何设计出容易适应变化的框架，大象也要跳舞。 这一年对框架设计的理解加深不少，之前为我们项目的活动写过一个活动框架。但随着时间的迁移以及新加入的其他程序员。框架变的越来越臃肿，以致于现在想改某个地方都要非常谨慎，而且在不断出现的新的需求面前，框架似乎也变的越来越无法适应，大象的囧境… 而这一切又是如何出现的呢？继承！没错，这个框架的思想完全是基于一个继承对象的理念来设计的。于是在A，B和C，D出现较大的分歧，框架只好将它们都包容，于是自己变的越来越臃肿，实在不行就必须在代码里出现很多if else 类语句… 组合为主，而不是继承！！将所有的功能组件化，新生的对象只是对自己需要的组件选择性的加载，代替之前的继承。这样可以让各个功能独立，每一个都是一个个独立的模块，以接口的形式提供功能。新生的对象可能又相同的功能但是实现又不同，只要加载不同的组件就ok～同样，如果某个模块不需要这个功能了，只要在加载的时候不加载就可以。而原有的代码在调用这个没有模块的的接口时需要对接口存在与否进行检查（COM），或者就像什么都没有发生过一样（Obj－C似乎就是这么做的，类似事件机制）。 当一切耦合都解开之后，会惊奇的发现，原来大象一样可以跳舞。因为它是由一个个小的部件组成的，而不是当年的庞然大物了。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 我不是一个纯粹的Coder，我是因为爱好游戏才会投身于此。（但Coding本身也是一种游戏，不是么？）接下来要讲讲对游戏设计的一些理念的变化。其实主要就一点，开放！ 设计的玩法不开放，是在给自己挖更多的坑，反过来却是给用户更多的发挥空间，何乐而不为？ 何谓开放？说白了很简单，就是除了基本规则设定和目标设定（甚至都不需要一个很明确的目标，只需要一个指引方向），剩下的都交给用户。恩，就是这样。