程序猿你是否有这些理解误区？

人们在一起可以做出单独一个人所不能做出的事业;智慧+双手+力量结合在一起，几乎是万能的。——美.韦伯斯特

   （昨天在合作开发时老师在我们旁边经过，看到我们对合作开发理解有误，并对软件工程中的图和文档没有清楚的认识，于是乎把我们臭骂了一顿，自感有愧，同时也发现很多人还有同样的理解错误，于是昨晚面壁思过检讨自己的过失。）

    你是否常常向项目主管提建议但却被骚到驳斥？你是否常常为项目主管的一些不合理分工而感到不平？你是否常常因为项目主管对项目的无知而感到苦恼……对于程序员来说，大多人会说是。今天我们不讨论这些问题的解决之道，而是要检讨下在合作开发中经常犯的错误。

    误区一：软件开发以文档和图为驱动，程序员只负责编码。错。

    在软件开发过程中，大多数认为开发过程是以文档和图为驱动，应该大多数人还是这么认为的吧。准确说项目开发不是以文档和图为驱动，而是把文档和图作为客户、老板、项目主管、程序员之间的交流工具，它们两个是项目开发过程中最重要的交流工具，除此之外的有关项目的一些问题程序猿要和项目主管的交流少之又少。

    先说文档

    文档是阐述系统开发各阶段最好的工具。它起到桥梁作用，有助于程序员编制程序，有助于管理人员监督和管理软件开发，有助于用户了解软件的工作和应做的操作，有助于维护人员进行有效的修改和扩充，所以文档的编制必须保证一定的质量。高质量的文档应符合下图的一些优点：

    再看图

    图是描述了软件最直观的一面，它从各个侧面对软件进行了彻底的描述。一张图抵过千言外语，对于程序猿来说，在对系统进行编码时，图是我们最直接的工具。现在最主流的软件建模语言当属UML，UnifiedModeling Language，统一建模语言，图是软件的原型，程序猿看到了图也就看到了完整的系统，当然前提是图画的要生动漂亮，画图不是要让自己看，而是要让其他系统开发者一目了然，看到图就看到了软件。

  误区二：开发过程中项目主管占主导地位，锻炼最多的是组长，程序猿只负责编码。错。

    先看下图中的有关团队的理解图：

    我们可以把上面的图近似看做菱形，团队也是一种菱形结构，连接彼此间的线是指项目的交流，在交流时彼此间的线会越来越短。现在来看，如果去掉上图中的文字，你能看出谁是项目主管吗？当然不能。所以团队中每个人都处于核心地位。

    一滴水只有放进大海里才永远不会干涸,一个人只有当他把自己和集体事业融合在一起的时候才能最有力量。二十一世纪团队合作站主导地位，团队中的每个人都是为了团队的高效率运行而服务的，包括项目主管他并不是项目的中心，项目的中心是文档和图。项目主管应该负责给开发人员指明方向，而不是一味地干涉，项目团队中的每个人都是团队重要的力量，在开发过程中要以文档和图为中心，每个人都会在合作开发中得到锻炼，只是锻炼的方面不同，没有最多之分。

    虽然在当下敏捷开发广泛受到好评，短暂看来敏捷开发很符合人性化，开发效率高，因为它是以人为核心，但是长远来看这种开发方式拥有很大的弊病。它的弊病表现在其一，后期的维护、升级；其二，项目人员的离开；其三，项目规模的限制。系统发布并不代表着系统开发完成，而只是完成了一部分，真正的软件工程是从开始到软件寿命结束。系统发布后期要进行维护、升级等的操作，如果这时开发人员没在，而且有关软件的文档和图又写的一团糟，维护人员会怎么办，会被坑死……

    软件系统的规模也限制了敏捷开发，敏捷开发讲究以人为中心，其中包含了沟通、简单、反馈、勇气等的价值观，这是针对于小型或者中型软件而言，如果涉及到特别大型的软件，开发人员较多，那去哪儿开会、哪儿讨论，人民大会堂也可能放不了这么多人。

   误区三：对于程序猿来说，能够实现功能就是系统开发成功。错。

    这是大错特错的，对于程序猿来说软件开发考虑的不仅仅是自己，更要考虑后期维护人员，阅读你程序的人员。代码无错就是优，这是最低级的开发方式，一款开发成功的软件，要用于以下特性：适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性软件工程、可互操作性，更要考虑客户、老板、项目主管及后期维护人员。系统开发完成后要使用的是客户，要让客户说出来好，而且后期维护人员负责对系统的更新、维护，要让他们对系统维护变得简单。

   误区四：项目开发是项目主管的事，自己只管自己那部分的内容。错。

    这里还是回到团队来说，团队不是只做好自己。高效的团队需要彼此间的沟通和交流，在软件开发过程中也是如此，增进彼此间的交流，让团队成员能迅速了解你的想法，这样在开过程中会避免很多误区。那它是不是和误区一之间相互冲突，误区一讲究少交流，但是误区四却是说要增进交流。答案是否，误区一是说项目在各阶段的各层之间的关系，我们应主要以图和文档为标准，各层之间应减少交流，下层看到图和文档就知道上层要表达的意思。

    但是现在我们说的情况不是各层间，而是一层间，当项目主管征求我们的意见时我们要大胆的说出自己的想法，相信一个明智的主管会采纳明智的观点。如果不采纳，也不要生气，最后错误了也不会怪罪你。说的权利在你，决定权在上层，我们不应该越权。有时会有这样的情况，主管向你征求意见时，你没有把你的真实想法告诉他，但当遇到问题时你却又抱怨，相信明智的主管迟早会炒你鱿鱼。所以增进交流，让团队成员及时知道你对项目的看法，即时不能够采纳，那至少也让主管看到你在努力。

    错误的出现是因为我们对团队和软件工程不正确的理解，想要高效的开发软件，文档和图是必不可少的工具，它就好比针和线把软件串联起来，软件才有活力。知人者智，自知者明。君子当一日三省。知道有了误区我们就要进行更改，因为我们不是圣人，只是普通人，知道有了错误就要更改，人往高处走，水往低处流。