标签：错误 用户 而且 系统 分割 变更 行业 同事 项目管理
构建之法现代软件工程（第四次）
本周阅读了《构建之法》第四章和第五章
代码规范：
虽然计算机只关心编译生成的机器码，但是由于现代软件工程一般都是在一个团队里工作，所以代码是要给同事看的，因此一个良好的代码规范相当重要。
代码规范可以分成两个部分：
1.代码风格规范：简明，易读，无二义性。
其中又包括缩进，行宽，括号，断行，命名，下划线，大小写，注释等一系列规范，这些规范有助于程序员们更好地理解和维护程序。
缩进：4个空格，而不是tab；
关于断行与空白的{}行：单独占一行；中间的代码缩进
下划线：用来分割变量名字中的作用域标注和变量的语义
大小写：通用的做法是，所有的类/函数名都采用所有单词首字母大写（Pascal）的形式；所有的变量首字母小写，随后的单词首字母大写(Camel)；
注释：解释程序做什么、为什么这样做以及要特别注意的地方。注释只用ASCII码字符，不要用中文或者其他特殊字符，否则会影响可移植性
2.代码设计规范：牵扯到程序设计，模块之间的关系，设计模式等等
函数：只做一件事，并且要做好。
goto：函数最好由单一的出口
错误处理：耗时长，使用断言验证参数的正确性
代码复审：
代码是否在代码规范的框架内正确地解决了问题，这是有必要的，因为如果有问题的代码已经嵌入到产品代码中，再要把所有的问题找出来就更困难了，而且修复的代价就会更大。
根据代码复审的核查表一一对应。
结对编程：
一对程序员一起面对一个电脑，一起分析，设计，编码，测试，写文档等，一直处于复审状态。
两个角色：驾驶员：控制键盘输入，领航员：起到领航，提醒的作用。
这样的编程有助于互相督促，减少错误，初始质量的提高，并且两个程序员互相学习传递经验，如果运用得当，可以取得更高的投入产出比。
两个人如何进行交流：
要学会与人进行思想交流，富有情商地与同伴相处。
软件团队的模式：
1.窝蜂模式：一群人直接写代码，并且希望能借此写出好软件（大型项目不现实）；
2.主治医师模式：主要核心在于首席程序员，其他成员从各种角度支持他的工作（IBM System 360项目）
3.明星模式：主治医师模式运用到极点，需要考虑团队利益最大化问题。
4.社区模式：需要严格的代码复审和签入的质量控制。
5.业余剧团模式：不同人承担不同角色。
6.秘密团队：团队内部有极大的自由，较高热情，没有外界干扰。
7.特工团队：软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而又紧迫性的问题。
8.交响乐团模式：适合某个软件领域处于稳定成长阶段的时候。
9.爵士乐模式：于交响乐团模式对立，比较强调个性化的表述。
10.功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。（很多软件公司的团队最后都成为的模式）
11.官僚模式：组织上有领导和被领导的关系
开发流程：
1.写了再改模式：
与蜂窝模式大相径庭，大家上来就写代码，写不出就直接改。
2.瀑布模型：
由别的成熟行业借用的模型转化而成软件行业的设计模型，适合于：定义非常稳定的产品，技术成熟，不能频繁交流的团队。
（1）.生鱼片模型
解决了各个步骤之间分离的缺点，但仍存在不知道上一个阶段何时会结束的问题。
（2）.大瀑布带着小瀑布
解决不同子系统之间进度不一的问题，用户只有等到最后才能看到结果。
3.统一流程：
重计划，重事先设计，重文档表达。
具体规程有：业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境、初始阶段、细化阶段、构造阶段、交付阶段。
4.老板驱动的流程：
开发流程由公司老板驱动，适合于：软件订单靠个人关系，老板比一般技术人员更懂市场和竞争，团队尚未成熟。
存在的问题：领导技术上是外行，领导不懂得管理软件项目，精力有限。
5.渐进交付的流程
很接近迭代式开发流程，当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的evolution循环中：开发→发布→听取反馈→根据反馈做改进
MVP：
由于团队在软件开发流程中要到最后才能给客户一个软件反馈，所以可先将最小可行产品开发出，来得到用户的反馈，比如先做一个IOS软件，而不是同时开发Android软件。
MBP：
适合极高水平的产品团队，把产品最全最美的形态展现出来，征服用户，比如IPHONE
标签：错误 用户 而且 系统 分割 变更 行业 同事 项目管理
原文地址：http://www.cnblogs.com/Marooned/p/6802930.html
