软件开发：一条痛苦而必经之路
——读《梦断代码》有感
海军工程大学 封皓君
在读研究生之前，我就对代码和软件有着浓厚的兴趣，恰逢属于电院的我遇到了愿意让我选感兴趣的课的导师，于是我便选修了这门软件设计与软件工程。在没上课之前我觉得也就是编编程序这么简单，从来不会考虑“软件”这个层面的更深的内涵是什么。随着课程的深入，我也明白了软件开发的意义，也深深体会到了这是一条“痛苦”（偶尔和搭档加班到深夜）而“必经”的道路。当然，只掌握课堂上的内容是不够的，于是在教员的推荐下我开始读《梦断代码》这本书，本以为这个名字类似于“魂断蓝桥”的书会像外文小说那样晦涩难懂，但读起来发现还津津有味，于是把观后感写下来以作记录。
第0章 软件时间
我还在奇怪为什么一本书需要有第0章，一般不都是以第1章开头吗。慢慢我发现这确实是作者的良苦用心。一个程序员需要熟悉0这个数字，也需要从头开始，慢慢积攒技术，就像本书的作者Scott Rosenberg和他的团队那样，万丈高楼需要有一个稳定的地基，我们在软件开发时也是这样，需要先打下良好的基础，然后慢慢开始创作自己的“艺术品”。
第1章 死定了
一般我们很少回去说死定了，但是作者在第1章就开始谈论这个话题。“软件缺陷列表”在Bugzilla之中，一直是Scott的痛苦，作者也在这里疾呼死定了。考虑到我们之前的PSP表格，不仅软件缺陷需要考虑，每个流程的耗时也需要考虑，于是无形之中我们的任务量又增加了很多。甚至有些任务，我们无法去估计需要耗时多久。例如最后的团队项目当中，分配给我的任务由于时间考虑错误，使整个团队的项目进度有所延缓。就像文中的小故事那样，某位开发人员计划修改一个Bug，需要4小时，但是实际上8个小时也没做出来，甚至给他8天也解决不了，这个Bug最终被解决是在几个月后。有时候修改这种棘手的Bug正的像这位开发人员所说“有时候，你一觉醒来，脑中灵光闪现，于是手到擒来。”
第2章 Agenda之魂
相较于其他国家，显然美国的科技是处在领先地位的，但是貌似他们的决策也没有一直保持正 确，也就是我们说的“外国的月亮也没有比较圆”。书中举了几个例子，我这里原文引用，麦当劳的Innovate项目耗资1亿7千万美金，计划把快餐链升级为实时网络，让管理层能随机查看每一锅炸薯条的精确状态，最终以失败告终；还有福特公司的Everest采购系统，成了耗资数亿美金、历时5年的黑洞。而美国正把大量巨无霸项目以失败告终的原因归咎于公司的赘疣和异常以及政府官僚作风的肆意疯长。因此，软件开发切忌目标忽上忽下，计划不切实际，这样不仅不能提高效率，反而会使人心生厌倦，慢慢失去对编程的信心和欲望。
第3章 原型与Python
Python 是一种“解释型语言(interpreted language)" 。“编译型语言(compiled language)" 通过编译器先将程序员的源代码翻译为机器可读的二进制代码后再运行，而解释型语言则是在运行时做类似的工作——解释器逐行翻译源代码，再喂给处理器运行。解释型语言效率较差，因为你要同时运行自己的程序和解释器。但这也使得解释型语言较为敏捷。
我们在大学本科伊始学习过C语言，但很显然这些是不够的。在大四的时候，我利用空闲时间慢慢开始学习Python，显然Python更加方便一些，因为它无需那么严格的语言格式。未来我也会更多的学习和使用Python。
第4章 乐高王国
我们总想着通过模块化的组件去构建属于自己的项目，但事实上这样的想法却很难完成。书中解释道：可以运行的模块通常不能与自己想写的程序配合工作，好的源代码由于商业利益也不太容易找到，程序员只能自己搭建自己的模块，但结果还是一样，做出来的东西难以让他人共享，这个现象周而复始，不断地在多个程序员身上上演。
我们都能找到很多满足需求的开源代码，但是能恰好契合我们问题的却很难，如果是创新性的项目就需要我们自己去解决这些差异。而创新性恰恰又是当今强调的问题之一，需要我们想出更好的解决方法。
第5章 管束奇客和狗
（这一章没怎么读懂，主要还是概念名词太多，我又疏于理解……）
国外技术人员不愿承担项目经理这种管理岗位，而在国内正好相反，许多时候还是不会编程的人来管理。
用代码行数做判断标准只会鼓励程序员写臃肿、蹩脚的代码。
用我通俗的理解来说就是：我们在制作工具的时候，不要花费太多的时间，任务需要分清主次。
第6章 完成设计方案
用作者的话来说就是我们在创建项目的时候不用一味的追求建立一个大项目，要学会从小项目入手，一步一个脚印。俗话说“一口吃不成个胖子”大概就是这额意思。
同样地，我们也别指望在短时间内就可以获得一个大的成就，这样同样是不切实际的，需要我们一步一步地提升自己的能力，然后慢慢做出大的成就。
第7章 细节视图
这一章强调了需求视图的重要性，需求搞错的严重后果，18英尺的巨石拱门变成了18英寸的石桩子，因此可见需求和细节的重要。
我们在进行项目设计的时候也要注意需求细节，否则只会造成白白丧失进度，浪费人力和资源，这个问题在我们以后的项目设计当中要更加注意。
第8章 白板上的即时贴
作者原话是非常敬佩写标准的人，你要用5年为计量标准的眼光看问题，得花上5年时间，才能得到你真正想要的有用之物。标准无非是项目当中必须要考量的问题之一，不符合标准，连敲门砖都没有。
因此我们需要对标准进行研究，无论是哪种渠道，同时也要时刻确认项目的各个流程是否符合标准规范。
第9章 方法
本章主要介绍了祖尔测试的12个问题，包括：
1、你们使用源代码控制吗？2、你们一步就能完成构建吗？3、你们做每日构建吗？4、你们有缺陷数据库吗？5、你们会在写新代码之前修复缺陷吗？6、你们有与当前工作吻合的进度安排吗？7、你们有规约吗？8、程序员工作环境安静吗？9、你们采用了市面上最好工具吗？10、你们有测试人员吗？11、你们会要求应聘者在面试时写代码吗？12、你们做走廊可用性测试吗？
虽然大部分针对企业，但我觉得在项目进程时也可以多思考一下这些问题，总之没什么坏处！
第10章 工程师和艺术家
从某种方面来说，工程师就是艺术家，艺术家也是一种工程师，在项目创作当中，工程师完全可以把自己当做是艺术家，创造项目就是打造一个艺术品的过程，这样项目的进行也趣味得多。
第11章 通往狗食版之路
最后的最后我们终于设计出了属于自己的软件，这时候应该把自己代入进去，当做软件的客户，这样可以发现之前隐藏的一些问题。当然，还是要祝贺作者，我在读这本书的时候，仿佛就是作者团队当中的一员，经历九九八十一难，最终成功的创造出了自己的项目。
尾声 长赌
软件开发是一个长久的过程，就像我们最后的团队项目一样，其实还有很多很多需要我们未来改进的地方，我们的游戏也不会是做出来就没有改变的方式了，与此同时，我们组不会放弃我们的项目并力争使它未来更加完备，这款小游戏会在未来变的越来越好！
