谈构建之法之前，先回答老师的几个问题~
1.我本科专业是物联网工程，四年间的学习内容一直处于软硬件间摇摆，一度使我怀疑人生。这种学习方式最大的好处是可以从底层理解整个计算机的运作，循序渐进，而最大的缺点是，体系太过于庞大，低效，冗杂。当我到了大三的时候，我依然不能够独立编写一些软件，也不能处理有意义的硬件问题，所以当务之急便是做出取舍，否则我的大学可能就止步于C语言和单片机了。几经周折，最后还是选定了偏向软件的方向，原因众多，硬件的学习难度和深度让我苦不堪言，对数模电，通信原理，高频电路亦有较高要求，而周边同学也大多偏软，大环境下，软件是占有优势的，所以最终还是选择了偏向软件的计算机专业读研。自认为本人资质普通，但对生活兴趣高涨，有生之年如若再有机会，还是愿意将丢掉的硬件知识再次捡起，毕竟当年学的很痛苦...
2.在做出一个大方向的转折之后（选择偏向软件方面），问题依然重重，一个具体的专业是很重要的。计算机发展史虽短，但也体系庞大，门类众多。兴趣任然是生活的导向，本科实习期间有过一个Unity的小的项目，让我对图像，游戏方面有兴趣，最后读研也是选择了图形图像方面。至于擅不擅长计算机领域，怎么说呢，我学了四年物联网，也算是计算机相关吧，加上平日的一些积累，相比于其他的技能，应该是蛮擅长的吧...
3.对一名合格的计算机专业的硕士研究生，我们的培养方案里是这样说的：
关于差距，我自己的看法是，在专业知识方面不够深入，目前还不具备独立从事计算机应用工程的开发能力，对专业前沿的信息不够清楚，外语能力也需提高。相信通过三年的学习情况会大为改善。
4.初来不久，同学们卧虎藏龙，我对他们还是不够十分的了解。只能谈谈我的自以为是，我本科期间我还算兴趣广泛，学习过C/C++,写过几个小的项目，用Unity做过简陋的游戏，了解一点C#，写过静态网页HTML/css，了解一点js，但没有用过，毕设开发一个APP，所以懂点Java和Android，用Python写过内涵网的爬虫，看过鸟哥的Linux私房菜，能简单操作Linux系统，能在Linux在进行简单的网络编程，和多线程/进程编程。若日后能用到这技能，那可能也是我的一点小小优势，然而劣势是，我会的都不太深入，与有深入学习的同学相比，我可能还没有入门。。。
5.三年规划：学习所需课程；完成一些项目，延伸学习项目中的一些技术；多读一些前沿论文，发表论文，顺利毕业；找个实习，毕业后找到个回报好点的工作。。。
以上信息纯手打（图片除外），真实可靠，人艰不拆，不喜勿喷，谢谢！
《构建之法》笔记
诚实守信是科学严谨和求真务实，这书我没全部看完。
从简单的编写一段代码，到一个软件工程，隔着一本《构建之法》。软件工程的目标是创建“足够好”的软件，在开发流程中又有5点特别的难题：复杂性，不可见性，易变性，服从性，非连续性。
复杂性：现代软件的规模都非常巨大，动辄超百万行代码，上万个文件，用以满足大规模用户的不同的复杂的要求和良好的用户体验。软件的各个模块之间有各种显性或隐性的依赖关系，随着系统成长和模块的增多，这些关系的数量往往以几何级数的速度增长，而理解这些复杂性的人却没有太大变化。软件团队的成员每天都在修改各种源码，在维护软件修改过程中维持和提高质量是一个很大的挑战，需要高效的源码管理和软件测试。
不可见性：软件以机器码的形式在计算机上运行，还可能在多核上运行，工程师是根本无法看到自己的源码是如何被执行的，一旦出现错误，只能看到出错的一瞬间留下的蛛丝马迹（错误代号，目标代码的大致位置，错误信息等），几乎无法完整重现程序的错误。
易变性：软件的更新迭代速度也在随着用户需要快速改变而进行，同事软件还要适应新的硬件基础，正确的修改软件也十分的困难。
服从性：软件并不独立，它必须服从于系统，硬件，用户甚至行业要求。
非连续性：人们比较容易接受连续性系统，增加输入，就能看到相应的输出增加。但要保持这样的特性越来越困难，大多时候，输入上很小的变化，就会引起输出上极大的变化。
在个人开发中，必须要遵循一定的流程来管理开发活动，这也是软件工程师在软件生命周期所做的工作流程。软件是由各种模块组成的，各个模块之间需要定义尽量明确，模块内部的改变不会影响其他的模块。单元测试是这些模块的质量稳定的，量化的保证。单元测试是指对软件中最小的可测试单元进行测试和检查，在最基本的功能上验证程序的正确性。好的单元测试标准为：由程序作者来编写测试代码；测试过后，机器状态保持不变；测试过程要快；测试结果为一致的，可重复的；保持独立性；测试覆盖所有代码路径。在单元测试的基础上，就能够建立这一模块的回归测试。当模块在构建一个新的功能时，有时会出现从稳定状态到不正常工作的“退步”，在一个模块功能完善的同时，与此的测试用例也在完善。而一个模块的单元测试便是这个模块最初的基准线（Baseline）。例如模块A的123测试用例通过了，打在新的版本中，改测试用例失败了，这便是一个“退步”，工程师们应该在新版本上测试所有已通过用例，验证是否“退步”。这个过程便是回归测试。然后便是软件的效能分析，以使自己的程序更加的高效。在效能分析中，通常采用抽样和代码注入来检测和分析代码在运行中的各项参数（运行时间，运行次数，内存开销等），对代码进行优化。
在多人合作中，代码的规范变得很重要，在开发的初期，便要代码风格，设计规范做出详细讨论，最后还需代码复审来增强程序的鲁棒性。在开发流程中我推荐也是普遍采用的敏捷流程，敏捷流程的开发原则是：
尽早持续的交付有价值的软件满足客户需求
欢迎需求变化，以此调高竞争力
经常发布可用的软件
业务人员和开发人员共同工作
项目核心为有进取心的人
面对面交流
步骤为：找出产品的当下所需，冲刺所需解决的问题，然后冲刺，最后得出软件的一个增量版本。
一款真正的软件，要经历需求分析，确定项目经理，确定典型用户和场景，软件设计与实现，用户体验设计，然后通过软件测试进行质量保证，直到稳定然后发布。这一整套的流程当需依据确定的项目来进行设计和调整。而这些思路正是《构建之法》教给我们的。