0202软件开发中的人员与过程2

《0202软件开发中的人员与过程2》由会员分享，可在线阅读，更多相关《0202软件开发中的人员与过程2（44页珍藏版）》请在金锄头文库上搜索。

1、 第二章软件开发中的人员与过程_2上节回顾l 软件的三要素： 程序、数据、文档 l 软件工程师应具备的素质要求： 智力、个人素质、技术能力、共同合作能力、危机感 l 软件工程师职责要求与任职条件： 程序员、软件工程师、系统分析师、项目经理 l 软件工程师的“武器”： 编程语言、开发工具/平台、数据库管理系统、操作系统、 软件工程本节目标l软件工程师需养成的习惯： 编码习惯与规范、撰写文档能力 、源代码管理习 惯 、主动沟通与反馈 、计划与总结的习惯 、测试 习惯 l软件开发生命周期介绍 需求分析、系统设计、编码实现介绍与难点分析软件工程师需养成的习惯l编码习惯与规范 编码规范 编码风格 编码误

2、区 l文档撰写能力 l源代码管理习惯 l主动沟通与反馈 l计划与总结的习惯 l测试习惯编码规范1l编码习惯与规范作为一名合格的软件工程师，代码必须按一定规 范编写，Martin Fowler曾经说过“任何一个傻瓜 都能写出计算机可以理解的代码，未有写出人类 容易理解的代码，才是一个优秀的程序员”。编码规范 2l 编码规范是公司或团体对代码编写的一个规定和约定，目的 是使程序代码具有更好的一致性与可读性。 l 写代码首先要遵循一定的编码规范。“没有规矩，不成方圆” 。作为专业的软件工程师，即使在程序设计工作中总能创造 性地奇思妙想，也必须遵守一定的规则和限制。 l 现代软件项目的开发往往需要团队

3、协作，那么所编写的代码 就不仅仅是给自己阅读的。况且，代码风格的简单一致通常 会减少bug；相反，对于风格糟糕的代码，软件工程师往往宁 愿重起炉灶，也不愿去阅读和维护。编码规范 3l 代码本身也可能会进行合作开发或后期维护，一个软件的生 命周期中，80%的花费在于系统维护，而且几乎没有一个软 件，在其整个开发生命周期中，由最初的程序员维护旧代码 ，若代码按规范编写，可以让维护者尽快理解代码要表现的 意图。 l 规范无所谓“好”与“不好”，同一门编程语言，可能会有多种 编程规范，各公司所用规范也不完全相同，但是为了执行规 范，每个软件开发人员必须一致遵守编码规范。 HandsOn实训体系中为各种

4、用到的编程语言都提供了编码规范， 按编码规范编写代码，可以促使自己养成良好的编码习惯，另外， 编码规范中还对如何编写高质量的代码提供了指导，而且有助于自 身编码水平的提高。 编码风格 l代码是给人看的，除了遵循编码规范外，还需 要有良好的代编码风格。好的代码应该简明扼 要、平实易懂。 l首先，要求代码条例清晰，顺着代码，很容易 看出作者的逻辑思路。要传达什么信息，要求 什么样的结果，直截了当，没有岐义。 l其次要求代码平实简明，不要简单问题复杂化 ，不要在代码中卖弄编程技巧，smiple is the best。 编码误区 1l 飞流直下三千尺，疑是银河落九天 这里用来形容象瀑布一样的代码，一

5、个函数或类写上千行，甚至上万 行，有人将这样的类或函数为“上帝类”或“上帝函数”，意思来戏称它 们是“万能的”。 一个函数行数太多，不符合人类的认知习惯，一般来讲，一个函数或 功能模块代码不要超过一屏幕，最好保持在30行以内。 如果把一个函数类比喻成文章中的一个段落的话，那么一个上千行的 函数就是一个跨度为几页的一个长段落。可以想象，没有人愿意读这 种长段落。 把一个很长的函数分化成很多很小的子函数或者子函数的子函数，不 仅可读性会变好，而且总体的代码量也会也会减少。因为很长的函数 中往往伴随着重复代码，变大为小的过程，我们称之为“重构”的过程 。 如果一个类中定义了太多的属性与方法，也说明它

