构建之法第七,第十七章读书有感

第四章 两人合作

  关于合作中算法的使用

   在第四章的叙述中,我们看到了代码的编写规范,代码的命名规范,我们还知道要写注释,要有良好的代码设计和错误处理。而这些都是我们在使用语言进行编辑中的问题。我们要阅读结队队友的代码,了解功能实现,明确函数意义。之后还要进行代码复审。

   但是我们同时也知道,在代码实现的过程中,我们的分工是有侧重的。而同一个事情的完成是可以使用一些成型或自己的算法进行优化的。而如果我们在使用一个比较“复杂”(是指思想复杂而实现简单,例如dp,kmp,manacher算法等)的思想和算法时,这些算法可以大大优化代码的效率和质量。但是同时,这些代码会对队友阅读代码造成一定的难度。在长期的合作中会需要解释很多的代码思想。而有些比较难理解的东西可能会耗费队友很多的时间。这是长期训练算法和专精开发的人之间各有所长的一点。但是此时问题就出现了。

   我们是否应该使用队友难以理解的算法对程序进行优化?如果使用了,是应该每次讲解给队友还是只说明算法功能?如果只说明功能,代码复审的时候是不是就又要一个人完成?如果因为麻烦而拒绝优化,是不是有违软件开发的思想理念 ,不能制作更优秀的程序服务大家?

   在提出这个问题时,我已经先考虑了使结对对象完全了解算法的可能。因为身边一开始确实有很多在做算法的人,慢慢的又因为太难而放弃了,所以这个问题不是臆测而是通过实际情况而提出的。那么在我们先假定这个情况为既定事实的情况下,去考虑解决的办法。

   结合提到过的单元测试的思路,已经书上本章讲到,一个模块只专注完成一件事并且做好。那么我的解决方法是,注释所有函数步骤的作用,参数调用和意义。然后两个人对这些函数单元进行统一测试,共同调试。而算法的使用者需要保证算法的正确性。要不然即便每个模块正确组合起来也没有用。

   写在后面:我的结对搭档很好,对算法也很有兴趣。这些只是我在阅读过程中结合日常实际情况所提出的一点想法,并不是抱怨和吐槽,也愿意和大家讨论,为之后的实际开发做好预警和铺垫。

第十四章  质量保障

  在软件质量保障工作的分工过程中,应该做到统一调配还是合作分工?

   在书中多次提及软件质量保障(QA)和软件测试(Testing)。而且也论述了测试的角色是否应该被独立出来。问题四种也提到了“画地为牢的分工”。

   在阅读了这么多的内容之后,我大概了解了,质量保障是一个,多阶段、多人合作,共同完成的一个事情。而在这个目标完成的过程中,不同的角色有不同的任务。那么这些任务是由一个boss专门指派,专人专项的负责呢?还是说由团队中的人进行讨论,认领工作分工,然后各自完成各自的项目。

   前者由boss专门指派,可以很好的统一调度,考虑到每个人的特长专精已经能力差异,以任务式的方式去让各自完成。成体较为协调有力,但是可能不符合个人意愿,主动性较差。而对于后者,团队讨论认领分工可能会出现调度不均,考虑不周的情况。但是主动性强,对自我的认识更周到,但是也会因为团队的个人偏向性而漏掉某一部分的内容。相较之下两者兼顾可能是比较理想的状态。

   我也针对这部分内容去百度和一些公司的网站上进行了查阅,但是并没有一个很明确的结果。可能在自己的实际行动中会去试验一下到底哪种会比较有效。

End

原文地址:https://www.cnblogs.com/ShadowGhostH/p/8684686.html

时间: 2024-10-08 22:06:35

构建之法第七,第十七章读书有感的相关文章

《构建之法》第四&十七章读书笔记

 <构建之法>第四&十七章读书笔记 一.         前言 再次阅读<构建之法>,愈发被其中生动有趣的举例吸引.作为一本给予软件工程学生的书籍,其不以枯燥的理论知识为核心,而是基于对知识和方法的引导.本次研读的这两章内容主要涉及了代码规范,两人结对与多人合作的团队方面等相关知识,从其中逐渐明白与人相处作业等方面的技巧与艺术.以下是我对这两章节的思考与疑惑. 二.        第四章<两人合作>. 本章主要涉及代码规范,极限编程,结对编程,两人合作不同阶段,

《构建之法》第4.17章读书笔记

<构建之法>第4.17章读书笔记 第四章 原文语句: 异常不能跨过DLL或进程的边界来传递信息,所以异常不是万能的. 提出问题: 1.什么是DLL?DLL是来解决什么问题的? 网上说法: DLL是Dynamic Link Library的缩写,意为动态链接库.在Windows中,许多应用程序并不是一个完整的可执行文件,它们被分割成一些相对独立的动态链接库,即DLL文件,放置于系统中.当我们执行某一个程序时,相应的DLL文件就会被调用.一个应用程序可有多个DLL文件,一个DLL文件也可能被几个应

