今天阅读了邹欣老师的《构建之法：现代软件工程》的第一章，也回想起了我之前对于软件和硬件的一些思考，在这里一并总结。
首先谈软件工程，在计算机技术刚刚发明的时候，跟其他的行业一样，肯定是没有工程这个概念的。肯特.柯西做热气球的时候如果还要想想这个热气球除了飞上天，还要不要能在上面做个饭睡个觉啥的（需求分析），要不要绘制模型，然后规范加工生产（构建管理），进而涉及到热气球的版本——什么时候发布热气球2.0（版本控制），然后怎么把我的热气球推广出去（推广），除非他对飞上天特别狂热，不然面对这么多繁杂的事物，我想他应该喝口水冷静一下，就会觉得或许把跑步作为个爱好会不会更简单点？事实上，他一开始只是单纯追随自己的爱好：我能不能也飞到天上去玩一下？然后他就开始去做了，搭一个热气球，能飞起来，可以了。
我在写第一行代码的时候，纯粹是因为好奇，把程序当作玩具，为什么我这样做就出现了一个hello world？挺有意思。然后如果有了兴趣会继续去看看为什么会这样，如果我想做到更多的事情会怎样，所以接下来的时间我基本上就是接触c++的各种功能，各种实现，这样过了一段时间之后我反而觉得它不好玩了，因为我需要记住太多的束缚，我必须这样写，该死的编译器才不会报错，我才有机会能够看到我预期的输出。
后来我慢慢开始发现其实代码是有意义的，它不只是能够看个输出，看个结果，它能通过与硬件结合然后实现某些功能，从而成为我们的一种工具。但是问题也来了：作为工具之后的代码，我希望它能够在一定的时间内实现某种功能，但是由于我杂乱无章的操作，我的代码更像是纯粹的堆砌，有时候自己会花很多时间去理解，自己前段时间写的这个功能到底是要干嘛？这种不好的编程习惯直接导致了编程效率的降低。而且我的程序只是个小程序，难道大公司的程序都是像我这样写出来的么？
后来也经过一段时间的思考，碰壁，甚至有时候觉得编程没什么意思，最后又重新捡起来，形成了我目前的“代码观”：
1、永远要以解决问题为导向，以前如果让我做一个51单片机的串口通信，我会从流水灯开始学起，虽然没什么用，但是我觉得这样才系统。现在我不这样想，我要做什么，我就去了解什么，这样才是最直接的方法。要学会说话并不要求你会走路，虽然你知道，会走路和会说话对人来说都同等重要。
2、软件工程与机械工程都一样，是解决问题的一个规范，这是由于前人在解决问题的时候总结出来，这样去解决问题是最稳妥的，最高效的，它不仅面对了这个问题，而且考虑了这个问题的各个方面，不光是完成功能，更有进一步的完善。这样才是完整的解决了这个问题。所以学习软件工程的流程很重要，因为迟早你会遇到这样的问题，与其到那时候才发现：哦，原来用软件工程的这个流程去做就可以规避这样的问题。还不如现在就这样去做，尽可能少地碰到问题。
3、你知道你面临的BUG有一天肯定会被你解决的，解决的方案才是最重要的。这是《黑客与画家》中的观点，我觉得很有道理，但是具体经验还不足，所以体会并不深。
关于为什么要学习软件工程，也在上面回答了，因为它很有用，所以要学习。
软件工程方法和机械工程方法我认为没有本质区别，其实都是为了解决问题。
学习这门课程我的安排是这样：首先认真上课，听懂老师的安排和要求，更多的时间会在课下去写代码。通过这门课我也有自己要完成的目标：
1、软件工程的流程我希望我能掌握，而且在研究生阶段我会去实践，我觉得这个很重要。
2、进入开源世界，用好github，多看别人的代码，也多思考，多运用。
3、一定的编程语言和编程思想的拓展。
PS：这是我的第一篇博客，写得重点不是很突出，博客这个东西是一个好的总结，也很有意义，我会试着多记录自己得到的东西。不过写这个也很花时间，所以要权衡，把什么东西都写出来，学得太慢。