做软件项目，只要知道计算机编程语言就可以做开发的工作了吗？

最近一直在思考一个问题：做软件项目，只要知道计算机编程语言就可以做开发的工作了吗？
以下是我的整个思考过程(从开发人员角度思考)：
----------------------------------------------------------------------------------------------------------------------

首先分析一下我们现在的开发过程。我这里概括为四步走原则：
第一步：需求分析
拿到一份requirement之后，先要从业务逻辑角度去理解吃透这份requirement文档，这个过程当中需要和谈需求的人员一起反复交流讨论，直到完全理解了其中的业务流程和逻辑，不然一旦需求理解错误，后续的开发工作将都成为无用功。
这个步骤当中最最重要的就是和USER谈清楚需求，这个需要非常扎实的业务逻辑和行业经验，不然不可能理解USER的意图和USER所提出的需求的意思！

第二步：详细设计
这一步的主要任务是把理解后的业务逻辑转换成程序逻辑。在这一步中首先要从系统的整体上把握住需求的重点和难点，从系统出发理出逻辑，画出流程图，时序图，数据状态转换图，找出需要新增哪些文件，需要修改哪些文件，怎么新增或者修改对原来的系统影响最少，并且还要考虑系统error handling的机制，直到把整个需求描述当中的业务逻辑完全翻译成计算机的程序逻辑为止。
在这个步骤当中最最重要的是要充分熟悉原本的系统，摸透理清原本系统的逻辑和架构，不然的话，从哪里着手、哪个是突破口都很难找到。
这个步骤当中需要和业务逻辑和行业经验很熟悉的人一起共同完成，开发人员完成程序编码系统层面的设计，业务行业专家需要完成针对需求的整个solution的设计(因为USER有可能只会提出一个最终的结果，在业务逻辑上怎么去最好的实现这个结果，就是solution)。

第三步：编码
这一步的主要任务就是把详细设计后的程序逻辑通过计算机编程语言来实现它，编码的工作对开发人员也不只要求只要掌握开发语言即可，还需要掌握：
（1）在编码的时候需要灵活的运用很多优秀的算法和数据结构，因为一个好的算法和数据结构能提高系统的性能(减少处理时间，降低内存使用率，减少CPU占有率……)；
（2）还要掌握很多的程序设计方法(用继承还是用组合，用全局变量还是用局部变量，用static函数还是用const型函数…)；
（3）不仅如此，编码的分格(函数、变量、类的命名，代码缩进，注释……)、可扩展性(是否容易修改和重构，不然一旦需求有一个很小的变动，整个编码将要重写的话，那之前的代码质量是不高的)、可维护性(可阅读性)、可重用性(以后的开发当中相似的逻辑是否可以拿之前已经实现的代码重用一下)；
（4）行业领域的相关技术，如一些专门领域的通信协议实现方式……
（5）需要理解原本系统的代码架构，不然要是需要修改原本系统的逻辑才能实现需求的话，就会无从下手
在这一步骤中，对于计算机编程语言语法层面的要求其实只用到了很小的一部分，因为那是最最基本的要求！

第四步：单元测试
开发人员在开发好之后，需要从程序角度测试一下数据的正确性(有别于系统测试的时候需要测试业务逻辑的正确性，这里只要测试处理数据的正确性和系统的性能即可)；设计测试用例需要覆盖大多数可能出现的数据，这其中包括很多非法数据，以保证系统的健壮。
上面的四个步骤是我们现在所用的开发过程，其中对于计算机编程语言的要求只是其中最最基本的一个要求；一个开发人员，除了需要掌握计算机编程语言之外，还需要掌握（我这里总结一下）：数据结构，算法，程序设计方法(面向过程，面向对象......)，操作系统，数据库，网络(协议，接口，实现机制……)，编译原理，软件工程方法(需求分析->系统设计->详细设计->编码->测试->维护，整个软件系统生命周期)，有时候还需要知道一些计算机的体系结构(处理比较棘手的问题，如：计算机对栈的分配，知道这些可以在编码给数组分配大小的时候要考虑会不会溢出计算机的最大长度)。

下面再来分析一下计算机编程语言的要求。
现在按照不同的设计角度来分，编程语言可以分为：
（1）面向过程语言，如C
（2）面向对象语言，如C++，JAVA，C#，VB
(这里先省略了一些不常用的如：面向问题语言，面向接口语言等等一些不常用的程序语言)
所以我个人觉得只要完全精通了其中一门语言的编程思想之后，别的同一类别的语言就可以触类旁通衍生开去理解，别的语言无外乎就是在一个基础的语言上改变了一下语法结构，提升了一些性能，优化了一些不足而已，在编码设计的思想上其实是大同小异的。就比如说C++，JAVA，C#，编码思想一致，都是OO的思想，所以在程序设计的时候设计过程也是差不多的（但是还是要特别的去理解一下相关语言各自的语言特点和不同之处）

上述的观点主要是想阐述一下从需求到最后release的整个过程和需要考虑的问题，把整个开发过程透明化，细节化。因为有时候开发人员在电脑面前一直盯着显示屏看着，手指不停的在敲着，嘴里不停的在叨咕着，草稿纸上一直在乱画着一些草图，很多不懂开发的旁人其实是不知道这个人到底是在捣鼓些什么东西的(:()！

还有就是一个开发人/天的评估问题，因为每个软件项目都要去评估一下预计的开发周期是多少。这个我觉得需要从以下几个方面去考虑：
（1）需求明确化。这个我个人认为是最最重要的，也是影响整个开发周期最厉害的因素。一旦一个需求很模糊，那么在理解错误的情况下去做开发，这些工作其实都是无用功，到最后还要重头开始去修改开发。所以在整个软件生命周期的开头一定要做的很充分，应该占整个周期的60%的时间，开发和测试的时间各占20%(6：2：2原则，这是最理想的开发过程)
（2）需求实现起来的难易度。因为有时候只是一个按钮点击一下的问题，在后面系统修改上可能需要修改很多个文件，需要新增很多条逻辑，可能牵连到其它很多业务逻辑，或者影响到整个系统的性能和原本设计上的架构。这些都需要考虑进去。
（3）人员的经验。对于有经验的项目，周期肯定不会很长。但是对于一个全新的项目，这个里面就会有学习成本的问题。学习周期和熟悉新技术的周期会大大加长整个开发周期。
（4）需求变更。一旦需求变更，肯定会加长周期。
（5）人员配置。这个就不需要解释了。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jindan_jinming/archive/2009/06/25/4296375.aspx