| 项目 | 内容 |
|---|---|
| 教学班级 | 006 |
| 作业属于 | 2020春季计算机学院软件工程(罗杰 任健) |
| 作业要求 | 提问回顾和个人总结 |
| 个人课程目标 | 掌握软件工程基础知识 |
| 具体有助方面 | 检查学习成果, 回顾提高 |
| 相关链接 | 原提问博客 |
问题解答/疑惑/新说
经过一学期的实践，看看自己学期初对《构建之法》一书中的不解之处，有没有一些新的看法。
《构建之法》3.1 个人能力的衡量与发展：
积累问题领域的知识和经验（例如：对医疗或金融行业的了解） ······ 随着经验的增长，一个工程师可以掌握更广泛、更深入的技术和问题领域的知识。
《构建之法》在这部分提到了初级软件工程师的几种成长，简单总结为 1.技术技能；2.问题领域的知识和经验；3.通用软件设计思想和软件工程思想；4.职业技能；5.实际成果。维基百科(中文)在软件工程师词条中，提到“软件工程师跟一般程序员的分别，在于一个程序员的工作是按照指定的规格进行编码，而软件工程师的工作则需要设计和规划。”这里着重提到了软件工程师的设计和规划作用，所以一个合格的软件工程师，积累问题领域的知识和经验也是一种成长的表现。学期初对软件工程师的作用理解还是较为浅薄。
《构建之法》4.3 代码设计规范：
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
关于goto语句的使用，这个在《构建之法》中是不反对使用的，但是是有前提的：“函数最好有单一的出口”“只要有助于程序逻辑的清晰提现”。所以在这个前提下，goto语句的使用大概是可以的。而我们在最初接触c语言的时候，对程序逻辑和结构的掌握肯定是浅显的，所以老师不建议我们使用goto语句。另外，自己搜索思考的do-wihle代码块和try-catch-finally代码块对goto语句进行替换，在理解程序时确实没有goto语句清晰。
《构建之法》16.1.3 创新的迷思之三：好的想法会赢：
这个问题主要还是考虑到很多实际因素，现实和理想不会一样。所以在很多情况下，‘好的想法’不一定会赢是合理的。比如Dvorak键盘布局没有把QWERTY键盘布局替换下去，因为目前大众已经习惯了QWERTY键盘布局，他们不认为Dvorak键盘布局可以对他们带来很大的工作效率收益，最终用户对此不感冒，那么键盘产商也不会去生产这样的键盘咯。同理，双拼输入法也是大部分用户不愿意去投入学习的成本，认为收益不值得，所以其受众目前也是小部分。所以想法除了在胜过原有想法外，还要考虑：1.利益相关人能否清楚“能从中得到什么”；2.创新的想法和目前流行的想法相比，其优势能否让别人清楚看到；3.创新和目前大众习惯、已有系统是否兼容等。
《构建之法》16.1.5 创新的迷思之五：要成为领域的专家，才能创新：
统计数据表明，70%的创新者说，它们最成功的创新，是在他们的拿手领域之外发现的。
为什么领域内的专家没有领域外的专家那么有创意？这个话题我现在也不是很理解，毕竟自己在各个领域都不是很精通，没有那种专家的体会。猜测是因为在行业内有了一定的固型思维，所以很大有大幅度的颠覆性创新。
《构建之法》16.2 创新的时机：
关于技术创新，一些趋势大家早就看到了，也有一些产品推出，但是往往最后成功的产品成功在时机上。
这个模型比较复杂，我当初的想法过于简单，没有考虑到大众/消费者的想法，他们看到了创新或者看到了投机，对于IT创新能否推广还是很有影响的。并不就是理想的那样，早点创新推广就有先机可以拿到一手的用户反馈，进而正向反馈推进产品发展。
"实践得来"的知识
需求
我们团队的开发设想是一个“寓教于乐”的编程启蒙游戏，所以用户只有模糊的需求（对编程的一些认识/了解/实践），我们主要借鉴了一些大厂游戏框架，同时关卡部分有自己的设计理念。由于是游戏开发，前期框架搭建比较复杂，所以alpha阶段的产品相对不成熟，没有体现到编程启蒙的这个“杀手功能”。
设计
设计我理解成两部分，一是游戏的具体设计，二是人员分工的设计。首先是人员分工，个人志愿然后协调分配的方式我觉得很好；游戏设计部分，围绕“编程思想”为核心，然后游戏的一些表现形式去参考同类游戏，同时考虑实现难度。这一部分学习到的东西就是要多角度思考，不仅仅只从表现形式，其怎样实现、实现难度都要去考虑。
实现
实现上团队采用游戏开发的典型分工：策划+程序+美工+测试。我是主要负责美工部分，主要任务是UI的设计、场景的搭建和3D模型问题。主要问题还是学习成本的问题，3D建模学习成本较高，部分需求难以实现。这部分学习到的知识点就是在敏捷开发的前提下，衡量学习成本和实现效果。
测试
采用Unity进行开发，前期没有找到合适的方法去给出代码覆盖率等代码质量参考指标，也不了解一些安卓版本模拟去自动测试。这部分学习到的主要内容就是尽量自动化测试，在不能自动化测试的时候，要去保存手动测试的数据。
发布
发布问题主要有发布平台和推广手段。不了解“行情”，现在绝大部分发布平台需要版号等证明，又游戏是单机游戏没有监控用户的手段。所幸还是找到了可发布的平台。这部分学习到的内容是发布材料应该提前准备。
维护
维护主要就是根据用户反馈来修复bug。一些小bug比较容易修复，但是从alpha向beta阶段的过渡，没有考虑到引导方面的设计，需要额外经历去开发这部分功能。这部分学到的知识点有“敏捷”，比如给出专门的用户反馈渠道等等。
个人理解与收获
回顾整个课程，我们学习到了一些软件工程的理论知识，并且以实践体会学习。个人项目和结对项目主要是技能的掌握和初步沟通的习惯，为团队合作稍作铺垫。我们团队项目做了一款具有教育意义的编程启蒙游戏。在团队开发的过程中，采用“敏捷开发”的方式，以需求为目标，与队友的讨论合作令人进步。在alpha阶段，一方面与团队交流、工作交接交互等方面有锻炼，另一方面在其他队友的代码风格能力或者工作方法有取长补短。进入beta阶段，虽然有队友的交换，但是过渡也很快。相比alpha开发速度就相对较快了，队员之间交互帮助也更多了。
软件=程序+软件工程，在有写程序的基础能力上，一些工程性知识也是很重要的。我们需要一些工程性的操作保证软件的质量，在课下(精力允许的话)应该去找一些项目继续锻炼这学期学到的知识。