提问回顾与个人总结
| 所属课程 | 2019春季计算机学院软件工程(任健) |
| 所属作业 | 提问回顾与问题总结 |
| 课程目标 | 理解软件工程的作用和重要性，提升工程能力，团队协作能力 |
| 作业目标 | 回顾软工课程，总结课程的收获 |
| 提问博客 | 软工第1次个人作业 |
一、问题回顾与解答
1. goto语句
goto语句在c语言中难以操纵，初衷可能是添加一两个goto为了体现程序逻辑，如书中提到的单一出口设计。但一旦函数的逻辑比较复杂，使用goto是否会反而破坏程序的条理性呢？
不论是使用更便捷的工具还是更复杂的工具，都会为项目带来很多的弊端和隐患。比如Python语言，在OO编程中就有着种种不利于工程性的一些特性，而更强大的C++却有着种种技术难题。但技术是人来使用的，只要软件工程师的使用符合工程标准，就可以使用种种技术。事实上，在我们的开发过程中，往往会使用很多更复杂，更不利于程序条理性的工具，但为了实现需求，我们是可以选择去挑战使用这样的技术的。
2. 全栈工程师
书中文字给人一种现在是个人就敢说自己是全栈工程师的感觉，可能作者对身边存在的这样一种浮躁的现象有一些自己的思考和驳斥。
考虑这样几种情况：某职工曾在多家互联网公司任职，在A公司做过后端，在B公司做过前端，在C公司做过服务器维护，在D公司又负责写算法，所以他在投给E公司的简历上写——我是全栈工程师。
某独立开发者自己维护了一个开源项目并且有着一些稳定的用户，这个开源项目部署在了网站上并且该项目的前端后端都是由该开发者自行搭建，并在网站上贴上了自己的支付宝收款码求各位大爷们救济。碰巧该开发者看了《构建之法》这一段，于是心里闪过——我是全栈工程师。
请问职工A和开发者B，究竟谁的技术更好？A作为一个有广泛工作经验的职工，他可能有着极强的工程能力和编码能力；而B可能只是一个刚毕业的研究生，有着维护自己开源项目的爱好。
这是否意味着，全栈工程师在不同的情境下有着不同的意味，而不代表着一个技术上更高一层的阶级呢？
先说结论，全栈工程师在同一个项目或系统内，代表着一个技术上更高的阶级。
在我小组软工的项目组内，有着一名对项目非常上心的同学。他做过的事情从前端到后端，从Linux Shell到Android，从项目需求定制到日常例会内容制订都有所涉猎，最终他也获得了应得的贡献分数。因此在我们这个项目内，他就是处于一个全栈工程师的地位。即便抛开对开发的热情，从纯技术层面来说，我认为他在我们的项目组，也属于一个技术上更高一层的阶级。这也是我们项目最终能成功完成的主要因素，就是有这样一位全栈工程师，为各个部分的同学出谋划策提供建议，甚至亲自动手。
当然，他目前的技术可能不足以在企业内担任全栈工程师，那需要更多的经验。但在每个项目内，都会有着这样一位技术上的领头人物，如果他真的能涉猎到项目的所有部分，那么他在这一场景下就符合全栈工程师的定义了。
3. 软件测试
关于软件测试的作用，在我们的项目中，通过单元测试和分支覆盖来找到的BUG屈指可数。这一点或许是因为我们的业务逻辑较为简单。对于大型项目，或许合格的单元测试可以在软件工程中提升效率，即花费部分测试的时间来减少返工修BUG的时间，在项目的敏捷开发中可以节省项目的总体人力成本。而在课程中应用这种形式，并不是为了节省时间和人力成本，也并不是真的要为了修BUG， 更多的是为了让我们了解软件工程中测试的重要性，形成软件测试的潜意识。
4. 人类学调查
据书中提到，这是某计算机系的同学，这里我要提出一些自己的见解。
该同学觉得自己每天翻墙上外网看quora，表姐父母却天天hao123，QQ秀，话语中体现出自己比海量的中国用户不知高到哪里去了。
如果他觉得站在墙外就更懂计算机，我还可以理解，但是他认为自己从来没为软件或服务付过费是一种很hacker的行为我就很奇怪了。上百度搜个注册机破解码就觉得自己比那些不愿意花钱干等着的人高半头？作为计算机未来的从业者，自己想用软件不花钱，自己写软件的时候你也别想着赚别人的钱啊？如果可以培养一些高素质人群的付费使用习惯，我认为这是可以促进现有软件工程的质量的。如果大家都想不花钱用，那软件提供商就只能在软件上挂广告，大家都不舒服，何必呢？
这只是一个和书中所选的某位同学的观点不合的一些看法，并没有构成提问。原书只是想借用这一例子来说明用户需求调查中，人类学调查的重要性，即世界上存在大量为使用便捷，或者Geek眼里的懒惰付钱的人。
Geek自然有资格评价他人的懒惰，但Geek却不应为自己会使用搜索引擎寻找破解软件而自豪。这不是Geek，这只是聪明的穷鬼而已。
5. 大马哈鱼洄游模型
书中提到了一些软件工程课的一些现象，看起来软件工程这门课似乎并不完善，这似乎主要是因为同学们的水平比较低（上课睡觉），还有一些课程安排方面过于高屋建瓴，没有落实到地。
比如本次博客作业，要大家在比较短时间内浏览完邹欣老师的《构建之法》这本书，这一看，上周课上的PPT基本上就是构建之法的扫描件嘛。书中安排了健身学员的身份给大家，你读完，你就是很想提高自己，你不想读，就是想把健身卡垫桌脚。那既然我们大家都读完构建之法了，是不是我们就已经大致了解软件工程理论，只需要等着编码实践了呢？那么如果未来的课程还只是构建之法的扫描缩印，那理论课的课程内容在第一次博客作业时就已经学习完毕了，理论课的内容是否显得空虚了一些呢？如果课程设计时知道大家在这很短的时间内看不明白构建之法的软工精髓，那么留本次博客作业让大家看完这本书是否合理，又是否自相矛盾呢？
如果不能解决上述问题，就盲目地认为是因为学生没有学好软工就是因为用健身卡垫桌脚了，是不是有些不妥呢？
私以为《构建之法》是一本很好的书，深入浅出而生动独特。软工课程是想以课程中所介绍的方法和实际的项目开发相结合，从而让学生更好地理解软工的精髓。但是在实际操作上却仍然有着一些不足之处。这样的不足之处，可以通过学生的热情和主观能动性来弥补。软工课程中介绍的理论和软工项目的开发在实际环境中脱节严重，至少在我身边的数个小组是这样的。当然，学生可以通过不懈的努力和主动去尝试学习来亲身实践，但更好的课程制度应该是去建立一个良好的学习体系，并以此联系理论和实践。这一点我认为软工课程还需要改进，但我个人没有很好的建议，因为这确实是一件很困难的事情，因为在我看来，很多软工的理论都是难以在课程项目这个级别就轻松实现的。
二、知识点总结
- 需求：用户的需求是推动项目功能设计的关键因素，因此用户调查是非常重要的
- 设计：在软件的功能设计上，应均衡考虑功能的效果及功能本身实现的难度等多方面
- 实现：实现时应尽量选用较为成熟的框架或工具，这样有详尽的文档和大量的社区贡献者所提供的资料
- 测试：测试工程师需要对项目所使用的的技术较为熟悉，并对项目的结构和每个函数的作用有着具体的了解才能更好地完成测试。
- 发布：App的发布需要考虑到很多因素，如安全因素，使用代码的开源许可等等。因此App的发布需要提前调研，防止由于应用市场的政策导致App发布的延期。
- 维护：对功能主要集中在本地的App的维护主要体现在日常反馈Bug的修复和新功能的跟进，新系统的适配等等。其次要对App使用的一些在线服务进行维护，保证其可用性，比如Bug反馈服务和软件检查更新服务。
三、理解和心得
对软工的课程项目，我认为在其中团队的协作和沟通是极为重要的，对项目的热情也是必不可少的。而每个人的技术实力应该是一个团队成功的主要因素，辅以软件工程方法的优秀应用，才可以成就一个更好的项目。
对此，我可以理解课程为什么会有大量的博客来进行展示，或许是课程更重视一个项目开发中软件工程方法的应用。对项目本身，更注重其功能的全面性，以及其功能和需求的切合度，能自圆其说便可。而项目的实现难度和技术的优秀与否，在课程的构建中并不是最重要的部分。虽然事实上很多成功的应用或许不会使用十分先进的技术，而是其抓住了市场的需求和痛点，但是对于程序员本身来说，对技术的追求应该是永不停歇的。