软件工程这个名词，在我进大学之前心中都只有一个很模糊的概念，但是我对他充满了好奇，是不是学会了以后就可以像电影里面一样破解什么国家机关的什么机密或是入侵什么系统之类的充满形式感而又帅气十足的那种样子，又或者是玩游戏不用花一分钱而体验感十足，外挂随便开但封号不存在呢？就这样在心中怀揣着如此美好的憧憬，我的高考第一志愿选了它，并且顺利的进入了我“梦寐以求”的专业。

两年多以后。。。。。。

经过了在大学的几年摸爬打滚，想想自己当初选这门专业的动机是多么的草率而幼稚，但却又不是。至少我现在还一直坚持认为我那幼稚的想法其实还都是可以实现的，只是时间、精力、和耐心的问题罢了。软件工程这个领域的范围很大很大很大，涉及的知识很多很多很多，任何一个很小的方面都值得你花上大把的时间去钻研(如果想要走在最前沿的话)。

目前我所认识到的问题的解决方法似乎都可以归结到写代码上面来，可以使各种语言的代码，c、c++、java、PHP、c#，Python。。。。。。

但是写代码又有很多很多的讲究，软件工程这个领域的任何设计都与软件紧密联系，写出一手好的代码，设计出一个好的软件真的很难很难。就比如我在上学期修过一门课程叫做软件工程导论，老师要求我们分组设计软件，其实根据软件的需求分析它的实现方法理论上好像特别特别的简单，但是实际动手过程中却会遇到各种各样的问题，抛开开发工具给我们开发者带来的困扰以外，最难受的就是找BUG了。

干软件这行的要是说自己不会DEBUG都不好意思说自己是程序员，DEBUG也是一门学问，他有很多的技巧，我个人认为一个有经验的程序员都是被BUG磨平了棱角的、圆滑的可以直接根据程序的报错特征以及一些返回信息直接定位到错误的位置或者多错误有个大致的了解，而不会半天摸不着头脑。这是我最崇拜的程序员了，但是要做到这些何谈容易，她只能靠自己不断地犯错然后不断地发现错误，一步一步的成长，慢慢的累积经验，记住“教训”。

其实回过头来想想那些解决的BUG都是自己“手贱”，如果自己能够很好地掌握设计模式或者遵守一些写代码的规则以及规范，很多很多的BUG都是可以避免的。事实就是我们这种半杯水的程序员, 非得硬刚，自己却没有很好地知识理论武装自己，只是清楚一点编译器的语法规则而已，以为付出了时间和精力就会相应的收到更多的回报，殊不知这是在为将来的自己埋下了一颗原子弹。

说起用知识武装自己，写出一手好的代码，其实就是多学，多看，就会长见识了。学习了数据结构让我们写代码有了一点章法，知道了为了达到目的可以有一些高效的简单的方法，或者有某些解决某种复杂问题的奇妙方法，这在我们后来学习计算机算法的时候有了进一步的深入了解；学习数字逻辑让我们知道了软件如何与硬件结合，特别是如何驱动硬件工作，达到某种既定的目的；学习了操作系统我们知道了程序在运行的时候是被怎么管理起来的，资源怎么被分配给程序的等等；学习了深入理解计算机系统我们知道了计算机的体系结构、程序的运行原理和机制，他的结构等等；学习了数据库系统似乎给我们打开了另一片广阔的天空，他并非旨在帮助我们设计更好的程序，而是帮助我们更好的进行程序之间的数据交流，数据共享等等。

至于我们下学期的专业选修我觉得才是重点，设计模式可以帮我们更好的设计程序，减少BUG，提高效率，可用性，可读性，编程的难度系数也会大大降低，但是由于全英文教学，已经被我弃选了，但是不得不说它是一门受益无穷的课程！！！而下学期即将开设的编译原理把我们的高级语言代码和程序紧密的联系在了一起，当我们明白了编译器的结构和原理以后，他报错我们就能更好的去把握这个错误了，并且还能够从编译器的角度写一写编译器友好型代码，最重要的是能够揭开我们多年的困惑，那些高级语言的语法规则为什么要求这样或是那样，编译器是怎么解析这些代码的？毕竟我们在未来的几十年里，都会要一直用它作为我们的开发工具(不过一般都被集成到某一个大型的软件里面了–IDE)。

根据以上种种原因，在软件行业、当一名程序员很简单，只要会简单的语法规则，能够写出编译器能够识别的、行为正确的代码就行；但是当一名优秀的程序员很难很难很难，它需要我们不断的用理论知识武装自己，并且还需要紧跟时代的步伐，“与时俱进”。