-
鄙人在研究生期间才学会Java，开始尝试使用Java编写俄罗斯方块，最终的成品，或者说半成品很失败，学到一个道理——数据才是软件的真正核心，是数据驱动软件，不能反向。
-
贪吃蛇和五子棋基本是同一时期的作品，所不同的是，贪吃蛇有后来一丁点修正的痕迹，也就是后来看我自己的博客上访问量不够多，于是详细阅读了一遍代码，对之前一些处理不是很妥当的代码进行了修正，或者说重构，才有了现在这个版本。五子棋这个游戏没有获得贪吃蛇的待遇，获得修改的机会，基本保持了最初的原样。这个时期是在研究生毕业的前期，入职一个公司参加其Java培训的作品，这个时候接触过一些设计模式以及数据结构，软件工程的思想。但是在使用上根本没有痕迹。
-
GameOfLife这个游戏是一个很有名的游戏，这部分的实现代码，是在我参加工作之后不久的作品，当时参加了公司的一个TDD(测试驱动开发培训)时候的一个题目，培训没听完，回来自己把这个程序进行了完整编写。
-
Github上的这个俄罗斯方块是今天的作品。也就是2016/4/4。经过清明节一天假期的时间，加上借鉴了一些贪吃蛇的代码，写出来的半成品。因为，代码没有真正的写完。只是搭建了基本的代码结构，以及一些上次的框架设计，包括使用工厂设计模式，策略模式等等。和前段时间的作品相比，差异在于，代码量可能会比前段时间编写多了很多，但是代码的逻辑变的更加清楚。代码职责类的分割也渐趋合理。是一个从面向过程到真正的面向对象的迁移。真的很高兴看到自己的进步。
-
俄罗斯方块最终的完成在2016/4/6的晚上，经过这之间的一些必要的思索和借鉴，进行了代码的最终我鞍山。并且进行了相应的博客更新，博客地址在：http://blog.csdn.net/u011233383/article/details/51058778。俄罗斯方块在昨天也就是2016/4/25号发现了新的bug，基本可以断定是粗心导致的。但是不容易debug，幸运的是我的经验对我有一定的帮助。这个问题也就彰显出UT在代码开发中存在的价值。这个俄罗斯的方块的代码量在1000行上下，bug就已经很多，那么对于更大规模的项目，代码在7万甚至更多，也就是代码量是1000的好几个量级，如何维护代码就提出了更大的要求。
-
俄罗斯方块在最近的测试中，尤其是意识到程序界面的刷新频率不够，导致在变形之后会有延迟才能更新屏幕界面，最初采用加入一个新的50ms的定时器，这样子在一定程度上解决了问题，后来又采用在变形之后加入重绘的步骤，以更加优雅的方式解决这个问题，变形的bug是在这个是偶出现的。有一些形状的改变不符合之前的预期，随后改正了bug。后来加入了暂停按钮，可以在游戏的中间暂停。
-
代码是逐渐在更新并优化的，代码优化的空间还有很大，新的代码又加入了log4j系统。可以通过系统log查询程序在运行过程中出现的bug。
-
这是一个我个人完成的，代码量在1000这个水平的唯一一个项目。以后还会更多，相信自己。
如果，你对鄙人的代码感兴趣，欢迎随便使用。也欢迎提建议。谢谢有你GitHub.