标签：交流 设计模式 struct 软件 适合 了解 str 成员 还需
构建之法 第四、五章心得
学习了第四第五章之后，我了解到了两人合作的注意要点，还有团队和开发流程。软件都是在相互合作中完成的，合作的最小单位是两个人。每个人的标准都不一样，对于什么是好的代码规范未必认同，所以我们需要给出一个基准线，即什么是好的代码规范和设计规范。
代码规范可以分成两个部分，一是代表风格规范，主要是文字上的规定，看似是表面文章，实际上非常重要。二是代码设计规范，牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。代码风格的原则是：简明、易读、无二义性。这里可以从几个方面来阐述代码风格规范。
1.缩进，在写代码时，4个空格的距离正好。
2.行宽，行宽必须限制，现在可以限定为100字符
3.括号，在复杂的条件表达式中，用括号可以清晰地表示逻辑优先级
4.断行与空白的{ }行，这样可以很容易看清结构和对应关系
5.分行，写代码时，不要把多个变量定义在一行上
6.命名，在变量面前加上有意义的前缀，程序员就能一眼看出变量的类型及相应的语义
7.下划线，下划线用来分隔变量名字中的作用域标注和变量的语义
8.大小写，便于区分由多个单词组成的变量名
9.注释，有了注释，才能解释程序做什么，为什么这么做，以及要特别注意的地方。
对于程序的错误处理，有参数处理和断言两种，所有的参数都要验证其正确性。对于C++中的类有以下几种处理方法：类，class vs.struct，公共/保护/私有成员，数据成员，虚函数，构造函数，析构函数，new和delete，运算符，异常，类型继承。
除了代码规范，我们还要进行代码复审。代码复审是看代码是否在“代码规范”的框架内正确的解决问题。在软件工程中，最基本的复审手段，就是同伴复审。代码复审可以找出代码的错误，或者说一些不符合 团队代码规范的地方，也可以让更多的成员熟悉项目各部分的代码，同时熟悉和应用领域相关的实际知识。如果我们不开发实际的软件，就只能在表面上完全掌握，所以要在实践中学习。
要注意避免不必要的繁文缛节，因为我们做代码复审的目的是为了减少错误的发生。我们还需要一个代码复审的核查表，在实际项目中，我们可以加上自己认为重要的注意事项：概要部分、设计规范部分、代码规范部分、具体代码部分、效能、可读性、可测试性。虽然代码复审很好，但是我们还是应该进行结对编程。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员各方面水平较好的那一位。
软件团队有很多种形式，适合不同的人员和需求。有主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式。不同的团队应根据团队本身选择各自的团队模式。
从瀑布模型开始的各种模型都有一个特点：重计划、重事先设计、重文档表达。RUP把软件开发的各个阶段整合在一个统一的框架里。要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情，这些不同类型的工作在RUP中叫做规程或者工作流。不同的软件设计有不同的流程，如RUP统一流程，老板驱动的流程，渐进交付的流程。
在团队合作中，我们都应该清楚的了解自己的定位，做好自己的本职工作，并且尽力配合团队中其他成员，一起完成设计。
标签：交流 设计模式 struct 软件 适合 了解 str 成员 还需
原文地址：http://www.cnblogs.com/hxy-/p/6771606.html
