《构建之法》一、二、十六章阅读笔记

 

第一章 概论

程序=数据结构+算法

软件=程序+软件工程

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

在第一章中解释了软件工程与计算机科学发关系，总的来说就是，软件工程的主要是实践方面,计算机科学主要研究理论科学。

 

 

写到（很多同学在报名时不知道它们的区别，进去后发现除了收费高低不同，学的学科差不多，毕业后大多数同学都是写程序，似乎差别不大），同时又很强调计算机科学与软件工程区别还是很大。这些都是事实，可作为本科学生学习感受不到差别，要感受到差别或许得等到研究生，那么本科大学里的软件工程和计算机科学分家的意义是什么？

 

It is not a bug,it is a feature!

Bug这种东西，是万千程序员的痛。生命不止，bug不息。

我认同本书的观点，好软件并不是指没有bug的软件。Bug的存在，也可以推动软件发展。

但同时也有疑问，我们应该如何判断一个bug对于我们开发的软件是利是弊？

对于软件工程我了解得实在太少。希望在学习和实践过程中能有更深的体会吧。

 

 

第二章 个人技术和流程

本章特别特别强调了软件工程开发中，单元测试的重要性。单元测试在团队作战中有着不可忽视的作用。单元测试是我们最需要细心的地方，也是最容易查漏洞的地方。而我们似乎都没有特别的重视它，或许是项目经验不足的缘故。

作者用幽默的语言告诉我们，不可以像对女朋友说“我们只是玩一玩”，对程序说“我只是写着玩一玩”，但是单元测试需要考虑的细节太多，总不能都测试一遍，我们应该如何判定单元测试的主要内容呢？

本章有写个人开发流程PSP，写出了软件工程师的任务清单。同时也写出了大学生vs工程师

 

其实还蛮有感触的，作为学生因为代码练习得不够重点总是放在能不能写出来上，对于一个项目的需求分析和测试总是比较忽略。记得一个项目，做完初稿谜之自信，交给老师看时，总是bug遍地，部分功能未考虑完全（老师是只是说想要什么，说完主要功能，辅助功能要我们自己想），并且是我们反复检查过的，然而很多功能细节被我们忽视了，于是变成了大改动。我觉得大学生和工程师的区别是经验所致。可能做得更多，做得更好。在做项目的时候，感觉我们并非没有做需求分析，对需求分析也很重视，但还是会忽略很多细节。我们应该如何合理安排需求分析呢？

 

 

第十六章 IT 行业的创新

站在巨人的肩膀上，看得更远。

本章提出了很多迷思，我也很有感触。创新是积极的，创新是上进的，创新之路也是漫漫的。

我认为，像阿基米德和牛顿对于浮力和万有引力这样创新的机会不多了。这还是自然科学，而对于IT，这是一门充满人类智慧的美学。其实第一章用飞机类比软件开发，我觉得不妥。我认为用飞机类比整个软件行业更为合适。从打孔条到人工智能的进步，是一代代人的努力。

没有什么比电气工程，软件工程，土木工程等等工程更能代表人类的伟大。每一门工程学科的进步都是人类智慧的结果。

创新是一个矛盾的美学。创新带来的变革是巨大的，同时成本或许是惨烈的。美团和饿了么的诞生使得传统方便面失宠，大量游戏诞生使得政府不得不加强管制。百度作为老牌it巨头却几次创新失利，百度空间，俱乐部纷纷关停。

对于IT公司来说，创新意味着付出金钱或更多，不敢轻易创新。而小公司或许有创新之意却无奈并没有足够资本去支持。

感觉创新，只有大公司的力量可以和传统桎梏相对抗，那么我们作为小小的个人，该如何去思考小小的创新呢？

正好我们现在经历着大学生创新创业计划，在筹备的时候，我们的老师有告诉我们现在创新区想出一个大家都没有想到的东西其实特别难，但是去做别人没有做好的事情无异于也是一种创新。我也这么认为，我们所思所想都是站在巨人的肩膀上，更上一层楼。

迷思中也提到很多创新的阻碍，但是历史终将告诉我们，谁是匆匆过客，谁能笑到后来。