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

第二章 软件开发中的人员与过程_2 上节回顾 软件的三要素： 程序、数据、文档 软件工程师应具备的素质要求： 智力、个人素质、技术能力、共同合作能力、危机感 软件工程师职责要求与任职条件： 程序员、软件工程师、系统分析师、项目经理 软件工程师的“武器”： 编程语言、开发工具/平台、数据库管理系统、操作系统、软件工程 本节目标 软件工程师需养成的习惯： 编码习惯与规范、撰写文档能力 、源代码管理习惯 、主动沟通与反馈 、计划与总结的习惯 、测试习惯 软件开发生命周期介绍 需求分析、系统设计、编码实现介绍与难点分析 软件工程师需养成的习惯 编码习惯与规范 编码规范 编码风格 编码误区 文档撰写能力 源代码管理习惯 主动沟通与反馈 计划与总结的习惯 测试习惯 编码规范1 编码习惯与规范 作为一名合格的软件工程师，代码必须按一定规范编写，Martin Fowler曾经说过“任何一个傻瓜都能写出计算机可以理解的代码，未有写出人类容易理解的代码，才是一个优秀的程序员”。 编码规范 2 编码规范是公司或团体对代码编写的一个规定和约定，目的是使程序代码具有更好的一致性与可读性。 写代码首先要遵循一定的编码规范。“没有规矩，不成方圆”。作为专业的软件工程师，即使在程序设计工作中总能创造性地奇思妙想，也必须遵守一定的规则和限制。 现代软件项目的开发往往需要团队协作，那么所编写的代码就不仅仅是给自己阅读的。况且，代码风格的简单一致通常会减少bug；相反，对于风格糟糕的代码，软件工程师往往宁愿重起炉灶，也不愿去阅读和维护。 编码规范 3 代码本身也可能会进行合作开发或后期维护，一个软件的生命周期中，80%的花费在于系统维护，而且几乎没有一个软件，在其整个开发生命周期中，由最初的程序员维护旧代码，若代码按规范编写，可以让维护者尽快理解代码要表现的意图。 规范无所谓“好”与“不好”，同一门编程语言，可能会有多种编程规范，各公司所用规范也不完全相同，但是为了执行规范，每个软件开发人员必须一致遵守编码规范。 编码风格 代码是给人看的，除了遵循编码规范外，还需要有良好的代编码风格。好的代码应该简明扼要、平实易懂。 首先，要求代码条例清晰，顺着代码，很容易看出作者的逻辑思路。要传达什么信息，要求什么样的结果，直截了当，没有岐义。 其次要求代码平实简明，不要简单问题复杂化，不要在代码中卖弄编程技巧，smiple is the best。 编码误区 1 飞流直下三千尺，疑是银河落九天 这里用来形容象瀑布一样的代码，一个函数或类写上千行，甚至上万行，有人将这样的类或函数为“上帝类”或“上帝函数”，意思来戏称它们是“万能的”。 一个函数行数太多，不符合人类的认知习惯，一般来讲，一个函数或功能模块代码不要超过一屏幕，最好保持在30行以内。 如果把一个函数类比喻成文章中的一个段落的话，那么一个上千行的函数就是一个跨度为几页的一个长段落。可以想象，没有人愿意读这种长段落。 把一个很长的函数分化成很多很小的子函数或者子函数的子函数，不仅可读性会变好，而且总体的代码量也会也会减少。因为很长的函数中往往伴随着重复代码，变大为小的过程，我们称之为“重构”的过程。 如果一个类中定义了太多的属性与方法，也说明它有可能需要改进。这时候可以考虑分拆成多个类，或者抽象父类等方法。 编码误区 2 为人性僻耽佳句，语不惊人死不休 诗人写诗可以打破常规，追求新奇，但是代码绝对不能这样。在代码中，我们要按照常规的手法来写，不要出“奇招”、“怪招”，因为稀奇古怪的代码容易引起隐含的bug，另外可读性也不好。 千呼万唤始出来，犹抱琵琶半遮面 这里指函数与变量的命名要见名知意。例如：function1（int i1，int i2）｛｝这样的函数，我们很难知道它的作用，以及参数的意义。 在实际的命名中，不要怕费事，长一点的函数与变量名可以提高代码的可读性。 犹抱琵琶半遮面的不仅仅是变量命名，迂回曲折的逻辑同样让人糊涂，我们在编写代码时，不论变量还是逻辑，都要以清晰易懂为佳。 编码误区 3 为赋新词强说愁 这里指有些软件工程师为了显示水平而套用一些不必要的结构和定势做法。尤其是在对面向对象与设计模式不太理解的情况下，抽象出不必要的类结构和继承关系。 把代码及其表达的逻辑分散到太多的类中，在代码管理和阅读理解上都会造成困难，同时对于系统性能，也有负面影响。 文档撰写能力 多数的软件工程师的代码水平好于其写文档水平，软件是文档的重要组成部分，这要求软件工程师必须具备文档书写能力。 文档的书写，一是要按文档模板完成，各公司均提供各种文档模板，二是要求文档易读、直白，采用书面语书写。 源代码管理习惯 绝大多数软件工程师都经历过源代码丢失，或者旧版本覆盖新版本的问题，防止这种情形发生的