44 lines
3.5 KiB
Markdown
44 lines
3.5 KiB
Markdown
# 阶段二：文字冒险（cool）
|
||
|
||
## 前言
|
||
|
||
本来打算让各位做下面的任务来进行进一步的学习的，但是想了想，实在是，**太无聊啦**！
|
||
|
||
又想让你们来做一个管理系统，但是又想到你们可能会进行无数个管理系统，**这也太无聊啦**！
|
||
|
||
因此呢，我打算带大家玩一个文字冒险游戏！[源头取自这里](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 法则，它的宗旨是**从易到难，逐步推进**, 一次只做一件事，少做无关的事。
|
||
|
||
如果你不知道这是什么意思，我们以可能发生的 `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 法则的重要性。
|