假期作业——《构建之法》初读后感

今天把《构建之法》看完了，到后面就有点着急，急于求成那种，看的比较水。整体也是看的比较水，很多概念只是看了看的了解，主要也是一堆词都没接触过。主要还是想说这一遍只是通读，去了解。里面很多思想都要仔细感悟，并要与实践结合。以后还是要再读的，也确实感觉值得反复去读。很给人启发。

就我现在的情况的话，我写的只能称之为程序。就如同书中所说，我只是在弄模型，而软件工程的行业，做出来的是实实在在的软件。而书也是写的软件工程，给我的感觉，就好像是井底之蛙突然看见了海吧。有一种格局打开的心情，感觉了解到了自己以后会怎么干，该怎么干。回到自己当下，自己只是搞模型，而且模型也是搞不好。大一的一年中，编写的程序并不多，更多的是应付。说道自己过去怎么做，无非就是看看书，按着书上的知识点去编写简单的程序。至于真像开发软件一样去写文档，想需求，设计开发，然后测试什么的，完全没有过。偶尔好一点的话，最多是有看了题目想想怎么求解，写完运行一下，看看程序能不能跑。勉勉强强算是设计、测试。而团队协作，彻底无从体验。

至于说这样的不好。第一或许就是一直在懒着学，看着课本，懂了之后写写例子，理解个差不多。从没有熟练的掌握，或者说精通一门技术。就像书中举的玩魔方的例子，只是看口诀，记口诀。没有太多的实际问题解决。到了最后，我的技术或许并不能解决问题。如果真完全记住了也是好的，自己连这种境界都没有达到。最后，自己就是书中说的，把时间花费在解决低层次问题上。这样的我，肯定是无法进入市场的。第二就是编程习惯的问题吧。大家都没有团队协作过，一直都是自己编自己的代码，编程习惯，可能并不好。这样去了团队，别人看不懂自己的代码，又怎么去测验？就是别人不看，到时候自己回头改，或许也就看不懂了。第三就是前后的工作吧，虽然是模型，写的只是个程序，但也应该想好现实中怎么干，在现实中解决后再把其转化为代码。虽然自己也有在想，编写之前思考该怎么写，写完了也会运行。不过这都是正常人都会干的。而像书中说的话，像软工人该做的去做的话，那应该是写之前有明确思路的，是从头到尾大致认为可行的，都想过的。运行也不是只简单的去运行，而应该能查bug，能改正自己的代码。有的同学遇见bug不会调，有的同学却知道怎么用注释的方法找bug。测试的方法更多，模型也应该有测试。如果仅我那样，编写代码前不完全的去想，那编写确实是对时间的一种浪费。不能调试，不会调试，那根本就写不出来能运行的程序，写出来了，又怎么证明能满足客户需求？模型和软件实体，本来就是有共性的啊！

仔细想想，所犯的导论课老师都提到过，自己以为自己注意了，回头一看，好多问题并没有自己想的那么简单。问题一要去解决，我想还是多去熟悉，反复实践。就像书中说的，通过不断的练习，把低层次的问题都解决了。另外学习技术也要明白是要解决问题的，怎么叫掌握技术，精通技术？不仅要记住，不仅要知其所以然，还要能解决问题。三者缺一不可。那就离不开学习，练习，实践解决问题。问题二要去解决的话，肯定是自己注意编程习惯。原来曾问过别人代码，当时就明白了代码风格的规范很重要。不过还是编写过程中遇到一些英文不会拼写，然后就命名随便的问题，还是说不能去拖延，遇到困难立刻解决吧。问题三就是前后工作都处理好，提前想好，学会调试。磨刀不误砍柴工！

至此还是感觉自己只是模型阶段，对软件工程接触不深。很多问题不是没有，是没遇到，没发觉到。通读了一遍之后，也只是对软件工程有了初步的了解，对开发软件的流程有了一定的熟悉。甚至来说，对老师所留作业中所说的过去怎么做，如何不好，怎么改还是不太明白深意。模型和实际开发，还是感觉不一样。我只是模型，又怎么从实际开发中悟出实际开发的经验呢？老师的问题是要一直思考下去的，软件工程，想必才刚刚开始吧...

至于软件=程序+软件工程。软件企业=软件+商业模式。软件质量=程序质量+软件工程质量。我感觉很有启发性，概括性。想说发现这三个公式已经说完了...从实践中感悟吧！