44 lines
3.4 KiB
Markdown
44 lines
3.4 KiB
Markdown
# 阶段二：文字冒险（cool）
|
||
|
||
# 前言
|
||
|
||
本来打算让各位做下面的任务来进行进一步的学习的，但是想了想，实在是，<strong>太无聊啦</strong>！
|
||
|
||
又想让你们来做一个管理系统，但是又想到你们可能会进行无数个管理系统，<strong>这也太无聊啦</strong>！
|
||
|
||
因此呢，我打算带大家玩一个文字冒险游戏！[源头取自这里](https://github.com/helderman/htpataic)，如果你想自己体验全流程的话可以试试玩哦！
|
||
|
||
当然，在编写的过程中，难免会出现你感到困惑的地方，比如说，你觉得这样更好，或者说，你不明白为什么要这样编写代码，欢迎你进行更多的独立的尝试。
|
||
|
||
其次我要说的是：
|
||
|
||
这个学习过程会非常硬核，所以你感觉非常多东西不会是很正常的！
|
||
|
||
我希望你可以通过这种方式，以后在面临一个大项目或者别人的代码时（你经常要借鉴别人的代码）保持冷静。
|
||
|
||
可以保证的是，如果你成功坚持下来了，你将会在接下来的编程生涯中保持长时间的游刃有余。
|
||
|
||
当然，如果你选择跳过，也不会对 python 开发那里造成非常大的影响但是你会错失一个非常宝贵的学习机会。
|
||
|
||
|
||
|
||
在 1980 年代， [文字冒险](http://en.wikipedia.org/wiki/Text_adventure) 是一种受人尊敬的电脑游戏类型。但是时代已经变了，在 21 世纪，它们与 带有 3D 引擎的现代 [MMORPG 相比显得苍白无力。](http://en.wikipedia.org/wiki/Mmorpg)书籍在电影的兴起中幸存下来，而基于文本的游戏很快就输掉了与图形游戏的战斗。“互动小说”由一个活跃的社区保持活力，但它的商业价值早已不复存在。
|
||
|
||
# 系统调试的黄金法则：KISS 原则
|
||
|
||
这里的 `KISS` 是 `Keep It Simple, Stupid` 的缩写, 它的中文翻译是: 不要在一开始追求绝对的完美.
|
||
|
||
随着以后代码量会越来越多, 各个模块之间的交互也越来越复杂, 工程的维护变得越来越困难, 一个很弱智的 bug 可能需要调好几天.
|
||
|
||
在这种情况下, 系统能跑起来才是王道, 跑不起来什么都是浮云, 追求面面俱到只会增加代码维护的难度.
|
||
|
||
唯一可以把你从 bug 的混沌中拯救出来的就是 KISS 法则, 它的宗旨是<strong>从易到难, 逐步推进</strong>, 一次只做一件事, 少做无关的事.
|
||
|
||
如果你不知道这是什么意思, 我们以可能发生的 `str` 成员缓冲区溢出问题来作为例子. KISS 法则告诉你, 你应该使用 `assert(0)`, 就算不"得体"地处理上述问题, 仍然不会影响表达式求值的核心功能的正确性.
|
||
|
||
如果你还记得调试公理, 你会发现两者之间是有联系的: 调试公理第二点告诉你, 未测试代码永远是错的. 与其一下子写那么多"错误"的代码, 倒不如使用 `assert(0)` 来有效帮助你减少这些"错误".
|
||
|
||
如果把 KISS 法则放在软件工程领域来解释, 它强调的就是多做[单元测试](http://en.wikipedia.org/wiki/Unit_testing): 写一个函数, 对它进行测试, 正确之后再写下一个函数, 再对它进行测试... 一种好的测试方式是使用 assertion 进行验证,
|
||
|
||
KISS 法则不但广泛用在计算机领域, 就连其它很多领域也视其为黄金法则, [这里](http://blog.sciencenet.cn/blog-414166-562616.html)有一篇文章举出了很多的例子, 我们强烈建议你阅读它, 体会 KISS 法则的重要性.
|