初次开发软件的心得

         寒假走的比较晚，留在实验室里把北京文化系统专家资源系统软件的 2.0 版本做完了。体会很多，最重要的是明白了书本上的学习和实际应用的差距是如此之大，尽管已经有了一些心理准备，但还是觉得自己以前所学仍是皮毛。

        

先说下实际项目和平时书本上东西的区别：

 

1.         代码篇幅：

老师布置的 C 语言作业题难一点的也不过四五十行代码，一个小例子几行代码就搞定了。而项目里做个登录窗体的组件加个身份验证基本就一百多行了，主框架精简后也有八百多行，自己手写的代码共有 2 千多行，这些还不算开发工具自动生成的代码和界面设计的隐藏代码。这么多的内容要很熟悉才行，还要管理好，这算是第一个比较大的改变。

2.         核心算法

平时学习时，编程最关键的就是算法，衡量一个程序员好坏的标准也是看他数据结构学的如何。而这次做项目我发现核心算法也就几十行而已，根本没用到很深奥的数据结构知识。大部分的时间花在接口的处理和界面的美化上面了。当然这不是说算法不重要，在编写底层和大型的软件时，一个程序员的功底就会因他数据结构写的好坏而体现出来了。

3.         知识的更新

这个时候才发现平时学的知识已经过时很多年了，除了一些基本功和基础理论。才拿着项目的时候什么东西对我来说都是新的，都要花一段时间去从头学。后来发现如果每看到一个新的东西都慢慢的从最简单的学起的话，最后根本学不到东西。技术更新我们永远也赶不上，但我们只用把基本功打扎实，任何新技术上手是很快的，看几个例程，自己做个简单的测试程序，这个技术就算学会了，实际做的时候查查参考手册，就可以完成了。其实外面很多所谓的新技术也都是建立在以前的基础理论上面，不外乎包装的好看点，用起来方便点。

 

         再从一个入门程序员的角度说下自己对开发软件的感受：

 

1.         组件开发的模式

做实际的项目由于代码的膨胀，很明显很多我们以前的编程方法就不现实了，比如都写在一个文件里面，甚至像开始学 C 时都放在 main 函数里面。在开始做前就要考虑你的项目是有什么组成的，可以分成几个模块。就说我做这个，就分成了开始启动时的身份验证，语音合成，通知专家的硬件操作，数据库操作和一个用户交互界面。因为硬件部分是另一个老师做的，所以最后是动态链接库的组件。剩下我自己的开始是用 C++ 做成的 DLL ，后来改用 C# 做了，直接写成几个类放在了 exe 文件里面。这几个方式都可以理解成组件开发的模式。

它的好处就是如果一个组件发现了 bug ，只要接口部分不变，那么其它的模块就不用修改。这样我们在测试时很快就能找到问题出在哪。这也是面向对象开发的一个思想，始终呈现给别人是一个接口，而隐藏内部的操作。其它程序员也不用去操心你是怎样去实现的。不过同时接口的处理就变成一个很麻烦的事情，有一次我和那位老师就是因为两个组件参数传递的问题调试两个礼拜的程序才解决。

我们写类当然也不会去关心底层的代码，自己去拨弄指针，去操作链表等等。也都是用微软开发类库，直接在上面开发应用程序。这也是数据结构的知识很少用到一个原因。

2.         调试的能力

其实写程序的时间可能还不到调试代码时间的十分之一，我们大部分的时间都是花在测试程序找 bug 上面了。做商业化的项目不比自己写作业，这里的一个错误就要承担一定的风险，所以平时就需要花很多时间来找错误。然而调试程序也是一门不简单的学问，调试的方法就很多：单步、跳跃、条件命中、追踪变量等等，这些还是有源代码的前提下。如果是别人提供的组件只有二进制文件的话，还得反汇编，自己会分析一大堆枯燥的汇编指令，不过还好这次没有遇到这种情况。有些调试比较方便多试几次也无所谓，而有的调试需要很多测试数据，像这次操作数据库的部分就需要很多专家、项目的测试数据，而且都是只能用一次就必须更新，这样调试就很麻烦，每次都得自己分析很久才运行一次，并争取在一次调试过程中解决问题。

3.         需求分析

这个是我在看书时明白过来的，这是软件工程的第一步。却是我这次开发中问题最多的一个环节，开发一个项目首先要弄清楚客户的需求，并根据这个需求来制定计划，如果需求没弄明白或者不停的变更，那么在后续开发的时候要付出很多代价，甚至重写代码。我自己的主框架代码就重写了两次。以前也没看过软件工程的书，后来看的时候发现了很多问题，不过因为是亲身经历过的，感觉体会更深一些。

现在已经开始为下个项目做准备了。首先是做需求分析，然后用 UML 建模，用系统的方法来开发。