近期完成的项目小总结：反正最后买单的还是程序员

[size=medium]技术上：
1.命名上的几个动词搞混了。一些下划线的滥用。
2.阅读上的复杂。太悲剧了，每次都在效率上纠结大半天，结果在未完成时就开始优化。而优化的代码总是有点怪异的，对着自己以前一个复杂的文件内流满面。
3.功能上的复杂。再次体会到KISS原则的威力。
[color=red]4.早上发现问题越界操作了。发现2个独立的for循环中，第二个for循环依赖了第一个for的变量值。由于在一些数据的依赖上优化和技巧性很强，所以一些数据的初始时很奇怪，比如N个for循环。出了问题好，不然我总是担心。
5.出了个大BUG.因为是2个游戏的混合，我负责的地方要取消一个值的存储，改为即时的。在改代码时，那代码太诱惑了。分了两端调用一次存储函数，其中那个值在第二段。我DEBUG的时候看了第一段发现无这个字段，就认为没问题了。结果造成了可以刷这个值。。虽然没测试到，但主要责任在我！ :cry:
[/color]

其实每回开发完，都是差不多以上的这些问题。无它，唯手熟尔，海量代码的喂食，充分的消化排泄系统，饥渴的吸收系统。

流程上：
一开始不温不火的搞了个把月，突然在一次会议上，莫名其妙提出好多需求，而时间又临近封版。连续奋战了两个晚上。
1.责任的不清。家家都有本难念的经，包括公司也是，尤其是领导参与进来后。东西的指派上全都乱了，而且在人员的分配上也不够，常常是美术和测试的干N方面的事。反正最后买单的还是程序员。
2.需求的不清和变动。我很难想象策划上居然还会出现"思考"“会不会”"引申"这样的字样。也可能这是份草稿。反正最后买单的还是程序员。
3.。。。
。。。
反正，最后买单还是程序员。


总之，这些问题都是一个没有规范的开发过程。尤其像我们这样的小公司，虽然程序员的个人能力在支撑着，但很难做大，问题还非常之多。

业余时间设计的游戏服务器已经开始设计编码了，挺辛苦的。加班到11点回去后，还得挣扎的思考会服务器的问题。过段时间稍微有点料后在BLOG上放出。[/size]