软件工程 in MSRA 第一周博客作业

2.现状 经验和计划

（1）怎么选择了这个专业的？

主要还是对算法，对编程的喜爱吧。觉得自己想出一个思路之后可以立刻动手实践验证的感觉很好。并且算法的思维让我觉得很有趣。

技能调查表：

技能	水平	期望水平	提高手段
程序理解	5	7	尽量高效阅读开源代码
程序设计	7	8	还在定期参与程序设计竞赛与训练
效能分析与改进	5	8	更多接触效能分析工具并熟悉
个人源码管理	1	6	尝试尽量规范化管理自己的代码库
单元测试	2	7	更多参考文献中提出的单元测试方法

（2）a）为何要来上课并认真参与？

技能是可以自学的。我认为上课，更多是为了感受老师是如何看待这些技能的，如何学习它们的。每个人对行业，对技能的理解都是不一样的，老师无疑对这些的理解比我们更深刻。我认为我们可以通过上课了解到对这些技能更好的学习方式，对行业更深的理解。

（2）b）师生关系

我认为大学的师生关系是双向的，每个人的目标，方向，着力点都是不一样的。学生可以获得老师传授的经验，老师也可以通过学生了解一些不同的观点。对于作业，我认为尽力而为吧，如果真的做不到，不需要勉强。老师的作业是统一的，但实际上每个人对于这门课期望获得的东西是不一样的，更何况每个人基础也有不同。尽力完成作业，达到自己的期望，我觉得就足够了。

（2）c）对抄袭的理解

参考需要明确地说明，表面知道这一部分成果是别人的，尊重别人的知识产权。而讲别人的成果冠以自己的名字，就是抄袭，剽窃。

（3）为将来的准备

现在还没有明确将来是不是要进行科研。毕竟大学前三年并没有进过实验室。我决定在 MSRA 实习一段时间，了解了科研的大致方法之后，再考虑我是否适合科研。对别人的优点，应该就是编程基础比较扎实吧，对基础算法的掌握更好一些。缺点就是较同学来说可能项目开发上的实践经验要少很多。

（4）学习计划

尽量高效完成老师给出的任务吧。我希望在学完这门课程之后能够达到给定问题，自己能够设计好一个完整的项目架构与流程的程度。
代码量：

语言	代码量
C/C++	80000
Python	5000
Java	3000
Pascal	2000

精确度。。没有精确度。我不认为代码量是衡量一个程序员水平的标准。可能精心想 3 个小时想出的 10 行代码，比暴力编写的 200 行代码要优秀的多。（竞赛中经常遇到）所以我没有为自己规划本课程的代码量。保证完成任务的前提下代码质量尽量高就可以了吧～

（5）博客感想

参考博客：https://book.douban.com/subject/4006425/discussion/22803961/

感想：看博主聊他上学时的迷茫，感觉和我很多时候的感觉很相似。工大（相信几乎所有学校都是）很多像线性代数这种对计算机学生非常重要的基础课程是由数学系来教的。这就导致一个非常严重的后果：完全不知道这东西学完有什么用。直到大三开始学各种专业课，开始用到数学知识，才发现之前的知识都忘了，再拼命回去补课。学东西一定要与能实践，有依托的项目或方法相结合，事半功倍。

---

3. 《构建之法》 有质量的问题

纸飞机/航模 <-> 写程序练习数据结构 / 算法：影响只限于自己，如果尝试失败，人们的兴趣会减弱。这类知识也有比赛，但是比赛之后，这些算法高手写的程序的可维护性怎样？有人会拿着程序去发布成为商业软件么？--P21 第 1 章 概论

我并不认同这个观点。首先，算法比赛考察的是对问题迅速的分析和解决能力。在考场上必然无法考虑到软件编写中的可维护性等标准。对这种程序去评价其可维护性是没有意义的。然后，我的观点是：把软件系统比作成熟的航空业，那么数据结构 / 算法就是每架飞机组装时精密的零件，甚至是飞机的骨架。参考《今日头条》，《抖音》，推荐算法是整个软件的灵魂。程序不会成为商业软件，但会成为软件的心脏。我认为一个算法的成功一样可以影响整个公司，甚至行业。

一个成熟的软件工程师应该能够降低任务交付时间的标准方差。 --P62 第 3 章 软件工程师的成长

我不是很理解这句话。《微微一笑很倾城》里说到（我知道是电视剧，但我觉得说得挺好的，老师不要打我QAQ）优化没有止境，做人要有追求。对一个任务而言，我认为交付时间和代码质量是有关系的。而当代码质量非常高时，由于其难度较高，其交付时间往往也偏差较大，难以预测。而且编程嘛，一个程序或软件有没有坑往往只有自己实现了测试了才会清楚。时间预测有偏差非常正常。我不清楚方差大小和一个工程师的能力究竟有多少联系。

MSF 的第一原则：所有的信息都保留，并公开。 --P140 第 7 章 MSF

我们期望的是：所有的信息都能为今后的工作提供帮助。然而，保存所有信息就像大数据，是肯定无法人工一条一条去看之前的记录的。我疑惑的是，保存所有数据，会不会导致当我想要寻找一条有用信息时找不到呢？或者，会不会使后面很多工作浪费在一些营养价值很低的记录上呢？就像记日记，如果每天把重要的事记录下来，那我之后闲暇下来可能会翻看一下之前的日记。但如果我把几点吃饭，吃了什么，几点工作，都写了啥流水账一样全部记下来，我可能就一点看日记的欲望都没有了。

几个程序员用他们从来没用过的技术去实现一个他们以前没碰到过的需求，他们的时间估计一定会很飘忽。 --P179 第 8 章 需求分析

这句话很好懂，很显然。但是，这只是告诉了我们：当程序员没有相关经验是，时间估计会估计得很差。书到这里对这个公式的探讨戛然而止了，并没有给出一个方法可以减少甚至规避这样的“测不准”所带来的风险（或者说，我感觉好像没有方法）。那么在这样的前提下，如果程序员对新的需求经验都不多（而且这种情况好像经常发生），那么我们估计时间还有多大意义呢？大家都知道不准的估计，还需要估计吗？

第三象限：建议采取“维持”的办法，以最低代价维持此功能。第四象限：建议采取“维持”的办法，或者现在“不做”，等待好的时机。 --P355 第 16 章 IT 行业的创新

第三象限和第四象限指的都是非必须的辅助需求，区别是第三象限大家都能做到，而第四象限只有我们能做到。我不理解的是：即使是辅助需求，突出我们独特能做到的不应该也是好的吗？为什么在第三象限这个离第一象限“最远”的需求都维持的情况下，第四象限可以“不做”呢？我以我非常喜欢的一款游戏《粘粘世界》举例：对于第三象限，可以对每一关设计“困难模式”，这在同类型游戏中非常常见。但对于第四象限，可以设计“沙盒”自定义模式，很多游戏是做不到的，但在这款游戏中由于其特殊的玩法设计，可以做到。在我看来，这个第四象限功能远比第三象限对于游戏带来的收益（可玩性）高。