《构建之法》第1、2、16章阅读随笔

第一章：概论

有一个朋友问我：“你们软件工程和计算机的课表差不多，你们有c有Java，他们也有，你们要学计算机组成原理，他们也要学，有什么区别吗？”大一我还真的无法回答，我只知道我们学费是他们三倍，但是学的课程差不多，师资也差不多，甚至一样的老师。读了第一章有了一定的认识。

问题：那么我们为什么有那么多一样的学科？

思考：科学家和工程师的区别：一个是回答why的问题，一个是回答how的问题;一个培养的能力是ask/answer why，一个培养的能力是know-how.那么我们为什么有那么多一样的学科？我想两个原因分别是软件需要一些计算机科学中的相应知识和对于以后又多一条选择之路。

第二章：个人技术和流程

 

问题1：什么是单元测试？

 

百度答案：单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。 单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

 

问题2：优秀的资深的程序员是否可以不做单元测试 ？

答案：在真实世界里，每个人都会犯错误。即使某个开发人员可以抱着这种态度在很少的一些简单的程序中应付过去。 但真正的软件系统是非常复杂的。真正的软件系统不可以寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。 编码不是一个可以一次性通过的过程。在真实世界中，软件产品必须进行维护以对操作需求的改变作出反应， 并且要对最初的开发工作遗留下来的Bug进行修改。你希望依靠那些原始作者进行修改吗？ 这些制造出这些未经测试的原始代码的资深专家们还会继续在其他地方制造这样的代码。在开发人员做出修改后进行可重复的单元测试可以避免产生那些令人不快的负作用。

我的思考：繁琐的步骤是不能侥幸省略的，人非圣贤，如果那些省略的步骤正好能规避麻烦，你恰好省略了，那么将造成系统的麻烦。

 

 第十六章  IT行业的创新

说到创新，我反应是现在的软件基本能够满足我们的需要，创新是很难了，除非是有很大的技术飞跃。通过对各种现有技术的有效集成，形成有市场竞争力的产品也是一种很好的方法，比如美团，从外卖到旅游，可以吃喝玩乐，还能买机票。支付宝也具有越来越多的功能，也是一条集成化的道路。

“不太做广告，主要靠口口相传，容易被技术进步淘汰”，的确作坊会被技术进步淘汰，因为他没有大公司的实力。比如说现在很火的“吃鸡”，感觉他就是找了一群忠实的粉丝，然后靠这群人来扩散，然后就形成了如果你不吃鸡你就out了的形势，这是一种成功的手段。创新要把握时机，否则面对的是风险和淘汰。