6、有可能需要改进。 这时候可以考虑分拆成多个类，或者抽象父类等方法。 编码误区 2l 为人性僻耽佳句，语不惊人死不休 诗人写诗可以打破常规，追求新奇，但是代码绝对不能这 样。在代码中，我们要按照常规的手法来写，不要出“奇招 ”、“怪招”，因为稀奇古怪的代码容易引起隐含的bug，另 外可读性也不好。 l 千呼万唤始出来，犹抱琵琶半遮面 这里指函数与变量的命名要见名知意。例如：function1（ int i1，int i2）这样的函数，我们很难知道它的作用 ，以及参数的意义。 在实际的命名中，不要怕费事，长一点的函数与变量名可 以提高代码的可读性。 犹抱琵琶半遮面的不仅仅是变量命名，迂回曲折的逻辑

7、同 样让人糊涂，我们在编写代码时，不论变量还是逻辑，都 要以清晰易懂为佳。 编码误区 3l为赋新词强说愁 这里指有些软件工程师为了显示水平而套用一些 不必要的结构和定势做法。尤其是在对面向对象 与设计模式不太理解的情况下，抽象出不必要的 类结构和继承关系。 把代码及其表达的逻辑分散到太多的类中，在代 码管理和阅读理解上都会造成困难，同时对于系 统性能，也有负面影响。 文档撰写能力 l多数的软件工程师的代码水平好于其写文档水 平，软件是文档的重要组成部分，这要求软件 工程师必须具备文档书写能力。 l文档的书写，一是要按文档模板完成，各公司 均提供各种文档模板，二是要求文档易读、直 白，采用书面语

8、书写。 HandsOn实训体系提供了一套相对简单的文档模板， 要求我们在做项目时，按模板要求完成相关项目文档。源代码管理习惯 l绝大多数软件工程师都经历过源代码丢失，或 者旧版本覆盖新版本的问题，防止这种情形发 生的一个好的方式就是采取版本控制工具。 l关于版本控制工具的配置及使用，我们将在第 二阶段的软件素养课程里面具体介绍。 主动沟通与反馈 l一个项目组由多名软件工程师组成，我们要学 会积极主动地与其他成员沟通与交流，保证项 目组成员对问题理解地一致性。遇到自己无法 解决的技术难题，要多与其他成员讨论，用最 短的时间解决问题。 计划与总结的习惯 l 项目有项目计划，项目组每个软件工程师需要

9、根据项 目计划制定自己的工作进度，如何准确估量自己的工 作进度，按项目计划安排好自己的工作计划，这个需 要软件工程师有经常性的计划习惯。 l 要做好计划，需要有好的时间管理计划及学会使用时 间管理工具，例如甘特图。 l 总结是学习与工作过程中一个重要的环节。善于学习 的人必然善于总结。总结能够将自己零散的收获条理 化，变成自己的知识与经验的积累。 测试习惯 l 鉴别软件工程师优秀与否的一个方面就是看其提交的 代码bug是否足够少。这必然要求软件工程师在提交 代码之前，先要自己测试无误。 l 作为一些商业化正规化的开发而言，专职的测试工程 师是不可少的。 l 问题发现的越早，解决的代价就越低。

10、l 开发人员在每段代码，每个子模块完成后进行认真的 测试，就可以尽量将一些潜在的问题最早的发现和解 决，这样对整体系统建设的效率和可靠性就有了最大 的保证。 软件生命周期概述 1 l一个人要经过胎儿、儿童、青年、中年、老年 ，直到最终死亡的生命周期。 l一个软件同样有一个从定义、开发、使用和维 护，直到最终被废弃的生命周期。 l在软件的生命周期中，需要完成许多性质各异 的工作，这就要求把软件生命周期划分成若干 个阶段，并相应地制定出切实可行的计划，然 后按照计划对软件的开发与维护工作进行管理 。软件生命周期概述 2l 软件产品从形成概念开始，经过开发、使用和维护， 直到最后退役的全过程称为软件

