《构建之法》读后感

  软件工程，我之所以选择这个专业是感觉自己编出来一个可以实现我想要的目的的程序蛮好玩的，从未想过，什么是软件工程，除了敲一敲代码还要干什么。入学一年来除了基本的数学英语之类，就学了C和C++这两种语言。

而书中给出了“软件=程序+软件工程”。编程全在程序里了，软件工程，软件、的、工程，重在工程二字，体现了它是一项工程。那软件工程又要做什么呢？学编程跟它又有什么关系呢？为了不当一个门外汉的管理者？

“软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。包括领域：软件需求分析、软件设计、软件构建、软件测试、和软件维护。”

  读完全书后，再回过头来看定义，发现还真就是这几件事。

  开发一个软件，需要以个团队，一个团队有很多人，恩多了就会有很多事。如何沟通，如何分配任务，如何保证高效的工作……

  沟通是个问题，尤其是和客户沟通。最大的感觉就是，怎么知道用户的需求，真的是好麻烦啊！用户居然有时候自己都不知道自己的需求是什么！或者，还会变来变去！顾客就是上帝，还能怎么着？改！

  但是，什么是好的软件？取决于做出来一个软件的目的是什么，而大多数软件都是为客户服务的，客户花钱来要求软件公司来实现某个需求，比如医院等的信息管理系统；或是软件公司，做出满足某个需求的软件卖给客户比如视频剪辑软件、数据库软件。“build to win”正是本书的名字。

  对于我来说，从未想过这个问题，需求是什么？老师的作业写得一清二楚，用什么方法，实现对什么的什么，其中……而且程序很短，大多几十行，不需要提前画个流程图、不需要一部分一部分的测试、不需要去想交完作业后这个程序还能怎么着。

  对于循环不确定循环几次，推演麻烦了干脆直接调试，根据结果改。出了错误就一行行检查，或是看错误输出显示是哪一行，最多再用调试，加个断点什么的。毕竟总共就那点东西，老师出的题也是最基础的知识。顶多在函数、类比较多的时候，写几个就运行一下，成功了在继续写，一直细心检查是不可能的。但如果哪里出错……可真的就是抓破脑袋也找不到了。

  这是个很不好的习惯，我大一一年一直作为老师的助理，上机课前做好作业，上课就负责帮同学们解决编程的问题，结合这些经验，让我深有感触。

分号、括号等用成了全角，头文件里类的构造函数没有相应的，某个单词拼写错误……有时错误输出可能多达几十行，且每一个都是看起来风马牛不相及。看老师解决几次后，我也学会了几招，比如把main函数除return 0全部注释掉，把不必要的成员函数注释掉，再一步步取消注释，看什么时候会出错。

  现在来看，这其实就是再把时间倒退，是编程者之前应该干而没有干的事——确保每一块都是对的。

  C语言主要就是围绕函数，有时我图省事，会让一个函数执行多个功能——反正主函数看着整洁就OK了。这很明显是不符合规范的，函数——就是要执行一个功能到最好。

  更为省事的是，一我不写注释，二，我的变量名从a开始排，排到几算几，函数名也是最简的描述。

  大一上学期学C语言时，老师展示过一个输出日历的程序，我觉得好玩，自己花了一个周末写完，又陆陆续续改了几天，直到满意。到下学期学C++时，老师让写了一个日期类，最后附加题是按日历的格式输出。我暗自高兴，我早就写过了，直接复制粘贴过来，对一对参数，把scanf、printf，改成cin、cout就行了！

  然而，打开之后我发现自己看不懂了……参数a,b,c都是什么东西？这个参数从哪传到哪的？最要命的是，我当时不知道算某一天是星期几是有现成公式可以套的，所以当做数学题来解，计算步骤很多……

  最终我花了一晚上来研究我自己的代码。看似当初省了时间其实是得不偿失。幸好我当时脑子一抽，把每一个运算放到了单独的函数里，分的很详细一个函数只管一件事，否则更是一团乱麻看不懂（在当时我自己看来就是脑子抽了闲着没事才这样做，虽然这是个正确的做法）。

  看完书，才知道老师课件中那长长的写着超烦的变量名、函数名有什么用。为什么类名首字母要大写，每次都要按shift感觉很烦。命名是有规范的（规范具体是什么不在赘述），程序不止要让自己看懂，还要方便别人去读，必要的注释也尤为重要。

  而且总是敲了没几行就开始纠结一些小问题，这里是输入正数，万一输入负数怎么办？虽然输入负数程序照常运行，但就不符合题意了，要不要加一个dowhile循环？可这样会不会显得程序太长，相似的输入还有好几个……

总而言之，要检查一个模块无误后再写下一个，要写注释，要写输入提示，要好好用英语去取变量名，不要过早去纠结一些小问题。

  不要嫌麻烦！！！