在没有接触这本书之前我一直以为设计编程和软件开发的书都会比较枯燥乏味，看了这本书的前几章之后才发现原来还会有这么有趣的软件开发方面的书籍。
概论中先阐述了健身教练与健身学员的师生关系，最基本的要求是及时反馈。学生要对自己严格要求，只有完成了比实战更重的任务才能不惧实战。又说了习而学的教学方式：先通
过具体实践激发学生兴趣，再学习高深的内部理论。
接下来我又了解到所谓软件，代码只是其中的一部分，还要考虑到配置管理、软件测试、软件维护、用户体验等各个方面，一款软件要想不存在BUG几乎不可能吧，但是我们要保证
这款软件不出现重大问题，可以满足客户要求即可。
一、个人开发的过程中，要学会使用效能分析工具和进行单元测试与回归测试。
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某
个特定函数的行为。
创建单元测试函数的主要步骤：
（1）设置数据（一个假想的正确的E-mail地址）；
（2）使用被测试类型的功能（用E-mail地址来创建一个User类的实体）；
（3）比较实际结果和预期的结果。
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。对于“回归测试”中的“回归”，我们可以理解为“回归到以前不正常的状态”。
个人的开发鼓励创新，但创新不是抄袭，然而很多人一直只是背口诀式的模仿，没有核心竞争力。
二、在两人合作的过程中，还要注意以下问题：
1、代码的规范性：
（1）代码风格规范。主要是文字上的规定，看似表面文章，实际上非常重要。原则是：简明，易读，无二义性。主要包括：缩进、行宽、 括号、断行与空白的{ }行、 分行、命名、
下划线、 大小写、注释。
（2）代码设计规范。代码设计规范不光是程序书写的格式问题，而且牵涉到程序设计、模块之间的关系、设计模式等方方面面，这里有不少与具体程序设计语言息息相关的内容（如
C、C++、Java、C#），但是也有通用的原则，这里主要讨论通用的原则。主要包括： 函数、 goto的使用与否、错误处理、如何处理C++中的类。
代码完成后还要进行代码复审。软件工程中最基本的复审手段，就是同伴复审。复审的目的在于：
（1）找出代码的错误。如：
a. 编码错误，比如一些能碰巧骗过编译器的错误。
b. 不符合项目组的代码规范的地方。（2）发现逻辑错误，程序可以编译通过，但是代码的逻辑是错的。
（3）发现算法错误，比如使用的算法不够优化。
（4）发现潜在的错误和回归性错误——当前的修改导致以前修复的缺陷又重新出现。
（5）发现可能改进的地方。
（6）教育（互相教育）开发人员，传授经验，让更多的成员熟悉项目各部分的代码，同时熟悉和应用领域相关的实际知识。
在代码复审后，开发者应该把复审过程中的记录整理出来：
（1）更正明显的错误。
（2）对于无法很快更正的错误，要在TFS中创建Bug把它们记录下来。
（3）把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步。
2、两人还可以结对编程：结对编程技术是指两位程序员坐在同一工作台前开发软件。与两位程序员各自独立工作相比，结对编程能编写出质量更高的代码。在结对编程模式下，一对程
序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测
试用例，一起编码，一起单元测试，一起集成测试，一起写文档等。
结对编程有如下的好处：
（1）在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作能有更强的解决问题的能力。
（2）对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
（3）在心理上, 当有另一个人在你身边和你紧密配合, 做同样一件事情的时候, 你不好意思开小差, 也不好意思糊弄。
（4）在企业管理层次上，结对能更有效地交流，相互学习和传递经验，能更好地处理人员流动。因为一个人的知识已经被其他人共享。
结对编程让两个人所写的代码不断地处于“复审”的过程，正如前所述，复审是不断地审核，提高设计和编码质量的过程，结对编程让复审随时随地发生，这样才能及时地发现问题和解
决问题，避免把问题拖到后面的阶段。
当然并不是所有的项目都适合结对编程，下面是一些不适合使用的例子：
1）处于探索阶段的项目，需要深入地研究，在这种情况下，一个人长时间的独立钻研是有必要的。
2）在做后期维护的时候，如果维护的技术含量不高，只需要做有效的复审即可，不必拘泥于形式，硬拉一个人来结对唱二人转。
3）如果验证测试需要运行很长时间，那么两个人在那里等待结果是有点浪费时间。
4）如果团队的人员要在多个项目中工作，不能充分保证足够的结对编程时间，那么成员要经常处于等待的状态，反而影响效率。
5）关键是如何最大限度地发挥“领航员”的作用，如果用处不大，也就无需结对。
3、关于如何与人合作，给予别人反馈，可以运用以下方法：
（1）做好铺垫, 例如可以从双方的共同点, 团队共同的愿景讲起, 让对方觉得处于一个安全的环境；
（2）用合适的方法和语气提出建设性的意见；
（3）呼应开头, 鼓励对方把工作做好。
三、团队合作中的各种方法论
1、什么是团队：
（1） 团队有一致的集体目标, 团队要一起完成这目标；
（2）团队成员有各自的分工, 互相依赖合作, 共同完成任务。
2、敏捷开发： 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过
测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发原则：
（1）尽早并持续地交付有价值的软件以满足顾客需求；
（2）敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势；
（3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短；
（4）业务人员和开发人员在项目开发过程中应该每天共同工作；
（5）以有进取心的人为项目核心，充分支持信任他们；
（6）无论团队内外，面对面的交流始终是最有效的沟通方式；
（7）可用的软件是衡量项目进展的主要指标；
（8）敏捷流程应能保持可持续的发展。 领导, 团队和用户应该能按照目前步调持续合作下去；
（9） 只有不断关注技术和设计才能越来越敏捷；
（10） 任何还没有明确的工作都会花不可知的时间， 不要把那些还没有做的工作和正在做的工作混起；
（11）只有能自我管理的团队才能创造优秀的架构, 需求和设计.；
（12）时时总结如何提高团队效率, 并付诸行动。
3、敏捷开发的几种方法论：Scrum/Sprint, TDD, XP，MSF
Scrum/Sprint：
第一步: 找出完成产品需要做的事情 – Product Backlog, Backlog 翻译成“积压的工作”, “待解决的问题”, “产品订单”都可以。
第二步: 决定当前的冲刺需要解决的事情 – Sprint Backlog。
第三步: 冲刺 (Sprint).。 在冲刺阶段, 外部人士不能直接打扰团队成员。 一切对交流只能通过SCRUM MASTER 来完成。 这一措施较好地平衡了 “交流”和 “集中注意力”的矛盾。 有任何需求的改变都留待冲刺结束后再讨论。
第四步: 得到软件的一个增量版本，然后在此基础上又进一步计划增量的新功能和改进。
TDD：即测试驱动开发，TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
XP：即极限开发，适用于软件需求模糊且挥发性强、开发团队人数在十人以下、开发地点集中的场合。XP方法强调交流的价值，通过交流，既可以向项目的相关人员传递信息，又可以从他们那里获得信息。
MSF：即Microsoft Solution Framework，也就是微软推荐的做软件的方法。
MSF有8个基本原则：
（1）推动信息共享与沟通（Foster open communications）。所有信息都保留，并公开，讨论要包括所有涉及的角色，决定要公开，并告知所有人。当然，对牵涉到技术机密、安全性等信息要采取必要的保护措施。
（2）为共同的远景而工作（Work toward a shared vision）。考虑产品的未来，面向更多的客户。
（3）充分授权和信任（Empower team members）。存在一定的风险，但信任必不可少。
（4）各司其职，对项目共同负责（Establish clear accountability and shared responsibility）。责任明确，每个人分工明确。
（5）重视商业价值（Focus on delivering business value）。要搞清楚我们的项目会解决什么问题，为谁解决问题，为什么它会解决问题，以及怎样才能拿到客户的报酬。
（6）保持敏捷，预期变化（Stay agile, expect change）。及时应对内外发生的变化。
（7）投资质量（Invest in quality）。重视质量。
（8）学习所有的经验（Learn from all experiences）。MSF在每一个里程碑结束时都要做一个“里程碑回顾”，这个回顾不必等到整个项目结束才做。这样做的好处是，大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。另外，一些好的做法可以及时得到总结和推广。
以后我还会接着把这本书看完，难的有这么一本有趣的书。
612
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
