阅读《构建之法》所得与初步思考

写在前面

　　虽然身在软件工程专业已经一年半有余了，但由于一直以来所学的课程基本都是基础课程，没有太多的专业色彩，所以我对于本专业的认识也就比较浅显，这门课程可以说是全面展示本专业特色的一门课程了，在阅读过邹欣老师的《构建之法》后，我对本专业到底是什么，到底与计算机专业有什么区别有了充分的了解，而且对于行业内的许多其他知识也有了很大收获，所以记述了我的阅读所得和在多次阅读后的一些思考和疑惑。

第一章  概论

　　在进入大学学习软件工程之后，我一直有一个问题不是很明白，就是软件工程专业与计算机科学与信息技术专业到底有什么不同之处？看着两个专业相似的课程安排，我更加疑惑了，既然两个专业如此相近，那么设立“软件工程”这个新学科的意义又在哪里呢？通过阅读《构建之法》第一章 概论，使我对这个问题有了清晰的了解。

　　在本章之初，作者就指出：“软件=程序+软件工程”，看到这里，我就意识到软件工程和计算机科学与技术肯定是有不同之处的，不然为什么这里偏偏使用了“软件工程”一词呢？接下来我就通过了阿超的例子对“软件工程”到底是什么有了初步的了解。原来想要做出一个软件，不仅仅是要编写程序，还要有需求分析，软件架构，配置管理等等步骤，还要兼顾用户体验，软件维护，国际化和本土化等等方面，这些着实与计算机科学有很大的差异，毕竟这些方面都是应用于我们实际生活中的，和人的行为、现实社会的需求息息相关，与纯理论就相差甚远了。

　　但是通过阅读这一部分内容，使我产生了一个疑问，那就是：一个成功的，可盈利的软件，必须具备哪些条件？

 

　　程序（算法、数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。

　　程序=数据结构+算法

　　软件=程序+软件工程

　　软件企业=软件+商业模式

　　

　　网上的答案是这样的：

　　一、App设计
　　做一个产品首先要有好的idea,要去搞明白，这款APP的使用者是谁（市场定位），为使用者解决什么样的问题（核心价值），怎么解决（产品功能），有没 有替代方案（竞争分析），为APP的拥有者带来什么好处（商业模式），怎么让目标使用者接触并安装使用这款APP（推广营销）……
　　二、用户体验
　　要拿出方案，使用者的使用场景是什么，态度是什么，哪些是核心功能，哪些是保健功能，哪些是边缘功能，最佳操作路径怎么建立，如何将功能分布到页面上，界面应该是什么风格和样式。
　　三、程序员
　　1、语言基础：Objective-C语言、xcode开发环境；2、手机使用经验：足够的iPhone使用经验与体会，不然你很难与产品经理和设计人员有效沟通；3、具体的开发能力：主要的开发将集中于界面开发、一定的数据库开发、通讯接口开发、协同开发与联调，如果是游戏，那么还需要涉及到引擎、建模、素材、光影、故事板等。

 　　但我现在对于这个问题还是有点不是特别明了。

　　接下来通过阅读对飞机的发展历程：纸飞机—>业余爱好“飞屋”—>莱特兄弟的飞机—>商用飞机 的讲解，和以飞机安全功能的设置与否的例子，我对于程序与软件的区别也有了初步的了解。

　　接下来的内容中，我从“软件工程”的定义这个方面更加规范和具体地了解了我所在的专业，更加全面的知道了软件工程与计算机科学的区别和联系。

 

　　看到书中引用的这段话，使我对“工程”的特殊性有了进一步的认识：

　　“工程”与其他类的学科的最大的不同就在于，其他学科是在发现已有的一些规律或者真理，而“工程”的核心是创造，是发明世上没有的，新的东西。

　　通过本章最后的讲解，我对本课程将要学习的内容也有了清晰的了解，这让我在学习过程中更加明晰目标，也让我对这门课程充满了期待，希望自己能有许多收获。

 

第二章  个人技术和流程

