lakoodev的专栏

在2003, Ken Beck发表了有关TDD的开发概念，令很多程序员重新重视测试的重要；也而且成为“敏捷开发"其中一个重要部分;基本上在学习中，很少情况，学校和导师跟你说要进行很多测试；通常的做法就是“编码后能跑到”就可以了。如果开发的目的学习，或者演示之用，这样是可以的；但是如果开发大型的应用，这样做会做出很多问题；～～ 没有测试的情况 ～～1. 开发流程：

今天在对一个类进行重构，这个是一个GUI类，里面包含了不同的逻辑；  包括 建立界面，事件处理，对数据逻辑，对监听者处理； 重构之前，不同类型的逻辑分布在不同的位置，导致难以了解和查找。这是整理的做法; 1） 制作大标题注释, 如下: // ----------------------------------------------------------------

昨天和同事一起玩LOL(英雄联盟)；游戏结束后，我发现在游戏的时候，我们都是十分专注的； 如果这份"专注"用在开发上，是一件很棒的事情, 可以打破开发效率低的问题；~~ 隔绝任何”打扰“ ~~  我们在游戏时，基本上是用”全屏模式“，什么 QQ聊天, 邮件，上网, 微信，胡思乱想等活动都停止；也不想受到任何打扰；大家都是全心投入控制”英雄“, 关注目前形势和小地图; 务求能杀对方和

周末读了一篇wiki, 说了一下技术的类型（Programmer stereotypes)，有点意思，和大家简单共享一下：1）Hardcore techie ( 核心技术牛人):专门解决用出神入化的手法来解决技术难题，而程序基本功十分好，例如知道如何优化OpenGL画图，如何省内存，App可用内存有多少等;2) Visionary (远景者)这类技术人能联想到游

1）测试 这里指的是认真和全面的测试，不是完成代码后运行一下的那种; 很多时运行一次，会看不见以下这些问题:Null 或者 out-of-bound的情况，按照开发时的输入，当然okay, 但是情况变了, 就会出现异常;界面布局因为参数不同而变化没有捕足的Exception (异常) 如果不反复测试，就看不见上面的问题;  (真人真事: 当去体验同事说已经”做好

这几周都在重构游戏的战斗界面，当中的过程也蛮辛苦；一来，代码的原著不是我而且写得比较乱；二来，时间紧逼；三来，功能点很多；不过也在当中学习了不少事情；1. 保持冷静，沉着；2. 保持开朗和有足够睡眠3. 坚持做unit test来确保功能正确4. 利用UML, Class Diagram来了解代码架构5. 利用State Diagram

最近在不断的为同时的代码进行重构，我常常在想一件事，一个程序做同样的事情，为什么需要重构；我的答案是： 重构的目的就是提升‘程序品质’！！！以下是不同的程序品质－ 劣质：程序不能正常的操作－ 普通：程序能正常的操作，而且没有异常处理－ 优良：程序能正常操作，能独立测试，有好的异常处理－ 极品：拥有’优良‘的特性，而且代码容易理解及扩展‘优良’和‘极品’不用说

最近在工作，遇上了一些让我不满的事情，就是同事做时，只草草完成却没测试；一次又一次说明测试的重要，但是一次又一次发现同事没有好好测试；在产品开发角度，没有测试好的东西基本是不算是完成；在游戏开发中，任何设计和程序，完成后，如果没有去证明它的对和没有方法去证明，这个设计或功能，可以说，就不能说它是正确或能正常运作；在制作时，很重要一点，要清楚自己要的东西，怎样才算完成，怎样才是正确；