标签：本书 流程 推荐 模式 构建 MSF 敏捷 软件 代码

推荐一本书，叫《构建之法》。

全书分为17章，作者是邹欣，这本书讲述了作者对于编程以及项目工程的一些独特见解。

读来令人拍案叫绝，惊叹不已，五体投地，感觉不读此书真是人生虚度。（黄金开头法，逼格满满，代入感贼强）

---

（这种书的作者就知道坑人，在书里写一些乱七八糟的混蛋东西。没准写书的这哥们就不理解，有个什么“灵感”就写下来。反正我就随便读，遇到什么定义，什么好思想就记下来，遇到感兴趣的就去网上查，遇到看不懂、不想看的，就略过。）

---

左边是目录（百度copy的），右面的是个人对他讲的内容的理解。

第1 章 概 论 /15
1.1　软件 = 程序 + 软件工程

软件=单个程序+软件开发过程。软件开发过程包括：构建管理、源代码管理、软件设计、软件测试、项目管理。

1.2　软件工程是什么

软件企业=软件+赢得用户的方法(即营销手段)。

1.3　练习与讨论

软件项目有四大分类：
Build To Learn：为做进一步的试验而造软件，试图发现客观规律或某个试验方法的优点与缺点，这玩意儿除了哄自己开心，没啥用处。例子：科研论文，我们集中训练几个小时造的软件。
Build To Show：为了开发一些演示为目的的软件，但是功能未必全面。例子：我正在参加的“中国大学生服务外包大赛”
Build To Serve：为了服务一定范围的目标用户而构建的软件。例子：石铁大学校教务系统
Build To Win：为了在市场上赢得用户而构建的软件，这本书的英文名字。例子：腾讯的“王者荣耀”，“绝地求生”。
这四个从上到下越来越难，也是我们一步步的目标。

第2 章 个人技术和流程 /35
2.1　单元测试

现在就只知道java可以用junit跑起来来测试局部代码的正确性

2.2　效能分析工具
2.3　个人开发流程

个人开发流程PSP（Personal Software Process）
这玩意儿就是自己一个人开发软件，有好处，也有局限性。
好处：不局限于某一种软件技术，而是着眼于软件开发的流程，开发的效率超级高
局限性：没有交流，缺少数据，软件质量不一定很好。

2.4　实践
2.5　练习与讨论
第3 章 软件工程师的成长 /57
3.1　个人能力的衡量与发展

软件工程不仅是开发软件，还有运营软件（给软件更新，更改软件内容）和维护软件（给软件改bug和增强软件的安全性）。

3.2　软件工程师的职业发展

软件工程师需要掌握技术技能和职业技能
技术技能例子：
  对JAVA、C/C++、C#的掌握，优化代码提升效率，对设备驱动程序、内核调试器的掌握，对于某一开发平台的掌握。
  积累问题领域的知识和经验（例如对医疗或金融行业的了解）
  对通用的软件设计思想和软件工程思想的理解
职业技能例子：
  表达交流的能力、与人合作的能力、睡服别人的能力。

3.3　技能的反面
3.4　练习与讨论
第4 章 两人合作 /73
4.1　代码规范

匈牙利命名法：要求前缀字母用变量类型的缩写，其余部分用变量的英文或英文的缩写，单词第一个字母大写。如  char cMyName[10]; （"c"代表char）。是 IDE 还十分智障的年代的产物。
驼峰式命名法（小驼峰式命名法）：要求第一个单词首字母小写，后面其他单词首字母大写，我们常用的命名法。
帕斯卡命名法（大驼峰式命名法）：每个单词的第一个字母都要大写，即小驼峰式命名法的第一个字母大写。
下划线命名法：在宏定义和常量中使用比较多（通过下划线来分割全部都是大写的单词）。

4.2　代码风格规范
4.3　代码设计规范
4.4　代码复审
4.5　结对编程

两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。
输入代码的人称作驾驶员，审查代码的人称作观察员(或导航员)。
两个程序员经常互换角色。
我吃着而火锅，唱着歌，看着他打代码，时不时踹一脚“墨迹啥呢”，多么温馨快乐的一件事呀。

4.6　两人合作的不同阶段和技巧
4.7　练习与讨论
第5 章 团队和流程 /101
5.1　非团队和团队
5.2　软件团队的模式

主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式。

5.3　开发流程

瀑布模型：从下往上，一步一步地来，没有回头路，应付不了需求不断变化的客户。
快速原型模型：从上往下，先根据用户需求确定大致模型，再搞软件。

5.4　练习与讨论
第6 章 敏捷流程 /118
6.1　敏捷的流程

怎么快怎么来，就是敏捷开发

6.2　敏捷流程的问题和解法
6.3　敏捷的团队
6.4　敏捷总结
6.5　敏捷的故事— 兼酒后问答
6.6　练习与讨论
第7 章 MSF /138
7.1　MSF 简史
7.2　MSF 基本原则
7.3　MSF 团队模型
7.4　MSF 过程模型
7.5　MSF 敏捷开发模式
7.6　MSF CMMI 开发模式

微软解决方案框架（Microsoft Solution Framework）
微软搞出来的一个造软件的合作方式
即每个成员都是平等的，网状结构（与之相对的还有层状结构）

7.7　练习与讨论
第8 章 需求分析 /157
8.1　软件需求
8.2　软件产品的利益相关者
8.3　获取用户 需求— 用户调查
8.4　竞争性需求分析的框架
8.5　功能的定位— 四象限方法

功能的分类：杀手功能、外围功能、必要需求、辅助需求
例子（英汉词典app）：
杀手功能：文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等
外围功能：在各个平台上都能运行
必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）
辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）
例子（王者荣耀）：
杀手功能：五V五比赛0延迟，，优秀的人机AI，支持上万人同时在线,等等
外围功能：支持Android，苹果
必要需求：优秀的反外挂系统和支付系统（如果达不到这一点，用户就不会来使用）
辅助需求：奖励系统做的太好以至于要做防沉迷系统来证明自己的“清白”，各种皮肤特效。

8.6　计划和估计
8.7　分而治之（Work Breakdown Structure）

。。。这有看的必要？

8.8　练习与讨论
第9 章 项目经理

PM————经理
分类：
  Product Manager：产品经理——做产品
  Project Manager：项目经理——做流程

第13 章 软件测试

白箱测试与黑箱测试的区别：前者可以看到源代码，后者注重功能。

标签：本书,流程,推荐,模式,构建,MSF,敏捷,软件,代码
来源： https://www.cnblogs.com/zhuangzhongxu/p/15783904.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。