　　经过第一章对软件工程的讲解，已经勾起了我们成为一个成功的软件工程师的热情，但是怎样才能称之为合格的，甚至于好的软件工程师呢？在第二章里，作者讲解了一个合格的软件工程师需要知道的概念和技术，为我们成为一个合格的软件工程师提供了条件。

　　经过第一章的概论，我知道了想要做出来一款软件，尤其是相对比较复杂的软件，是离不开团队协作，离不开人与人的配合的。所以在工作中一定会出现一个人负责的部分代码会被其他人所调用，但是这个时候就会出现许多问题，这是因为每一个人对一段代码的理解大都各不相同，那么应该如何解决这个问题呢？邹欣老师提出了单元测试。

　　通过代入“小飞”的经历，邹老师讲解了用VSTS来写单元测试，同时也通过小飞和阿超之口向我们传达了单元测试的重要性【详见第三版《构建之法》P.25两人的对话】。之后又对好的单元测试标准和回归测试进行了讲解。

　　之后我有了解了效能分析工具和两种分析方法，抽样和代码注入，知道了要“先用抽样的方法找到效能瓶颈所在，然后对特定的模块用代码注入的方式进行详细分析”

　　接下来本书对个人开发流程做了详述，详见下图，所以我的问题就来了：这些步骤非常繁琐，如果所开发的项目十分简单的话，那还有必要遵守每一个步骤吗？

　　然而对于这个问题我在网上并没有找到相应的回答。

 

　　另外我还有一个疑问，对于下图中黄色部分的差异，书中得出的结论是

显然，从学生到职业程序员，并不是更加没完没了的写程序——花在写代码的时间上反而少了很多

　　而我认为造成这个结果的原因是职业程序员比一个学生在怎样写程序更方便快捷方面，有更多的经验，而且也应该更加熟悉写程序，毕竟他们整天的工作就是写程序，而学生每天要做的事就相对比较杂了，对如何写程序会较为生疏一些，而不仅仅是二者对于写代码的重视程度不同。

第十六章  IT行业的创新

　　在这一章里，邹欣老师主要讲了关于IT行业内的关于创新的一些问题和现象，众所周知，IT行业是一个充满了创新的行业，在阅读这一章之后，我发现我对于创新确实有许多误解。比如：我之前一直以为创新这么好肯定是所有人都喜欢的，但是经过学习，我发现确实会有一些人会因为或是损害自己的利益或是挑战自己的面子等而不欢迎创新；或是我一直以为创新肯定靠的是技术，但是看了铱星计划的手机这个例子，我惊觉用户对于创新的作用也是巨大的；还有，在我心目中创新的人一定是最具有冒险精神的人，但是经过书中的讲解，我恍然大悟，创新并不代表冒险，而是意味着愈挫愈勇，强烈的好奇心，自学能力强，不在乎面子和价值观坚定。除了这些，我还了解了技术成熟的过程，创新的一些招数等有用的知识。

　　但是在这一章的最后一部分里邹老师谈了对“作坊”这个模式的看法，虽然小标题看起来是这种模式存在的问题：

3.只做某种行业，不太改行，商业技巧比较缺乏

4.不太做广告，主要靠口口相传，容易被技术进步所淘汰

……

 　　但是细读内容，可以看出邹老师对“作坊”这个模式是持正面态度的。

　　我从网络上查找相关释义，觉得手工作坊的含义更为贴切：封建社会城市中的手工业生产的基本单位。手工作坊主拥有私有的生产资料，分散经营，以本人的手工劳动为主要的生活来源，一般不雇佣工人，只有做辅助性工作的帮工和学徒。帮工、学徒没有工资，仅有维持生计的微薄报酬。

　　加上我对作坊的一贯印象就是规模小，私人的，所以我对于这种模式是否完全是好处产生了疑问。我感觉这种“作坊”模式在当今商业领域内的抗风险能力有点小，可能因为一个软件的失误的亏损就无法继续运作，所以我认为这种模式的好坏见仁见智，是否应该大力提倡也是值得思考的，不能一概而论（比如在大公司内设立这种小的精研各个方向的“作坊”我觉得不错）。