ASE

这篇博客是高级软件工程（ASE）课程的热身作业，主要内容包括：1. 自我介绍；2. 我的现状、经验和计划； 3. 阅读《构建之法》一书后提出的5个问题（或者自身思考）。

1. 自我介绍

我叫宇桐，来自西安交大，所学专业为计算机，目前即将进入VC组成为MSRA的一名实习生。

我很喜欢逛bilibili，看各种“沙雕”无聊的视频，我承认这很浪费时间，但这确实给我带来了很多的欢乐。我还喜欢看剧，在各种老剧中，我最喜欢的是《士兵突击》和《武林外传》。

其他的，我还喜欢看小说和打排球。看小说方面我是个假粉，一年也看不了几本，但之前有一段时间确实觉得看小说很舒服，可能因为那是考试周吧。打排球的话，我还是挺喜欢的，从高一开始接触，但是水平就一般般了；平时校内比赛的时候，我是打二传的位置，但我传球水平很菜，而且我自己更喜欢接一传。

个人性格方面我自己也说不准，但应该不会太难相处，也希望和大家都成为好朋友呀！

2. 我的现状、经验和计划

Q: 为啥选择了当前的专业（计算机）？

A: 我和计算机结缘于高一，当时我所在的高中开设有OI班，我当时没见过计算机编程，想着去开开眼；当然我去的是初级班，就当兴趣玩玩的，最后也没参加过OI竞赛，主要是水平问题。

后来上了大学，我所在的班是工科试验班，大一读完再分流。在大一的一年里，我最开始想的是学机械，但上完工图课我觉得机械和我想的不大一样，自动化似乎更适合我，但后来又发现自动化的课程对我吸引力一般，反而是程序设计课程蛮有意思的，所以我就决定了，选计算机吧。

总结：高中的接触埋下了种子，大一时的尝试让我觉得计算机是我的菜。

Q: 离成为一个合格的 IT专业毕业生，在专业知识、技能、能力上还差距哪些？

A: 技能与水平列表如下：

Skills	目前的水平	课程结束希望达到的水平
Programming Design	1	6
Programming Implementation	3	6
Program Performance	3	7
Personal Software Progress	1	7
Programming Test	3	6

从表中我们发现，个人的水平其实非常的有限，亟需提高；对于如何提高，我们有以下的几个方法：

• 上课。其实我也不知道我们这门课会怎么样，但对于我来说，上课向来是初步掌握一些知识的最简单的方法；
• 看书看资料。上课的一种补充和拓展吧；
• 看人？就是通过和其他同学的合作、讨论，来学习他们的一些优点，进而互相促进；其实这是自己瞎想的，我之前不算真的这么做过吧，希望这一次能尝试一下；
• 实践。学习了很多内容之后，终究是要通过实践来转化、丰富自身的；从我看《构建之法》的感受来看，软件工程光是看的话也太难有什么理解了；
• 做一些和课程没有直接联系的事情。（这一点就当我为了凑够5点而写的吧）不过一些无关的事情也能促进我们的学习....

Q: 为何要来上课并认真参与？

A: 原来的博客给出了五点内容，但我觉得可以归纳为三点：1. 我们需要一种专注的品质，认真听讲可以锻炼这种品质； 2. 课堂讲的好不好，课程有无用，不该成为自己不认真听讲的借口； 3. 大学课堂会锻炼 到自己的思维和思路。对于第1和第3点，我个人比较认同；但我不认可第2点：作者认为学生没有水平和视野来对课程和课堂进行评判，但我认为这不对。大学生应当具有独立思考的品质，认真听讲显得很“正  确”，但其实学习的方法各种各样，每个人的需求也千奇百怪，我们需要思考哪一种方法更适合自己。认真听课只是我们达成目标的一种可能的途径，而不是我们所追求的目标。

Q: 你希望这门课是什么师生关系？如果老师布置的作业对你来说有些困难， 你会怎么样?

A: 嘻嘻，其实没得选呀，只能让自身来贴合老师的风格；我觉得老师的博客中讲的一些师生关系的类型，可能老师觉得不好，但我觉得有可取之处，比如 Buddies/Buddies, Baby-sitter/Babies 等等。每个老师有自己的认识吧，作为学生的我们当然可以提建议，但还是得学会主动配合吧。

至于作业困难的问题，现在已经感受到了【嚎啕大哭】。只能说是尽力吧，用一种迭代的思想，先尽力交付，再不断改进。

Q: 你在这门课的计划是什么？

A: 看完老师提供的资料，我发现这个课真的不是学出来的，而是做出来的。所以计划就是应用一些理论吧，然后多和伙伴们交流，一起learning by doing吧。

三、 阅读《构造之法》，提出问题

1.  P42 ~ P49, 关于单元测试的讨论。

疑惑：单元测试可以很好地保证每一模块的可靠性，但也带来了许多额外的工作。那么在什么样的情况下，单元测试是必要的，有用的？而在哪些情况下，我们又要谨慎使用单元测试？

尝试解答自身疑惑：因为自己从没写过单元测试，在看这一章之前甚至没听过这个名词，所以只能看看其他人的想法了。个人认为知乎上“如何评价不写单元测试的程序员？ - 舒琴的回答”对我是有所帮助的。总体上来说，写单元测试是一种素养，应当养成；一般情况下我们应当做单元测试以保证质量，尤其是一旦出bug会有巨大影响的情况。但同时，如果做单元测试过于影响效率（或者没有好的方法做），可以适当变通，想其他方法来保证代码质量。

2.  P71 "我在某个同学的程序中看到有些变量叫'ILoveXXX', 'SB', 不知道这些变量在现实生活中有没有什么意义"

我的理解：这样的命名很有可能会降低程序的可读性，不利于维护，如果是放在一些正式的项目中那肯定是不合适的。但是如果是在比较个人的项目，我觉得倒还是没什么...毕竟主要的阅读者还是自己，在代码里“寄寓”一些自己的情感也无可非议....

3.  P75 "函数最好有单一的出口"

我的理解：个人认为单一出口原则很有帮助，许多情况下会让程序更加的清晰；但如果为了实现这一个原则而弄得非常麻烦，就没有必要了。我觉得Peter87的这一篇博文就讲得挺好的（百度搜索“单一出口原则”的第一条结果）

4. P118 每日例会的一种可能的发展结果，是大家的发言变成了“我昨天写代码，我今天继续写，我没碰到困难”

我的理解：非常尴尬地发现自己就是这样的“狗熊级的程序员”，在过去的一些经历中，自己经常这么发言...其实一般在这种情况下，真相都是自己都没有很投入到一个任务里面，不然怎么可能真的没碰到困难，没问题想问。书中的两个改进“定义好任务”与“记录完成任务还需要多少时间”对我来说很有意义，因为很多时候我自己一直拖着一些事情没去做，就是因为目标不清、计划不明。

5.  P130 软件匠艺宣言

看了P132的参考资料17，发现很精彩。个人认为“精益求精”的“匠艺精神”是我们应当追求的，但不是我们所唯一追求的。应该说在不同的场景下，着重的东西不同，应当按情况来。

不管怎么样，这个宣言还是给我自己提了个醒：应当有匠人精神，不要只会制造垃圾。