11、生命周期。 l 软件工程是把软件生命周期依此划分为若干个阶段， 每个阶段有相对独立的任务，然后对每一阶段进行严 格管理。 l 把软件生命周期划分成若干个阶段，每个阶段的任务 相对独立，而且比较简单，便于不同人员分工协作， 从而降低了整个软件开发工程的困难程度；在软件生 命周期的每个阶段都采用科学的管理技术和良好的技 术方法，使得软件开发的全过程以一种有条不紊的方 式进行，这样，能保证软件的质量，特别是提高软件 的可维护性。 软件生命周期概述 3l软件的生命周期通常划分为五个阶段： 需求分析 系统设计 编码实现 软件测试 运行维护 需求分析概述l需求分析是解决“做什么”的问题，即我们需要 做一个

12、什么样的系统。 l系统分析阶段的基本任务是：系统分析员与用 户在一起交流，充分了解用户的要求，并把双 方的理解用系统方案书表达出来。 需求分析可行性分析 l 在进行具体需求分析之前，还需要对项目进行可行性分析， 可行性分析是解决“做与不做”的问题。即我们能否做这个项 目。 l 从理论上讲，只要资源和时间不加限制，所有的项目都是可 行的。然而，由于资源缺乏和交付时间限制的困扰以及项目 是否能够盈利，对软件项目的可行性做出细致而谨慎的评估 是十分必要的。如果在制定计划阶段及早发现将来可能在开 发过程中遇到的问题，及早做出决定，可以避免大量的人力 、财力、时间上的浪费。 l 可行性分析内容主要包括：

13、市场可行性分析、政策可行性分 析、技术可行性分析、成本效益分析、SWOT分析等几个方 面。需求分析SWOT分析 1lSWOT分析即“强弱机威”综合分析法，是一种 企业项目竞争态势分析方法，通过评价项目的 ： 优点(Strengths) 弱点(Weaknesses) 竞争市场上的机会(Opportunities) 威胁(Threats) l通过SWOT用以在决定企业项目前对企业项目 进行深入全面的分析以及竞争优势的定位。需求分析SWOT分析 2l 分析出项目的SWOT后进而需用USED技巧来产出解 决方案，USED是下列四个方向的重点缩写，如用中 文的四个关键字，会是用、停、成、御。USED分

14、别是： How can we Use each Strength ? 如何善用每个优势？ How can we Stop each Weakness ? 如何停止每个劣势 ？ How can we Exploit each Opportunity ? 如何成就每个 机会？ How can we Defend against each Threat ? 如何抵御每 个威胁？ 需求分析难点解析 1 l开发软件系统最困难的部分就是准确说明开发 什么。最困难的概念性工作是编写出详细的需 求，包括所有面向用户、面向机器和其它软件 系统的接口。此工作一旦做错，将会给系统带 来极大的损害，并且以后对它修改也

15、极为困难 。 l需求是产品的根源，需求工作的优劣对产品影 响最大。就像一条河流，如果源头被污染了， 那么整条河流也就被污染了。需求分析难点解析 2需求分析难点解析 3l 把所有与需求直接相关的活动通称为需求工程。需求 工程中的活动可分为两大类，一类属于需求开发，另 一类属于需求管理。 需求分析难点解析 4l行业知识匮乏 软件工程师一般技术比较在行，但是业务知识不 一定理解。假如对用户所在的行业不了解，则不 能很好地与用户沟通，需求也难以详细调查清楚 。例如，需要为客户做一套财务软件，若是需求 调查人员根本不懂财务知识，则与用户交流都很 困难。 此时应当赶紧补习应用域知识，不论是通过自学 还是培训的方式，如果可能的话，开发方最好请 既懂软件又懂应用域知识的行业专家来帮忙。 需求分析难点解析 5l 用户说不清需求 用户说不清楚需求是普遍现象，这是让开发人员头痛的大 问题。其实这个并不能怪用户，试想，假如我们去买鞋子 ，我们非常了解自已的脚，但很难用语言说清楚脚的大小 和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。 需求分析员绝不能以用户说不清楚需求为借口而草率地对 待需求开发工作，否则会连累整个开发团队的。 无论是什么原因导致用户说不清楚需求，需求分析员必须 设法搞清楚用户真正的需求，这是分析人员的职责，也是 职业的挑战。 需求分析阶段成果 l可行性研