读构建之法第四、十七章有感(作业四)

第四章: 问题: 看到这里的时候,才注意到代码中的"下划线"这个东西,在之前的敲代码过程中并没有怎么遇到下划线,在经过百度后得到了一些答案: 这只是Python中下划线的一部分应用,在不同的语言中,下划线的用处也不太相同,而在原文中作者对下划线的解释很简单,对于"下划线用来分隔变量名字中的作用域标注和变量的语义"这句话也不太理解,我认为作者可以适当地放一些代码片段来说明下划线的用法,如果作者提及下划线的原因仅仅是因为命名的话,我觉得完全可以放在下划线的上一小节&qu

构建之法第七章学习心得

这周我学习了构建之法第七章MSF的介绍.MSF有9个基本原则,针对信息共享,团队内部运营,市场,还有客户.同样是强调效率,人性,灵活,还有前景. MSF对信息共享和沟通十分强调,对团队内部运营强调相互信任,各司其职.MSF敏捷开发模式分为两支,MSF敏捷开发模式和MSF CMMI开发模式.都是很人性,灵活,以及对自身有高要求的模式.结合上一章的敏捷流程和这次学习的MSF,在我看来相对比较迅捷,给人一种少了很严肃气愤的方法,个人还是比较喜欢.MSF的最大特性是商业化,并一直体现在项目的实施过程中.

0502,读《构建之法》第6~7章有感

<构建之法>第6和7章讲的是敏捷流程和MSF.大概了解了一些关于敏捷流程和MSF的一些基本概念.敏捷流程是一系列价值观和方法论的集合.敏捷流程同MSF同有着自己的基本原则. 先来说一说“敏捷流程”吧. 敏捷开发原则有12点,针对客户需求,市场竞争,软件自身的更新完善,还有就是开发团队自身以及开发团队和业务人员的关系.原则本身强调的是效率,人性,以及灵活.我个人感觉这套原则挺不错的. 敏捷流程分出了四步,Product Backlog,Sprint Backlog,Sprint,改进更新.就像名

《构建之法》之第一二三章读后感

读<构建之法>这本书就像读故事书那样,耐人寻味,又很多故事和经验都是源自作者本身,读起来很有趣,并不会像其他书那样的枯燥乏味. 这本书的第一章——概论,为我们解释什么是软件,什么是软件工程,读完这章对这些概念有一定的认识这章让我明白,代码不能盲目的敲,好的软件并非两三天内就能赶出来的.在编写程序之前,需要做一系列的分析.设计,要满足客户的需求,后续还要对软件进行测试.维护等.在这之前,我一直觉得能把程序运行,能有正确的结果,那就完成任务了,可这只是整个软件流程的一部分而已. 问题:目前软件工程

构建之法 第七次心得

构建之法14.15章总结 第14章 这一章讲的是质量保障.在我们做软件的时候,最重要的是质量,如果做成功的软件质量不过关,那无疑是白费心血,浪费时间.程序的质量体现在软件外在功能的质量,用户体验的质量,国际化的质量,安全性的质量等等. 软件开发过程中有三个主要的特性:好.快.便宜,即软件需要在成本.功能.时间三方面满足利益相关者的需求.一个团队可以靠很多方法来提高程序的质量,比如交付前不断测试,修改,也可以在软件发布之后再一直进行修复问题,但是软件工程的质量需要长期的过程来提高. 软件工程的质量

浅谈对《构建之法——现代软件工程》第一章的理解

---恢复内容开始--- 一.精读第一章后对专业术语的整理 <构建之法——现代软件工程>一书第一章向我们主要介绍了计算机科学的领域.软件工程与计算机科学的关系.软件的特性以及软件工程的定义与组成部分. 1.通过对第一章的学习,我们了解到了软件的 几种分类: 系统软件:操作系统.设备驱动程序.工具软件等 应用软件:办公软件.通信软件.游戏视频软件等 恶意软件:软件病毒等 以及软件的几种特殊性:1.负责性:2.不可见性:3.易变性:4.服从性:5.非连续性: 2.软件工程与计算机科学的关系 首先,

第四章与第十七章阅读有感

第四章 两人合作 此章主要讲了两人合作中的主要注意事项,最主要的是代码规范与代码复审 我的困惑也主要来自这两个地方 代码规范方面: ①P61缩进问题,本书提倡用空格而不提倡用tab键.但是我个人在编写代码时,工作室学长有提醒我最好用tab键.他向我展示了空格与tab键两种编写代码方式,其中明显tab键更加美观和清晰.本书解释的不要用tab键的原因是tab键在不同情况下会显示不同的长度.但在团队中大家使用的编译器应该是同一个,tab键的缺陷其实在团队作业中并不明显.那么在这种情况下应该选择大家认为