一、First项目地址：https://git.coding.net/yangmx2016011904/First.git
二、问题1:你为什么选择计算机专业？你认为你的条件如何？和这些博主比呢？
既然选择了远方 便只顾风雨兼程
在高考前，对于未来上什么大学，去哪个城市上大学，选择什么专业...这些问题，我似乎没什么特别喜欢的，也没什么特别讨厌的。我的内心有着深深的无力感和不知所措。从小到大的按部就班让我不知道如何选择，我感受到了未来的不确定性。
与博客F博主类似，我也是由于偏科，高考成绩并没有想象中理想，我也没有选择的权利，因此被调剂到了——计算机科学与技术专业。
不如博客F博主的“糊里糊涂”，这个专业并不是我感兴趣并且擅长的，从小学到高中学校的计算机课并没有被重视，所以上大学前，我对计算机的了解并不多，更不用说这个专业。当得知自己的未来可能全部都要与这个专业相关了，我特意上网搜了一下计算机科学与技术。这也是我在上大学前，第一次接触这个专业。
我认为自己是一个不太聪明的人，适应了被老师灌输的讲课方式自我学习能力也不是很强，初入大学遇到了一些困难，但我还算是个愿意努力的人，就像博客B中郎朗说没有所谓的兴趣，兴趣都是练出来的。面对全新的大学我觉得更多的是适应。相比博主，我没有大佬般的天赋和高起点，但我有一颗努力上进的心。正如博客F的博主，从偏科到找到正确的学习方法、专注地学习专业知识，从社团到公司，未来很美好，我们一直在路上。
问题2：你理想中的大学应该是什么样子？
我渴望着这样一所大学，思想自由开放，学科门类齐全，人们不是纯粹为了实用而是因为兴趣而去学习，没有学科界限，不分具体专业，没有必修课程，随时有各类课程，可以自由听课，学习氛围浓厚却不看重成绩，重视全面发展又肯定个人兴趣方向与特长，除了品格与思想培养不强求学生学习哪一科课程，各类大师汇聚，精英云集，谈天说地，无所限制，不否定每一个人，不否定思想。
在我眼里，理想的大学是遇见几个志同道合的朋友，能有一个自由开放的环境，能洒脱不羁的活出自我的地方。
在学我想学的东西，看我喜欢的书，在画我喜欢的画，在睡觉前对第二天充满期待，而不是为了绩点忘记享受我的18岁。
问题3：对于你未来在IT行业的发展，你有什么样的梦想或者未来想从事什么样的工作？你准备怎样来规划你技术道路，职业道路和社会道路？
对于我未来的发展，从我小时候的心愿来说就是成为一名老师，最好的就是能成为一名大学老师，我喜欢学校里的氛围，也喜欢能一直和有活力的年轻人们待在一起。
所以我目前对自己的规划就是认认真真，仔仔细细地学好学校开设的课程，并尽早为考研做准备，同时多看书，多积累。我认为积累是极其重要的。很多博客都分享了很多经验，我认为对我很有帮助。我曾经看过这样一段话“珍惜每一个生命阶段。每一个人的生活都是精彩的，没有必要厚此薄彼，也没有必要给自己太多的打击。每个人独立地拥有时间，也许我很笨，也许我很穷，所以我需要花费比别人更多的宝贵时间，仅此而已，我要的是——享受过程。”每个人的生命都很短，我们的大学生活更是转瞬即逝。。所以我希望自己在以后的日子里，踏踏实实做好眼前的每一件事，能一点一点进步，享受努力的过程。
三、关于《构建之法》的思考
第1章
“什么是好的软件，一些同学认为，所谓好软件，就是软件没有缺陷（bug），所谓软件工程就是把软件中的bug都消灭的过程。这的确抓住了软件工程的一个要素”看到这，引发了我的思考，到底怎样的软件是好的软件？虽然内心里认为有无bug不能作为唯一标准，但在一些软件测试中这一项确实是占比不小的衡量标准。我也通过百度得知了衡量软件质量的5个最常用的指标：SLOC（源代码行，可以使用Metrics工具来统计）；每个代码段/模块/时间段中的bug数；代码覆盖率（单元测试阶段考虑）；设计/开发约束（可维护性，可读性）；圈复杂度（用来衡量一个模块判定结构的复杂程度，已经成为评估软件质量的一个重要标准，能帮助开发者识别难于测试和维护的模块，在成本、进度和性能之间寻求平衡。圈复杂度可以使用pmd工具来自动化计算。）我认为不能过分强调bug数和软件好坏的关系。
第2章
通过代入“小飞”的经历，老师讲解了用VSTS来写单元测试，同时也通过小飞和阿超之口向我们传达了单元测试的重要性。之后又对好的单元测试标准和回归测试进行了讲解。之后我又了解了效能分析工具和两种分析方法，抽样和代码注入，知道了要“先用抽样的方法找到效能瓶颈所在，然后对特定的模块用代码注入的方式进行详细分析”，接下来对个人开发流程做了叙述，从而提出来PSP模型，但在我看来，这样的流程可能就适合那种大佬，能够把握自己做好每一项的时间和花费，而对于一些初出茅庐者并不太适用。同时PSP是依赖于数据的而且是需要工程师输入数据，会不会有些麻烦？
第4章
在本章老师提出来不间断地复审，“结对编程让两个人所写的代码不断地处于“复审”的过程，程序员们能够不断地审核，提高设计和编程质量，可以及时发现并解决问题，避免把问题拖到后面的阶段”，但我想这样的复审，会不会双方都不太了解彼此的程序，同时如果复审效果不好也可能会影响团队进度。同样结对编程中如果双方都不认可对方的看法僵持不下，是不是对工作的进度更加不利？
第7章
章节7提到成员授权和信任问题。如果在实际开发中，当项目开始前所信任的有能力干活的人中途离开了或者在开发过程中这个人遇到技术难题，长时间未解决，其他成员对这个人产生能力质疑时，如何解决这个问题？
第16章
看书本的16章时觉得这章的内容轻松有趣，在有很强的故事性的同时，也蕴含了很多使我们受益的想法。“不要一开始就想着找到并拼对所有的拼图块，以为能够打造一个巨大的创新。”对于这句话我很认同，过于追求结果只会使事不如人愿。一步一步，不急不躁，踏实稳步的走，你会发现，走着走着，你想看到的一切风景，尽在你眼前。但现在这个社会，很多事情都追求一个实效性，而又很多时候过于追求时间上的需求而忽略了质量，怎样能做到二者的平衡呢？