构建之法 阅读笔记02

Posted 2023-04-18 syhxx

第四章 两人合作

4.1 代码规范

包括代码风格规范和代码设计规范

4.2 代码风格规范

代码风格原则：简明、易读、无二异性

缩进：4个空格，而不是TAB

行宽：限定为100字符

括号

断行与空白的行

分行

命名：匈牙利命名法

下划线：分隔变量名字中的作用域标注和变量语义

大小写（Pascal形式和Camel形式）

注释

4.3 代码设计规范

函数：只做一件事，并且要做好

goto：有助于程序逻辑的清晰体现

错误处理：参数处理、断言

类的处理

4.4 代码复审

①形式：自我复审、同伴复审、团队复审

②目的：找出代码错误、发现逻辑错误、发现算法错误、发现潜在的错误和回归性错误、发现可能需要改进的地方、传授经验

③代码复审后把记录整理出来：

（1）更正明显的错误

（2）记录无法很快更正的错误

（3）把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步

4.5 结对编程

①角色：

驾驶员：控制键盘输入

领航员：起到领航、提醒的作用

②好处：（1）在开发层次，可以提供更好的设计质量和代码质量，两人合作解决问题的能力更强。

（2）对开发人员，带来更多的信心，高质量的产出带来更高的满足感。

（3）企业管理层次上，有效地交流，相互学习和传递经验，分享知识，取得更高的投入产出比。

 

第五章 团队和流程

5.2 软件团队的模式

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

5.3 开发流程

①写了再改模式

②瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

瀑布模型的适用范围：产品的定义非常稳定但正确性非常重要、产品模块之间的接口能很好地定性定义和验证、使用的技术很成熟、子团队不能做到频繁的交流。

③瀑布模型的变形：生鱼片模型（各个相邻模块像生鱼片那样部分重叠）以及大瀑布带着小瀑布（各个子系统统一到最后进行系统测试）

5.4 统一流程RUP

统一流程Rational Unified Process，团队的各种成员在一个复杂的软件项目中的不同阶段做不同的事。这些不同类型的工作在RUP中叫做规程或者工作流。简介：

业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理。

分为四个阶段：初始阶段（达到生命周期目标里程碑）、细化阶段（达到生命周期结构里程碑）、构造阶段（达到初始功能里程碑）、交付阶段（达到产品发布里程碑）

 

第六章 敏捷流程

6.1 敏捷的流程

①敏捷开发原则：

（1）尽早并持续地交付有价值的软件以满足顾客需求

（2）敏捷流程欢迎需求的变化，并利用这些变化来提高用户的竞争优势

（3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短

（4）业务人员和开发人员在项目开发过程中应该每天共同工作

（5）以有进取心的人为项目核心，充分支持信任他们

（6）无论团队内外，面对面的交流始终是最有效的沟通方式

（7）可用的软件是衡量项目进展的主要指标

（8）敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去

（9）只有不断关注技术和设计，才能越来越敏捷

（10）保持简明——尽可能简化工作量的技艺

（11）只有能自我管理的团队才能创造优秀的架构、需求和设计

（12）时时总结如何提高团队效率并付诸行动

②敏捷流程概述：找出完成产品需要做的事情→决定当前的冲刺（Sprint）需要解决的事情→冲刺（冲刺期间每天开每日例会）→得到软件的一个增量版本并发布

6.3 敏捷的团队

自主管理：自己挑选任务、自己提出改进并实施改进

自我组织：每个人联合起来对项目负责

多功能型：每个人都全面负责，自己搞定规格说明书，和别人沟通，自己搞定测试

6.4 敏捷总结

在迭代开始时，团队审视摆在他们面前的任务，选择他们认为可以在迭代期间完成的那些任务（Plan）。然后团队独立地尽最大努力完成这些任务（Do）。在迭代结束时，团队给利益关系人展示成果（Check），并对开发流程进行调整（Act/Adjust）。

这里有一些实践者的经验教训：

（1）敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。

（2）Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。

（3）一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。

（4）在复杂的项目里，要让一线团队成员做决定。

（5）创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫论证自己到底有多么Scrum）。

（6）在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。

