关键词：
第四章 两人合作
关于合作中算法的使用
在第四章的叙述中，我们看到了代码的编写规范，代码的命名规范，我们还知道要写注释，要有良好的代码设计和错误处理。而这些都是我们在使用语言进行编辑中的问题。我们要阅读结队队友的代码，了解功能实现，明确函数意义。之后还要进行代码复审。
但是我们同时也知道，在代码实现的过程中，我们的分工是有侧重的。而同一个事情的完成是可以使用一些成型或自己的算法进行优化的。而如果我们在使用一个比较“复杂”（是指思想复杂而实现简单，例如dp，kmp，manacher算法等）的思想和算法时，这些算法可以大大优化代码的效率和质量。但是同时，这些代码会对队友阅读代码造成一定的难度。在长期的合作中会需要解释很多的代码思想。而有些比较难理解的东西可能会耗费队友很多的时间。这是长期训练算法和专精开发的人之间各有所长的一点。但是此时问题就出现了。
我们是否应该使用队友难以理解的算法对程序进行优化？如果使用了，是应该每次讲解给队友还是只说明算法功能？如果只说明功能，代码复审的时候是不是就又要一个人完成？如果因为麻烦而拒绝优化，是不是有违软件开发的思想理念 ，不能制作更优秀的程序服务大家？
在提出这个问题时，我已经先考虑了使结对对象完全了解算法的可能。因为身边一开始确实有很多在做算法的人，慢慢的又因为太难而放弃了，所以这个问题不是臆测而是通过实际情况而提出的。那么在我们先假定这个情况为既定事实的情况下，去考虑解决的办法。
结合提到过的单元测试的思路，已经书上本章讲到，一个模块只专注完成一件事并且做好。那么我的解决方法是，注释所有函数步骤的作用，参数调用和意义。然后两个人对这些函数单元进行统一测试，共同调试。而算法的使用者需要保证算法的正确性。要不然即便每个模块正确组合起来也没有用。
写在后面：我的结对搭档很好，对算法也很有兴趣。这些只是我在阅读过程中结合日常实际情况所提出的一点想法，并不是抱怨和吐槽，也愿意和大家讨论，为之后的实际开发做好预警和铺垫。
第十四章 质量保障
在软件质量保障工作的分工过程中，应该做到统一调配还是合作分工？
在书中多次提及软件质量保障（QA）和软件测试（Testing）。而且也论述了测试的角色是否应该被独立出来。问题四种也提到了“画地为牢的分工”。
在阅读了这么多的内容之后，我大概了解了，质量保障是一个，多阶段、多人合作，共同完成的一个事情。而在这个目标完成的过程中，不同的角色有不同的任务。那么这些任务是由一个boss专门指派，专人专项的负责呢？还是说由团队中的人进行讨论，认领工作分工，然后各自完成各自的项目。
前者由boss专门指派，可以很好的统一调度，考虑到每个人的特长专精已经能力差异，以任务式的方式去让各自完成。成体较为协调有力，但是可能不符合个人意愿，主动性较差。而对于后者，团队讨论认领分工可能会出现调度不均，考虑不周的情况。但是主动性强，对自我的认识更周到，但是也会因为团队的个人偏向性而漏掉某一部分的内容。相较之下两者兼顾可能是比较理想的状态。
我也针对这部分内容去百度和一些公司的网站上进行了查阅，但是并没有一个很明确的结果。可能在自己的实际行动中会去试验一下到底哪种会比较有效。
End
读《构建之法》第十七章有感
&n 查看详情
《构建之法》（第十七章）读书笔记(代码片段)
一、关于代码规范1.1因为软件开发多数是一个团队的事情，所以需要格外注意代码规范。我们的代码日后通常是需要去维护的，是需要去给别人看的。但是，不同的编程语言对代码规范的要求是否相同呢？因为在工作室学的是前... 查看详情
读《构建之法》第四章第十七章有感
书是我们永远的朋友它陪伴我们走过人生的春夏秋冬在我们的生命中生根、发芽、枝繁叶茂书是人类发展的录像机我们可以在其中看到前辈的足迹 书是知识的海洋我愿是一叶轻舟，载着理想之帆在海面上荡漾它蕴含着祖祖辈... 查看详情
读构建之法第四章第十七章有感
第四章 1、原文；“函数最好有单一的出口，为了达到这个目的，可以使用goto.只要有助于程序逻辑的清晰体现，什么方法都可以使用。——P69” 问题：关于goto，我记得老师讲过，这个在编程中是尽力避免的，所以我在之... 查看详情
读《构建之法》第四章第十七章有感
第四章 问题1：程序各方面的质量只取决于水平较高的程序员么？ 引用：在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。 结对编程在我看来是一种合... 查看详情
《构建之法》第四&十七章读书笔记
《构建之法》第四&十七章读书笔记一． 前言 再次阅读《构建之法》，愈发被其中生动有趣的举例吸引。作为一本给予软件工程学生的书籍，其不以枯燥的理论知... 查看详情
读《构建之法》第四，十七章有感
第四章：我看到这样一段文字：反对解体阶段：好不容易找到合适自己的编程伙伴，并且磨合了这么久，为啥在完美解决一个问题之后就要走向解散，各找舞伴？那样岂不是走了弯路？那么我们在学校没做完一个结对项目，就要... 查看详情
《构建之法》读第十七章收获(代码片段)
《构建之法》读第四、十七章收获第四章两人合作读了第四章，我才意识到代码规范的重要性，代码不仅要自己看懂，也要能让别人看懂，代码规范能使团队合作更好的进行。代码规范分为代码风格规范和代码设计规范。其中代... 查看详情
《构建之法》——第第十七章
第四章，主要内容为讲述两个程序员（从作者大篇幅讲述代码规范等内容来看…应该是把大部分阅读此章的读者看作基础的程序员了）如何合作。这章我在看完之后分了两个板块：“代码交流”与“合作交流”。“代码交流... 查看详情
读《构建之法》第四章第十七章
第四章 两人合作 通过对于《构建之法》第四章的阅读使我对代码规范、代码复审、以及结对编程有了更加深刻的认识，所谓代码规范可以分为两个部分，代码风格规范和代码设计规范，代码风格规范的原则是：... 查看详情
阅读《构建之法》第四章第十七章收获
阅读《构建之法》第四章、第十七章阅读这一章的时候，我意识到了很多以前写程序没有注意到的地方，以前写程序就只知道能运行就好，根本不管自己写的程序占多少内存，运行的时间，是否有优化的空间，写代码的时候也不... 查看详情
构建之法第四章第十七章
一、关于goto函数：滥用goto语句会使程序变得很难理解，而不是所有人能正确的使用goto函数，我的问题是：是不是因为这样所以很多文档规定禁用或少用goto函数？但其实如果可以正确的使用goto语句就不能说程序结构坏了？所以... 查看详情
《构建之法》第第十七章读后感(代码片段)
第四章 在这一章最后一页“让独占一样还有一个好处：一眼就能看出是否有多余的代码行，还有些情况下是致命的错误”给出的参考链接http://lpar.ath0.com/2014/02/23/learning-from-apples-goto-fail/，我还是没明白的致命错误在... 查看详情
关于《构建之法》第四章和第十七章的问题(代码片段)
关于《构建之法》第四章和第十七章的问题第四章：问题一：在关于“缩进”，书中不提倡用tab键。而建议使用四个空格。但是tab键可设置占符数，在实际开发中，tab键是缩进的快捷键，我无法想像每次使用缩进都要敲四次空格... 查看详情
读《构建之法》第四章第十七章(代码片段)
第四章《两人合作》1.原文：“注释（包括所有源代码）应该只用ASCLL字符，不要使用中文和其他字符，否则会极大影响程序的可植性”疑问：引擎根本不对空行和注释进行解析，直接忽略掉，它们不参与计算代码行数也不参与... 查看详情
我读《构建之法》十七章
这几天我都在读《构建之法》第四章和第十七章，看的比较缓慢也比较认真。根据精读的要求和个人看书的习惯，我总共读了三遍，第一遍是大致浏览了一遍内容，第二遍是静下心来圈画、标注疑惑内... 查看详情
《构建之法》第四章第十七章读后感
第四章问题：如果另一个合作者不合作的话，我是应该选择脱离这个团队还是去催他工作？ 本章讲了许多关于结对编程的内容，文中写了结对编程的分工问题，结对过程中会出现的问题以及结对合作的不同阶段。 正常来... 查看详情
谈谈我对构建之法第四章与第十七章的理解
第四章：两人合作 问题一： 引用：“对于至关重要的代码，我们要请不止一个人来做代码复审” 理解：我对于这句话有些疑问甚至有些反驳。首先我觉得每一段代码都是应该被重视的，也许对于一个刚... 查看详情