阅读云风大大《游戏之旅------我的编程感悟》时，于书中看到好些我认可的、该以相同态度去践行的建议，摘抄于此处供现在与未来的自己享用：
终其整本书，虽然参考之书籍、网站、代码众多，但我自己都一直坚持一个原则：建立在充分理解的基础上，再用自己的语言表达出来。我相信只有这样，读者才能够看到一个从独立思考角度获得的知识体系，凌乱中不失一缕联系。
其实，这些智能算法，本质上并不复杂，都只是提供一个思路而已。举凡大自然中存在的事物，刨根问底，又有哪点是构造在复杂的原理之上的呢？如果一切都可以从前人那里得到，那时代岂不是在倒退吗？
多年的编程经历让我明白了一个道理：绝大多数情况下，没有解决不了的问题，只是因为平时缺少练习而惧怕问题的复杂度，畏惧的心理让我们选择避让，采取并不那么好的方案去解决问题。最后，还可以找到一个合适的理由，比如一切以稳定一切以工期为重，以此获得心灵的安慰。
从理解编程这件事本身，我不觉得有比basic更好的选择。
以我多年的经验，对于游戏程序的设计，除了整体框架外，考虑最多的无非就是时间和空间。有时候我们需要空间换时间，以突破速度的极限，有时又需要时间换空间，使程序能在合适的机器配置下流畅地运行。
学习新的技术，翻译一本相关的英文著作可以算是一条捷径了，比囫囵吞枣地读一遍英文原文要有效得多。因为责任感，使你必须用心地搞清楚每一个句子的意思，以免译错而误导阅读你的译作的人们。即使以前对此有所了解，翻译完成后，也一定使自己的理解更上一层楼。其实，技术书籍的翻译，英文能力是很次要的，相关技术知识的掌握尤显重要。
这一章，将领略一下在x86下优化代码的乐趣。在阅读这些之前，希望读者明白一个道理：CPU的设计不是一成不变的，所有的优化策略和原则都可能在有一天产生翻天覆地的变化，以前相对快的方法变得相对慢，相对慢的方法变快。在编码生涯中，我们需要不断地学习新的知识，以适应新的硬件环境。好在大原则较小原则变化得慢，不用过于担心知识过期，对于已经写好的代码，如非必要，也不必老是从头翻新。因为一旦CPU有了革命性的变化，也意味着其绝对速度有了巨大的提高，作为游戏程序员，考虑以前代码的效率问题大多是不必要的。
在我的程序设计哲学里，程序员的水平是和其代码长度成反比的，我们开发的一款几十万人同时在线的大型网络游戏客户端的C++部分，统计下来不超过1M的源码，经过几年的不停维护修改，本来风貌并无太大改变。
终其整本书，虽然参考之书籍、网站、代码众多，但我自己都一直坚持一个原则：建立在充分理解的基础上，再用自己的语言表达出来。我相信只有这样，读者才能够看到一个从独立思考角度获得的知识体系，凌乱中不失一缕联系。
只要自己能保持真诚和谦逊，存在的错误就能够得到理解；虽然整体上并不完善，但于后来者，依旧可以从中学到一些闪光点，而避免踏上过多的弯路。无论是从一开始公开"风魂"的源码，还是现在以并非专家的身份写这么一本大杂烩一样的书，我想，这些于己于人都还应该是有意义的事情。
对估算能力的训练是如何的必要，这里给出一些建议，这也是我时常无意识去做的事情。（1）面对问题立刻对时间和空间，还有解决问题需要多复杂的代码做出反应。在任务完成后反思自己当初的估算究竟有多少偏差。
（2）准确地弄清问题，并确定会发生有关影响的前提条件。除了在设定条件下做出准确的估算外，还需要估算各种不同条件的发生几率。
（3）确定估算结果的精度需要达到怎样的程度。
（4）把问题分成更为细致的子问题，找到子问题之间的关系，确定哪个子问题最需要被估算。
（5）不要急于达成结论，多做思考。重要的或是没有碰到过的问题不要太相信自己的估算结果，应该用行动来验证。
C++提供了太多的灵活性，这些灵活性中布满了陷阱，一不小心就会让初学者陷进去。工具越方便，就越容易被滥用，我们应该时刻警惕这一点。以我个人的经历，总结出一条不被很多人接受，但自己却十分受用的准则：尽可能地使用结构最简单的工具来完成任务，直到这个工具不合适。
几乎任何一个有经验的程序员都明白，复制一段写过的代码，贴在另一个地方改动几句让它可以正常工作，这种令人作呕的行为，无论何时都应该被避免。因为这简直是大部分程序错误的根源，在多个地方表达相似的概念，意味着日后改动一个地方，就必须记得改动相似的所有地方。而直接复制这些代码，导致编译器并不知道这些地方的相似性，不能为你提供这种帮助。而人，随着项目的扩大，几乎不可能记住自己干过多少这种复制的动作。
程序员有时或许没有意识到他们在重复，有时是出于偷懒，这些都可以用加强对代码糟糕味道的嗅觉敏感度和提高作为编码者的责任心来达到。