（7）不要和管理层谈“流程”，他们只关心“结果”。

（8）在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点.

 

总结

之后在合作完成项目时，要更加注意自己的代码格式，方便其他人阅读，进行统一的测试，容易发现并更改错误。

团队合作时需要多沟通，对每个人的情况做出了解，分析如何进行项目设计。

构建之法阅读笔记03

                                   构建之法阅读笔记03

           ——结对编程

     随着这几周（其实也就两周……）老师开展的有关“结对编程”的项目工作，加上我和组员孔同学的合作，我对于上几周老师讲的书中的问题有了进一步深层次的理解。

     结对编程技术是指两位程序员坐在同一工作台前开发软件。与两位程序员各自独立工作相比，结对编程能编写出质量更高的代码。它是一个非常简单和直观的概念，能达到事半功倍的工作效果。但是，人与人之间的合作不是一件简单的事情——尤其当人们都早已习惯了独自工作的时候。实施结对编程技术将给软件项目的开发工作带来好处，只是这些好处必须经过缜密的思考和计划才能真正体现出来。在结对编程中最重要的是要找到合适自己的伙伴，老师在上课时提醒我们，最好不要找自己同宿舍的小伙伴或者是多年的老朋友甚至是自己的男女朋友，否则会因为分歧导致感情分崩离析。起初我们不懂啊，因为毕竟大学三年也有过不少的合作项目，节课大作业什么的，那个时候我们基本上都是宿舍小伙伴一块儿。我的合作伙伴孔同学虽然不是我的室友，但是我们也是老朋友了。虽然我们在合作的工程中虽然没有发生什么大的分歧，当然，讨论和意见不统一在所难免，我们对于这个结对编程的意义理解的更深刻了。下面是我的几点浅谈~~

      首先，关于伙伴的选择。《构建之法》书中写到“结对开发是程序员肩并肩、平等地、互补地进行开发工作……”“结对编程不是程序开发者独到的发明，生活中也有不少这样的例子……”因此我们不要再内心排斥结对项目，认为什么自己一个人习惯了之类的，我们首先要在心里认可同伴的地位，做到平等的开发。我个人觉得什么朋友室友都不重要，我们应该选择与自己水平相差不太远的做伙伴就好，不一定非要强求比自己强有着”抱大腿“的想法。这样我们无论是在分析、测试、编码、集成、写文档等方面都会达到事半功倍的效果。

     其次，关于结对小团体中的个人。书中讲到，在结对编程中每一段代码都不是’你的代码‘或者’我的代码‘，而是’我们的代码‘。既然代码的责任不是个人的而是团体的，我们应该避免产生“英雄主义”或是“撇清关系”的状态。我们要相互督促、更加认真的工作。提高自己的个人技术能力，以免被别人小看。现在的我们毕竟还是身处学校这个大环境中，各项任务其实是有老师护航什么的，但是以后在单位中，我们的逞强、不听他人的建议、事不关己高高挂起、推卸责任、个人能力差拖别人后腿…这些都可能导致我们被团队除名，后果很严重。

     最后，就是有关成员之间的“反馈”。我们既然是合作开发项目，每个人的水平和看问题的角度都不禁相同，因此我们肯定或多或少的会产生分歧。最开始我们都希望能够通过商谈解决问题，但是有可能大家情绪都比较激动，最后就一发不可收拾了。书中像我们介绍了三个层次的反馈：最外层，行为和后果；中间层，习惯和动机；最内层，本质和固有属性。我们在提出意见时尽量不要伤人，先做好铺垫，强调对方的优点，然后应该不带有任何情绪的提出问题和改进的方法，最后呼应开头鼓励对方把工作做好。以前我们在争论中经常会用到“你赶快写啊怎么这么费劲”“还能不能好好干活了”“那你说咋办吧”“我不会我不管了”这种含有情绪的话，这样我们不但会影响团队的效率还会给自己给同伴带来满满的负能量。

    学习《构建之法》之后，加之我们实际进行的结对编程开发，我逐渐领会在程序员的世界里合作的“游戏规则”，相信我们以后都能带这这些好习惯很快的融入公司！！